Posted on 09-10-2015 09:06 AM
One of our xserves died. We were using it to netboot. We have a second one that is still working but I am curious what everyone else uses for diskless netbooting. Since the xserve is no longer available what would you consider an enterprise level solution for netbooting?
Posted on 09-10-2015 09:16 AM
https://bitbucket.org/bruienne/bsdpy
Do a search on this site for other discussions related to it.
Posted on 09-10-2015 09:28 AM
JAMF NetBoot/NetSUS VM Appliance
Super easy to set up within a few minutes.
Posted on 09-10-2015 09:29 AM
You can use JAMF's NetBoot/SUS appliance. But last time I checked, that could only host a single NetBoot image. So if you need two, that won't work. The other option is to get a Mac mini and rack mount it.
Posted on 09-10-2015 09:35 AM
Look also at Docker as part of the larger Linux bsdpy solution – it's able to host multiple NBIs and works quite well.
Posted on 09-10-2015 09:44 AM
+1 for Docker. Last place I worked, I moved us off the NetSUS appliance to a custom Linux image running BSDPy, Reposed, and a JDS - each in their own Docker containers. Made management and updating really easy, and deploying a new site was as easy as uploading a VM Template and updating a few config files.
Posted on 09-10-2015 09:51 AM
The Mini, especially with an SSD, is a plenty capable little machine for serving NetBoot.
I've considered the Docker + BSDPy setup a few times, but ultimately I've never run into evidence that the Mini wasn't keeping up with demand. To be fair, I don't do multicast ASR across labs of machines at once or anything, but a couple dozen simultaneous netboots have never caused my any trouble.
Posted on 09-10-2015 09:58 AM
I use an iMac for Netboot. Build 'em with AutoCasperNBI.
Posted on 09-10-2015 12:19 PM
I use Mac Pro's... Mostly because we want plenty of overhead for high speed imaging for ~50 units at a time. And yes... AutoCasperNBI is so easy I've stopped manually building NBIs all together
Posted on 09-14-2015 07:29 PM
@Chris_Hafner Question when you are using AutoCasperNBI to create the netboot.nbi for new model machines coming with Yosemite where are you getting the base Yosemite .dmg from ? I have tried multiple times to create a new .nbi for the new retina and airs with updated track pad and it just loops back to the black apple 1st time log in and doesn't reach the netboot server. I am currently using a mac mini for this and i have older working .nbi's but cant image the new items.
Posted on 09-14-2015 07:36 PM
Posted on 09-15-2015 03:03 AM
For netbooting I am about to use CentOS 7 minimal in the company.
Here are the three links that you will need for setting this up on a CentOS 7 minimal install:
https://themacwrangler.wordpress.com/2015/04/24/creating-a-netboot-server-with-centos-7-and-bsdpy/comment-page-1/#comment-113
https://macmule.com/projects/autocaspernbi/
http://www.projectatomic.io/blog/2015/06/notes-on-fedora-centos-and-docker-storage-drivers/
So from those links you should derive the following:-
AutoDMG
Basically, use AutoDMG application to create a never booted DMG of the latest OS X with Updates.
AutoCasperNBI
Start up AutoCasperNBI application and use at least the following settings:
Tick “Will be served from NetSUS or BSDPy".
And make sure to tick “Install modified rc.netboot file".
Start-up your CentOS 7 Minimal system
$ yum -y update
$ systemctl stop firewalld && systemctl disable firewalld
$ sed -i -e 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config
$ reboot
$ yum -y install vim docker
$ systemctl start docker
$ systemctl enable docker
$ systemctl restart docker
$ docker pull hunty1/bsdpydocker
$ rm -rf /var/lib/docker/
$ vim /etc/sysconfig/docker-storage
And amend to the following:
DOCKER_STORAGE_OPTIONS= -s overlay
$ systemctl restart docker
run “docker info” to verify that Storage Driver is now called overlay.
$ mkdir /nbi
$docker run --restart=always -d -v /nbi:/nbi -p 69:69/udp -p 67:67/udp -p 80:80 -e BSDPY_IP=Your_CentOS7_IPAddress --name netboot_server hunty1/bsdpydocker
Verify that docker container is running “docker ps -a". Look at docker logs for container: “docker logs -f netboot_server".
$ yum -y install samba samba-client
$ useradd smmbuser
Set the password for smbuser
$ smbpasswd -a smbuser
$ useradd smbuser
$ smbpasswd -a smbuser
$ mv /etc/samba/smb.conf /etc/samba/smb.conf.backup
$ vim /etc/samba/smb.conf
[global]
workgroup = MYGROUP
server string = Samba Server Version %v
log file = /var/log/samba/log.%m
max log size = 50
security = user
passdb backend = tdbsam
local master = no
create mask = 0744
force create mode = 0744
directory mask = 0755
force directory mode =0755
inherit permissions = yes
[nbi]
path = /nbi
available = yes
read only = no
browseable = yes
public = no
writable = yes
$ systemctl start smb
$ systemctl start nmb
$ systemctl enable smb
$ systemctl enable nmb
$ chown smbuser /nbi
Now copy the netboot image set to /nbi that you created with AutoCasperNBI by dropping it into the smb share that you have just created.
$ docker restart netboot_server
Verify the docker container picked up the /nbi by running “docker logs netboot_server", you should see something like:
09/09/2015 04:15:47 PM - DEBUG: [========= Using the following boot images =========]
09/09/2015 04:15:47 PM - DEBUG: /nbi/10.10.5AutoCasperNBI.nbi
Now netboot a MacBook (or on a Mac just use Startup Disk utility to the netboot image being presented).
Posted on 09-16-2015 06:58 AM
Posted on 09-16-2015 01:04 PM
Oh, and just for fun, I made a small time lapse of our student imaging process (utilizing a single OS X Netboot server). I had intended to get the entire process but I mis calculated the battery requirements of such an endeavor. So, instead of all 365 students being imaged over a 7 hour period (with breaks) this only shows ~80 units being netbooted and imaged over a much slower 1.25 hours. However, there are up to 40 netbooted at once in the video. The YouTube description givers a better idea of the specifics of the setup. This is a fully manual Casper Imaging you're seeing and NOT a pre-stage for various reasons. I'll only say that it SHOULD have been pre-staged but a last min network failure caused me to need to physically bring DPs into the imaging area
YouTube link:
BA Student Imaging