Michael Schloh von Bennewitz wrote: > > On Wed, Jul 30, 2003, Bernd Dammann wrote: > > The bootstrap process adds "/lib/openpkg/bash" to /etc/shells, > > without checking if this files exists or not. Since there is default > > /etc/shells under Solaris 9, the file gets created with a single line > > only, rendering the system useless to e.g. login by other users than > > root (provided the login procedure does check /etc/shells, but XDM and > > ftp do!). > > > Hello Bernd, > > I believe that something has gone wrong during your OpenPKG bootstrap. > It should indeed create or append the local OpenPKG bash path to /etc/shells, > however the path should be valid. For example, if you bootstrap using > --prefix=/cw then the entry in /etc/shells should be /cw/lib/openpkg/bash. > > In your case the prefix '/cw/' (or whatever you chose when bootstrapping) was > truncated, and this is actually the problem to fix. To troubleshoot this, run > the bootstrap again and capture the scrolling text using 'tee' or 'script'. > Search for a line something like: > > echo /cw/lib/openpkg/bash >>/etc/shells > > and let me know what you see there. Good luck. > > Michael >
Hi, I think it should read 'Since there is NO default /etc/shells ...'. If /etc/shells is missing, then the system uses a default set of shells. Which shells are used as default should be mentioned in some man pages (man shells ?). So no user will be able to login if his/her shell is not listed in /etc/shells if this file exists. If the OpenPKG bootstrap process simply creates the file when it doesn't find one, then beginning from this time on /etc/shells is used for validating the possible shells. As only the OpenPKG version of bash is listed in this file then only this shell is allowed and no user will be able to login except root (and users who use this shell, which is rather unlikey directly after bootstrapping). To deal with this kind of problem, the bootstrap process should first check for the existance of /etc/shells and in case no /etc/shells exists issue a warning and maybe create an additional file /etc/shells.openpkg containing the OpenPKG bash. This file could then be added to a manually created /etc/shells. In this case the sysadmin has control over the machine in any case. Another solution would be to create the missing /etc/shells containing the system default shells and the additional OpenPKG bash. But this would be more difficult because you have to know all the default shells of all supported systems, so a warning and a separate file should be ok. Regards, Stefan ______________________________________________________________________ The OpenPKG Project www.openpkg.org User Communication List [EMAIL PROTECTED]
