Re: ris-linux review pending

[Jeroen van Meeuwen]

James Cammarata wrote:
>  Do you know if all of the windows pxe boot files have to be in the
> root
>  directory of the tftp server?  I would like to create subdirectories like
>  this:
>  
>  /tftpboot/ris/profiles/$profile_name/startrom.n12 -> /tftpboot/winxp.0
>                                      /NTLDR -> /tftpboot/XPLDR
>                                      /winnt.sif
>                                      /winxp ->
>  /var/www/cobbler/ks_mirror/winxp
>  
>  And then the pxeboot line would be:
>  
>  label winxp
>     kernel ris/profiles/$profile_name/startrom.n12
>  
>  label xpsystem1
>     kernel ris/systems/$system_name/startrom.n12
>   
You can't.  startrom will look for a file in the TFTP root; unless you 
rewrite the location with tftpd.rules (or the like), it needs to be in 
the TFTP root.

That said, when going down the rewrite road to have Windows pick up the 
appropriate file(s), it needs to ask for different files to begin with 
or the rewrite will cause it to pick up the same file after all.

That said, you can sed -i -e 's/winnt.sif/12345.sif/g' NTLDR to specify 
an alternative to "winnt.sif". As such, you can have profiles based on 
these three files:

startrom.n12 which points to NTDLR,
NTLDR which points to winnt.sif,
and winnt.sif

Note how the latter two contain 5 chars (excluding the .sif suffix), and 
the name of startrom.n12 really doesn't matter.

You could create a:

xp321.0 from startrom.n12,

sed -i -e 's/NTLDR/xp321/g' xp321.0

xp321 from NTLDR,

sed -i -e 's/winnt.sif/xp321.sif/g' xp321

create a xp321.sif file

Note that in this case I use Windows _XP_ _32_-bit Profile #_1_ as the 
five chars to use, but those are up to you.

bootfont.bin, ntdetwxp.x86 can just live in the TFTP root since they can 
be shared and do not refer to other files.

Now, creating a Cobbler profile or system can grab the originals, copy 
them anywhere, replace whatever they want to replace, and as such create 
"a unique" unattended installation. With unique filenames per profile 
however, you would not necessarily need to create a subdirectory in the 
TFTP root however it gets messy fast, so creating one subdirectory 
entirely managed by Cobbler probably makes the most sense, provided a 
rewrite rule for TFTP.

I'm working on some more documentation about this and more different 
Windows unattended installations over the network / using PXE on 
http://www.kanarip.com/courses/ClassRoomManual-WindowsInstallationsOverTh...

