On Mar 2, 2012, at 8:07 PM, Bruce Dubbs wrote: > Qrux wrote: >> On Mar 2, 2012, at 4:26 PM, James Robertson wrote: >>> On Mar 1, 2012 2:49 PM, "Ken Moffat" <[email protected]> >>> wrote: >>>> Actually, we used to have a guy who did run production servers - >>> LOL. I still do. I am much more efficient than in years past. LFS >>> has provided me a very stable, modern and downright fast platform. >> >> *whew* I was starting to think I was the only one who'd ever >> considered running LFS (or a very close derivative) in production. > > I've been doing that since 2004. And the lfs servers are running lfs. > I'd consider that 'production', wouldn't you?
LOL--I guess it's just hard to tell sometimes. Seems like Ken is often the only who pings back whenever I used the word "production", often to suggest that it's a bad idea. >> James, if you automate your builds, I'd love to compare notes. You >> can see my work here: https://github.com/qrux/xlapp. It's an >> automated build for virtualization using Xen with LFS as the base >> system. It provides a few server "types" (DNS, smtp/imap, and a LAPP >> stack). The README is now pretty dated, but still paints the big >> picture. > > jhalfs does a very nice job with LFS and I have my build scripts for > BLFS packages, so a build goes pretty fast. For multiple virtualization > builds, I have a generic build with few add ons that I can just copy and > add additional BLFS packages. I spent a little time with jhalfs in 6.8. I had some trouble with the build (I'm sure it was me, or an outdated host). It's very pretty, and I might try a similar menuconfig-style-interface in my own stuff. Right now I just use 'read VAR' for my scripts (or edit a config file). It's less pretty, but it works all the same. My stuff also aggressively tries to use "-j4", and manually changes MAKEFLAGS for some packages that won't build correctly with it. Is jhalfs capable of being completely blind to the book? Is the book complete (or, literal) enough such that the extracted scripts (I assume these are just the <userinput> parts of the XML) can just be strung together in the order in which they are encountered to produce a build? Other than the "for each package, unpack and descend" assumed instructions, of course. If so, I may try that approach in my own work, especially if point-releases will continue to exhibit the behavior of massive renumberings (seemed like 7.1 decided to reorder a large swath of chapter 6). * * * My Xen-based build is a bit more complex. Since Xen is a Type-1 hypervisor, it needs to be running under the host OS (not LFS host, but virt host); I assume this is different from KVM. So, there's a reboot. And, since I don't want to pollute my guests with the Xen administration stuff, I build it *after* the reboot. It helps keep the guests clean and small. Their kernels are also minimized. My scripts to create the guests take the "pristine" guest image, (made just before the reboot), and edit files in the new guest filesystem based on another series of prompts; that's probably like your "generic build". From there, like you, I have various sets of BLFS-like scripts I run. Another difference of my system is that I require the LFS host to use Grub Legacy, and I require that the LFS host use a separate /boot partition. Then, instead of installing a boot-loader, I assume one is there; I just append entries to /boot/grub/menu.lst, and change the default. I also install a "watchdog timer", so that if no one logs in (via SSH) in 30 seconds after the initial boot the will automatically revert the changes in menu.lst, and reboot into the host. That's saved several trips to the colo. As another convenience, once a build is tested, I can run them in a mode that doesn't execute the very time-consuming test suites (I've noticed that many of these features are present in jhalfs, though many are marked *new*, whatever time horizon that refers to). Once my stuff is a bit more mature (I'm almost to the point where I've tested as much downstream as is relevant to my uses), I'd like to add a xen-from-scratch link on the LFS page. What's the process there? Q -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
