Centralized Netboot/SUS?

Contributor III

Hi everyone,

I am working on a plan to implement Netboot/SUS servers across 5-10 sites in our environment, and a coworker asked me if the NetSUS could be a single application server with multiple distribution points (like the JSS/DPs).

In this scenario there would one NetSUS that downloads the patches from Apple and talks to the clients. We'd then use our internal file replication to get those updates to remote sites. When a client talks to the NetSUS, any patches it needs would be pulled from the local copy. My initial thought was "No this wouldn't work" but I thought I'd ask the NetSUS/Reposado experts....is this possible? If not, is it best practice to just manage a NetSUS at each site individually?



@Josh.Smith hey Josh i guess my first question is why don't you use cache server? Also, with help from your network Team you can use a IP table basically the router will forward all requests for SUS to your "internal". Basically if theres 5-10 sites id assume you'd be on the same Network so that could work some work but YES can be done.

Contributor III

Thanks for you your response @MAD0oM

why don't you use cache server?

My company is trying to eliminate Macs from the datacenter. The server guys would much prefer a RHEL VM running NetSUS to a Mac Mini in the data center.

Also, with help from your network Team you can use a IP table basically the router will forward all requests for SUS to your "internal". Basically if theres 5-10 sites id assume you'd be on the same Network so that could work some work but YES can be done.

I'm having trouble understanding your point here. I'd like to know if it is possible to separate the SUS app from the content.

Valued Contributor