>  The problem will arise if Windows expects the winnt.sif file to be in
> the
>  root of the tftp server, and not in the same directory as the startrom.n12
>  file.  We may be able to get around this by adding a rewrite rule for tftp
>  (as part of the cobbler sync process the rules file would be regenerated
>  and tftpd would be HUP'd), so that it hides the fact that things are not
>  all in the tftp root.
>   
re-writing "/winnt.sif" to anything else will always cause you to 
eventually end up with the same file, just from a different location.

>  Doing it this way, we will be able to have custom .sif's for
> each
>  system/profile that is created.  Otherwise, we will have to come up with
>  some way to modify the binaries in a unique way for each system, which I
>  really don't want. 
Modifying binaries is all you can do when all you get is binaries.

For systems (and profiles), referring to one or the other startrom.n12 
file would suffice to differentiate. The NTLDR and .sif used from that 
point can be set with a simple sed command like the few in my examples. 
This of course could also be done on-the-fly, possibly by Cobbler.

Note that for Windows XP, using the startrom.n12 from Windows 2003 is 
basically your only option or it won't ever find txtsetup.sif although 
the error message will be garbled beyond recognition.

   The entire profile/system directory may be a link to
>  another folder somewhere in /var/www/cobbler, just for cleanliness
> reasons.
>   
in.tftpd does not handle links very well.

Kind regards,

Jeroen van Meeuwen
-kanarip

ris-linux review pending

[James Cammarata]

On Wed, 17 Dec 2008 16:13:49 +0100, Jeroen van Meeuwen
<kanarip(a)kanarip.com&gt; wrote:
>  James Cammarata wrote:
> > Do you know if all of the windows pxe boot files have to be in the root
> > directory of the tftp server?  I would like to create subdirectories
>  like
> > this:
> >
> > /tftpboot/ris/profiles/$profile_name/startrom.n12 -> /tftpboot/winxp.0
> >                                     /NTLDR -> /tftpboot/XPLDR
> >                                     /winnt.sif
> >                                     /winxp ->
> > /var/www/cobbler/ks_mirror/winxp
> >
> > And then the pxeboot line would be:
> >
> > label winxp
> >    kernel ris/profiles/$profile_name/startrom.n12
> >
> > label xpsystem1
> >    kernel ris/systems/$system_name/startrom.n12
> >
>  
>  You can't.  startrom will look for a file in the TFTP root; unless you
>  rewrite the location with tftpd.rules (or the like), it needs to be in
>  the TFTP root.
>  
>  That said, when going down the rewrite road to have Windows pick up the
>  appropriate file(s), it needs to ask for different files to begin with
>  or the rewrite will cause it to pick up the same file after all. 

You can match on the IP/MAC address, can't you?  So we could theoretically
at least use a custom sif for systems?

If that's not an option, are we expecting cobbler at this point to do
nothing but a vanilla XP/2003 installation?


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

ris-linux review pending

[Jeroen van Meeuwen]

James Cammarata wrote:
>  You can match on the IP/MAC address, can't you?  So we could
> theoretically
>  at least use a custom sif for systems?
>   
Under "FILENAME REMAPPING", in in.tftpd's man page:

\i     The IP address of the requesting host, in dotted-quad notation 
(e.g. 192.0.2.169).

\x     The IP address of the requesting host, in hexadecimal notation 
(e.g. C00002A9).

This would imply your nodes get reserved DHCP leases which isn't 
feasible for most situations (such as multi-subnet setups since host 
declarations are global and not subnet specific).

Using these, one could create /NTLDR -> /windows/\i/NTLDR rewrites, but 
wouldn't allow profiles to be selected from the "default" menu.

These two aspects (no host reservations and being able to select 
different profiles from the "default menu") are in my list of requirements.

>  If that's not an option, are we expecting cobbler at this point
> to do
>  nothing but a vanilla XP/2003 installation?
>   
We're not yet expecting cobbler to do anything without the ris-linux 
package being reviewed and properly landing in Fedora / EPEL

We'll see where we go from there. It's obviously the Windows part that 
is going to require the most work.

-Jeroen

ris-linux review pending

[James Cammarata]

On Wed, 17 Dec 2008 17:18:19 +0100, Jeroen van Meeuwen
<kanarip(a)kanarip.com&gt; wrote:
>  James Cammarata wrote:
> > You can match on the IP/MAC address, can't you?  So we could
>  theoretically
> > at least use a custom sif for systems?
> >
>  
>  Under "FILENAME REMAPPING", in in.tftpd's man page:
>  
>  \i     The IP address of the requesting host, in dotted-quad notation
>  (e.g. 192.0.2.169).
>  
>  \x     The IP address of the requesting host, in hexadecimal notation
>  (e.g. C00002A9).
>  
>  This would imply your nodes get reserved DHCP leases which isn't
>  feasible for most situations (such as multi-subnet setups since host
>  declarations are global and not subnet specific). 

Not true at all, when adding systems to cobbler you can specify the MAC
address (this is used to create the pxe file for Linux).  This could be
used for the rewrite rule as well.  For instance:

re   ^winxp\.sif    \x.sif

This might create a problem for profiles that don't have a MAC though...
maybe do one XPLDR for systems and one for profiles (with different file
names used internally, ie. winxp.sif and winxp.sys, then rewrite
winxp.sys...)


> > If that's not an option, are we expecting cobbler at this
> point to do
> > nothing but a vanilla XP/2003 installation?
> >
>  
>  We're not yet expecting cobbler to do anything without the ris-linux
>  package being reviewed and properly landing in Fedora / EPEL
>  
>  We'll see where we go from there. It's obviously the Windows part that
>  is going to require the most work. 

What I mean is, what are we _wanting_ cobbler to do at this point?  Because
doing a vanilla installation would be feasible, but currently we don't have
any way to customize the install, which is a big feature in cobbler.  Using
the rewrite method outlined above, I believe we can add a rewrite rule for
the .sif, which should get around this.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

ris-linux review pending

[Michael DeHaan]

James Cammarata wrote:
>  On Wed, 17 Dec 2008 17:18:19 +0100, Jeroen van Meeuwen
>  <kanarip(a)kanarip.com&gt; wrote:
>    
> > James Cammarata wrote:
> >     
> >> You can match on the IP/MAC address, can't you?  So we could
> >>       
> > theoretically
> >     
> >> at least use a custom sif for systems?
> >>
> >>       
> > Under "FILENAME REMAPPING", in in.tftpd's man page:
> >
> > \i     The IP address of the requesting host, in dotted-quad notation
> > (e.g. 192.0.2.169).
> >
> > \x     The IP address of the requesting host, in hexadecimal notation
> > (e.g. C00002A9).
> >
> > This would imply your nodes get reserved DHCP leases which isn't
> > feasible for most situations (such as multi-subnet setups since host
> > declarations are global and not subnet specific).
> >     
>
>
>  Not true at all, when adding systems to cobbler you can specify the MAC
>  address (this is used to create the pxe file for Linux).  This could be
>  used for the rewrite rule as well.  For instance:
>
>  re   ^winxp\.sif    \x.sif
>
>  This might create a problem for profiles that don't have a MAC though...
>  maybe do one XPLDR for systems and one for profiles (with different file
>  names used internally, ie. winxp.sif and winxp.sys, then rewrite
>  winxp.sys...)
>
>
>    
> >> If that's not an option, are we expecting cobbler at this point to do
> >> nothing but a vanilla XP/2003 installation?
> >>
> >>       
> > We're not yet expecting cobbler to do anything without the ris-linux
> > package being reviewed and properly landing in Fedora / EPEL
> >
> > We'll see where we go from there. It's obviously the Windows part that
> > is going to require the most work.
> >     
>
>
>  What I mean is, what are we _wanting_ cobbler to do at this point?  Because
>  doing a vanilla installation would be feasible, but currently we don't have
>  any way to customize the install, which is a big feature in cobbler.  Using
>  the rewrite method outlined above, I believe we can add a rewrite rule for
>  the .sif, which should get around this.
>
>
>     
Ideally if we can point it at answer files the user can tweak and 
replace using --kickstart=(windows file thingy), that seems ideal.

--Michael

ris-linux review pending

[James Cammarata]

On Wed, 17 Dec 2008 11:31:45 -0500, Michael DeHaan <mdehaan(a)redhat.com&gt;
wrote:
>  James Cammarata wrote:
> >
> > On Wed, 17 Dec 2008 17:18:19 +0100, Jeroen van Meeuwen
> > <kanarip(a)kanarip.com&gt; wrote:
> >
> >> James Cammarata wrote:
> >>
> >>> You can match on the IP/MAC address, can't you?  So we could
> >>>
> >> theoretically
> >>
> >>> at least use a custom sif for systems?
> >>>
> >>>
> >> Under "FILENAME REMAPPING", in in.tftpd's man page:
> >>
> >> \i     The IP address of the requesting host, in dotted-quad notation
> >> (e.g. 192.0.2.169).
> >>
> >> \x     The IP address of the requesting host, in hexadecimal notation
> >> (e.g. C00002A9).
> >>
> >> This would imply your nodes get reserved DHCP leases which isn't
> >> feasible for most situations (such as multi-subnet setups since host
> >> declarations are global and not subnet specific). 

Dangit, just realized that \x is the IP in hex format, not the MAC...  back
to the drawing board :\  This would still work if you specify both the mac
and IP, but I don't know how many people do that currently.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

ris-linux review pending

[Michael DeHaan]

James Cammarata wrote:
>  On Wed, 17 Dec 2008 11:31:45 -0500, Michael DeHaan
> <mdehaan(a)redhat.com&gt;
>  wrote:
>    
> > James Cammarata wrote:
> >     
> >> On Wed, 17 Dec 2008 17:18:19 +0100, Jeroen van Meeuwen
> >> <kanarip(a)kanarip.com&gt; wrote:
> >>
> >>       
> >>> James Cammarata wrote:
> >>>
> >>>         
> >>>> You can match on the IP/MAC address, can't you?  So we could
> >>>>
> >>>>           
> >>> theoretically
> >>>
> >>>         
> >>>> at least use a custom sif for systems?
> >>>>
> >>>>
> >>>>           
> >>> Under "FILENAME REMAPPING", in in.tftpd's man page:
> >>>
> >>> \i     The IP address of the requesting host, in dotted-quad notation
> >>> (e.g. 192.0.2.169).
> >>>
> >>> \x     The IP address of the requesting host, in hexadecimal notation
> >>> (e.g. C00002A9).
> >>>
> >>> This would imply your nodes get reserved DHCP leases which isn't
> >>> feasible for most situations (such as multi-subnet setups since host
> >>> declarations are global and not subnet specific).
> >>>         
>
>
>  Dangit, just realized that \x is the IP in hex format, not the MAC...  back
>  to the drawing board :\  This would still work if you specify both the mac
>  and IP, but I don't know how many people do that currently.
>
>
>     
FWIW, ia64 and certain yaboot's can't boot from the MAC and require the 
IP. It would be a tolerable limitation and still nice to have, and would 
work painlessly if someone was using
the manage_dhcp feature.

--Michael

ris-linux review pending

[James Cammarata]

Ok, think I've got a working solution (but haven't tested it yet).

