Hi one thing that has come up over and over again (here) is that Debian is easier to install into a diskless workstation environment than Red Hat. I being the RH bigot that I am have not tried this yet, but I get the feeling that it is.
I would really like to see some work on making a Heavy Diskless Workstation install possible in the future. [Heavy Diskless means boxes that have say 1-2 gigs of Ram, big CPUs, and 100 mbps network at least.] THere are many environments that use this heavy duty, and right now I am having to admin 4 different ways of killing the problem with no one absolutely correct.
On Wed, 2003-07-23 at 17:40, Stephen Smoogen wrote:
Hi one thing that has come up over and over again (here) is that Debian is easier to install into a diskless workstation environment than Red Hat. I being the RH bigot that I am have not tried this yet, but I get the feeling that it is.
I would really like to see some work on making a Heavy Diskless Workstation install possible in the future. [Heavy Diskless means boxes that have say 1-2 gigs of Ram, big CPUs, and 100 mbps network at least.] THere are many environments that use this heavy duty, and right now I am having to admin 4 different ways of killing the problem with no one absolutely correct.
Well, if I understand what you are asking for, the K12LTSP project (at http://www.k12ltsp.org/) serves this purpose quite well. Version 3.1.1 is Red Hat 9 with updates (through around June 24), ltsp packages from http://www.ltsp.org/ and a few additional packages suitable for an educational environment. So a *lot* of this (excellent) work has already been done by Eric Harrison and Paul Nelson who head up the project. I've been able to do an install of a server and *even before ever logging into the server* to tweak even a single setting, I'm able to boot a thin client with a PXE enabled network card and have a working desktop. Fabulous work on Eric and Paul's part. What does require some work is the ltsp packages themselves. They most certainly won't meet any Red Hat criteria. The K12LTSP project takes them directly from the LTSP project and makes some minor tweaks but they suffer from what I consider a nasty problem: they are built from binary tarballs created by lifting binaries directly from an existing distribution (in this case, Red Hat 7.1, I believe). The ltsp packages included in K12LTSP 3.1.1 are based on ltsp version 3.x. The new ltsp version 4.x (I think still currently in alpha stage) takes an entirely different approach. What they do now is build an entire cross-compiling, chrooted environment to build all packages (tarballs, really) for the thin clients. This allows the LTSP project to be more distribution agnostic, but it isn't much better from a perspective of fitting into Red Hat neatly. I've been working on (and am willing to take on the task of doing so for the Red Hat Linux project) coming up with better ltsp packages that will fit nicely into Red Hat. No binary tarballs in the src rpms, no special build environments, but very specific to Red Hat. There are some issues to be worked out, however:
1) It seems the LTSP project has been concerned about disk space for the thin client tree (defaults to /opt/ltsp/i386), as is evidenced in their use of busybox instead of the real tools. I ask, what's the point? It's all stored on the server and it takes no additional RAM on the clients. Heck, the commands are barely (if at all) even used outside the boot process. So why not just install second copies of the rpms that are needed by the thin clients into an alternate root (like /opt/ltsp/i386)? There's other stuff that needs to be added (config files an the like), but those can be in additional packages.
2) Is it reasonable to ask for a change to anaconda to allow for these rpms to be installed in this alternate root? It would probably be an invasive change, as it's not currently done anywhere in anaconda, to the best of my knowledge, except that the actually installer *does* in fact install the entire distribution into an alternate root (after, how else would you do it?). What's different is that now I'm asking for anaconda to switch gears in the middle of the installation and install a specific list of packages in a different alternate root.
3) If the above isn't considered the best approach, another possibility is to rebuild the required rpms (and probably rename them with an 'ltsp-' prefix or some such distinction), with a different prefix directory. That seems like potentially a lot of extra build time and complexity, however, especially since both the (mknbi enabled) kernel and XFree86 are needed. Thoughts?
4) The last approach that I can think of is having a single ltsp-config package (or equivalent, name it whatever) that has includes all the additional ltsp stuff (config files, etherboot images, etc.) and a single script that checks to make sure all the rpms required for the thin client tree are actually installed in the normal root directory. and just copies all the required binaries into place in the /opt/ltsp/i386 tree. Alternatively, the script might not require that the rpms be installed on the server, but instead take a directory with the required rpms so that the appropriate rpms can be extracted. Of course, this approach has the problem of issuing errata: the script would have to be run whenever any relevant errata was issued.
So I'd like some input into how to approach this and I'd also like to hear if there is sufficient interest in having this included in the Red Hat Linux project. If so, looks like I found my niche! (Unless of course Eric Harrison is on this list and would like to do it himself -- I tend to doubt it, though, given how busy he already is. ;-))
On Wed, 2003-07-23 at 16:33, Paul Iadonisi wrote:
On Wed, 2003-07-23 at 17:40, Stephen Smoogen wrote:
Hi one thing that has come up over and over again (here) is that Debian is easier to install into a diskless workstation environment than Red Hat. I being the RH bigot that I am have not tried this yet, but I get the feeling that it is.
I would really like to see some work on making a Heavy Diskless Workstation install possible in the future. [Heavy Diskless means boxes that have say 1-2 gigs of Ram, big CPUs, and 100 mbps network at least.] THere are many environments that use this heavy duty, and right now I am having to admin 4 different ways of killing the problem with no one absolutely correct.
Well, if I understand what you are asking for, the K12LTSP project (at http://www.k12ltsp.org/) serves this purpose quite well. Version 3.1.1 is Red Hat 9 with updates (through around June 24), ltsp packages from http://www.ltsp.org/ and a few additional packages suitable for an educational environment.
Actually it is the opposite of want I need. The clients are usually multi cpu/ large ram machines/ etc with the server being not much at all.
I think that LTSP servers 90% of most diskless environment needs.. I just end up in the 10% where the machines are diskless for programatic needs but the work must be done on the workstation (Lets just say a lot of the work maxes out a 2-4 CPU workstation.)
On Wed, 2003-07-23 at 18:41, Stephen Smoogen wrote:
[snip]
Actually it is the opposite of want I need. The clients are usually multi cpu/ large ram machines/ etc with the server being not much at all.
I think that LTSP servers 90% of most diskless environment needs.. I just end up in the 10% where the machines are diskless for programatic needs but the work must be done on the workstation (Lets just say a lot of the work maxes out a 2-4 CPU workstation.)
Ah, I see. So it sounds like a job for openMosix (with node/cpu affinity), Compaq/HP's SSI, or maybe a customized LTSP config that creates a really big ramdisk to hold a full OS instead using NFS mounts. Hmm, if you use the big ramdisk approach, then it seems like not so big a change from the usually LTSP config, though I wouldn't call it LTSP at that point, but instead 'diskless-client' or something similar. I think most of what wrote might still apply. It could be made as some config option. Or even if it's separate, they are related enough that I might be able work on both.
No we do everything via NFS at the moment. Using a big ramdisk would cut into why all the machines have so much memory and CPU's. Basically the idea is that all CPU cycles are local and all data is foreign. The approach to this seems to follow either SGI or Sun ways of doing diskless clients. I like the Sun way of doing it (with each client getting its own tree) versus the SGI where most is common with the server and clients need a rebuild if server code changes.
On Wed, 2003-07-23 at 17:40, Paul Iadonisi wrote:
On Wed, 2003-07-23 at 18:41, Stephen Smoogen wrote:
[snip]
Actually it is the opposite of want I need. The clients are usually multi cpu/ large ram machines/ etc with the server being not much at all.
I think that LTSP servers 90% of most diskless environment needs.. I just end up in the 10% where the machines are diskless for programatic needs but the work must be done on the workstation (Lets just say a lot of the work maxes out a 2-4 CPU workstation.)
Ah, I see. So it sounds like a job for openMosix (with node/cpu affinity), Compaq/HP's SSI, or maybe a customized LTSP config that creates a really big ramdisk to hold a full OS instead using NFS mounts. Hmm, if you use the big ramdisk approach, then it seems like not so big a change from the usually LTSP config, though I wouldn't call it LTSP at that point, but instead 'diskless-client' or something similar. I think most of what wrote might still apply. It could be made as some config option. Or even if it's separate, they are related enough that I might be able work on both.
-- Rhl-devel-list mailing list Rhl-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/rhl-devel-list
On Wed, 2003-07-23 at 20:28, Stephen Smoogen wrote:
No we do everything via NFS at the moment. Using a big ramdisk would cut into why all the machines have so much memory and CPU's. Basically the idea is that all CPU cycles are local and all data is foreign. The approach to this seems to follow either SGI or Sun ways of doing diskless clients. I like the Sun way of doing it (with each client getting its own tree) versus the SGI where most is common with the server and clients need a rebuild if server code changes.
Okay, I give. ;-)
Looks like it's a lot lest complicated than I was thinking, but I get your point about it being a bit of pain to set up. It would be nice to be able to do this OOB.
Anyhow, all I wrote is still something I might do if there is enough interest. Maybe I'll look at what you need, too, and since they are somewhat related. (sorta, kinda, maybe...)
No we do everything via NFS at the moment. Using a big ramdisk would cut into why all the machines have so much memory and CPU's. Basically the idea is that all CPU cycles are local and all data is foreign. The approach to this seems to follow either SGI or Sun ways of doing diskless clients. I like the Sun way of doing it (with each client getting its own tree) versus the SGI where most is common with the server and clients need a rebuild if server code changes.
Can a user move to another workstation and resume their session? I've seen this done with RFID tags that automatically detach your session if you move away from the terminal and re-attach you when you move closer.
-Chuck
I have been working on a package called redhat-config-netboot that allows you to setup diskless environments using NFS, as well as network installations. It is based somewhat off of LTSB. It is basically a series of scripts and python code that sets up a PXE boot environment and an diskless NFS partition.
ftp://people.redhat.com/dwalsh/netboot
Comments welcome.
Dan
Chuck Wolber wrote:
No we do everything via NFS at the moment. Using a big ramdisk would cut into why all the machines have so much memory and CPU's. Basically the idea is that all CPU cycles are local and all data is foreign. The approach to this seems to follow either SGI or Sun ways of doing diskless clients. I like the Sun way of doing it (with each client getting its own tree) versus the SGI where most is common with the server and clients need a rebuild if server code changes.
Can a user move to another workstation and resume their session? I've seen this done with RFID tags that automatically detach your session if you move away from the terminal and re-attach you when you move closer.
-Chuck
Thanks I will try to look at this next week. What I am trying to figure out is the best/fastest way to set up new diskless clients that have 'full' installs.
Currently we have two systems here.
The first is where /usr and some other directories are stored on the master tree and then the few remaining (/lib /var /etc /initrd etc) are seperate per machine. This is very fast to bring up a new machine because the date to be copied is small (20-40 megs on average). However it is a pain in the ass to update as all the clients have to be rebuilt after errata that change /etc, /lib etc occur.
The second is much more disk intensive but easier to maintain. In this version each client gets a complete install in an NFS tree. This allows for a lot of customization per client (some can run 7.1 while others run 9.0). Maintenance is much easier because RPM can be run on each of the trees seperately. However installs are SLOW because they are either server side using a chroot anaconda (which I havent gotten working seamlessly) or the client is doing all the writes via NFS.
On Thu, 2003-07-24 at 07:23, Daniel J Walsh wrote:
I have been working on a package called redhat-config-netboot that allows you to setup diskless environments using NFS, as well as network installations. It is based somewhat off of LTSB. It is basically a series of scripts and python code that sets up a PXE boot environment and an diskless NFS partition.
ftp://people.redhat.com/dwalsh/netboot
Comments welcome.
Dan
Chuck Wolber wrote:
No we do everything via NFS at the moment. Using a big ramdisk would cut into why all the machines have so much memory and CPU's. Basically the idea is that all CPU cycles are local and all data is foreign. The approach to this seems to follow either SGI or Sun ways of doing diskless clients. I like the Sun way of doing it (with each client getting its own tree) versus the SGI where most is common with the server and clients need a rebuild if server code changes.
Can a user move to another workstation and resume their session? I've seen this done with RFID tags that automatically detach your session if you move away from the terminal and re-attach you when you move closer.
-Chuck
-- Rhl-devel-list mailing list Rhl-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/rhl-devel-list
This diskless is a single /root directory containing all files and a /.snapshot directory containing files that are specific to the client. (A very small subset). It then uses mount -o bind to mount the snapshot files over the /root files on the client. You need to do a chroot on the server to up2date it or rpm install it. It will not support older versions of RH. It should work on RH9 or greater and it might work on RH8.
Dan
Stephen Smoogen wrote:
Thanks I will try to look at this next week. What I am trying to figure out is the best/fastest way to set up new diskless clients that have 'full' installs.
Currently we have two systems here.
The first is where /usr and some other directories are stored on the master tree and then the few remaining (/lib /var /etc /initrd etc) are seperate per machine. This is very fast to bring up a new machine because the date to be copied is small (20-40 megs on average). However it is a pain in the ass to update as all the clients have to be rebuilt after errata that change /etc, /lib etc occur.
The second is much more disk intensive but easier to maintain. In this version each client gets a complete install in an NFS tree. This allows for a lot of customization per client (some can run 7.1 while others run 9.0). Maintenance is much easier because RPM can be run on each of the trees seperately. However installs are SLOW because they are either server side using a chroot anaconda (which I havent gotten working seamlessly) or the client is doing all the writes via NFS.
On Thu, 2003-07-24 at 07:23, Daniel J Walsh wrote:
I have been working on a package called redhat-config-netboot that allows you to setup diskless environments using NFS, as well as network installations. It is based somewhat off of LTSB. It is basically a series of scripts and python code that sets up a PXE boot environment and an diskless NFS partition.
ftp://people.redhat.com/dwalsh/netboot
Comments welcome.
Dan
Chuck Wolber wrote:
No we do everything via NFS at the moment. Using a big ramdisk would cut into why all the machines have so much memory and CPU's. Basically the idea is that all CPU cycles are local and all data is foreign. The approach to this seems to follow either SGI or Sun ways of doing diskless clients. I like the Sun way of doing it (with each client getting its own tree) versus the SGI where most is common with the server and clients need a rebuild if server code changes.
Can a user move to another workstation and resume their session? I've seen this done with RFID tags that automatically detach your session if you move away from the terminal and re-attach you when you move closer.
-Chuck
-- Rhl-devel-list mailing list Rhl-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/rhl-devel-list
Is it is simple to rename .snapshot to soemthing else. The NFS server is a netapp :)
On Thu, 2003-07-24 at 10:11, Daniel J Walsh wrote:
This diskless is a single /root directory containing all files and a /.snapshot directory containing files that are specific to the client. (A very small subset). It then uses mount -o bind to mount the snapshot files over the /root files on the client. You need to do a chroot on the server to up2date it or rpm install it. It will not support older versions of RH. It should work on RH9 or greater and it might work on RH8.
Dan
Stephen Smoogen wrote:
Thanks I will try to look at this next week. What I am trying to figure out is the best/fastest way to set up new diskless clients that have 'full' installs.
Currently we have two systems here.
The first is where /usr and some other directories are stored on the master tree and then the few remaining (/lib /var /etc /initrd etc) are seperate per machine. This is very fast to bring up a new machine because the date to be copied is small (20-40 megs on average). However it is a pain in the ass to update as all the clients have to be rebuilt after errata that change /etc, /lib etc occur.
The second is much more disk intensive but easier to maintain. In this version each client gets a complete install in an NFS tree. This allows for a lot of customization per client (some can run 7.1 while others run 9.0). Maintenance is much easier because RPM can be run on each of the trees seperately. However installs are SLOW because they are either server side using a chroot anaconda (which I havent gotten working seamlessly) or the client is doing all the writes via NFS.
On Thu, 2003-07-24 at 07:23, Daniel J Walsh wrote:
I have been working on a package called redhat-config-netboot that allows you to setup diskless environments using NFS, as well as network installations. It is based somewhat off of LTSB. It is basically a series of scripts and python code that sets up a PXE boot environment and an diskless NFS partition.
ftp://people.redhat.com/dwalsh/netboot
Comments welcome.
Dan
Chuck Wolber wrote:
No we do everything via NFS at the moment. Using a big ramdisk would cut into why all the machines have so much memory and CPU's. Basically the idea is that all CPU cycles are local and all data is foreign. The approach to this seems to follow either SGI or Sun ways of doing diskless clients. I like the Sun way of doing it (with each client getting its own tree) versus the SGI where most is common with the server and clients need a rebuild if server code changes.
Can a user move to another workstation and resume their session? I've seen this done with RFID tags that automatically detach your session if you move away from the terminal and re-attach you when you move closer.
-Chuck
-- Rhl-devel-list mailing list Rhl-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/rhl-devel-list
-- Rhl-devel-list mailing list Rhl-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/rhl-devel-list
Stephen Smoogen wrote:
Is it is simple to rename .snapshot to soemthing else. The NFS server is a netapp :)
Not really sure what you are asking. /.snapshot is a directory on the client that mounts a client specific directory on the server. The server directories could be on a netapp server, but you would then have the problem of upgrading over NFS. One other solution would be to have a Diskfull machine that you could upgrade and the rsync to the netapp server.
On Thu, 2003-07-24 at 10:11, Daniel J Walsh wrote:
This diskless is a single /root directory containing all files and a /.snapshot directory containing files that are specific to the client. (A very small subset). It then uses mount -o bind to mount the snapshot files over the /root files on the client. You need to do a chroot on the server to up2date it or rpm install it. It will not support older versions of RH. It should work on RH9 or greater and it might work on RH8.
Dan
Stephen Smoogen wrote:
Thanks I will try to look at this next week. What I am trying to figure out is the best/fastest way to set up new diskless clients that have 'full' installs.
Currently we have two systems here.
The first is where /usr and some other directories are stored on the master tree and then the few remaining (/lib /var /etc /initrd etc) are seperate per machine. This is very fast to bring up a new machine because the date to be copied is small (20-40 megs on average). However it is a pain in the ass to update as all the clients have to be rebuilt after errata that change /etc, /lib etc occur.
The second is much more disk intensive but easier to maintain. In this version each client gets a complete install in an NFS tree. This allows for a lot of customization per client (some can run 7.1 while others run 9.0). Maintenance is much easier because RPM can be run on each of the trees seperately. However installs are SLOW because they are either server side using a chroot anaconda (which I havent gotten working seamlessly) or the client is doing all the writes via NFS.
On Thu, 2003-07-24 at 07:23, Daniel J Walsh wrote:
I have been working on a package called redhat-config-netboot that allows you to setup diskless environments using NFS, as well as network installations. It is based somewhat off of LTSB. It is basically a series of scripts and python code that sets up a PXE boot environment and an diskless NFS partition.
ftp://people.redhat.com/dwalsh/netboot
Comments welcome.
Dan
Chuck Wolber wrote:
No we do everything via NFS at the moment. Using a big ramdisk would cut into why all the machines have so much memory and CPU's. Basically the idea is that all CPU cycles are local and all data is foreign. The approach to this seems to follow either SGI or Sun ways of doing diskless clients. I like the Sun way of doing it (with each client getting its own tree) versus the SGI where most is common with the server and clients need a rebuild if server code changes.
Can a user move to another workstation and resume their session? I've seen this done with RFID tags that automatically detach your session if you move away from the terminal and re-attach you when you move closer.
-Chuck
-- Rhl-devel-list mailing list Rhl-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/rhl-devel-list
-- Rhl-devel-list mailing list Rhl-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/rhl-devel-list
On Thu, 2003-07-24 at 11:12, Daniel J Walsh wrote:
Stephen Smoogen wrote:
Is it is simple to rename .snapshot to soemthing else. The NFS server is a netapp :)
Not really sure what you are asking. /.snapshot is a directory on the client that mounts a client specific directory on the server. The server directories could be on a netapp server, but you would then have the problem of upgrading over NFS. One other solution would be to have a Diskfull machine that you could upgrade and the rsync to the netapp server.
The main reasons were to try and do as much over NFSv3 with TCP as possible. We have found that the clients (400+ workstations) perform much better when we put as much on a netapp as possible and mount things as v3-tcp when possible.
Sorry for not saying that earlier.
I have been working on a package called redhat-config-netboot that allows you to setup diskless environments using NFS, as well as network installations. It is based somewhat off of LTSB. It is basically a series of scripts and python code that sets up a PXE boot environment and an diskless NFS partition.
ftp://people.redhat.com/dwalsh/netboot
Comments welcome.
Pretty intuitive and straightforward approach. If I read your README correctly, it looks as if you install an OS on a machine that will be a similar configuration to the diskless machines and then upload that image at boot time to the diskless clients.
My only comment so far is, why are you locking things down by MAC address? Wouldn't end user authentication be a more appropriate method (RFID is what comes to mind, but PAM is a good abstraction model)? It seems like you're really marrying the hardware to the software in several ways. Why can't I boot from a floppy and load my workstation image onto my laptop (which happens to have 1GB of RAM) if I'm in a meeting "down the hall" without having to update a dhcpd.conf file.
-Chuck
Chuck Wolber wrote:
I have been working on a package called redhat-config-netboot that allows you to setup diskless environments using NFS, as well as network installations. It is based somewhat off of LTSB. It is basically a series of scripts and python code that sets up a PXE boot environment and an diskless NFS partition.
ftp://people.redhat.com/dwalsh/netboot
Comments welcome.
Pretty intuitive and straightforward approach. If I read your README correctly, it looks as if you install an OS on a machine that will be a similar configuration to the diskless machines and then upload that image at boot time to the diskless clients.
My only comment so far is, why are you locking things down by MAC address? Wouldn't end user authentication be a more appropriate method (RFID is what comes to mind, but PAM is a good abstraction model)? It seems like you're really marrying the hardware to the software in several ways. Why can't I boot from a floppy and load my workstation image onto my laptop (which happens to have 1GB of RAM) if I'm in a meeting "down the hall" without having to update a dhcpd.conf file.
-Chuck
I am locking the system to an IP Address, nothing more. The reason for this is so that the machine boots the same every time, unless the sysadmin changes the boot configuration file (PXE File). This way there is consistancy between boots, like there would be in a diskfull system. The client uses the IP Address to find the system specific data on the server. I can't use the authentication because there is no gaurantee that anyone is even going to be logging into the machine (think blade servers). Also a lot of the system specific information is required long before the login prompt happens.
One interesting point that people keep bringing up is the idea of having the entire operating system in RAM instead of using NFS. In this situation you would get a completely fresh machine on every reboot, ie there would be nothing retained between boots. Might be an interesting experiment to try.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
redhat-config-netboot is included in Taroon (it is even mentioned in the README file). Any chance this will be added to Severn too?
Michael
On Thu, 24 Jul 2003, Daniel J Walsh wrote:
I have been working on a package called redhat-config-netboot that allows you to setup diskless environments using NFS, as well as network installations. It is based somewhat off of LTSB. It is basically a series of scripts and python code that sets up a PXE boot environment and an diskless NFS partition.
ftp://people.redhat.com/dwalsh/netboot
Comments welcome.
Dan
Chuck Wolber wrote:
No we do everything via NFS at the moment. Using a big ramdisk would cut into why all the machines have so much memory and CPU's. Basically the idea is that all CPU cycles are local and all data is foreign. The approach to this seems to follow either SGI or Sun ways of doing diskless clients. I like the Sun way of doing it (with each client getting its own tree) versus the SGI where most is common with the server and clients need a rebuild if server code changes.
Can a user move to another workstation and resume their session? I've seen this done with RFID tags that automatically detach your session if you move away from the terminal and re-attach you when you move closer.
-Chuck
- -- Michael Redinger Zentraler Informatikdienst (Computer Centre) Universitaet Innsbruck Technikerstrasse 13 Tel.: ++43 512 507 2335 6020 Innsbruck Fax.: ++43 512 507 2944 Austria Mail: Michael.Redinger@uibk.ac.at BB98 D2FE 0F2C 2658 3780 3CB1 0FD7 A9D9 65C2 C11D http://www.uibk.ac.at/~c102mr/mred-pubkey.asc
On Wed, 2003-07-23 at 15:33, Paul Iadonisi wrote:
- Is it reasonable to ask for a change to anaconda to allow for these
rpms to be installed in this alternate root? It would probably be an invasive change, as it's not currently done anywhere in anaconda, to the best of my knowledge, except that the actually installer *does* in fact install the entire distribution into an alternate root (after, how else would you do it?). What's different is that now I'm asking for anaconda to switch gears in the middle of the installation and install a specific list of packages in a different alternate root.
I don't know if it can be done with Anaconda, but you should be able to build the tree by relocating packages, if the packages are built properly and permit relocation. If memory serves, most don't however, which makes relocation mostly useless in these cases. I wonder if it would be horribly broken to change that, perhaps by giving a default Prefix of '/'. This would let you more easily built a tree not intended to be used localy.
I can see another benefit of being able to more easily relocate packages: It makes building chroot jails much easier, esp for things that depend on a number of libraries, such as ucd-snmpd.
I wonder if it would be possible to specify that a package depends not only on a package name and version, but also that package being installed in a relocated place? I'm thinking of something like:
Requires: foo >= x.y; prefix=/var/chroot/bar, baz
(This is this inverse of the way we'd use commas and semi-colons in English, but the comma is already in use and I can't think of a better separator.)
Wil
-
Chuck Wolber -
Daniel J Walsh -
Michael Redinger -
Paul Iadonisi -
Stephen Smoogen -
Wil Cooley