People have definitely implemented cascading Apple Software Update servers using Reposado, though I have had no need to do so myself. You might search the archives of the Reposado mailing list (http://groups.google.com/group/reposado) or post a question there.

New Contributor


We had the same question and stumbled upon this:


Contributor III

+1 on Sean's method linked above. Have used it for quite a few multi site environments.

Also I would suggest installing Reposado from the source, rather than the NetSUS. NetSUS seems to have butchered Reposado a little bit (lots). For a GUI slap Margarita on the 'Master' https://github.com/jessepeterson/margarita

Contributor III

Thanks for the feedback everyone, I'll read up on the supplied links.

@calumhunter I think I am starting to see what you mean about NetSUS. Do you know of any alternative Netboot options that can run on RHEL? I setup NetSUS on CentOS and was pretty disappointed, but I'll keep playing with it. Maybe I'll rethink the Mac Mini option too if NetSUS doesn't meet our needs.

Valued Contributor II

There are links out there, you should be able to setup netboot on any linux flavor you like. I have netboot running on CentOS6 and 7 just fine. SeLinux, tftp, dhcpd and xinetd are all very important parts to get working properly. First Problem was I was so exhausted after getting it all to work, I never really documented a concise answer. second problem I might be lazy, or busy or something.
Here are some of the links I used to get it all working:
unix netboot
convert ASCII to HEX
Plus you will need to learn about the firewall and selinux with google searches as well. for instance when adding a new image run chcon -R -t tftpdir_rw_t /path/to/Library/NetBoot/NetBootSP0/<NEWIMAGENAME>.nbi/

Here is the relevant section of my dhcpd.conf file that does the netboot stuff I tried to comment it as much as possible to make it maintainable. of course you need your server

class "Apple-Intel-Netboot" { match if substring (option vendor-class-identifier, 0, 14) = "AAPLBSDPC/i386"; option dhcp-parameter-request-list 1,3,17,43,60; if (option dhcp-message-type = 1) { option vendor-class-identifier "AAPLBSDPC/i386"; option vendor-encapsulated-options 08:04:01:00:B4:8E; log(info,"BSDP_SELECT_type1-default fell through on choices"); filename "NB-10.9.3.nbi/i386/booter"; next-server; option root-path = "nfs:"; } if (option dhcp-message-type = 😎 { option vendor-class-identifier "AAPLBSDPC"; if (substring(option vendor-encapsulated-options, 0, 3) = 01:01:01) { log(info, "BSDP_LIST"); option vendor-encapsulated-options 01:01:01: # Start BSDP Inform/List Option 1 (01:), Length 1 (01:), Message Type List(1) (01:) 03:04: # BSDP option code 3 (length 04) -- Server Identifier 01:01:01:01: # Server IP (, Dec->Hex 04:02: # BSDP option code 4 (length 02) -- Server Priority 80:00: # Priority (32768) Dec->Hex 07:04: # BSDP option code 7 (length 04) -- Default Image ID 01:00:B4:8C: # Image ID - (46221) Dec->Hex 09: # BSDP option code 9 -- Boot image list 1C: # Length - =5<numofimages><sumofallimagenames>, eg =52(10+9) =29, Dec->Hex =1C Sum of all imagenames if the name is NB-10.10.3 that is 01:00:B4:8C: # Image ID - (46220) Dec->Hex 0A:4e:42:2d:31:30:2e:31:30:2e:33: # ascii-hex 10:NB-10.10.3 http://www.dolcevie.com/js/converter.html 01:00:B4:8E: # Image ID - (46222) Dec->Hex 09:4e:42:2d:31:30:2e:39:2e:33; # ascii-hex 9:NB-10.9.3 # when adding a new image run chcon -R -t tftpdir_rw_t /path/to/Library/NetBoot/NetBootSP0/<NEWIMAGENAME>.nbi/ # have to add a new elsif clause below for new image as well } elsif (substring(option vendor-encapsulated-options, 0, 3) = 01:01:02) { log(info, "BSDP_SELECT"); if (substring(option vendor-encapsulated-options, 9, 4) = C0:A8:C7:0F) { log(info, "BSDP_SELECT-Responding, Client is talking to us."); if (substring(option vendor-encapsulated-options, 15, 4) = 01:00:B4:8C) { log(info, "BSDP_SELECT-Image: 46220:NB-10.10.3"); filename "NB-10.10.3.nbi/i386/booter"; next-server; option root-path = "nfs:"; } elsif (substring(option vendor-encapsulated-options, 15, 4) = 01:00:B4:8E) { log(info, "BSDP_SELECT-Image: 46221:Base-10.9.3"); filename "NB-10.9.3.nbi/i386/booter"; next-server; option root-path = "nfs:"; } elsif (substring(option vendor-encapsulated-options, 15, 4) = 01:00:00:8A) { log(info, "BSDP_SELECT-Image: DSR-NB01012012-05122012"); filename "NB-10.10.3.nbi/i386/booter"; option root-path = "nfs:"; next-server; } else { log(info,"BSDP_SELECT-ERROR: Client responded with an image we don't have a match for! -- (Image added to list, but not in select catch?)"); filename "NB-10.9.3.nbi/i386/booter"; option root-path = "nfs:"; next-server; } } else { log(info,"BSDP_SELECT-Ignoring, Client is talking to another server--We're not worthy!"); } } } }

hope that helps

Valued Contributor

"Do you know of any alternative Netboot options that can run on RHEL?"

BSDPy: https://bitbucket.org/bruienne/bsdpy


@gregneagle is bsdpy now considered stabe? Last time I played with it (about 1.5 years ago) it was still a bit experimental.

Valued Contributor

1.5 years is long time! Ask bruienne yourself, but pretty sure University of Michigan has been using it in production for a while.

I think it's more stable/useful/functional than the NetBoot part of NetSUS at any rate.

New Contributor II

Hi there!

BSDPy is close to being released as a 1.0 version after some last community-contributed PRs are merged and a few remaining minor issues closed. As of right now though the API branch has been very stable for us and is being used in our production environment. I would recommend checking out the Docker image if you want to get a test environment setup quickly. Various folks have written up the process of standing up BSDPy, TFTP and HTTP with Docker - I'd recommend this recent writeup by Graham Gilbert.

Let me know if you have any questions in the mean time.

Contributor III

We're using BSDPy in production here.. will be over 2k netboot servers pretty soon

+1 on the blog post by Graham Gilbert. If you need something more step by step from the beginning. I've also got a post about it here. CentOS7 + Docker + BSDPy

Mine differs a little bit as I bundle up the HTTP, TFTP and BSDPy into a single container as it makes for a simpler deployment for me.

If you go down the Docker path, then getting Reposado and Margarita running becomes very easy as there are already docker containers available for both of those.


Re: resposado cascading, it works perfectly. Just point your slave servers at your master.

You can also fork updates with margarita on the master, then just point your slaves at the master fork URLs. repo_sync ... good times.

Honored Contributor

@calumhunter Am I reading that right or is that a typo? 2k as in 2,000 netboot servers? Any particular reason or do you have that many offices? Must be quite interesting working in such a large environment.

Contributor III

@bpavlov No typo. We have that many sites.

Interesting is one way of putting it 😉