All profiles/systems will have a 4 character random_id variable that is
generated pretty much like the UID variable.  This will be alpha-numeric,
so the hard limit on systems in cobbler will be 36^4 (1,679,616) windows
systems... I don't see a problem there :)

So, when a profile/system is detected as being breed=windows, this
random_id will be used to generate the required files:

/tftpboot/{profiles/systems}/name/winpxe.0 
/tftpboot/{profiles/systems}/name/NTLDR
/tftpboot/{profiles/systems}/name/winnt.sif

In addition, rules will be created in the /etc/tftpd.rules file, for
example:

re      ^LOIB4          /profiles/winxp-i386/NTLDR
re      ^wOIB4\.sif     /profiles/winxp-i386/winnt.sif
re      ^L2pWf          /systems/xp2/NTLDR
re      ^w2pWf\.sif     /systems/xp2/winnt.sif

As you can see, the lines with ^Lxxxx in them are rewrites for the loader,
and the ^wxxxx lines are the .sif rewrites.  The winpxe.0 file will point
to /Lxxxx, and the NTLDR file will point to /wxxxx.sif 

Here's what the system pxeboot file will look like:

# cat /tftpboot/pxelinux.cfg/xp2
prompt 0
timeout 1
label xp2
        kernel /systems/xp2/winpxe.0


And the default file will have the entries for the profiles looking like
this:

label winxp-i386
        kernel /profiles/winxp-i386/winpxe.0



So far, what works:
1) importing XP from CD
2) profile/system creation
3) ASCII pxe file generation
4) tftpd rule generation

What doesn't: 
1) sif (answer file) generation
2) binary pxe boot file generation
3) my random_id isn't persisting when a new system is created (everytime
you do a dumpvars it changes...), only after editing the first time... need
to figure that out.


As soon as I can get 1 & 2 done, I'll be able to start doing build testing.
 Overall I think this is looking very promising! Any thoughts/comments
would be appreciated of course.


James C.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

ris-linux review pending

[Jeroen van Meeuwen]

James Cammarata wrote:
>  Ok, think I've got a working solution (but haven't tested it
> yet).
>   
This pretty much sounds like what I have suggested we do earlier, but 
for the random generation of NTLDR and winnt.sif names. Those can just 
sequence (w0001, w0002, ... if you will). If nothing else, a sqlite db 
can track what is what.

>  This will be alpha-numeric,
>  so the hard limit on systems in cobbler will be 36^4 (1,679,616) windows
>  systems... 
actually the filename is limited to exactly 5 characters, but if you 
make it start with a "w", there's only one set of TFTP rewrite rules 
you'd have to do to have all Windows related files in a sub-directory of 
the TFTP root.

>  
>  So far, what works:
>  1) importing XP from CD 
Note that I found you'll need startrom.n12 from Windows 2003 and we're 
not allowed to ship it.

>  2) profile/system creation
>  3) ASCII pxe file generation
>  4) tftpd rule generation
>   
This could be a one time if you settle for having all Windows related 
files in one sub-directory of the TFTP root.

>  What doesn't: 
>  1) sif (answer file) generation 
This could just be a single winnt.sif to get things running and evolve 
from there.

Kind regards,

Jeroen van Meeuwen
-kanarip

ris-linux review pending

[James Cammarata]

On Sat, 20 Dec 2008 12:51:02 +0100, Jeroen van Meeuwen
<kanarip(a)kanarip.com&gt; wrote:
>  James Cammarata wrote:
> > Ok, think I've got a working solution (but haven't tested it yet).
> >
>  
>  This pretty much sounds like what I have suggested we do earlier, but
>  for the random generation of NTLDR and winnt.sif names. Those can just
>  sequence (w0001, w0002, ... if you will). If nothing else, a sqlite db
>  can track what is what. 
Random or sequential, either works for me.  I did random because it was
easier (not currently checking for collisions... though it will).


> > This will be alpha-numeric,
> > so the hard limit on systems in cobbler will be 36^4 (1,679,616) windows
> > systems...
>  
>  actually the filename is limited to exactly 5 characters, but if you
>  make it start with a "w", there's only one set of TFTP rewrite rules
>  you'd have to do to have all Windows related files in a sub-directory of
>  the TFTP root. 
What I meant was, 1 fixed, 4 variable, so that's 36^4 possible windows
systems (since linux/other probably wouldn't use this id).  But yeah, using
the same leading character for all the files would make things a bit more
simple.


> > So far, what works:
> > 1) importing XP from CD
>  
>  Note that I found you'll need startrom.n12 from Windows 2003 and we're
>  not allowed to ship it. 
That's fine, we can put it on the wiki.  However I'm using the following
two links as my guide, and neither mention this:

http://oss.netfarm.it/guides/ris-linux.php
http://oss.netfarm.it/guides/pxe.php


> > 2) profile/system creation
> > 3) ASCII pxe file generation
> > 4) tftpd rule generation
> >
>  
>  This could be a one time if you settle for having all Windows related
>  files in one sub-directory of the TFTP root.
>  
> > What doesn't:
> > 1) sif (answer file) generation
>  
>  This could just be a single winnt.sif to get things running and evolve
>  from there.
>  
>  Kind regards,
>  
>  Jeroen van Meeuwen
>  -kanarip
>  
>  --
>  This message has been scanned for viruses and
>  dangerous content by MailScanner, and is
>  believed to be clean. 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

ris-linux review pending

[Michael DeHaan]

> > Note that I found you'll need startrom.n12 from Windows 2003
> and we're
> > not allowed to ship it.
> >     
>
>  That's fine, we can put it on the wiki.  However I'm using the following
>  two links as my guide, and neither mention this:
>
>  http://oss.netfarm.it/guides/ris-linux.php
>  http://oss.netfarm.it/guides/pxe.php
>
>     
For purposes of clarification, I think you mean you can mention that you 
need it on the Wiki, not that we're going to upload it onto the Wiki.  
We obviously can't do that, but instructions for getting it off of the 
CD are fine.

