Difference between pages "Keychain" and "PXE Network Windows Installation"

From Funtoo
(Difference between pages)
Jump to: navigation, search
(Setting up Authentication)
 
 
Line 1: Line 1:
== Introduction ==
+
''Howto use your Funtoo machine to serve a MS Windows installation over the network''
 +
In this guide we will assume that you have followed the [[PXE network boot server]] Wiki article and have a working network/pxe boot setup. As of now this guide will cover Windows XP. Soon it will be expanded to also cover Windows 7.
 +
==Prerequisites==
 +
#A working Funtoo installation
 +
#A working PXE Setup (DHCP, TFTP, PXELinux)
 +
#app-arch/cabextract
 +
#A legitimate copy of Microsoft Windows
 +
#Driver for your NIC - ''Suggested to use a complete driver pack with all major supported NIC hardware for the version of Windows to be installed.''
 +
#RIS Linux toolkit >=0.4
 +
#A working Samba server setup
  
<tt>Keychain</tt> helps you to manage ssh and GPG keys in a convenient and secure manner. It acts as a frontend to <tt>ssh-agent</tt> and <tt>ssh-add</tt>, but allows you to easily have one long running <tt>ssh-agent</tt> process per system, rather than the norm of one <tt>ssh-agent</tt> per login session.
+
== Creating the Windows XP Image ==
  
