Qmail Solaris 9 x86
 

To install qmail on a Solaris 9 x86 box I replaced the default shell "/usr/bin/sh" with "/usr/bin/bash" by issuing the commands "mv /usr/bin/sh /usr/bin/sh.old" and "ln -s /usr/bin/bash /usr/bin/sh". Anybody know how this may affect the system? What affect if any, will it have on the installation of standard SUNW packages? Is "bourne again" backwards compatible with the bourne shell?

sh is one of those statically linked binaries that is very important if something goes awry on your system and you are booting into single user mode. Whether or not it will affect your systems operation will depend on how bash is built and how you partitioned your system. Why didn't you just modify the Qmail stuff to use bash?

actually I think that is the /sbin/sh program that is the one that you want to run for single user mode. That should be the statically linked version. And yes, bash claims to be backward compatible with the original Bourne shell.

The package is daemontools-0.76, while unpacking the archive "automake" generates the "Makefile" which calls the standard shell "/bin/sh"( which is a symlink to "/usr/bin/sh" after compiling and installing, the software is incorrectly configured. Part of the program is executed by "init", every few minutes "init" echo's an error at the console stating that the "Command is respawning too rapidly". An alternative workaround suggested placing ">/dev/null" after the command in "/etc/inittab" but "ps -ef | grep command" shows that the program is not running, a google search turned up these points;

* init runs actions in inittab without any open descriptor.

* When /bin/sh opens "command", it gets 0 as the
descriptor associated with that file.

* Executing svscanboot, sh redirects descriptor 0 to
/dev/null (as instructed in svscanboot, line 6); the
next read attempt from svscanboot will result in an EOF.

* Since sh reads svscanboot with a 128-byte buffer, it
only sees the first 256 bytes of svscanboot.

The problem seems to be with the bourne shell? I did try with a standard account and set the shell "usermod -s /usr/bin/bash user" but the same error appeared. I had thought of modifying the scripts in daemontools, but I wanted a fast(lazy) workaround, this works ok, but I have not yet put the mail server into production.

Argh. Forgot the static stuff is in /sbin.

Single user mode runs the su shell variable. For example here I have the root account set to use "bash" at level 1 "env" command returns "SHELL=/usr/bin/bash". Any suggestions regarding the workaround? Any alternatives?

I'm kinda shooting in the dark here, but have you checked out the /etc/default/init file.
Is there anything in there that you could set that would assist with your command spawning from inittab?
I have found certain startup scripts need environment variables defined in that file in order to execute properly.

#ident "@(#)init.dfl 1.6 00/05/27 SMI"
#
# This file is /etc/default/init. /etc/TIMEZONE is a symlink to this file.
# This file looks like a shell script, but it is not. To maintain
# compatibility with old versions of /etc/TIMEZONE, some shell constructs
# (i.e., export commands) are allowed in this file, but are ignored.
#
# Lines of this file should be of the form VAR=value, where VAR is one of
# TZ, LANG, CMASK, or any of the LC_* environment variables.
#
TZ=Europe/Stockholm
CMASK=022
LC_COLLATE=da_DK.ISO8859-1
LC_CTYPE=da_DK.ISO8859-1
LC_MESSAGES=C
LC_MONETARY=da_DK.ISO8859-1
LC_NUMERIC=da_DK.ISO8859-1
LC_TIME=da_DK.ISO8859-1

Not too sure if it will do the job, here is an example of a "/etc/default/init" from a Solaris 9 box, as you can see it mentions the use of shell variables, but it says they are ignored. I think I'll stick it out as is.