We can also have the code complain if it's not where we expect it when 
you do a distro add with --breed=windows, I'd think :)

--Michael

ris-linux review pending

[James Cammarata]

On Sun, 21 Dec 2008 14:01:56 -0500, Michael DeHaan <mdehaan(a)redhat.com&gt;
wrote:
>  
> >> Note that I found you'll need startrom.n12 from Windows 2003 and we're
> >> not allowed to ship it.
> >>
> >
> > That's fine, we can put it on the wiki.  However I'm using the following
> > two links as my guide, and neither mention this:
> >
> > http://oss.netfarm.it/guides/ris-linux.php
> > http://oss.netfarm.it/guides/pxe.php
> >
> >
>  
>  For purposes of clarification, I think you mean you can mention that you
>  need it on the Wiki, not that we're going to upload it onto the Wiki.
>  We obviously can't do that, but instructions for getting it off of the
>  CD are fine.
>  
>  We can also have the code complain if it's not where we expect it when
>  you do a distro add with --breed=windows, I'd think :)
>  
>  --Michael 
I don't think even that will be required, I'm getting a XP system to boot
with no problems, need to get vmware drivers loaded up though so it will
actually install.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

ris-linux review pending

[James Cammarata]

On Sun, 21 Dec 2008 13:21:45 -0600, James Cammarata <jimi(a)sngx.net&gt; wrote:
>  
>  On Sun, 21 Dec 2008 14:01:56 -0500, Michael DeHaan <mdehaan(a)redhat.com&gt;
>  wrote:
> >
> >>> Note that I found you'll need startrom.n12 from Windows 2003 and
> we're
> >>> not allowed to ship it.
> >>>
> >>
> >> That's fine, we can put it on the wiki.  However I'm using the
>  following
> >> two links as my guide, and neither mention this:
> >>
> >> http://oss.netfarm.it/guides/ris-linux.php
> >> http://oss.netfarm.it/guides/pxe.php
> >>
> >>
> >
> > For purposes of clarification, I think you mean you can mention that you
> > need it on the Wiki, not that we're going to upload it onto the Wiki.
> > We obviously can't do that, but instructions for getting it off of the
> > CD are fine.
> >
> > We can also have the code complain if it's not where we expect it when
> > you do a distro add with --breed=windows, I'd think :)
> >
> > --Michael
>  
>  I don't think even that will be required, I'm getting a XP system to boot
>  with no problems, need to get vmware drivers loaded up though so it will
>  actually install. 
I've also found a solution to tftpd not traversing symlinks: bind mounts :)
 The only downside is they require a little bit more care when cleaning up,
since an rm -rf will follow it and delete stuff you don't want it to.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

ris-linux review pending

[Michael DeHaan]

James Cammarata wrote:
>  On Sun, 21 Dec 2008 13:21:45 -0600, James Cammarata
> <jimi(a)sngx.net&gt; wrote:
>    
> > On Sun, 21 Dec 2008 14:01:56 -0500, Michael DeHaan <mdehaan(a)redhat.com&gt;
> > wrote:
> >     
> >>>> Note that I found you'll need startrom.n12 from Windows 2003 and
> we're
> >>>> not allowed to ship it.
> >>>>
> >>>>           
> >>> That's fine, we can put it on the wiki.  However I'm using the
> >>>         
> > following
> >     
> >>> two links as my guide, and neither mention this:
> >>>
> >>> http://oss.netfarm.it/guides/ris-linux.php
> >>> http://oss.netfarm.it/guides/pxe.php
> >>>
> >>>
> >>>         
> >> For purposes of clarification, I think you mean you can mention that you
> >> need it on the Wiki, not that we're going to upload it onto the Wiki.
> >> We obviously can't do that, but instructions for getting it off of the
> >> CD are fine.
> >>
> >> We can also have the code complain if it's not where we expect it when
> >> you do a distro add with --breed=windows, I'd think :)
> >>
> >> --Michael
> >>       
> > I don't think even that will be required, I'm getting a XP system to boot
> > with no problems, need to get vmware drivers loaded up though so it will
> > actually install.
> >     
>
>  I've also found a solution to tftpd not traversing symlinks: bind mounts :)
>   The only downside is they require a little bit more care when cleaning up,
>  since an rm -rf will follow it and delete stuff you don't want it to.
>
>     
You could just use hardlinks (os.link), an unlink will only remove the 
file if it's the last one.

--Michael

ris-linux review pending

[James Cammarata]

>  You could just use hardlinks (os.link), an unlink will only remove
> the 
>  file if it's the last one.
>  
>  --Michael 
Can't hardlink a directory, nor can you hardlink across partitions, so that would be
an issue for people (ie. sane admins) that have /var on a different partition than
/tftpboot.  True, you could move tftpboot to var and symlink to the root directory, but
I'm trying to be as non-invasive by default as possible.  Bind mounts are well
recognized and documented, so to me it is the way to go on this one.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

ris-linux review pending

[Michael DeHaan]

James Cammarata wrote:
> > You could just use hardlinks (os.link), an unlink will only
> remove 
> > the file if it's the last one.
> >
> > --Michael
>
>  Can't hardlink a directory, nor can you hardlink across partitions, so 
>  that would be an issue for people (ie. sane admins) that have /var on 
>  a different partition than /tftpboot.  True, you could move tftpboot 
>  to var and symlink to the root directory, but I'm trying to be as 
>  non-invasive by default as possible.  Bind mounts are well recognized 
>  and documented, so to me it is the way to go on this one.
>  
I was thinking of just put the content on /var/www and try hardlinking 
the files, but it's true I have no idea how big the files you are 
talking about are, or how many there are.

If it's just a few mtab entries or something that's not too bad.

--Michael

[PATCH] ris-linux support for remote installation of Windows XP

[James Cammarata]

I am proud to announce that preliminary support for RIS linux is available
via my git hub:

git://github.com/jimi1283/cobbler.git, branch ris-devel

This is currently not for the extremely faint of heart, but it shouldn't be
bad for dev types.  Here are some links to help everyone get started and up
to speed:

http://www.promodus.net/linuxris
http://oss.netfarm.it/guides/ris-linux.php
http://oss.netfarm.it/guides/pxe.php

The first link is the most important, however the second and third give
some extra details that help understand how we hide some of the gory
details and allow for some customization of builds.

What you need to do this:

1) cabextract ("yum -y install cabextract" should do it)

