Re: More NSS Info
Would it not be sufficient to create the NSS with just the boot disk and maybe swap configured in on the kernel parameter line, and then using something very early on in the boot process to add the other disks using /proc/dasd/devices? It might take some work to get the NSS and RO boot disk just right for this to work, but it would make it a lot more flexible. Kris On Fri, Nov 08, 2002 at 10:43:15AM -0500, Adam Thornton wrote: I don't have the faintest idea why IBM claims that you have to have an identical DASD layout on all machines that share an NSS. Admittedly cursory testing seems to show that your NSS will have whatever parameter line you burned into it, which does specify a range of devices. But not only can those devices change size (I tested this with an ext3 and a swap filesystem), if you boot without a listed device, the only problem you will have that I could find was that you may trip over it in /etc/fstab. But if you have a disk that's not in /etc/fstab, which you detach before IPL, you can re-link and then access that disk pefectly normally from Linux (using the console or hcp to perform the link). So it's looking to *me* like you should pick a lowest-common-denominator disk layout (for most of our guests, that'd be / on 150, swap on VDISK on 151, and /usr on 152), build the NSS with as small a storage size as you can (24M works for us) and then not worry about it. If anyone can tell me why I'm wrong, and that, although I have mounted differently-sized disks, I'm heading for fatal filesystem corruption just around the corner, I'd appreciate it. Adam -- Never underestimate a Mage with: - the Intelligence to cast Magic Missile, - the Constitution to survive the first hit, and - the Dexterity to run fast enough to avoid being hit a second time.
Re: More NSS Info
You would need at least one non-root/swap address mounted as /config or something for storing the configuration of what goes where, and you'd have to move at least a few of the utilities (eg mount, ifconfig, etc) from /usr to /sbin (generating statically linked versions) and include /sbin in the root filesystem. Much as I dislike Solaris, their diskless workstation filesystem layout is a pretty good model for this. We should use that as a model for ideas. -- db David Boyes Sine Nomine Associates -Original Message- From: Linux on 390 Port [mailto:LINUX-390;VM.MARIST.EDU]On Behalf Of Kris Van Hees Sent: Friday, November 08, 2002 11:00 AM To: [EMAIL PROTECTED] Subject: Re: More NSS Info Would it not be sufficient to create the NSS with just the boot disk and maybe swap configured in on the kernel parameter line, and then using something very early on in the boot process to add the other disks using /proc/dasd/devices? It might take some work to get the NSS and RO boot disk just right for this to work, but it would make it a lot more flexible. Kris On Fri, Nov 08, 2002 at 10:43:15AM -0500, Adam Thornton wrote: I don't have the faintest idea why IBM claims that you have to have an identical DASD layout on all machines that share an NSS. Admittedly cursory testing seems to show that your NSS will have whatever parameter line you burned into it, which does specify a range of devices. But not only can those devices change size (I tested this with an ext3 and a swap filesystem), if you boot without a listed device, the only problem you will have that I could find was that you may trip over it in /etc/fstab. But if you have a disk that's not in /etc/fstab, which you detach before IPL, you can re-link and then access that disk pefectly normally from Linux (using the console or hcp to perform the link). So it's looking to *me* like you should pick a lowest-common-denominator disk layout (for most of our guests, that'd be / on 150, swap on VDISK on 151, and /usr on 152), build the NSS with as small a storage size as you can (24M works for us) and then not worry about it. If anyone can tell me why I'm wrong, and that, although I have mounted differently-sized disks, I'm heading for fatal filesystem corruption just around the corner, I'd appreciate it. Adam -- Never underestimate a Mage with: - the Intelligence to cast Magic Missile, - the Constitution to survive the first hit, and - the Dexterity to run fast enough to avoid being hit a second time.
Re: More NSS Info
If you put something like cmsfs or hcp on the root disk, you should have enough to read a config file from the CMS A-disk and use information in there to do the dynamic configuration of the disks. Despite what Sun Microsystems did with linking /usr/bin and /usr/sbin into the root filesystem as /bin and /sbin, a more sensible setup is still to have the core utilities that are required to boot a system (and to do basic maintenance) as part of the actual root partition. I've banged my head against that stupidity in Solaris more than once when a disk that held /usr happened to die. Especially when you do not have a CDROM to boot the install media from. Kris On Fri, Nov 08, 2002 at 11:23:25AM -0500, David Boyes wrote: You would need at least one non-root/swap address mounted as /config or something for storing the configuration of what goes where, and you'd have to move at least a few of the utilities (eg mount, ifconfig, etc) from /usr to /sbin (generating statically linked versions) and include /sbin in the root filesystem. Much as I dislike Solaris, their diskless workstation filesystem layout is a pretty good model for this. We should use that as a model for ideas. -- db David Boyes Sine Nomine Associates -Original Message- From: Linux on 390 Port [mailto:LINUX-390;VM.MARIST.EDU]On Behalf Of Kris Van Hees Sent: Friday, November 08, 2002 11:00 AM To: [EMAIL PROTECTED] Subject: Re: More NSS Info Would it not be sufficient to create the NSS with just the boot disk and maybe swap configured in on the kernel parameter line, and then using something very early on in the boot process to add the other disks using /proc/dasd/devices? It might take some work to get the NSS and RO boot disk just right for this to work, but it would make it a lot more flexible. Kris On Fri, Nov 08, 2002 at 10:43:15AM -0500, Adam Thornton wrote: I don't have the faintest idea why IBM claims that you have to have an identical DASD layout on all machines that share an NSS. Admittedly cursory testing seems to show that your NSS will have whatever parameter line you burned into it, which does specify a range of devices. But not only can those devices change size (I tested this with an ext3 and a swap filesystem), if you boot without a listed device, the only problem you will have that I could find was that you may trip over it in /etc/fstab. But if you have a disk that's not in /etc/fstab, which you detach before IPL, you can re-link and then access that disk pefectly normally from Linux (using the console or hcp to perform the link). So it's looking to *me* like you should pick a lowest-common-denominator disk layout (for most of our guests, that'd be / on 150, swap on VDISK on 151, and /usr on 152), build the NSS with as small a storage size as you can (24M works for us) and then not worry about it. If anyone can tell me why I'm wrong, and that, although I have mounted differently-sized disks, I'm heading for fatal filesystem corruption just around the corner, I'd appreciate it. Adam -- Never underestimate a Mage with: - the Intelligence to cast Magic Missile, - the Constitution to survive the first hit, and - the Dexterity to run fast enough to avoid being hit a second time. -- Never underestimate a Mage with: - the Intelligence to cast Magic Missile, - the Constitution to survive the first hit, and - the Dexterity to run fast enough to avoid being hit a second time.
Re: More NSS Info
On Fri, 8 Nov 2002, David Boyes wrote: Much as I dislike Solaris, their diskless workstation filesystem layout is a pretty good model for this. We should use that as a model for ideas. They also demonstrated the first shared /usr implementation. They also do something I call folding (for lack of terminology) of /bin and /lib into /usr which works nicely for Linux (with care). There is a lot we can learn from Sun. But speaking of all this config and NSS and booting, I'm going to say it again: we need the STM trick in the kernel start. Sometime AFTER the stop at 0x01 STM 0,15,VMPARM then shortly later read from sacred 64-byte area VMPARM in the regular parm processing. (the VMPARM chunk is guaranteed to be EBCDIC, translate to ASCII, override that which the bootstrap loaded (that is, the parm *file*)) It is positively insane that we do not have this support already. Some examples: # adjust your DASD addresses from default hcp ipl linux dasd=400-40f # select a different root from the default hcp ipl linux root=/dev/dasdc1 # prep to load a DCSS maybe hcp def stor 512M ipl linux mem=256M While non-VM Linux cannot use this, it is no harm to have the support in there.
Re: More NSS Info
You mean set up a Linux NSS like we do a CMS NSS? When you IPL the CMS NSS it expects 190 to be the boot disk, 19E to be the CMS equivalent of /usr and 191 to contain the configuration files. When it comes up the first thing CMS does is to run the PROFILE EXEC on the 191 disk. The commands to access any other disks and load any needed extensions are in that file. You can place any CP or CMS commands you want to in the PROFILE EXEC and they will be run whenever CMS starts up in that virtual machine. Stephen Frazier Oklahoma Department of Corrections -Original Message- From: [EMAIL PROTECTED] [mailto:owner-linux-390;VM.MARIST.EDU]On Behalf Of Kris Van Hees Sent: Friday, November 08, 2002 10:00 AM To: Linux on 390 Port Subject: Re: More NSS Info Would it not be sufficient to create the NSS with just the boot disk and maybe swap configured in on the kernel parameter line, and then using something very early on in the boot process to add the other disks using /proc/dasd/devices? It might take some work to get the NSS and RO boot disk just right for this to work, but it would make it a lot more flexible. Kris On Fri, Nov 08, 2002 at 10:43:15AM -0500, Adam Thornton wrote: I don't have the faintest idea why IBM claims that you have to have an identical DASD layout on all machines that share an NSS. Admittedly cursory testing seems to show that your NSS will have whatever parameter line you burned into it, which does specify a range of devices. But not only can those devices change size (I tested this with an ext3 and a swap filesystem), if you boot without a listed device, the only problem you will have that I could find was that you may trip over it in /etc/fstab. But if you have a disk that's not in /etc/fstab, which you detach before IPL, you can re-link and then access that disk pefectly normally from Linux (using the console or hcp to perform the link). So it's looking to *me* like you should pick a lowest-common-denominator disk layout (for most of our guests, that'd be / on 150, swap on VDISK on 151, and /usr on 152), build the NSS with as small a storage size as you can (24M works for us) and then not worry about it. If anyone can tell me why I'm wrong, and that, although I have mounted differently-sized disks, I'm heading for fatal filesystem corruption just around the corner, I'd appreciate it. Adam -- Never underestimate a Mage with: - the Intelligence to cast Magic Missile, - the Constitution to survive the first hit, and - the Dexterity to run fast enough to avoid being hit a second time.
Re: More NSS Info
If you use the cmsfs stuff, that information can all be on the 191 disk and read by the startup scripts. What about a CMSFS that can do directories and specials (device files) akin to the UMSDOS hack?
Re: More NSS Info
On Fri, 8 Nov 2002, Kris Van Hees wrote: Despite what Sun Microsystems did with linking /usr/bin and /usr/sbin into the root filesystem as /bin and /sbin, a more sensible setup is still to have the core utilities that are required to boot a system (and to do basic maintenance) as part of the actual root partition. Yes and no. I mean, you are most certainly correct that we need these core utilities in the root. But I suggest that we have them placed under their /usr paths where /usr will get overmounted later. I've done this for years and never had problems from Linux with it. I've banged my head against that stupidity in Solaris more than once when a disk that held /usr happened to die. What a shame. I can see how frustrating that would be! Still, the scheme itself is good. It's just the implementation that fell apart. In the case you mention having something more than an empty directory at /usr in the root should make your problem go away.
Re: More NSS Info
On Fri, Nov 08, 2002 at 10:58:30AM -0600, Rick Troth wrote: If you use the cmsfs stuff, that information can all be on the 191 disk and read by the startup scripts. What about a CMSFS that can do directories and specials (device files) akin to the UMSDOS hack? If you create a CMS file called PROGRA~1 DIR I'll have to murder you. Just so you know. Other than that, sure, sounds like a plan--I assume you mean that you use some filesystem convention like a file which always has some particular name, which contains a CMS filename to Unix directory mapping? Adam
Re: More NSS Info
On Fri, Nov 08, 2002 at 01:15:01PM -0500, Adam Thornton wrote: On Fri, Nov 08, 2002 at 10:58:30AM -0600, Rick Troth wrote: If you use the cmsfs stuff, that information can all be on the 191 disk and read by the startup scripts. What about a CMSFS that can do directories and specials (device files) akin to the UMSDOS hack? If you create a CMS file called PROGRA~1 DIR I'll have to murder you. Just so you know. Other than that, sure, sounds like a plan--I assume you mean that you use some filesystem convention like a file which always has some particular name, which contains a CMS filename to Unix directory mapping? Perhaps (though it might be more work) use the same naming convention as is used to encode long filenames on the ISO9660 filesystem, just to stick to a well known and accepted convention? I would *love* to see a CMSFS that can support things like device files so we can finally put /dev somewhere other than the root filesystem, so / can truly be made RO. I worked on that using initrd, but cmsfs would be so much nicer (as long as it is efficient). Then again, if devfs keeps going the way it is, the need for a writable /dev may finally disappear! I do fear though that it won't go all the way :( Kris
Re: More NSS Info
David Boyes writes: You would need at least one non-root/swap address mounted as /config or something for storing the configuration of what goes where, and you'd have to move at least a few of the utilities (eg mount, ifconfig, etc) from /usr to /sbin (generating statically linked versions) and include /sbin in the root filesystem. The basevol+guestvol environment I describe in the ...zSeries...Large Scale Linux Deployment redbook (SG246824) (I really ought to bind that phrase to a single keystroke :-) lets you have a readonly root filesystem which is linked to (readonly) and booted by any number of clones. The boot process then mounts a (potentially very) small guest-specific readwrite volume (whatever disk is at devno 777) and binds all the necessary writable directories into the filesystem. Other parts of the redbook then describe how you can then bootstrap yourself to get other information (via a PROP guest and then via LDAP). We can do better than Sun since we have shared disks in known, manageable namespaces at boot time and since we have Al Viro's namespace support in Linux for bind mounts (again, described in the redbook for those unfamiliar with the concept). [Next is updates-in-place with CLONE_NEWNS and pivot_root() and/or immediate kernel-to-kernel reboots when kexec() is stable...] I'll set up the NSS stuff on my own VM system and get it to work nicely with basevol+guestvol (which I've just got working properly with SuSE SLES7; the original redbook environment having some dependencies on the RedHat boot scripts). --Malcolm -- Malcolm Beattie [EMAIL PROTECTED] Linux Technical Consultant IBM EMEA Enterprise Server Group... ...from home, speaking only for myself
Re: More NSS Info
On Fri, Nov 08, 2002 at 11:23:25AM -0500, David Boyes wrote: You would need at least one non-root/swap address mounted as /config or something for storing the configuration of what goes where, and you'd have to move at least a few of the utilities (eg mount, ifconfig, etc) from /usr to /sbin (generating statically linked versions) and include /sbin in the root filesystem. What distribution are you using which places these utilities in /usr? Those utilities are (or may be) required in order to mount /usr. Also, they should not need to be statically linked, as they should only be linked with libraries in /lib. -- - mdz
Re: More NSS Info
On Fri, Nov 08, 2002 at 10:52:52AM -0600, Rick Troth wrote: On Fri, 8 Nov 2002, David Boyes wrote: Much as I dislike Solaris, their diskless workstation filesystem layout is a pretty good model for this. We should use that as a model for ideas. They also demonstrated the first shared /usr implementation. They also do something I call folding (for lack of terminology) of /bin and /lib into /usr which works nicely for Linux (with care). There is a lot we can learn from Sun. This folding, as far as I know, is just a couple of symlinks, from /bin to /usr/bin and from /lib to /usr/lib. Doing the same thing on a typical Linux system would be problematic, since generally /bin and /lib are expected to be present on the root filesystem (mount, for example, is typically in /bin). -- - mdz
Re: More NSS Info
On Fri, Nov 08, 2002 at 12:24:13PM -0500, Kris Van Hees wrote: I would *love* to see a CMSFS that can support things like device files so we can finally put /dev somewhere other than the root filesystem, so / can truly be made RO. I worked on that using initrd, but cmsfs would be so much nicer (as long as it is efficient). Then again, if devfs keeps going the way it is, the need for a writable /dev may finally disappear! I do fear though that it won't go all the way :( /dev doesn't prevent / from being read-only. devfs sidesteps this problem entirely, and with a normal /dev, device nodes are generally static. If you consider it to be useful, it is not too complex to run Linux with a read-only root filesystem. -- - mdz
Re: More NSS Info
You would need at least one non-root/swap address mounted as /config or something for storing the configuration of what goes where, and you'd have to move at least a few of the utilities (eg mount, ifconfig, etc) from /usr to /sbin (generating statically linked versions) and include /sbin in the root filesystem. What distribution are you using which places these utilities in /usr? Sorry, finger check. I date back far enough that everything was in or near /usr... thanks. Meant to say from their default location. Also, they should not need to be statically linked, as they should only be linked with libraries in /lib. This I would argue about. Why should I need /lib and dynamic library support at a point where the system is still initializing? What if I want to mount /lib from another disk? If I have the absolutely critical utilities available in a statically linked version, I need only a root file system containing the critical static binaries and a kernel and minimal configuration info. -- - mdz
Re: More NSS Info
On Fri, Nov 08, 2002 at 02:16:47PM -0500, Matt Zimmerman wrote: On Fri, Nov 08, 2002 at 12:24:13PM -0500, Kris Van Hees wrote: I would *love* to see a CMSFS that can support things like device files so we can finally put /dev somewhere other than the root filesystem, so / can truly be made RO. I worked on that using initrd, but cmsfs would be so much nicer (as long as it is efficient). Then again, if devfs keeps going the way it is, the need for a writable /dev may finally disappear! I do fear though that it won't go all the way :( /dev doesn't prevent / from being read-only. devfs sidesteps this problem entirely, and with a normal /dev, device nodes are generally static. If you consider it to be useful, it is not too complex to run Linux with a read-only root filesystem. I worked on a RO / before (presented briefly at SHARE in TN), and unfortunately Linux has (or had - they may have fixed it) a C library that usesthe Unix domain socket /dev/log for syslog handling, and that one is created dynamically at each boot. The introduction of devfs and possible changes to glibc may have removed that limitation (which would be a GOOD thing). Kris
Re: More NSS Info
On Fri, Nov 08, 2002 at 03:09:54PM -0500, Kris Van Hees wrote: I worked on a RO / before (presented briefly at SHARE in TN), and unfortunately Linux has (or had - they may have fixed it) a C library that usesthe Unix domain socket /dev/log for syslog handling, and that one is created dynamically at each boot. The introduction of devfs and possible changes to glibc may have removed that limitation (which would be a GOOD thing). devfs solves this of course, but even without it, there are other ways to approach the problem. For example, using a ramdisk or other storage for the full /dev, keeping only a minimal, static /dev on the real root filesystem. devfs seems to work fine on s390, though, so that seems like the most straightforward solution. -- - mdz
Re: More NSS Info
If you create a CMS file called PROGRA~1 DIR I'll have to murder you. ;-) Just so you know. Other than that, sure, sounds like a plan--I assume you mean that you use some filesystem convention like a file which always has some particular name, which contains a CMS filename to Unix directory mapping? Yep.
Re: More NSS Info
On Fri, Nov 08, 2002 at 02:44:19PM -0500, David Boyes wrote: What distribution are you using which places these utilities in /usr? Sorry, finger check. I date back far enough that everything was in or near /usr... thanks. Meant to say from their default location. I do not date back very far in UN*X years, so I do not speak from first-hand experience, but I have the distinct impression that /bin predates /usr/bin. SunOS/Solaris, though, has lacked a separate /bin for a long time, but I believe even it originally had one. Also, they should not need to be statically linked, as they should only be linked with libraries in /lib. This I would argue about. Why should I need /lib and dynamic library support at a point where the system is still initializing? What if I want to mount /lib from another disk? If I have the absolutely critical utilities available in a statically linked version, I need only a root file system containing the critical static binaries and a kernel and minimal configuration info. You don't need shared libraries to run your system at all. However, they are beneficial for many reasons, and most of those reasons hold for things which live on the root filesystem. If you want to mount /lib from another disk, you must (at least) be sure that you don't require _any_ loadable kernel modules to get to that point, and that every executable along the way is statically linked. If you are willing to pay the price in maintainability, it is of course possible. If you have the absolutely critical utilities available in a dynamically linked version, you need only a root filesystem containing the critical static binaries and a kernel and minimal configuration info and the shared libraries (usually only libc). Personally, my preference is to run with dynamically linked executables, and to use a statically linked copy of busybox or sash for recovery purposes. One can boot such a system using only the kernel and a single user executable if necessary. -- - mdz
Re: More NSS Info
This folding, as far as I know, is just a couple of symlinks, from /bin to /usr/bin and from /lib to /usr/lib. Doing the same thing on a typical Linux Specifically, running 'ls -l' in root, you see bin - usr/bin lib - usr/lib If memory serves, you do NOT usually see sbin - usr/sbin. system would be problematic, since generally /bin and /lib are expected to be present on the root filesystem (mount, for example, is typically in /bin). No. Not a problem. It DOES work. I've done it. What you do is have /usr populated with bin and lib and minimal contents. Those are available at boot time. Later, when /usr is mounted over this non-empty directory, life continues without catastrophe and the new files are used when next invoked. (The old copies are hidden and can no longer be referenced. But no one misses them!) It works.
Re: More NSS Info
Hello from Gregg C Levine And if you murder him, I'll be forced to use my Jedi Knight functions to send you to Kessel. Just going along with it, Rick. --- Gregg C Levine [EMAIL PROTECTED] The Force will be with you...Always. Obi-Wan Kenobi Use the Force, Luke. Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) -Original Message- From: Linux on 390 Port [mailto:LINUX-390;VM.MARIST.EDU] On Behalf Of Rick Troth Sent: Friday, November 08, 2002 4:42 PM To: [EMAIL PROTECTED] Subject: Re: [LINUX-390] More NSS Info If you create a CMS file called PROGRA~1 DIR I'll have to murder you. ;-) Just so you know. Other than that, sure, sounds like a plan--I assume you mean that you use some filesystem convention like a file which always has some particular name, which contains a CMS filename to Unix directory mapping? Yep.
