NetSUS on CentOS 7

bmarks
Contributor II

Can anyone using the NetSUS product verify if it works on CentOS 7? I have been struggling with this for a while now, and I finally got it set up and running to the point that I could test a NetBoot image only to discover that none of my Macs will NetBoot from it. The icon is there in the Boot Picker but it seems to fail instantly, and by "instantly" I mean I don't see the small spinning globe even for a fraction of a second, just straight to normal boot. A previous-gen Ubuntu-based version of the NetSUS product worked without issue, so I'm pretty sure it's not related to my network. I even gave the new one the same IP to remove variables. I don't know if logs will help, but here is what happens when I click on the NetBoot image in the Boot Picker. With that said, I am at a point where I am wondering if this even works at all on CentOS 7, so if there's anyone out there that can verify this (or not) please let me know because that will determine how much (if any more) troubleshooting I perform:

DHCPREQUEST for 10.126.97.224 from 00:3e:e1:c2:39:ee via 10.126.96.1: unknown lease 10.126.97.224.
2016-08-30T22:06:13.181422+00:00 caspershare-pdx dhcpd: DHCPINFORM from 10.126.96.97 via 10.126.96.1
2016-08-30T22:06:13.181596+00:00 caspershare-pdx dhcpd: JAMF-DHCP change
2016-08-30T22:06:13.181885+00:00 caspershare-pdx dhcpd: N Key or encapsulated
2016-08-30T22:06:13.182044+00:00 caspershare-pdx dhcpd: 68
2016-08-30T22:06:13.182180+00:00 caspershare-pdx dhcpd: DHCPACK to 10.126.96.97 (b8:ca:3a:b9:35:d0) via eth0
10 REPLIES 10

itupshot
Contributor II

@bmarks It's supposed to work on CentOS 7, but with some tweaks. Please see this post, as it may help you: [https://jamfnation.jamfsoftware.com/discussion.html?id=20033#responseChild123600](link URL)

Frankly, it seems like there are quite a few issues with NetSUS 4.1.0. I haven't been able to get it to sync all updates from Apple, and I also can't get NetBoot to work on CentOS 6.8. See the discussions at: [https://jamfnation.jamfsoftware.com/viewProduct.html?id=180&view=discussions](link URL)

I agree with you that the previous version (4.0) working on Ubuntu Server 14.04.x was much more reliable. However, our production servers are CentOS, so I've been trying to get it to work on it without much success.

crmeade
New Contributor III

I had this exact issue and I found that with RHEL 7, the NetSUS installer doesn't seem to configure the tftp server correctly. I had to modify /lib/systemd/system/tftp.service to actually start tftp with the correct directory, specifically the line

ExecStart=/usr/sbin/in.tftpd -s /srv/NetBoot/NetBootSP0

I'm not 100% sure this was the trick since I was having to do troubleshooting with NetSUS in other areas.

bmarks
Contributor II

@crmeade I'm not at the office right now so I can't test this, but if I look at "/lib/systemd/system/tftp.service" it looks like this:

[Unit]
Description=Tftp Server
Requires=tftp.socket
Documentation=man:in.tftpd

[Service]
ExecStart=/usr/sbin/in.tftpd -s /var/lib/tftpboot
StandardInput=socket

[Install]
Also=tftp.socket

So, in theory, I should be able to fix this by changing "/var/lib/tftboot" to "/srv/NetBoot/NetBootSP0" and then it will work, correct?

crmeade
New Contributor III

@bmarks I'm fairly certain that was our issue. I would see the DHCPACK's as expected and then no other activity. Looking through the tftp logs showed that the /var/lib/tftpboot being the default directory caused the clients to not be able to see the nbi and thus fail to boot instantly.

bmarks
Contributor II

Hmmm. So I changed that path, and restarted the service (and rebooted the VM eventually) but no change. One thing I noticed is that if I type telnet x.x.x.x 69 (i.e. the port for tftp) I get immediately rejected. However, there is no firewall nor any other restrictions on this VM. I can see most other expected ports are open with telnet. Maybe tftp doesn't work this way?

bmarks
Contributor II

I figured it out.

http://www.bo-yang.net/2015/08/31/centos7-install-tftp-server

More specifically, these commands to check and modify the SELinux TFTP status:

getsebool -a | grep tftp

On mine, the results were:

tftp_anon_write --> **off**
tftp_home_dir --> **off**

So I turned them these on with the following commands:

setsebool -P tftp_anon_write 1
setsebool -P tftp_home_dir 1

And my results are now:

tftp_anon_write --> **on**
tftp_home_dir --> **on**

Afterwards, I immediately was able to NetBoot. As a side note, I was able to ignore the yum commands in step 1. I already had TFT and I didn't need XINETD. Your environment may vary.

MikeF
Contributor II

I just set up a new server yesterday, When you pick a minimum install you need to also run these 2 commands

sudo yum install xinetd
sudo service tftp restart

Should work fine after this. I ran these before the install in the netsus and all worked properly for me

bmarks
Contributor II

With a minimal install, this info in this thread may not be relevant. Does SELinux come at all as part of the minimal install? SELinux appears to be the root of most peoples' issues I believe and many of the workarounds you'll find here and on the Github project site are related to it as well.

andyinindy
Contributor II

OK, so I ran into this issue as well with NetSUS 4.1.0 and the culprit in my case ended up being iptables. The NetSUS installer created the following config:

[root@myserver NetBootSP0]# /etc/init.d/iptables status
Table: filter
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination         
1    ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:67 
2    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:548 
3    DROP       udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:69 
4    ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:69 

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

Notice the DROP rule for udp traffic on port 69 (tftp). Um, WTF? This basically tells the server to drop all traffic on that port. Disabling iptables with /etc/init.d/iptables stop allowed a client to use tftp to get the booter file in testing and netboot properly, so I restarted iptables and deleted the DROP entry with iptables -D INPUT 3. Clients are now able to netboot with iptables enabled.

Why the heck is the NetSUS installer making this change to iptables? So bizarre. Anyway, one more thing to check in your config.

Cheers,

--Andy

itupshot
Contributor II

Does anyone know if xinetd package is required to be installed in the computer for TFTP to work?

@bmarks said that he didn't need xinetd in his environment.

The setup I'm testing against is CentOS 7 (1611), "Server with GUI." It doesn't seem to have xinetd installed by default.