2) in.tftpd (should be standard on Red Hat boxes, need to be able to do
rewrite rules with it)

3) After doing an import, you must cabextract all inf/cab files in the i386
directory to someplace binlserver can read them, and then run infparser.py
on them.  This builds the devcache.list file, which binlserver uses to
serve drivers out to booting systems.  You may also need to copy any .sys
files that are extracted back to the i386 directory.  These two steps were
the single greatest roadblock to me getting things working.  Don't forget
to restart binlserver after updating the driver cache either!

4) Samba, as configured in the links above.  A smb.conf is not yet included
in my patch, and samba is not managed in any way yet.

5) The ris-linux package.  jmeeuwen provided the link to that earlier I
believe.



What doesn't work yet:

1) XP distros are not bind-mounted to the /tftpboot directory yet.  During
the start of the boot process, the windows boot reads driver files from the
/tftpboot/<distro name> directory.  The easiest way I've come up with to
get around linking issues is to use bind mount:

mount --bind /path/to/src/dir /path/to/dst/dir

The destination must exist before mounting (unlike linking).

2) Xinetd isn't managed, so if you do a cobbler sync you will need to
restart/reload xinetd to have it read the tftp rules file.

3) Part of #2, the random_id variable used by systems/profiles is not
persistent quite yet, so unless you edit a system/profile after adding them
the id will change.  This causes issues as shown above, because the file
names change and the rules are updated to reflect that.

4) Only winxp is supported right now, and I think my CD is an original
release, no service pack installed, so that's the only thing i've been able
to test this on so far.  I also haven't done a git pull in a week, so there
may (most likely will) be some conflicts that may need to be sorted out to
get this merged in.  It's 1AM and my wife is sick, so everyone's on their
own for this right now :)

5) My installs are complaining about some options missing for a successful
unattended installation.  I know the big one is the product key (left out
for obvious reasons), but there may be others that prevent a flawless
installation.

6) cobbler check needs to be updated to check for all the stuff above.


My todo list for ris support:

* add bind-mount function to create directory mount in /tftpboot
* fixup cleanup function to remove mounts
  - mounts will also have to be cleaned up when a distro is deleted
* make the random id persistent, or change to a sequential ID
* version/flavor/service pack detection
* restart xinted after a sync so that the new rules are read in
* manage samba config/process
* automatic cabextract of inf/cab files in i386 and rebuild of driver
cache/hup binlserver

I'm sure I'm forgetting something, so if anyone applies this patch and has
problems, let me know!  This is all fresh in my mind and I will be glad to
help out.

Happy patching!

James Cammarata

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[PATCH] ris-linux support for remote installation of Windows XP

[Jeroen van Meeuwen]

James Cammarata wrote:
>  4) Only winxp is supported right now, and I think my CD is an
> original
>  release, no service pack installed, so that's the only thing i've been able
>  to test this on so far.  I also haven't done a git pull in a week, so there
>  may (most likely will) be some conflicts that may need to be sorted out to
>  get this merged in.  It's 1AM and my wife is sick, so everyone's on their
>  own for this right now :)
>   
I think whether the SP is included maybe causes the subtle difference in 
whether the startrom.n12 file from Windows XP works or not... My version 
of events includes the startrom.n12 from a SP2 slipstreamed CD.

It's worth investigating and updating the documentation for... I don't 
have any media without SP2 but maybe you can try it and see if there's a 
difference.

-Jeroen

[PATCH] ris-linux support for remote installation of Windows XP

[Michael DeHaan]

James Cammarata wrote:
>  I am proud to announce that preliminary support for RIS linux is
> available
>  via my git hub:
>
>  git://github.com/jimi1283/cobbler.git, branch ris-devel
>
>     
I've merged this in so we can continue from there.  Meanwhile, I'm 
working on getting some ISOs together for testing.

>  This is currently not for the extremely faint of heart, but it
> shouldn't be
>  bad for dev types.  Here are some links to help everyone get started and up
>  to speed:
>
>  http://www.promodus.net/linuxris
>  http://oss.netfarm.it/guides/ris-linux.php
>  http://oss.netfarm.it/guides/pxe.php
>
>  The first link is the most important, however the second and third give
>  some extra details that help understand how we hide some of the gory
>  details and allow for some customization of builds.
>
>  What you need to do this:
>
>  1) cabextract ("yum -y install cabextract" should do it)
>
>  2) in.tftpd (should be standard on Red Hat boxes, need to be able to do
>  rewrite rules with it)
>     
Can "cobbler import" be made to do the above?   I see you've added a 
cobbler settings
attribute to just generate/clobber the TFTP configuration file (from a 
template) which seems
sane, though I wanted to know if you could explain a bit more about why 
this was done and what
options would be used?

>  3) After doing an import, you must cabextract all inf/cab files in
> the i386
>  directory to someplace binlserver can read them, and then run infparser.py
>  on them.  This builds the devcache.list file, which binlserver uses to
>  serve drivers out to booting systems.  You may also need to copy any .sys
>  files that are extracted back to the i386 directory.  These two steps were
>  the single greatest roadblock to me getting things working.  Don't forget
>  to restart binlserver after updating the driver cache either!
>
>  4) Samba, as configured in the links above.  A smb.conf is not yet included
>  in my patch, and samba is not managed in any way yet.
>     
Is the intent for import to do 3 & 4 ?
>  5) The ris-linux package.  jmeeuwen provided the link to that earlier
> I
>  believe.
>
>
>
>  What doesn't work yet:
>
>  1) XP distros are not bind-mounted to the /tftpboot directory yet.  During
>  the start of the boot process, the windows boot reads driver files from the
>  /tftpboot/<distro name> directory.  The easiest way I've come up with to
>  get around linking issues is to use bind mount:
>
>  mount --bind /path/to/src/dir /path/to/dst/dir
>
>  The destination must exist before mounting (unlike linking).
>
>  2) Xinetd isn't managed, so if you do a cobbler sync you will need to
>  restart/reload xinetd to have it read the tftp rules file.
>     
I see some start of code to make it managed, though I'm unclear as to 
why we need to.

Ultimately we just need to turn TFTP on, right?  What else in the config 
is changing that might
require restarts?
>  3) Part of #2, the random_id variable used by systems/profiles is
> not
>  persistent quite yet, so unless you edit a system/profile after adding them
>  the id will change.  This causes issues as shown above, because the file
>  names change and the rules are updated to reflect that.
>     
I recently added a new "uid" field to cobbler that is persistent, though 
it's quite long.

You could likely hash off of that or follow that example to create more 
persist windows-specific IDs.
These just show up in the API and are not human editable.

