PXE: Not Just for Server Networks Anymore!
Listing 1. Example pxelinux.cfg/default file
default 1 serial 0,9600n8 timeout 300 prompt 1 DISPLAY pxemenu.msg F1 pxemenu.msg LABEL 1 KERNEL vmlinuz APPEND ro initrd=initrd.img quiet splash LABEL 2 KERNEL unat APPEND initrd=unatin.img z_user=guest z_password=guest ↪z_path=//192.168.1.20/install
Now, when I booted a PXE client, I got a choice as to whether to go to the Ubuntu LTSP session or the Unattended install. At this point, I tested the Unattended installation, and it sort of worked—it installed a base Windows system just fine, but it didn't install any of the drivers, nor any of the patches to the operating system. I realized just how spoiled I am by Ubuntu's driver coverage and update manager, but I slogged ahead and continued to work to refine the system so that the driver and update installation happened without my intervention.
It turns out I didn't have to re-invent the wheel, as the driver issue and the update issue both have been addressed by the Unattended team. As far as the driver stuff goes, there is a method to integrate DriverPacks (which are large compressed archives of drivers) into the Unattended system. It's a little bit too involved for the scope of this article, but see the DriverPack link in the Resources section for more information.
With respect to automatic update installation, the method the Unattended folks use is very Linux-like in its resourcefulness. Under the Unattended root path, there are two directories: the /install/scripts and /install/tools directories. The scripts directory contains Windows batch files (.bat) that are used to do automated installation of various software packages, as well as some basic updates. The tools directory contains a set of scripts that will look at your Unattended server's current configuration and scripts directory, and then compare it to the CVS tree maintained by the Unattended team. The scripts then will grab the latest .bat files and drop them in the correct place in the scripts directory. At that point, the next Windows install that's done with the Unattended system will get all the patches and install them automagically. The system even will reboot at the appropriate times, then pick up the next patch in the series and install it. To update the Unattended system's patch repository, it's as simple as running a ./script-update; ./check; ./prepare from the /install/tools directory under the Unattended root.
The CVS archive of scripts, as well as the script archive on the wiki, proved to be invaluable. Those resources allowed me to finish the complete automation of my install, and now, I have a configuration that meets my company's needs for Windows. After about 30 seconds of typing the machine-specific information at the beginning of the installation, I now can walk away and know that Windows, Office, the Cisco VPN client, Symantec Anti-Virus and many other things my Windows users need will be done my way, automagically, without requiring myself or another staff member to babysit it.
In closing, thanks to the efforts of the Ubuntu and LTSP teams, I now have an environment that lets my users do some kind of work, even when their systems may have some kind of issue. And, thanks to the Unattended team, I don't have to sit at a Windows machine physically to install it, nor do I have to mess with half-baked images or other strange packaging solutions. I'm already getting other ideas on how to extend this system even further.
“PXE Magic: Flexible Network Booting with Menus” by Kyle Rankin (April 2008 issue of LJ): www.linuxjournal.com/article/9963
Ubuntu Wiki—LTSP Installation: https://help.ubuntu.com/community/UbuntuLTSP/LTSPQuickInstall
Active Directory Authentication in Ubuntu 8.04 and 8.10: anothersysadmin.wordpress.com/2008/04/06/howto-active-directory-authentication-in-ubuntu-804
Unattended: a Windows Deployment System: unattended.sourceforge.net
Unattended Step-by-Step Instructions: unattended.sourceforge.net/step-by-step.php
Unattended Wiki: ubertechnique.com/unattended/FrontPage
Using DriverPacks with Unattended: ubertechnique.com/unattended/BTS_Driver_Packs
Unattended Script Archive: ubertechnique.com/unattended/Scripts
Bill Childers is an IT Manager in Silicon Valley, where he lives with his wife and two children. He enjoys Linux far too much, and probably should get more sun from time to time. In his spare time, he does work with the Gilroy Garlic Festival, but he does not smell like garlic.
Bill Childers is the Virtual Editor for Linux Journal. No one really knows what that means.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide