James Cammarata wrote: > On Tue, 13 Jan 2009 11:46:11 -0500, Michael DeHaan <[email protected]> > 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 > > > _______________________________________________ cobbler mailing list [email protected] https://fedorahosted.org/mailman/listinfo/cobbler
