The current 14.04 build has been tested on:

• Optiplex - 745, 755, 760, 780, 790, 7010
• Precision - T5500, T7500, T5600, T7600, T5610*, T7610*, T5810*, T7810*, T7910*
  • *RAID controllers seem to change frequently, which adds more time to testing.

Basic steps…

• Register the system as ususal in NETDB, with the RST-PXE DHCP option.
  
• Boot the system…if there are two onboard network adapters, disable the second adapter in BIOS.
  
• Boot from the NIC to connect to our IPXE server.
  
• Boot the Foreman Discovery Image.
  
• Use Foreman to configure the build, add packages, add local users, add local admins.
  
• Foreman will reboot once, apply the build, install packages and in around an hour or so it should be finished ready to login.
  

1. Unbox the system and look for the barcode label printed by Asset Management. This code is a copy of the system's serial number and needs to be placed in an easy-to-find location, usually on top of the system's case, near the manufacturers own label.
2. Boot the system into its BIOS, usually with F12, on most of the modern Dell hardware.
3. Under the BIOS > Drives settings, disable the 'Floppy Disk' if there is not one present - this is personal preference.
4. Under the BIOS > Integrated Devices, find the network adapters and enable the primary adapter for PXE.
5. Under the BIOS > Virtualization settings, make sure the options are checked. These have typically came checked from Dell, but it is good to review. Without these options checked, the instruction set of the processor can not understand 64-bit virtual hosts.

Now, if this system is one of the T7610 or T7910 Precision workstations, they come with dual onboard NICs. In the BIOS, under Integrated Devices, disable the secondary NIC. When there are two NICs present, our build scripts attempt to use the first NIC, eth0/em1 to PXE, then tries to use eth1/em2 to build from. It's confusing and troublesome, thus we just disable the secondary NIC. If for some reason, the user needs the second NIC, its easy enough to re-enable in BIOS, then add to the systems registration after the build is complete.

1. Register the system to the correct owner/group just like any other system in our mst-users domain. .managed.mst.edu
2. 
3. Under the NetDB options, set the DHCP option to PXE-RST
4. Add the proper location and description to the system. This is important as it saves some legwork when determining what system someone called in a request about.
5. In the Admin comments section, add Ubuntu 14.04 Workstation. Since we can search the fields in NetDB, we use this field for tracking systems to some extent.
6. 

1. Reboot the system and hit F12 for the Boot Menu
2. Once it goes through the POST sequence, select the Onboard NIC.
3. Based on the correct DHCP option in NetDB, this will then boot to our iPXE server.

• iPXE boot screen

• ITRSS iPXE Menu
• Select Foreman Discovery Image

• Foreman/Puppet is a similar setup to our current Template Generator For Windows 7.
• Effectively, Foreman is configured to name the system, auto-assign it to the .managed.mst.edu domain, provides an interface of adding software packages we have built, add machine admins, add SSH users and it provides an interval based monitoring system where we can see what is online, updated, out-of-sequence, being built–all in real-time.

While the Discovery Image is loading, open a browser and go to https://rssinst.srv.mst.edu/

• Accept the security certificate if prompted. * When iPXE boots, and you select the Discovery Image, it will appear to be doing something. It is pulling our discovery image down and prepping the system to be 'discovered' by Foreman.

As the image boots, when it gets to the point where you see what is in the yellow box, the system has sent the requests back to the Foreman server. This may take a minute or so.

We have hostname based provisioning configured, however if you are using a custom host name you may be required to use the steps below regarding discovered hosts. You will know this to be the case if the host doesn't automatically reboot after a few seconds of displaying the portion in the yellow box.

Back on the Foreman website, click on the Hosts > Discovered Hosts menu.

Click on the mac############ link

Clicking on the mac############ link will go to the Provision page.
Provisioning is what Foreman does to configure the system to build and this page is a summary of what Foreman knows about the system as this point.
Click the blue Provision button to continue.

