Posted on 08-30-2016 03:22 PM
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
Posted on 08-30-2016 03:49 PM
@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.
Posted on 08-30-2016 05:25 PM
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.
Posted on 08-30-2016 05:50 PM
@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?
Posted on 08-30-2016 06:15 PM
@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.
Posted on 08-31-2016 12:19 PM
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?
Posted on 08-31-2016 12:36 PM
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.
Posted on 09-01-2016 06:48 AM
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
Posted on 09-01-2016 09:57 AM
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.
Posted on 01-09-2017 02:37 PM
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
Posted on 04-28-2017 09:40 AM
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.