On Thu, Mar 21, 2013 at 03:07:20AM +0100, Martin Bähr wrote: > i am at last getting an opportunity to use foresight on a VM on a remote > server. ... > like a tar-ball. does anyone have a backup of those? > downloads.foresightlinux.org only has the DVDs.
Something like a year ago, I wrote a shell script that successfully built images, and I converted it into a simplistic python script a few months later. It is very ugly. It shows its history as a quick shell script hack that's been trivially modified into a python script. It is so ugly that I hesitated to even show it to anyone... It's just a proof of concept. It has some real limitations, but it would work for you. It can build raw filesystem images, raw hard drive images, and raw images configured to be build into AMIs for EC2. When building any of those images, it can also optionally write out a tarball of the contents of the image. It can lay down an archive of contents that you want on the system before Conary starts. I tend to use this for /etc/passwd and /etc/group to keep user ids in sync between systems. It can also lay down archives of content after installing with Conary; I have used this for things like pre-populated home directories that I want to be in an image but do not want to have under Conary control. It can run arbitrary commands within the image after installation; I have used this to run chkconfig commands instead of packaging up chkconfig overrides (despite the fact that I was the original designer and author of the chkconfig override feature). It allows you to choose whether to reset the root password in the image. It allows you to choose the default initlevel. If you are building multiple images from the same model, you can give it a directory in which to store model-cache files that allow Conary to get started building additional images quicker. You can use qemu-img to convert the hard drive images to other image types. It has no explicit accommodations for building for 32-bit. Running it under setarch might work but I haven't tested it. It does nothing to avoid using the conary configuration from the host system. This means that if you have different excludeTroves in the system on which you run it from excludeTroves in the configuration within the image, running "conary sync" in the images might add/remove components; I tend to see this with :supdoc components. I haven't even added the ability to add its python module directory to sys.path, so it depends on PYTHONPATH being set. It has no test suite whatsoever. It tries to clean up after itself when it encounters failures, but the try is rather half-hearted, and you might end up having to use kpartx -d by hand to clean up from mounting a partitioned loopback file. You have been warned. It doesn't even rename its logfiles to names that are associated with the produced images, so you are left with tmpnamed log files. ... Since you and Dick Marinus said on IRC that you would be willing to help users with it and contribute fixes to it, I'm willing to put it up publicly with all these caveats attached somehow. I think I'll put it on github and use the associated issue tracker to note the bugs and limitations that I've listed in this email, and then I'll follow up with a pointer to the repository on github and expect some help fixing up those issues. > also, can anyone share a system-model suitable for a server so i don't > have to fiddle around myself how to remove the desktop parts? My base server group is: search foresight.rpath.org@fl:2-qa/2.5.3+2013.02.14-0.1-1 install group-core group-base Then to that I add the things that I care about. I generally remove libata-migrate since it hasn't been needed for years; it was there for upgrades from rPL1, basically. I mean, if device names change again and you don't mount by UUID or label, then it could still be useful, but that seems unlikely in the general case... I tend to add things like dstat, strace, sysstat, openssh-client, vim, sudo, etc. That's really personal preference. _______________________________________________ Foresight-devel mailing list [email protected] https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
