-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 John Summerfied wrote: |> A while ago I promised to post a lengthy description of a design I |> use in our z/VM environment, which is based on SLES9 and makes it |> possible to have z/VM users sharing complete root and /boot |> partitions and "own" as little as two MDISKs (or more, two is |> minimum), a 70-cylinder /srv containing /etc, and a 660 cylinder |> /var. | | How big is /etc in megabytes? I looked at mine (peecee) and its | rather larger than I expected at 89 Mbytes, but 49 of this is | Gconf:-(
Um, yes. :) I refuse to install anything related to X11R6 on z/Linux users, as it has absolutely no place there, with the possible exception of core X11 libraries (needed for some Java-based installers, which will unfortunately refuse to work in headless environments) and whatever is needed to get the YaST2 GUI ticking. Even that second bit is, IMNSHO, absolutely over the top, and I'll only do it at gunpoint (or our IBM accounts kindly suggesting this is the only way our SLES maintenance agreement still holds :)). With a really large heap of packages installed (I obviously want to have as much as possible available on the master image, as there's no way for me to differentiate between users with regard to "system" software, that is, the alotted contents of SLES install media going to root, /usr and /opt filesystems), but no Gnome or KDE, of course, the /etc on my z/Linux users never exceeds 18MB, which gives more than plenty of space for the root user's home directory and the standard /srv/www and /srv/ftp (however they come, I don't even poke them) on the /srv partition I use to store /etc on. 70 ECKD MDISK cylinders will amount to approximately 48MB when the filesystem has been created. | Is it small enough you could use a ram disk or tempfs, and create the | customised version at IPL time with a per-host patch? I do admit I've been playing with several ideas, ranging from specifying whatever one needs to be able to configure individual users at boot time, to even having the users autoconfigure from their OSA MAC IDs, suspending any need to have boot-time parameters at all and just never bother with per-user /etc directories, etc., but the harsh reality is, I will want to tweak /etc/sysconfig/kernel and /etc/sysctl.conf at the very least, in accordance with the workload of an individual user, not to mention all the different services I may be running on one, but not on others. So, while your idea is quite plausible if you're running a farm of Linux users that perform the same job, such as for the purpose of high availability and/or load balancing, I gave that thought up in favor of a slightly more flexible setup which enables me to deploy all hosts in an identical, known state and then work my way up (apart? :)) from there. That is also the precise reason why I don't run any services apart from ssh on the LNXMAINT user, infact I seldomly even log it on: I want to have some level ground to start a new user on, then disable, enable, configure, misconfigure, relax or strengthen a single cloned user to my heart's (and the job's) desires. | You'd need to make a special arrangement for your ssh keys and | changes, maybe regenerate the patch on demand (or on a crontab) and | at shutdown. Or even use the good, old diskless boot strategy: a trusted FTP (*not* TFTP, of course) server to copy the per-user files from upon boot and use them to populate a V-DISK, of course. Your imagination (and bash scripting knowledge :)) is the limit. Hope this helped, - -- ~ Grega Bremec ~ gregab at p0f dot net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFD1Vz7fu4IwuB3+XoRAyfqAJ97WB3FAsOI6uVNg1aDuoWtPANjAwCfYu4i kO8kSCiTevFxnkM6qPWlfa8= =N8Xt -----END PGP SIGNATURE----- ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