This dramatically reduces the number of times you need to enter your passphrase. With <tt>keychain</tt>, you only need to enter a passphrase once every time your local machine is rebooted. <tt>Keychain</tt> also makes it easy for remote cron jobs to securely &quot;hook in&quot; to a long running <tt>ssh-agent</tt> process, allowing your scripts to take advantage of key-based logins.
+
*In the previous guide, [http://www.funtoo.org/wiki/PXE_network_boot_server PXE Network Boot Server], we used /tftproot as the working directory so we will also use it in this guide for convenience. If you chose to use a different working directory then please apply it where needed in place of the /tftproot we will be going by here.
  
== Download and Resources ==
+
First you will need to create an ISO from your Windows XP installation disc. If you already have the ISO image you may skip this step.
  
The latest release of keychain is version <tt>2.7.1</tt>, and was released on May 7, 2010. The current version of keychain supports <tt>gpg-agent</tt> as well as <tt>ssh-agent</tt>.
+
<console>
 +
###i## dd if=/dev/sr0 of=/tftproot/winxp.iso
 +
</console>
 +
If your cdrom device isn't ''<code>/dev/sr0</code>'' please use the appropriate device in this command.
  
Keychain is compatible with many operating systems, including <tt>AIX</tt>, <tt>*BSD</tt>, <tt>Cygwin</tt>, <tt>MacOS X</tt>, <tt>Linux</tt>, <tt>HP/UX</tt>, <tt>Tru64 UNIX</tt>, <tt>IRIX</tt>, <tt>Solaris</tt> and <tt>GNU Hurd</tt>.
+
== Mount the ISO and Prepare Installation Sources ==
 +
Mount the image to ''<code>/tftproot/cdrom</code>'':
 +
<console>
 +
###i## mkdir /tftproot/cdrom; mount -o loop /tftproot/winxp.iso /tftproot/cdrom
 +
</console>
 +
Create the new directory for the network installation files and copy the needed files to it:
 +
<console>
 +
###i## mkdir /tftproot/winxp; cp -R /tftproot/cdrom/i386 /tftproot/winxp/i386
 +
</console>
 +
Depending on your CD/DVD copy of windows the directory name may be I386 as opposed to i386, if that is the case you will just need to change the first part of the command, keeping the new directory name i386 - this is going to be very important later on when creating the remap file!
 +
Check the contents of your newly created i386 directory to see if the filenames are in all CAPS or if they are already in lowercase.
 +
<console>
 +
###i## ls /tftproot/winxp/i386
 +
</console>
 +
If you happen to have all UPPERCASE filenames, lets go ahead and run a script to convert it to all lowercase:
 +
<console>
 +
###i## cd /tftproot/winxp/i386;ls | awk '$0!=tolower($0){printf "mv \"%s\" \"%s\"\n",$0,tolower($0)}' | sh
 +
</console>
  
=== Download ===
+
==Extracting and Modifying the Required Boot Files ==
 +
Install {{Package|app-arch/cabextract}}
 +
<console>
 +
###i## emerge -av app-arch/cabextract
 +
</console>
 +
Extract the prepackaged drivers:
 +
<console>
 +
###i## cd /tftproot/winxp/i386;cabextract driver.cab
 +
</console>
 +
Install support for a large list of network cards:
 +
<console>
 +
###i## cd /tftproot/;wget http://downloads.sourceforge.net/project/bootfloppy/pxefiles.tar.gz
 +
###i## tar zxvf pxefiles.tar.gz; cp pxefiles/drivers/* winxp/i386/
 +
</console>
 +
Copy the BINLSRV /INFParser tools to /tftproot:
 +
<console>
 +
###i## cp pxefiles/script/* /tftproot/
 +
</console>
 +
Extract the netboot startrom:
 +
<console>
 +
###i## cd /tftproot; cabextract winxp/i386/startrom.n1_
 +
</console>
 +
Fix the startrom for netbooting xp:
 +
<console>
 +
###i## sed -i -e 's/NTLDR/XPLDR/gi' startrom.n12
 +
###i## mv startrom.n12 winxp.0
 +
</console>
 +
Fix XPLDR:
 +
<console>
 +
###i## cabextract winxp/i386/setupldr.ex_
 +
###i## sed -i -e 's/winnt\.sif/winxp\.sif/gi' setupldr.exe
 +
###i## sed -i -e 's/ntdetect\.com/ntdetect\.wxp/gi' setupldr.exe
 +
###i## mv setupldr.exe xpldr
 +
###i## cp winxp/i386/ntdetect.com ntdetect.wxp
 +
</console>
  
* ''Release Archive''
+
== Creating a remapping file ==
** [http://www.funtoo.org/archive/keychain/keychain-2.7.1.tar.bz2 keychain 2.7.1]
+
Create the file ''<code>/tftproot/tftpd.remap</code>'' and add the following to it:
 
+
* ''Apple MacOS X Packages''
+
** [http://www.funtoo.org/archive/keychain/keychain-2.7.1-macosx.tar.gz keychain 2.7.1 MacOS X package]
+
 
+
 
+
Keychain development sources can be found in the [http://www.github.com/funtoo/keychain keychain git repository]. Please use the [http://groups.google.com/group/funtoo-dev funtoo-dev mailing list] and [irc://irc.freenode.net/funtoo #funtoo irc channel] for keychain support questions as well as bug reports.
+
 
+
== Quick Setup ==
+
 
+
=== Linux ===
+
 
+
To install under Gentoo or Funtoo Linux, type
+
 
<console>
 
<console>
###i## emerge keychain
+
###i## nano /tftproot/tftpd.remap
</console>. For other Linux distributions, use your distribution's package manager, or download and install using the source tarball above. Then generate RSA/DSA keys if necessary. The quick install docs assume you have a DSA key pair named <tt>id_dsa</tt> and <tt>id_dsa.pub</tt> in your <tt>~/.ssh/</tt> directory. Add the following to your <tt>~/.bash_profile</tt>:
+
ri ^[az]: # Remove “drive letters”
{{File
+
rg \\ / # Convert backslashes to slashes
|~/.bash_profile|<pre>
+
rg \# @ # Convert hash marks to @ signs
eval `keychain --eval --agents ssh id_rsa`
+
rg /../ /..no../ # Convert /../ to /..no../
</pre>}}
+
rg A a
If you want to take advantage of GPG functionality, ensure that GNU Privacy Guard is installed and omit the <tt>--agents ssh</tt> option above.
+
rg B b
 +
rg C c
 +
rg D d
 +
rg E e
 +
rg F f
 +
rg G g
 +
rg H h
 +
rg I i
 +
rg J j
 +
rg K k
 +
rg L l
 +
rg M m
 +
rg N n
 +
rg O o
 +
rg P p
 +
rg Q q
 +
rg R r
 +
rg S s
 +
rg T t
 +
rg U u
 +
rg V v
 +
rg W w
 +
rg X x
 +
rg Y y
 +
rg Z z
 +
r ^/(.*) \1
 +
r ^xpldr xpldr
 +
r ^ntdetect.wxp ntdetect.wxp
 +
r ^winxp.sif winxp.sif
 +
</console>
  
=== Apple MacOS X ===
+
==Install/Configure Samba ==
 
+
If you don't already have {{Package|net-fs/samba}} installed, then:
To install under MacOS X, install the MacOS X package for keychain. Assuming you have an <tt>id_dsa</tt> and <tt>id_dsa.pub</tt> key pair in your <tt>~/.ssh/</tt> directory, add the following to your <tt>~/.bash_profile</tt>:
+
 
+
{{File
+
|~/.bash_profile|<pre>
+
eval `keychain --eval --agents ssh --inherit any id_dsa`
+
</pre>}}
+
{{Note}}The <tt>--inherit any</tt> option above causes keychain to inherit any ssh key passphrases stored in your Apple MacOS Keychain. If you would prefer for this to not happen, then this option can be omitted.
+
 
+
== Background ==
+
 
+
You're probably familiar with <tt>ssh</tt>, which has become a secure replacement for the venerable <tt>telnet</tt> and <tt>rsh</tt> commands.
+
 
+
Typically, when one uses <tt>ssh</tt> to connect to a remote system, one supplies a secret passphrase to <tt>ssh</tt>, which is then passed in encrypted form over the network to the remote server. This passphrase is used by the remote <tt>sshd</tt> server to determine if you should be granted access to the system.
+
 
+
However, `OpenSSH` and nearly all other SSH clients and servers have the ability to perform another type of authentication, called asymmetric public key authentication, using the RSA or DSA authentication algorithms. They are very useful, but can also be complicated to use. <tt>keychain</tt> has been designed to make it easy to take advantage of the benefits of RSA and DSA authentication.
+
 
+
== Generating a Key Pair ==
+
 
+
To use RSA and DSA authentication, first you use a program called <tt>ssh-keygen</tt> (included with OpenSSH) to generate a ''key pair'' -- two small files. One of the files is the ''public key''. The other small file contains the ''private key''. <tt>ssh-keygen</tt> will ask you for a passphrase, and this passphrase will be used to encrypt your private key. You will need to supply this passphrase to use your private key. If you wanted to generate a DSA key pair, you would do this:
+
 
+
<console># ##i##ssh-keygen -t dsa
+
Generating public/private dsa key pair.</console>
+
You would then be prompted for a location to store your key pair. If you do not have one currently stored in <tt>~/.ssh</tt>, it is fine to accept the default location:
+
 
+
<console>Enter file in which to save the key (/root/.ssh/id_dsa): </console>
+
Then, you are prompted for a passphrase. This passphrase is used to encrypt the ''private key'' on disk, so even if it is stolen, it will be difficult for someone else to use it to successfully authenticate as you with any accounts that have been configured to recognize your public key.
+
 
+
Note that conversely, if you '''do not''' provide a passphrase for your private key file, then your private key file '''will not''' be encrypted. This means that if someone steals your private key file, ''they will have the full ability to authenticate with any remote accounts that are set up with your public key.''
+
 
+
Below, I have supplied a passphrase so that my private key file will be encrypted on disk:
+
 
+
<console>Enter passphrase (empty for no passphrase): ##i#########
+
Enter same passphrase again: ##i#########
+
Your identification has been saved in /var/tmp/id_dsa.
+
Your public key has been saved in /var/tmp/id_dsa.pub.
+
The key fingerprint is:
+
5c:13:ff:46:7d:b3:bf:0e:37:1e:5e:8c:7b:a3:88:f4 root@devbox-ve
+
The key's randomart image is:
+
+--[ DSA 1024]----+
+
|          .      |
+
|          o  . |
+
|          o . ..o|
+
|      . . . o  +|
+
|        S    o. |
+
|            . o.|
+
|        .  ..++|
+
|        . o . =o*|
+
|        . E .+*.|
+
+-----------------+</console>
+
 
+
== Setting up Authentication ==
+
 
+
Here's how you use these files to authenticate with a remote server. On the remote server, you would append the contents of your ''public key'' to the <tt>~.ssh/authorized_keys</tt> file, if such a file exists. If it doesn't exist, you can simply create a new <tt>authorized_keys</tt> file in the remote account's <tt>~/.ssh</tt> directory that contains the contents of your local <tt>id_dsa.pub</tt> file.
+
 
+
Then, if you weren't going to use <tt>keychain</tt>, you'd perform the following steps. On your local client, you would start a program called <tt>ssh-agent</tt>, which runs in the background. Then you would use a program called <tt>ssh-add</tt> to tell <tt>ssh-agent</tt> about your secret private key. Then, if you've set up your environment properly, the next time you run <tt>ssh</tt>, it will find <tt>ssh-agent</tt> running, grab the private key that you added to <tt>ssh-agent</tt> using <tt>ssh-add</tt>, and use this key to authenticate with the remote server.
+
 
+
Again, the steps in the previous paragraph is what you'd do if <tt>keychain</tt> wasn't around to help. If you are using <tt>keychain</tt>, and I hope you are, you would simply add the following line to your <tt>~/.bash_profile</tt> or if a regular user to<tt>~/.bashrc</tt> :
+
 
+
{{File
+
|~/.bash_profile|<pre>
+
eval `keychain --eval id_dsa`
+
</pre>}}
+
The next time you log in or source your <tt>~/.bash_profile</tt> or if you use <tt>~/.bashrc</tt>, <tt>keychain</tt> will start, start <tt>ssh-agent</tt> for you if it has not yet been started, use <tt>ssh-add</tt> to add your <tt>id_dsa</tt> private key file to <tt>ssh-agent</tt>, and set up your shell environment so that <tt>ssh</tt> will be able to find <tt>ssh-agent</tt>. If <tt>ssh-agent</tt> is already running, <tt>keychain</tt> will ensure that your <tt>id_dsa</tt> private key has been added to <tt>ssh-agent</tt> and then set up your environment so that <tt>ssh</tt> can find the already-running <tt>ssh-agent</tt>. It will look something like this:
+
 
+
Note that when <tt>keychain</tt> runs for the first time after your local system has booted, you will be prompted for a passphrase for your private key file if it is encrypted. But here's the nice thing about using <tt>keychain</tt> -- even if you are using an encrypted private key file, you will only need to enter your passphrase when your system first boots (or in the case of a server, when you first log in.) After that, <tt>ssh-agent</tt> is already running and has your decrypted private key cached in memory. So if you open a new shell, you will see something like this:
+
 
+
This means that you can now <tt>ssh</tt> to your heart's content, without supplying a passphrase.
+
 
+
You can also execute batch <tt>cron</tt> jobs and scripts that need to use <tt>ssh</tt> or <tt>scp</tt>, and they can take advantage of passwordless RSA/DSA authentication as well. To do this, you would add the following line to the top of a bash script:
+
 
+
{{File
+
|~/.bash_profile|<pre>
+
eval `keychain --noask --eval id_dsa` || exit 1
+
</pre>}}
+
The extra <tt>--noask</tt> option tells <tt>keychain</tt> that it should not prompt for a passphrase if one is needed. Since it is not running interactively, it is better for the script to fail if the decrypted private key isn't cached in memory via <tt>ssh-agent</tt>.
+
 
+
== Keychain Options ==
+
 
+
=== Specifying Agents ===
+
 
+
In the images above, you will note that <tt>keychain</tt> starts <tt>ssh-agent</tt>, but also starts <tt>gpg-agent</tt>. Modern versions of <tt>keychain</tt> also support caching decrypted GPG keys via use of <tt>gpg-agent</tt>, and will start <tt>gpg-agent</tt> by default if it is available on your system. To avoid this behavior and only start <tt>ssh-agent</tt>, modify your <tt>~/.bash_profile</tt> as follows:
+
 
+
<pre>eval `keychain --agents ssh --eval id_dsa` || exit 1</pre>
+
The additional <tt>--agents ssh</tt> option tells <tt>keychain</tt> just to manage <tt>ssh-agent</tt>, and ignore <tt>gpg-agent</tt> even if it is available.
+
 
+
=== Clearing Keys ===
+
 
+
Sometimes, it might be necessary to flush all cached keys in memory. To do this, type:
+
 
+
<console># ##i##keychain --clear</console>
+
Any agent(s) will continue to run.
+
 
+
=== Improving Security ===
+
 
+
To improve the security of <tt>keychain</tt>, some people add the <tt>--clear</tt> option to their <tt>~/.bash_profile</tt> <tt>keychain</tt> invocation. The rationale behind this is that any user logging in should be assumed to be an intruder until proven otherwise. This means that you will need to re-enter any passphrases when you log in, but cron jobs will still be able to run when you log out.
+
 
+
=== Stopping Agents ===
+
 
+
If you want to stop all agents, which will also of course cause your keys/identities to be flushed from memory, you can do this as follows:
+
 
+
<console># ##i##keychain -k all</console>
+
If you have other agents running under your user account, you can also tell <tt>keychain</tt> to just stop only the agents that <tt>keychain</tt> started:
+
 
+
<console># ##i##keychain -k mine</console>
+
 
+
== GPG ==
+
 
+
Keychain can ask you for your GPG passphrase if you provide it the GPG key ID. To find it out:
+
 
<console>
 
<console>
$ gpg -k
+
###i## emerge -av net-fs/samba
pub  2048R/DEADBEEF 2012-08-16
+
uid                  Name (Comment) <email@host.tld>
+
sub  2048R/86D2FAC6 2012-08-16
+
 
</console>
 
</console>
 +
Create a Samba share for your tftp server in ''<code>/etc/samba/smb.conf</code>''
  
Note the '''DEADBEEF''' above is the ID. Then, in your login script, do your usual
+
{{Note}} Be sure you have the other required samba settings configured in the file
 +
<console>
 +
###i## nano /etc/samba/smb.conf
 +
[Global]
 +
interfaces = lo eth0 wlan0
 +
bind interfaces only = yes
 +
workgroup = WORKGROUP
 +
security = user
  
 +
[tftproot]
 +
path = /tftproot
 +
browsable = true
 +
read only = yes
 +
writable = no
 +
guest ok = yes
 +
</console>
 +
Start Samba:
 
<console>
 
<console>
keychain --dir ~/.ssh/.keychain ~/.ssh/id_rsa DEADBEEF
+
###i## /etc/init.d/samba start
source ~/.ssh/.keychain/$HOST-sh
+
</console> 
source ~/.ssh/.keychain/$HOST-sh-gpg
+
or if samba has already been started:
 +
<console>
 +
###i## /etc/init.d/samba restart
 
</console>
 
</console>
  
== Learning More ==
+
== Creating a Setup Instruction File ==
 +
Create the file ''<code>/tftproot/winxp.sif</code>'' and add the following, replacing SAMBA_SERVER_IP with the local IP address of your samba server:
 +
<console>
 +
###i## nano /tftproot/winxp.sif
 +
[data]
 +
floppyless = "1"
 +
msdosinitiated = "1"
 +
; Needed for second stage
 +
OriSrc = "\\SAMBA_SERVER_IP\tftproot\winxp\i386"
 +
OriTyp = "4"
 +
LocalSourceOnCD = 1
 +
DisableAdminAccountOnDomainJoin = 1
  
The instructions above will work on any system that uses <tt>bash</tt> as its default shell, such as most Linux systems and Mac OS X.
+
[SetupData]
 +
OsLoadOptions = "/fastdetect"
 +
; Needed for first stage
 +
SetupSourceDevice = "\Device\LanmanRedirector\SAMBA_SERVER_IP\tftproot\winxp"
  
To learn more about the many things that <tt>keychain</tt> can do, including alternate shell support, consult the keychain man page, or type <tt>keychain --help | less</tt> for a full list of command options.
+
[UserData]
 +
ComputerName = *
 +
</console>
  
I also recommend you read my original series of articles about [http://www.openssh.com OpenSSH] that I wrote for IBM developerWorks, called <tt>OpenSSH Key Management</tt>. Please note that <tt>keychain</tt> 1.0 was released along with Part 2 of this article, which was written in 2001. <tt>keychain</tt> has changed quite a bit since then. In other words, read these articles for the conceptual and [http://www.openssh.com OpenSSH] information, but consult the <tt>keychain</tt> man page for command-line options and usage instructions :)
+
== Editing the pxelinux.cfg/default boot menu ==
 
+
Edit your boot menu so that it contains the following entry:
* [http://www.ibm.com/developerworks/library/l-keyc.html Common Threads: OpenSSH key management, Part 1] - Understanding RSA/DSA Authentication
+
<console>
* [http://www.ibm.com/developerworks/library/l-keyc2/ Common Threads: OpenSSH key management, Part 2] - Introducing <tt>ssh-agent</tt> and <tt>keychain</tt>
+
LABEL WinXP
* [http://www.ibm.com/developerworks/library/l-keyc3/ Common Threads: OpenSSH key management, Part 3] - Agent forwarding and <tt>keychain</tt> improvements
+
MENU LABEL Install MS Windows XP
 
+
KERNEL winxp.0
As mentioned at the top of the page, <tt>keychain</tt> development sources can be found in the [http://www.github.com/funtoo/keychain keychain git repository]. Please use the [http://groups.google.com/group/funtoo-dev funtoo-dev mailing list] and [irc://irc.freenode.net/funtoo #funtoo irc channel] for keychain support questions as well as bug reports.
+
</console>
 
+
== Project History ==
+
 
+
Daniel Robbins originally wrote <tt>keychain</tt> 1.0 through 2.0.3. 1.0 was written around June 2001, and 2.0.3 was released in late August, 2002.
+
 
+
After 2.0.3, <tt>keychain</tt> was maintained by various Gentoo developers, including Seth Chandler, Mike Frysinger and Robin H. Johnson, through July 3, 2003.
+
  
On April 21, 2004, Aron Griffis committed a major rewrite of <tt>keychain</tt> which was released as 2.2.0. Aron continued to actively maintain and improve <tt>keychain</tt> through October 2006 and the <tt>keychain</tt> 2.6.8 release. He also made a few commits after that date, up through mid-July, 2007. At this point, <tt>keychain</tt> had reached a point of maturity.
+
== Re-Start all required daemons==
 +
If the daemon isn't already running use start instead or restart in the following commands
 +
<pre>
 +
/etc/init.d/dnsmasq restart
 +
/etc/init.d/in.tftpd restart
 +
</pre>
 +
== Modify Binlsrv, update driver cache, and start driver hosting service ==
 +
Change the BASEPATH= variable at or around line #62 of binlsrv.py so that it is:
 +
<pre>
 +
BASEPATH='/tftproot/winxp/i386/'
 +
</pre>
 +
Generate driver cache
 +
<pre>
 +
cd /tftproot;./infparser.py winxp/i386/
 +
</pre>
 +
Start binlservice
 +
<pre>
 +
./binlsrv.py
 +
</pre>
  
In mid-July, 2009, Daniel Robbins migrated Aron's mercurial repository to git and set up a new project page on funtoo.org, and made a few bug fix commits to the git repo that had been collecting in [http://bugs.gentoo.org bugs.gentoo.org]. Daniel continues to maintain <tt>keychain</tt> and supporting documentation on funtoo.org, and plans to make regular maintenance releases of <tt>keychain</tt> as needed.
+
== Booting the client ==
 +
If all is well, you should be able to boot the client choosing to ''boot from network'' in the boot options, you should get to your PXELinux bootloader, and see the Install Windows XP option after pressing enter you *should* kick off your XP installation via network!! Congratulations!
  
 
[[Category:HOWTO]]
 
[[Category:HOWTO]]
[[Category:Projects]]
 

Revision as of 19:06, 13 January 2014

Howto use your Funtoo machine to serve a MS Windows installation over the network In this guide we will assume that you have followed the PXE network boot server Wiki article and have a working network/pxe boot setup. As of now this guide will cover Windows XP. Soon it will be expanded to also cover Windows 7.

Prerequisites

  1. A working Funtoo installation
  2. A working PXE Setup (DHCP, TFTP, PXELinux)
  3. app-arch/cabextract
  4. A legitimate copy of Microsoft Windows
  5. Driver for your NIC - Suggested to use a complete driver pack with all major supported NIC hardware for the version of Windows to be installed.
  6. RIS Linux toolkit >=0.4
  7. A working Samba server setup

Creating the Windows XP Image

  • In the previous guide, PXE Network Boot Server, we used /tftproot as the working directory so we will also use it in this guide for convenience. If you chose to use a different working directory then please apply it where needed in place of the /tftproot we will be going by here.

First you will need to create an ISO from your Windows XP installation disc. If you already have the ISO image you may skip this step.

# dd if=/dev/sr0 of=/tftproot/winxp.iso

If your cdrom device isn't /dev/sr0 please use the appropriate device in this command.

Mount the ISO and Prepare Installation Sources

Mount the image to /tftproot/cdrom:

# mkdir /tftproot/cdrom; mount -o loop /tftproot/winxp.iso /tftproot/cdrom

Create the new directory for the network installation files and copy the needed files to it:

# mkdir /tftproot/winxp; cp -R /tftproot/cdrom/i386 /tftproot/winxp/i386

Depending on your CD/DVD copy of windows the directory name may be I386 as opposed to i386, if that is the case you will just need to change the first part of the command, keeping the new directory name i386 - this is going to be very important later on when creating the remap file! Check the contents of your newly created i386 directory to see if the filenames are in all CAPS or if they are already in lowercase.

# ls /tftproot/winxp/i386

If you happen to have all UPPERCASE filenames, lets go ahead and run a script to convert it to all lowercase:

# cd /tftproot/winxp/i386;ls | awk '$0!=tolower($0){printf "mv \"%s\" \"%s\"\n",$0,tolower($0)}' | sh

Extracting and Modifying the Required Boot Files

Install app-arch/cabextract

# emerge -av app-arch/cabextract

Extract the prepackaged drivers:

# cd /tftproot/winxp/i386;cabextract driver.cab

Install support for a large list of network cards:

# cd /tftproot/;wget http://downloads.sourceforge.net/project/bootfloppy/pxefiles.tar.gz
# tar zxvf pxefiles.tar.gz; cp pxefiles/drivers/* winxp/i386/

Copy the BINLSRV /INFParser tools to /tftproot:

# cp pxefiles/script/* /tftproot/

Extract the netboot startrom:

# cd /tftproot; cabextract winxp/i386/startrom.n1_

Fix the startrom for netbooting xp:

# sed -i -e 's/NTLDR/XPLDR/gi' startrom.n12
# mv startrom.n12 winxp.0

Fix XPLDR:

# cabextract winxp/i386/setupldr.ex_
# sed -i -e 's/winnt\.sif/winxp\.sif/gi' setupldr.exe
# sed -i -e 's/ntdetect\.com/ntdetect\.wxp/gi' setupldr.exe
# mv setupldr.exe xpldr
# cp winxp/i386/ntdetect.com ntdetect.wxp

Creating a remapping file

Create the file /tftproot/tftpd.remap and add the following to it:

# nano /tftproot/tftpd.remap
ri ^[az]: # Remove “drive letters”
rg \\ / # Convert backslashes to slashes
rg \# @ # Convert hash marks to @ signs
rg /../ /..no../ # Convert /../ to /..no../
rg A a
rg B b
rg C c
rg D d
rg E e
rg F f
rg G g
rg H h
rg I i
rg J j
rg K k
rg L l
rg M m
rg N n
rg O o
rg P p
rg Q q
rg R r
rg S s
rg T t
rg U u
rg V v
rg W w
rg X x
rg Y y
rg Z z
r ^/(.*) \1
r ^xpldr xpldr
r ^ntdetect.wxp ntdetect.wxp
r ^winxp.sif winxp.sif

Install/Configure Samba

If you don't already have net-fs/samba installed, then:

# emerge -av net-fs/samba

Create a Samba share for your tftp server in /etc/samba/smb.conf

Note Note: Be sure you have the other required samba settings configured in the file

# nano /etc/samba/smb.conf
[Global]
interfaces = lo eth0 wlan0
bind interfaces only = yes
workgroup = WORKGROUP
security = user

[tftproot]
path = /tftproot
browsable = true
read only = yes
writable = no
guest ok = yes

Start Samba:

# /etc/init.d/samba start

or if samba has already been started:

# /etc/init.d/samba restart

Creating a Setup Instruction File

Create the file /tftproot/winxp.sif and add the following, replacing SAMBA_SERVER_IP with the local IP address of your samba server:

# nano /tftproot/winxp.sif
[data]
floppyless = "1"
msdosinitiated = "1"
; Needed for second stage
OriSrc = "\\SAMBA_SERVER_IP\tftproot\winxp\i386"
OriTyp = "4"
LocalSourceOnCD = 1
DisableAdminAccountOnDomainJoin = 1

[SetupData]
OsLoadOptions = "/fastdetect"
; Needed for first stage
SetupSourceDevice = "\Device\LanmanRedirector\SAMBA_SERVER_IP\tftproot\winxp"

[UserData]
ComputerName = *

Editing the pxelinux.cfg/default boot menu

Edit your boot menu so that it contains the following entry:

LABEL WinXP
	MENU LABEL Install MS Windows XP
	KERNEL winxp.0

Re-Start all required daemons

If the daemon isn't already running use start instead or restart in the following commands

/etc/init.d/dnsmasq restart
/etc/init.d/in.tftpd restart

Modify Binlsrv, update driver cache, and start driver hosting service

Change the BASEPATH= variable at or around line #62 of binlsrv.py so that it is:

BASEPATH='/tftproot/winxp/i386/'

Generate driver cache

cd /tftproot;./infparser.py winxp/i386/

Start binlservice

./binlsrv.py

Booting the client

If all is well, you should be able to boot the client choosing to boot from network in the boot options, you should get to your PXELinux bootloader, and see the Install Windows XP option after pressing enter you *should* kick off your XP installation via network!! Congratulations!