>  4) Only winxp is supported right now, and I think my CD is an
> original
>  release, no service pack installed, so that's the only thing i've been able
>  to test this on so far.  I also haven't done a git pull in a week, so there
>  may (most likely will) be some conflicts that may need to be sorted out to
>  get this merged in.  It's 1AM and my wife is sick, so everyone's on their
>  own for this right now :)
>
>  5) My installs are complaining about some options missing for a successful
>  unattended installation.  I know the big one is the product key (left out
>  for obvious reasons), but there may be others that prevent a flawless
>  installation.
>
>  6) cobbler check needs to be updated to check for all the stuff above.
>     
If we package linux-ris I can see it needing to check for that, though 
couldn't "cobbler import" do the rest of the legwork?
It seems it is pretty close to doing this.

>  My todo list for ris support:
>
>  * add bind-mount function to create directory mount in /tftpboot
>  * fixup cleanup function to remove mounts
>    - mounts will also have to be cleaned up when a distro is deleted
>  * make the random id persistent, or change to a sequential ID
>  * version/flavor/service pack detection
>  * restart xinted after a sync so that the new rules are read in
>  * manage samba config/process
>  * automatic cabextract of inf/cab files in i386 and rebuild of driver
>  cache/hup binlserver
>
>  I'm sure I'm forgetting something, so if anyone applies this patch and has
>  problems, let me know!  This is all fresh in my mind and I will be glad to
>  help out.
>     
It's applied now for the purposes of having a common place to work on 
the feature, though I think what we could really use now is a Wiki page for
this feature, coupled with the instructions on what cobbler commands to 
run.  Basically what you have above but with examples and command lines, 
etc?

What would it take to get it to do something other than just XP?  
>  Happy patching!
>
>  James Cammarata
>
>

[PATCH] ris-linux support for remote installation of Windows XP

[James Cammarata]

On Tue, 13 Jan 2009 11:46:11 -0500, Michael DeHaan <mdehaan(a)redhat.com&gt;
wrote:
>  James Cammarata wrote:
> > I am proud to announce that preliminary support for RIS linux is
> > available
> > via my git hub:
> >
> > git://github.com/jimi1283/cobbler.git, branch ris-devel
> >
> >   
>  
>  I've merged this in so we can continue from there.  Meanwhile, I'm 
>  working on getting some ISOs together for testing. 
Wahoo!


> > This is currently not for the extremely faint of heart, but it
> shouldn't
> > be
> > bad for dev types.  Here are some links to help everyone get started and
> > up
> > to speed:
> >
> > http://www.promodus.net/linuxris
> > http://oss.netfarm.it/guides/ris-linux.php
> > http://oss.netfarm.it/guides/pxe.php
> >
> > The first link is the most important, however the second and third give
> > some extra details that help understand how we hide some of the gory
> > details and allow for some customization of builds.
> >
> > What you need to do this:
> >
> > 1) cabextract ("yum -y install cabextract" should do it)
> >
> > 2) in.tftpd (should be standard on Red Hat boxes, need to be able to do
> > rewrite rules with it)
> >   
>  
>  Can "cobbler import" be made to do the above?   I see you've added a 
>  cobbler settings
>  attribute to just generate/clobber the TFTP configuration file (from a 
>  template) which seems
>  sane, though I wanted to know if you could explain a bit more about why 
>  this was done and what
>  options would be used? 
Yes, I was planning on having cobbler import do all of this.

As for tftp, we need to have rewrite rules for file name requests.  An
example of why this is required is the fact that since MS doesn't have a
case-sensitive file system, requests come in as a mish-mash of upper/lower
case.  Rewriting all of these to lowercase makes life much more simple.  In
addition to this, in order to support customization of response (.sif)
files, we need to rewrite some other filename requests based on that random
ID.



> > 3) After doing an import, you must cabextract all inf/cab files
> in the
> > i386
> > directory to someplace binlserver can read them, and then run
> > infparser.py
> > on them.  This builds the devcache.list file, which binlserver uses to
> > serve drivers out to booting systems.  You may also need to copy any 
.sys
> > files that are extracted back to the i386 directory.  These two
> steps
> > were
> > the single greatest roadblock to me getting things working.  Don't 
forget
> > to restart binlserver after updating the driver cache either!
> >
> > 4) Samba, as configured in the links above.  A smb.conf is not yet
> > included
> > in my patch, and samba is not managed in any way yet.
> >   
>  
>  Is the intent for import to do 3 & 4 ? 
Yes.


> > 5) The ris-linux package.  jmeeuwen provided the link to that
> earlier I
> > believe.
> >
> >
> >
> > What doesn't work yet:
> >
> > 1) XP distros are not bind-mounted to the /tftpboot directory yet. 
> > During
> > the start of the boot process, the windows boot reads driver files from
> > the
> > /tftpboot/<distro name> directory.  The easiest way I've come up with to
> > get around linking issues is to use bind mount:
> >
> > mount --bind /path/to/src/dir /path/to/dst/dir
> >
> > The destination must exist before mounting (unlike linking).
> >
> > 2) Xinetd isn't managed, so if you do a cobbler sync you will need to
> > restart/reload xinetd to have it read the tftp rules file.
> >   
>  
>  I see some start of code to make it managed, though I'm unclear as to 
>  why we need to.
>  
>  Ultimately we just need to turn TFTP on, right?  What else in the config 
>  is changing that might
>  require restarts? 
Whenever the tftp rules file changes (which happens when adding a new
distro/profile/system), tftp needs to be HUP'd to pick up the changes.


> > 3) Part of #2, the random_id variable used by systems/profiles is
> not
> > persistent quite yet, so unless you edit a system/profile after adding
> > them
> > the id will change.  This causes issues as shown above, because the file
> > names change and the rules are updated to reflect that.
> >   
>  
>  I recently added a new "uid" field to cobbler that is persistent, though 
>  it's quite long.
>  
>  You could likely hash off of that or follow that example to create more 
>  persist windows-specific IDs.
>  These just show up in the API and are not human editable. 
I thought about doing that, but I couldn't find any good way of doing a
variable length hash.  If you have one we can sub it in, or we can do
jmeeuwen's suggestion of just assigning an incrementing ID.


