Configuring the HTTP and DHCP Daemons

NOTE If you are unfamiliar with VI please check Appendix A for the commands and a brief tutorial. The VI editor is very powerful and so there is a slight learning curve for beginners.

Using VI, or a text editor, you need to change the httpd.conf file and add a section to the WebDAV module to look like this:

# WebDAV module configuration section.

# Location of the WebDAV lock database.

DAVLockDB /var/lib/dav/lockdb

</IfModule>

Dav On

</Directory>

DAV stands for Distributed Authoring and Versioning and enables the file system provider under the HTTP daemon. This will be used in the advanced ZTP processes when you utilize Network Director to build the DHCP configuration and push the images and configurations using the GUI.

Ensure That Root is a Member of the Group Apache

The technical editors for this Day One book wanted to provide more information in response to the query: Why do you have to make root a member of the Apache group? If you have the same question, here’s some reasoning.

If you look in the preceding output from ls –al you will see that root is the group and owner of the files in the /etc/httpd/conf directory, and if you look at the following ls –al output for the /var/www directory, the owner is root as well. The next step after adding root as a member of the group apache, however, is to change the group and owner of /var/

www/html to apache. Once the group and owner is changed to that directory, you still want root to have access to make any necessary changes to those files, without changing the group and owner, and /var/

www/html is where the web pages and files and images are served from.

So, the reason you are changing the file owner and group is to provide security. You don’t want to serve up anything from a web server with the file that is owned as root. It could be exploited. The Apache user can serve web pages with just read permissions and keep all the files separated from the root directory:

[root@localhost conf]# usermod -G apache root [root@localhost conf]# more /etc/group | grep apache apache:x:48:root

And let’s change the owner of the HTML directory to apache:

[root@localhost conf]# cd /var/www/

[root@localhost www]# ls -al total 24

drwxr-xr-x. 6 root root 4096 Oct 10 12:09 .;;;;

drwxr-xr-x. 21 root root 4096 Oct 10 12:09 ..

drwxr-xr-x. 2 root root 4096 Aug 24 12:53 cgi-bin drwxr-xr-x. 3 root root 4096 Oct 10 12:09 error drwxr-xr-x. 2 root root 4096 Aug 24 12:53 html drwxr-xr-x. 3 root root 4096 Oct 10 12:09 icons

You can see that the HTML directory is owned by root in this last output. Now, let’s do a recursive change owner (chown) to change the directory and all the files residing under that directory to reflect apache as owner and group:

[root@localhost www]# chown -R apache:apache html/

[root@localhost www]# ls -al total 24

drwxr-xr-x. 6 root root 4096 Oct 10 12:09 . drwxr-xr-x. 21 root root 4096 Oct 10 12:09 ..

drwxr-xr-x. 2 root root 4096 Aug 24 12:53 cgi-bin drwxr-xr-x. 3 root root 4096 Oct 10 12:09 error drwxr-xr-x. 2 apache apache 4096 Aug 24 12:53 html drwxr-xr-x. 3 root root 4096 Oct 10 12:09 icons

Open the TCP Port 80 on the IPTABLE:

[root@localhost www]# iptables -I INPUT -i eth0 -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT

NOTE A common mistake is to add a space character between NEW and ESTABLISHED. But the format seen above is correct: NEW,ESTABLISHED. If this is not entered correctly the rule will not be added to the IPTABLE and the ZTP request, for the image and configuration, will fail:

[root@localhost www]# iptables -L Chain INPUT (policy ACCEPT)

target prot opt source destination

ACCEPT tcp -- anywhere anywhere tcp dpt:http state NEW,ESTABLISHED ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED

ACCEPT icmp -- anywhere anywhere ACCEPT all -- anywhere anywhere

ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh

REJECT all -- anywhere anywhere reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT)

target prot opt source destination

REJECT all -- anywhere anywhere reject-with icmp-host-prohibited Chain OUTPUT (policy ACCEPT)

target prot opt source destination

Let’s confirm our web server status.

