[svlug] Linuxizing Solaris

[Dagmar d'Surreal]

On Thu, 26 Apr 2001, Erik Steffl wrote:

>   /etc/init.d/dtlogin stop is better practise because it's always
> there (the links under /etc/rc[0-6].d can have various names and be
> under different directories, or not even be there, depending on config)

This I agree with, contrary to what may have been said elsewhere here.  If
you _know_ that you're dealing with a default-installed Solaris subsystem
and which one it is, and that it _is_ running, then the init.d directory
is simply a lot easier to type.

>   all startup scripts (most accepting start|stop|restart) are under
> /etc/init.d, with links to these scripts created under /etc/rc[0-6].d
> directories, where N is runlevel, that way you can configure what is
> being run when you boot/switch into each runlevel.

Only one problem being that 2.5.1 and 2.6 (and 2.7 as well if I remember
correctly, but I'm not intersted enough to go and double check right
now.  I've got very few 2.7 systems to deal with) don't use links.  They
outright copy the files.  (Well, I suppose they *could* be using hard
links, but it doesn't make much difference if they are doing it)

>   the links start with S or K (S means start the service, K means stop
> the service) and number, the links with smaller numbers are executed
> first.
> 
>   so you play with [SK][0-9][0-9]serviceName scripts to change
> runlevel configuration but when you start/stop/restart services
> manually you run the scripts under /etc/init.d (it's easier to find
> them there, you can of course run any link under /etc/rc[0-6].d)
> 
> > then remove /etc/rc2.d/S99dtlogin
> > or 
> > mv /etc/rc2.d/S99dtlogin /etc/rc2.d/no.S99dtlogin
> 
>   you can remove it, it's just a link to /etc/init.d/dtlogin (well,
> check first:-)
> 
> > and edit /etc/inittab
> >  is:3:initdefault:
> 
>   if you remove the link above then why would you do this? it does not
> make any sense, you just suggested to change the configuration of
> runlevel 2 and then change to runlevel 3. perhaps you meant do one or
> another (assuming runlevel 3 does not run dtlogin)?
> 
> > You can always run /etc/rc2.d/no.S99dtlogin [stop|start] to go back and
> > forth
> 
>   /etc/init.d/dtlogin start|stop (if you followed my advice and just
> removed the link under /etc/rc2.d)

It's a bit obnoxious to deal with having to manually remove all those
entries (granted, rm /etc/rc?.d/???servicename seems to work fine for
me) so I took a different way out.  Solaris package management has some
serious problems with lumping almost everything into the main software
cluster, which is only a few packages which don't separate much (like, why
the heck is mail a part of the main system packages?) so I've found it
much easier to package everything I've replaced, and go with a minimum
installation and then add the packages that need to be there with a custom
profile.  Ensuring that the new packages follow the init mechanisms of
their predecessors has saved me a lot of trouble in this respect
(preinstall calls the same init script to shut down the service first,
just in case).  Create your pre- and post-install scripts carefully and
you should have no trouble dropping replacements into a machine.

(If you need info on how to make custom Solaris packages, send a private
email, since it's way beyond the scope of this list.  Solaris's
documentation on the matter is pure crap.)

Probably the spookiest thing I've dealt with was replacing patch and diff
on Solaris.  GNU tar seems to support almost all of the options that the
Solaris tar has, so it was somewhat safe, but I was seriously concerned
that possibly the Solaris diff might be getting called by various patch
clusters and could break a lot of stuff if it as changed.  Solaris' diff
and patch binaries are really really weak compared to the GNU
replacements.  Luckily for me it doesn't appear that any of the Solaris
patches pay close enough attention to what was already installed to
matter.  (for example, the last sendmail patch they added would merrily
turn sendmail back ON, and/or replace YOUR sendmail binary with their 
older one) GNU autoconf, automake, and libtool didn't even
have competition from any native binaries.  m4 and make were a little
creepy, but I've recompiled dozens of binaries with GNU make instead of
the Solaris ones and still seem to get the same binaries out of it.  sed
and awk I'm still testing.  There seem to be differences between the way a
lot of different OS's implementation of sed behave, but it looks like all
the GNU software seems to expect GNU sed, or at least knows to check which
version you're using if it's going to come up.  GCC was downright easy to
compile, but if you value your uptime, just don't go fooling around with
replacing ar & friends with GNU binutils.  (At least it doesn't seem to
result in stable binaries for 2.6)