> > 4) Only winxp is supported right now, and I think my CD is an
> original
> > release, no service pack installed, so that's the only thing i've been
> > able
> > to test this on so far.  I also haven't done a git pull in a week, so
> > there
> > may (most likely will) be some conflicts that may need to be sorted out
> > to
> > get this merged in.  It's 1AM and my wife is sick, so everyone's on
their
> > own for this right now :)
> >
> > 5) My installs are complaining about some options missing for a
> > successful
> > unattended installation.  I know the big one is the product key (left 
out
> > for obvious reasons), but there may be others that prevent a
> flawless
> > installation.
> >
> > 6) cobbler check needs to be updated to check for all the stuff above.
> >   
>  
>  If we package linux-ris I can see it needing to check for that, though 
>  couldn't "cobbler import" do the rest of the legwork?
>  It seems it is pretty close to doing this. 
Sure, #5 was resolved, and I think I commited the changes.  I believe I
even rewrote the default .sif to look for the product key as a meta
variable.  If I haven't committed that, let me know.

#4 just requires more real-world testing.

#6 is not a neccessity, it's just there to make life easier for begginers. 
Since we're adding 3 new moving parts (ris binlserver/tftp/samba), alerting
that they may be misconfigured would be helpful.  Import will still do all
the legwork of getting things setup.


> >
> > My todo list for ris support:
> >
> > * add bind-mount function to create directory mount in /tftpboot
> > * fixup cleanup function to remove mounts
> >   - mounts will also have to be cleaned up when a distro is deleted
> > * make the random id persistent, or change to a sequential ID
> > * version/flavor/service pack detection
> > * restart xinted after a sync so that the new rules are read in
> > * manage samba config/process
> > * automatic cabextract of inf/cab files in i386 and rebuild of driver
> > cache/hup binlserver
> >
> > I'm sure I'm forgetting something, so if anyone applies this patch and
> > has
> > problems, let me know!  This is all fresh in my mind and I will be glad
> > to
> > help out.
> >   
>  
>  It's applied now for the purposes of having a common place to work on 
>  the feature, though I think what we could really use now is a Wiki page 
for
>  this feature, coupled with the instructions on what cobbler commands
> to 
>  run.  Basically what you have above but with examples and command lines, 
>  etc?
>  
>  What would it take to get it to do something other than just XP?   
Absolutely, I was waiting for you to review the patch before starting any
wiki page, since you may have run screaming from this :)  Since it's
applied to dev, the wiki page will be a priority now.

Unfortunately I don't have access to 2k or Vista, so I can't work on those
unless someone wants to send me a legal copy.



James Cammarata


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[PATCH] ris-linux support for remote installation of Windows XP

[Michael DeHaan]

James Cammarata wrote:
>  On Tue, 13 Jan 2009 11:46:11 -0500, Michael DeHaan
> <mdehaan(a)redhat.com&gt;
>  wrote:
>    
> > James Cammarata wrote:
> >     
> >> I am proud to announce that preliminary support for RIS linux is
> >> available
> >> via my git hub:
> >>
> >> git://github.com/jimi1283/cobbler.git, branch ris-devel
> >>
> >>   
> >>       
> > I've merged this in so we can continue from there.  Meanwhile, I'm 
> > working on getting some ISOs together for testing.
> >     
>
>  Wahoo!
>
>
>    
> >> This is currently not for the extremely faint of heart, but it shouldn't
> >> be
> >> bad for dev types.  Here are some links to help everyone get started and
> >> up
> >> to speed:
> >>
> >> http://www.promodus.net/linuxris
> >> http://oss.netfarm.it/guides/ris-linux.php
> >> http://oss.netfarm.it/guides/pxe.php
> >>
> >> The first link is the most important, however the second and third give
> >> some extra details that help understand how we hide some of the gory
> >> details and allow for some customization of builds.
> >>
> >> What you need to do this:
> >>
> >> 1) cabextract ("yum -y install cabextract" should do it)
> >>
> >> 2) in.tftpd (should be standard on Red Hat boxes, need to be able to do
> >> rewrite rules with it)
> >>   
> >>       
> > Can "cobbler import" be made to do the above?   I see you've added a 
> > cobbler settings
> > attribute to just generate/clobber the TFTP configuration file (from a 
> > template) which seems
> > sane, though I wanted to know if you could explain a bit more about why 
> > this was done and what
> > options would be used?
> >     
>
>  Yes, I was planning on having cobbler import do all of this.
>     
Excellent.
>  As for tftp, we need to have rewrite rules for file name requests. 
> An
>  example of why this is required is the fact that since MS doesn't have a
>  case-sensitive file system, requests come in as a mish-mash of upper/lower
>  case.  Rewriting all of these to lowercase makes life much more simple.  In
>  addition to this, in order to support customization of response (.sif)
>  files, we need to rewrite some other filename requests based on that random
>  ID.
>
>     
Fair enough.  I'd propose that the TFTP management feature be off by 
default probably, just in case someone
was using TFTP for something else.  I think you were already planning it 
that way which is good.
>    
> >> 3) After doing an import, you must cabextract all inf/cab files in the
> >> i386
> >> directory to someplace binlserver can read them, and then run
> >> infparser.py
> >> on them.  This builds the devcache.list file, which binlserver uses to
> >> serve drivers out to booting systems.  You may also need to copy any
> >>       
>  .sys
>    
> >> files that are extracted back to the i386 directory.  These two steps
> >> were
> >> the single greatest roadblock to me getting things working.  Don't
> >>       
>  forget
>    
> >> to restart binlserver after updating the driver cache either!
> >>
> >> 4) Samba, as configured in the links above.  A smb.conf is not yet
> >> included
> >> in my patch, and samba is not managed in any way yet.
> >>   
> >>       
> > Is the intent for import to do 3 & 4 ?
> >     
>
>  Yes.
>
>     
Excellent.
>    
> >> 5) The ris-linux package.  jmeeuwen provided the link to that earlier I
> >> believe.
> >>
> >>
> >>
> >> What doesn't work yet:
> >>
> >> 1) XP distros are not bind-mounted to the /tftpboot directory yet. 
> >> During
> >> the start of the boot process, the windows boot reads driver files from
> >> the
> >> /tftpboot/<distro name> directory.  The easiest way I've come up with
> to
> >> get around linking issues is to use bind mount:
> >>
> >> mount --bind /path/to/src/dir /path/to/dst/dir
> >>
> >> The destination must exist before mounting (unlike linking).
> >>
> >> 2) Xinetd isn't managed, so if you do a cobbler sync you will need to
> >> restart/reload xinetd to have it read the tftp rules file.
> >>   
> >>       
> > I see some start of code to make it managed, though I'm unclear as to 
> > why we need to.
> >
> > Ultimately we just need to turn TFTP on, right?  What else in the config 
> > is changing that might
> > require restarts?
> >     
>
>  Whenever the tftp rules file changes (which happens when adding a new
>  distro/profile/system), tftp needs to be HUP'd to pick up the changes.
>     
Understood...