You will need a configuration to load on the device. Here the curl

command is used to load an EX2200-C configuration for this demon- stration. The reason curl is used is because the Junos Space server uses

curl to upload the files and images. By using curl now you are ensuring that the functionality exists for an advanced ZTP configuration.

Otherwise, if you just wanted to use SFTP, or SCP, those protocols would work as well.

First, you want to place the configurations and the Junos OS images on the web server in the /var/www/html directory:

sreisinger$ curl -u ztpuser -T CAN1.config http://192.168.2.252

Enter host password for user ‘ztpuser’:

<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>

<title>201 Created</title>

</head><body>

<h1>Created</h1>

<p>Resource /CAN1.config has been created.</p>

<hr />

<address>Apache/2.2.15 (CentOS) Server at 192.168.2.252 Port 80</address>

</body></html>

The same thing is required for the EX Series Junos OS image. The following Junos OS image was uploaded to the lab’s HTTP server using curl. The actual image requires a Juniper login.

NOTE The image used is a domestic U.S. image which has encryption embed- ded in the code. For those using this Day One book outside of the United States you need to utilize world wide code.

NOTE With a valid Juniper account you can pull the images from the Juniper Networks download page located at: https://www.juniper.net/support/

downloads/.

Now let’s copy the image(s) to the server:

sreisinger-mbp:Downloads sreisinger$ curl -u ztpuser -T jinstall-ex-2200-12.3R9.4- domestic-signed.tgz http://192.168.2.252

Enter host password for user ‘ztpuser’:

<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>

<title>201 Created</title>

</head><body>

<h1>Created</h1>

<p>Resource /jinstall-ex-2200-12.3R9.4-domestic-signed.tgz has been created.</p>

<hr />

<address>Apache/2.2.15 (CentOS) Server at 192.168.2.252 Port 80</address>

</body></html>

Check the /var/www/html directory on the server. You should now have two files:

[root@localhost html]# ls -al /var/www/html total 97344

drwxr-xr-x. 2 apache apache 4096 Oct 10 13:59 . drwxr-xr-x. 6 root root 4096 Oct 10 12:09 ..

-rw-r--r--. 1 apache apache 4267 Oct 10 12:51 CAN1.config

-rw-r--r--. 1 apache apache 99661037 Oct 10 13:59 jinstall-ex-2200-12.3R9.4-domestic- signed.tgz

Configure the DHCP Daemon

This section is the most important part of this book. It provides an explanation of why you need to take certain actions, as well as the commands to initiate them.

Understanding the DHCPD.CONF File

Now, let’s paste an example dhcpd.conf file and walk through what is what, and why, and then upload it to the server:

set vendor-string = option vendor-class-identifier; <<< This must be here

The vendor-class-identifier option in the DHCP configuration file tells the device to send its vendor information in the DHCP query. In the lab you want to use this vendor class to act on a specific type of device, or devices.

