starting ssh early in boot
By Liane Praza-Oracle on Jun 27, 2006
It's nice that as of Solaris 9,
ssh is included in Solaris. We've always started it late,
though. That's a conscious decision made by the
ssh team to include dependencies which mean
that it won't start until all local and network services any user might need, including remote filesystems, are available.
This is great for interactive environments with many home directories stored on the network. Your users don't end up with spurious and surprising home directory not available messages if you try to log in too early during the boot process. But, if you've got a server stranded in a co-lo many miles away, this might not be what you want. You may want ssh to start up as soon as the root filesystem and basic networking are available, and be available if you boot to single-user mode. Here's how for Solaris 10 and similar releases (no guarantee of fitness for more recent bits):
sshdependencies on services you don't need. The full dependency list for ssh is:
$ svcs -d ssh STATE STIME FMRI online Dec_19 svc:/network/loopback:default online Dec_19 svc:/network/loopback:default online Dec_19 svc:/network/physical:default online Dec_19 svc:/system/filesystem/usr:default online Dec_19 svc:/system/cryptosvc:default online Dec_19 svc:/system/filesystem/local:default online Dec_19 svc:/system/utmp:default online Dec_19 svc:/system/filesystem/autofs:default
Since I said I wanted just the network and the root filesystem to be available (oh, yeah, and the crypto services we need to do proper encryption), I'll delete everything else. That means I first look at the dependency property group names:
# svccfg -s ssh listpg config_data dependency cryptosvc dependency net dependency fs-local dependency fs-autofs dependency net-loopback dependency net-physical dependency utmp dependency [...]
Dependencies are helpfully named here and have type
dependency, so I'm not looking much futher to see the ones to delete. Deleting the dependency on utmpd is a little risky, but I'm willing to live with the risk to commands like last(1). So, I go ahead and delete the property groups which configure those dependencies.
# svccfg -s ssh delpg fs-local # svccfg -s ssh delpg fs-autofs # svccfg -s ssh delpg utmp # svcadm refresh ssh # svcs -d ssh STATE STIME FMRI online Dec_19 svc:/network/loopback:default online Dec_19 svc:/network/loopback:default online Dec_19 svc:/network/physical:default online Dec_19 svc:/system/cryptosvc:default online Dec_19 svc:/system/filesystem/local:default
None of this is endorsement to go around deleting dependencies willy-nilly on your system. All of them are there for a reason, and deleting them without understanding their purpose is guaranteed to lead to pain. If you have any problems with a service where you've deleted dependencies, the first step is to put them back! There are no places in which we've added dependencies to services for fun. Some of the dependencies you might see that seem superfluous are the ones that we added only after finding some very subtle breakage without them.