I take it we only need to add the rewrite rules for the systems that 
have Windows parents?

Sounds reasonable.
>    
> >> 3) Part of #2, the random_id variable used by systems/profiles is not
> >> persistent quite yet, so unless you edit a system/profile after adding
> >> them
> >> the id will change.  This causes issues as shown above, because the file
> >> names change and the rules are updated to reflect that.
> >>   
> >>       
> > I recently added a new "uid" field to cobbler that is persistent, though 
> > it's quite long.
> >
> > You could likely hash off of that or follow that example to create more 
> > persist windows-specific IDs.
> > These just show up in the API and are not human editable.
> >     
>
>  I thought about doing that, but I couldn't find any good way of doing a
>  variable length hash.  If you have one we can sub it in, or we can do
>  jmeeuwen's suggestion of just assigning an incrementing ID.
>     
The incremental ID seems the most reasonable.   The one problem you may 
encounter is when you reach the maximum value, in which case
it may make it better to make a cobbler class for managing pools of 
numbers/things (which the network stuff may also need, as it also has ids).

Not sure...

We can start with something simple and tweak it later if need be.
>    
> >> 4) Only winxp is supported right now, and I think my CD is an original
> >> release, no service pack installed, so that's the only thing i've been
> >> able
> >> to test this on so far.  I also haven't done a git pull in a week, so
> >> there
> >> may (most likely will) be some conflicts that may need to be sorted out
> >> to
> >> get this merged in.  It's 1AM and my wife is sick, so everyone's on
> >>       
>  their
>    
> >> own for this right now :)
> >>
> >> 5) My installs are complaining about some options missing for a
> >> successful
> >> unattended installation.  I know the big one is the product key (left
> >>       
>  out
>    
> >> for obvious reasons), but there may be others that prevent a flawless
> >> installation.
> >>
> >> 6) cobbler check needs to be updated to check for all the stuff above.
> >>   
> >>       
> > If we package linux-ris I can see it needing to check for that, though 
> > couldn't "cobbler import" do the rest of the legwork?
> > It seems it is pretty close to doing this.
> >     
>
>  Sure, #5 was resolved, and I think I commited the changes.  I believe I
>  even rewrote the default .sif to look for the product key as a meta
>  variable.  If I haven't committed that, let me know.
>
>  #4 just requires more real-world testing.
>
>  #6 is not a neccessity, it's just there to make life easier for begginers. 
>  Since we're adding 3 new moving parts (ris binlserver/tftp/samba), alerting
>  that they may be misconfigured would be helpful.  Import will still do all
>  the legwork of getting things setup.
>     
I think I'd be ok, since this is Windows, on just having the setup steps 
well documented on a Wiki page.

We don't suspect folks will have Windows systems in the default case, so 
having cobbler check warn about
them may be wrong, unless we have a setting that's clearly "enable 
windows support", in which case checking
would make sense.

>    
> >> My todo list for ris support:
> >>
> >> * add bind-mount function to create directory mount in /tftpboot
> >> * fixup cleanup function to remove mounts
> >>   - mounts will also have to be cleaned up when a distro is deleted
> >> * make the random id persistent, or change to a sequential ID
> >> * version/flavor/service pack detection
> >> * restart xinted after a sync so that the new rules are read in
> >> * manage samba config/process
> >> * automatic cabextract of inf/cab files in i386 and rebuild of driver
> >> cache/hup binlserver
> >>
> >> I'm sure I'm forgetting something, so if anyone applies this patch and
> >> has
> >> problems, let me know!  This is all fresh in my mind and I will be glad
> >> to
> >> help out.
> >>   
> >>       
> > It's applied now for the purposes of having a common place to work on 
> > the feature, though I think what we could really use now is a Wiki page
> >     
>  for
>    
> > this feature, coupled with the instructions on what cobbler commands to 
> > run.  Basically what you have above but with examples and command lines, 
> > etc?
> >
> > What would it take to get it to do something other than just XP?  
> >     
>
>  Absolutely, I was waiting for you to review the patch before starting any
>  wiki page, since you may have run screaming from this :)  Since it's
>  applied to dev, the wiki page will be a priority now.
>
>  Unfortunately I don't have access to 2k or Vista, so I can't work on those
>  unless someone wants to send me a legal copy.
>     
I expect I'll have versions here for testing, though I'm not sure I'd 
know what would need to change.

I also believe Jeroen said he had legal copies for himself.

Just getting XP going and nicely streamlined would be a start, perhaps 
those interested in deploying other distros could add the rest.

I would expect they wouldn't be terribly different, at least not more 
different than existing Linux install trees (could be wrong).  I take it 
if linux-ris
supports them it would not be too bad.

Thanks very much for tackling this!

--Michael

>  James Cammarata
>
>
>

[PATCH] ris-linux support for remote installation of Windows XP

[James Cammarata]

I've finally gotten around to starting a wiki page for the ris-linux stuff,
so feel free to take a look and let me know if you try it and have trouble
getting started.

https://fedorahosted.org/cobbler/wiki/RisLinux

Enjoy!

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[PATCH] ris-linux support for remote installation of Windows XP

[Michael DeHaan]

James Cammarata wrote:
>  I've finally gotten around to starting a wiki page for the
> ris-linux stuff,
>  so feel free to take a look and let me know if you try it and have trouble
>  getting started.
>
>  https://fedorahosted.org/cobbler/wiki/RisLinux
>
>  Enjoy!
>
>     
Great... I plan to be taking a look at this closer myself in a couple of 
weeks.

Don't let this stop anyone else from starting on it now!

--Michael

ris-linux review pending

[Jeroen van Meeuwen]

James Cammarata wrote:
>  Not true at all, when adding systems to cobbler you can specify the
> MAC
>  address (this is used to create the pxe file for Linux). 
This is the pxelinux.cfg file pulled in by the host and this information 
is lost as soon as the menu is loaded.

   This could be
>  used for the rewrite rule as well.  For instance:
>  
>  re   ^winxp\.sif    \x.sif
>  
>  This might create a problem for profiles that don't have a MAC though...
>  maybe do one XPLDR for systems and one for profiles (with different file
>  names used internally, ie. winxp.sif and winxp.sys, then rewrite
>  winxp.sys...)
>   
Note that \x is the heximal *IP* address, not the MAC address. Like I 
said before, this could only be used in combination with fixed-addresses 
(as that nails the host down to the heximal IP address it's going to 
get), but doesn't satisfy my requirements.

-Jeroen