James Cammarata wrote:
On Tue, 13 Jan 2009 11:46:11 -0500, Michael DeHaan
<mdehaan(a)redhat.com>
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