When provisioning, the first tab you will see is the Host tab.

Here, enter the name of the system. .managed.mst.edu is not needed as it will auto-populate.
Under the Host Group, select Workstation. As you can see, we have a few options available.

• These are different, pre-configured options to tell Foreman what to install, based on the need of the system.
  
• Most of what we do are Workstations, with a few VMware-Workstations.

Next, click on the Puppet Classes tab.

Basically, the Puppet Classes are the packages we have created for Foreman to install.
Similar to our template generator, where we select the software we want to install, the classes operate in a similar manner.

When you expand the wk_pkgs (workstation packages), selecting the + sign next to the package name, adds that package to the build list.

Once the correct packages are added, visit the Network tab.

• Everything here is auto-populated. There should not be anything that needs to be entered, however, being Foreman's connection to the systems is based on IP address, there is always that chance where, during a reboot, the system picked up another IP address. When this happens, you will need to ping the system name, take its new IP address and insert that new address into the IP address field. This has only happened a couple of times.

After the Network tab is the Operating System tab. In a larger setting, where multiple operating systems are supported, this is the summary page telling the installer what will be used.
Everything here is set be default.

• Our Ubuntu workstation build is about 10GB in size.
• We usually make virtual machines in the 50GB+ range, to accommodate for user data or other software packages like Ansys or Matlab.
  

After the OS tab, comes the Parameters Tab.

Again, options here are set as default, but we can add localadmins and localusers. Admins allows SSH access and 'sudo' access. Users are just SSH capable.
Add Privileges to Users on Campus Ubuntu

On the Additional Information tab, this lists the machine owner, or really the installer that built the system.
The Hardware Model is just that, desktop models, precision models, VMware, Virtualbox, etc.
The Comments section can contain details about the build, its purpose, specific non-campus software, or other special considerations.

Now that each tab has been seen and updated, the configuration is ready.
Click the blue Submit button when ready to start the build.

You will see it being the preseed installation, much like a non-gui install of linux.

Now, at the end of the magenta install screens, there will come a point where you will see this.

This screen is somewhat deceiving. The build is still going and will probably run for about an hour, depending on your connection speed. On real hardware, you will see the hard drive activity light constantly flashing during the build. When it is complete, the activity will slow down, you will see a login screen, and you can check the All Hosts page in Foreman and if it has a green O (for online) the system is built.

When the build is complete you should see this:

At this point, the system is ready to be logged into.

There are more finer points to the build, like the S drive, printers and adding other software from the Ubuntu repos or elsewhere.
Those tutorials are in process.

Adding supported software titles to an existing installation is as easy as editing the host in foreman, visit https://rssinst.srv.mst.edu, sign in, and go to the hosts tab and search for the host you would like to change.

Then click the Puppet Classes tab and wk_pkgs, the plus button adds the package to the machine and it should begin installing inside 30 minutes of being added to the system.

Sometimes Foreman will not flush it's dns entries of systems that have long since changed IP addresses and the system you are trying to build will grab an IP that the Foreman server thinks is someone else. This causes a dns reverse lookup error to occur, to resolve the conflict we have to remove the offending IP from the reverse lookup table and restart the dns service on rssinst. Here's how you do that:

ssh rssinst.srv.mst.edu
sudo -i
cd /var/cache/bind/zones
vi db.151.131.in-addr.arpa

In this file IP addresses are broken down by octet in reverse order, see picture:

For example, if you're looking for IP 131.151.53.112, you'll search for the header 53.151.131.in-addr.arpa and under that will be an entry for 112 and a hostname Foreman thinks is associated with that IP. Just delete that line. Please note (I don't really think you're going to do this, but CYA and all that) don't actually delete 53.112 unless that's actually the machine you're having issues with, please search for the proper 3rd and 4th octets and delete the line that is the IP of the machine actually giving you issues.

Now save the file and go out to the system and restart the bind service.

service bind9 restart

Then retry your build attempt.