This next area is all boilerplate. The option space ZTPDEMO allows for grouping and action on other vendors’ sets of configurations. (If you state option space Blah then the other highlighted options need to be

BLAH.image, Blah.config, and so on:

option space ZTPDEMO;

option ZTPDEMO.image-file-name code 0 = text;

option ZTPDEMO.config-file-name code 1 = text;

option ZTPDEMO.image-file-type code 2 = text;

option ZTPDEMO.transfer-mode code 3 = text;

option ZTPDEMO-encapsulation code 43 = encapsulate ZTPDEMO;

option ZTPDEMO.image-file-type “symlink”;

The following defines the server holding the configuration for the device and should be customized to your lab setup:

option option-150 code 150 = ip-address;

The host statement is only relevant to this book’s lab, but should indicate what you are configuring:

host CAN1 {

The hardware address is the me0 interface’s MAC address. You get this by looking for the MAC on the chassis label. Then add HEX 3F to it if

using the me0 interface on an EX2200 or EX3300, add 1 for the default VLAN or IRB interface for all EX Series products (refer to Appendix D if you do not understand this):

hardware ethernet 78:fe:3d:e4:01:bf;

This is the address you are assigning to the EX switch’s me0.0 interface:

fixed-address 192.168.2.10;

And this is the hostname of the device:

option host-name “CAN1”;

The vendor class identifies the hardware and is sent in the BOOTP request, as you will see later. It’s important to get this right or it will not execute. It’s an additional check to the MAC address:

option vendor-class-identifier “Juniper-ex2200-c-12p-2g”;

option option-150 192.168.2.252;

option ZTPDEMO.transfer-mode “http”;

The option-150 statement tells the device where to go to fetch its configuration and image—remember the comment on the boilerplate section? The option ZTPDEMO.transfer-mode “http” statement tells the device that HTTP will be the transfer mode. You can change the transfer mode to FTP or TFTP, but the Day One lab uses HTTP because it is easy and it uses TCP port 80 to transfer the files.

And now let’s identify the configuration that belong to this EX Series switch:

option ZTPDEMO.config-file-name “CAN1.config”;

It’s very important to get the right configuration; you should have the MAC address, the IP address, and the vendor class. The device’s configuration file is going to be loaded on the device with the unique MAC address identified in this stanza.

Finally, the device will check the image that you are going to load on the device, and if it is already at this version level, no download will take place, but if this image is higher or lower, it will download the image from the server (identified by option-150) and then reboot. If you don’t need to change the image then comment this out or just leave it out of the configuration:

option ZTPDEMO.image-file-name “jinstall-ex-2200-12.3R9.4-domestic-signed.tgz”;

}

The last piece of the dhcpd.conf file is to configure DHCP to listen on a specific interface. In the Day One lab for this book there is only one interface on the 192.168.2.0/24 network. The following stanza goes under the host stanza:

subnet 192.168.2.0 netmask 255.255.255.0 { option domain-name-servers 8.8.8.8;

option routers 192.168.2.1;

default-lease-time 600;

max-lease-time 7200;

authoritative;

option ZTPDEMO.transfer-mode “http”;

pool {

range dynamic-bootp 192.168.2.10 192.168.2.19;

option OPTION-150 192.168.2.252;

option P61.config-file-name “default-ex2200-c-12p.config”;

} }

The subnet stanza will be used for devices that do not have a specific vendor ID, MAC address, or configuration in the host stanza. If the device falls through to this section it will be given an IP address in the range of 192.168.2.10 – 192.168.2.19. It will be given a DNS server of 8.8.8.8 and it will use HTTP as its transfer mode to pull up a default configuration.

MORE? The number and range of options to configure in this stanza are numerous. To identify all of the different options available for your customization please check out the following CentOS tutorial: https://

www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-dhcp-configuring-server.html.

That ends the brief tour to help facilitate your understanding of the DHCPD.CONF file. Now let’s run the one in the lab and examine it.

The Uncommented Version of the dhcpd.conf File

This example dhcpd.conf file uses the me0 interface so we added 3F to the chassis MAC-address to get 78:fe:3d:e4:01:bf for the lab. We could just as easily have added 1 to the chassis MAC address and plugged the cat-5 cable into any revenue port. Appendix D has a quick reference on how to obtain the MAC address for EX Series switches:

set vendor-string = option vendor-class-identifier;

option space ZTPDEMO;

option ZTPDEMO.image-file-name code 0 = text;

option ZTPDEMO.config-file-name code 1 = text;

option ZTPDEMO.image-file-type code 2 = text;

option ZTPDEMO.transfer-mode code 3 = text;

option ZTPDEMO-encapsulation code 43 = encapsulate ZTPDEMO;

option ZTPDEMO.image-file-type “symlink”;

option option-150 code 150 = ip-address;

host CAN1 {

hardware ethernet 78:fe:3d:e4:01:bf;

fixed-address 192.168.2.10;

option host-name “CAN1”;

option vendor-class-identifier “Juniper-ex2200-c-12p-2g”;

option option-150 192.168.2.252;

option ZTPDEMO.transfer-mode “http”;

option ZTPDEMO.config-file-name “CAN1.config”;

option ZTPDEMO.image-file-name “jinstall-ex-2200-12.3R9.4-domestic-signed.tgz”;

}

subnet 192.168.2.0 netmask 255.255.255.0 { option domain-name-servers 8.8.8.8;

option routers 192.168.2.1;

default-lease-time 600;

max-lease-time 7200;

authoritative;

option ZTPDEMO.transfer-mode “http”;

pool {

range dynamic-bootp 192.168.2.10 192.168.2.19;

option OPTION-150 192.168.2.2;

option P61.config-file-name “default-ex2200-c-12p.config”;

} }

Now place the dhcpd.conf file on the server using SCP:

sreisinger$ scp dhcpd.conf ztpuser@192.168.2.252:/home/ztpuser ztpuser@192.168.2.252’s password:

dhcpd.conf 100% 1115 1.1KB/s 00:00

[root@localhost ztpuser]# cd /etc/dhcp/

[root@localhost dhcp]# ls -al total 20

drwxr-x---. 3 root root 4096 Oct 10 12:07 . drwxr-xr-x. 99 root root 4096 Oct 10 12:42 ..

drwxr-xr-x. 2 root root 4096 Jul 24 02:50 dhclient.d -rw-r--r--. 1 root root 193 Jul 24 02:50 dhcpd6.conf -rw-r--r--. 1 root root 112 Jul 24 02:50 dhcpd.conf [root@localhost dhcp]# mv dhcpd.conf orig.dhcpd.conf [root@localhost dhcp]# ls -al /home/ztpuser/dhcpd*

-rw-r--r--. 1 ztpuser ztpuser 1115 Oct 10 15:02 /home/ztpuser/dhcpd.conf [root@localhost dhcp]# cp /home/ztpuser/dhcpd.conf .

[root@localhost dhcp]# ls -al total 24

drwxr-x---. 3 root root 4096 Oct 10 15:04 . drwxr-xr-x. 99 root root 4096 Oct 10 12:42 ..

drwxr-xr-x. 2 root root 4096 Jul 24 02:50 dhclient.d -rw-r--r--. 1 root root 193 Jul 24 02:50 dhcpd6.conf -rw-r--r--. 1 root root 1115 Oct 10 15:04 dhcpd.conf -rw-r--r--. 1 root root 112 Jul 24 02:50 orig.dhcpd.conf

NOTE If the DHCP daemon comes back with [failed] that indicates there is something wrong with the dhcpd.conf file. You can use $ tail –f /var/

log/messages to get more information on why the DHCP daemon will not start.

And let’s start the DHCP Server:

[root@localhost dhcp]# service dhcpd status dhcpd is stopped

[root@localhost dhcp]# service dhcpd start Starting dhcpd: [ OK ]

Typically, BOOTP uses UDP as its transport protocol. The well-known UDP port for a BOOTP client is 68 and for a BOOTP server is 67.

Now let’s open the IP tables for ports 67 and 68:

[root@localhost dhcp]# iptables -I INPUT 1 -i eth0 -p udp -m udp --dport 68 -j ACCEPT [root@localhost dhcp]# iptables -I INPUT 2 -i eth0 -p udp -m udp --dport 67 -j ACCEPT [root@localhost dhcp]# iptables -I INPUT 4 -i eth0 -p udp -m udp --dport 69 -j ACCEPT

[root@localhost dhcp]# iptables -I INPUT 3 -i eth0 -p tcp -m tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT

NOTE Once again, a common mistake is leaving a space between

NEW,ESTABLISHED on the TCP IPTABLE rules. If you leave a space it will complain and you will not be able to reach your server to pull the configuration or the image.

Once you have entered the IPTABLE rules you can list your changes using iptables –L (only as root or sudo) to see what rules are currently running:

MORE The sudo command is used in Linux platforms to elevate privileges for users such as a normal user wanting to have root privilege levels. The sudo access is obtained from the administrator (root) via adding the user to the sudoers file. This is accomplished by the root user running the $ visudo command and then adding those permissions to the appropriate section. For more information on using the sudo command please check out https://wiki.centos.org/TipsAndTricks/Becom- ingRoot :

[root@localhost dhcp]# iptables -L Chain INPUT (policy ACCEPT)

target prot opt source destination

ACCEPT udp -- anywhere anywhere udp dpt:bootpc ACCEPT udp -- anywhere anywhere udp dpt:bootps

ACCEPT tcp -- anywhere anywhere tcp dpt:http state NEW,ESTABLISHED ACCEPT udp -- anywhere anywhere udp dpt:tftp

Chain FORWARD (policy ACCEPT)

target prot opt source destination Chain OUTPUT (policy ACCEPT)

target prot opt source destination

After you have verified the rules are in the table, it’s a good idea to save this rule set so that if you reboot they will already be in place and you will not have to redo them to get things working:

[root@localhost ztpuser]# service iptables save

iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ]

Once you enter the save command it will give you your firewall rule location, such as /etc/sysconfig/iptables. Now you can move that file just to check, or use the iptables –L command:

[root@localhost ztpuser]# more /etc/sysconfig/iptables

# Generated by iptables-save v1.4.7 on Sun Oct 11 10:25:15 2015

*filter

:INPUT ACCEPT [0:0]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [426:87580]

-A INPUT -i eth0 -p udp -m udp --dport 67 -j ACCEPT -A INPUT -i eth0 -p udp -m udp --dport 68 -j ACCEPT

-A INPUT -i eth0 -p tcp -m tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT -A INPUT -i eth0 -p udp -m udp --dport 69 -j ACCEPT

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT

-A INPUT -i lo -j ACCEPT

-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited

-A FORWARD -j REJECT --reject-with icmp-host-prohibited COMMIT

# Completed on Sun Oct 11 10:25:15 2015

Monitor the DHCP/BOOTP Request

You want to monitor the traffic from the EX Series as it does its BOOTP request and then subsequently downloads the configuration and the jinstall file from the HTTP server.

NOTE For the sake of simplicity this book’s lab ran the DHCP and HTTP daemons on the same server, but they could be distributed to multiple HTTP servers for load balancing. You just have to identify the correct server in the option 150 field in the dhcpd.conf file.

To monitor the traffic, let’s use tcpdump on the server. It can be tricky at times, especially on a one-armed server like the one built so far for testing. Monitoring the interface itself will result in your SSH session scrolling across the screen. The following tcpdump command eliminates that port so you hopefully should get ports 67, 68, and 80, and only what you want to see:

[root@localhost html]# tcpdump -npi eth0 host 192.168.2.252 and not port 22 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes [root@localhost ztpuser]# tail -f /var/log/messages | grep dhcpd

Oct 18 08:09:01 localhost dhcpd: This version of ISC DHCP is based on the release available Oct 18 08:09:29 localhost dhcpd: Internet Systems Consortium DHCP Server 4.1.1-P1

Oct 18 08:09:31 localhost dhcpd: DHCPDISCOVER from 78:fe:3d:e4:01:bf via eth0

Oct 18 08:09:31 localhost dhcpd: DHCPOFFER on 192.168.2.10 to 78:fe:3d:e4:01:bf via eth0 Oct 18 08:09:31 localhost dhcpd: DHCPDISCOVER from 78:fe:3d:e4:01:81 via eth0: network 192.168.2.0/24: no free leases

Oct 18 08:09:31 localhost dhcpd: DHCPREQUEST for 192.168.2.10 (192.168.2.252) from 78:fe:3d:e4:01:bf via eth0

Oct 18 08:09:31 localhost dhcpd: DHCPACK on 192.168.2.10 to 78:fe:3d:e4:01:bf via eth0 Oct 18 08:09:35 localhost dhcpd: DHCPDISCOVER from 78:fe:3d:e4:01:81 via eth0: network

Okay! You and your setup are almost there. Let’s move on to something called ZTP.