[csw-maintainers] cswclassutils: location of template init scripts

[Maciej (Matchek) Blizinski]

No dia 9 de Junho de 2010 22:56, Philip Brown <phil at bolthole.com> escreveu:
> On Wed, Jun 9, 2010 at 2:03 PM, Maciej (Matchek) Blizinski
> <maciej at opencsw.org> wrote:
>>
>> I see; the init file under /opt/csw is there for the NFS client machines.
>>
>> There's also the argument that you don't need to vary the init script
>> between the zones, but it's not a strong one.
>
> and more importantly: if the init script needs per-machine
> modifications... the maintainer should be allowing it by way of config
> files or smf variables, etc. The init script itself should never have
> to be edited by a sysadmin.

Right, this means that it can be installed into /opt, but it doesn't
mean that it has to.

It's sometimes convenient to edit the init file for debugging
purposes.  In debugging context, private init file is better than a
global one (you don't influence other zones).

>>  The
>> main point of the elegance being the 1:1 correspondence between the
>> init files and CAS executions.  Losing it would be a significant cost
>> from the SMF handling point of view, if you think about debugging
>> situations for instance.
>
> yup.
>
>
>>
>> IIUC, the main problem with the NFS setup is the absence of the init
>> script from /opt.  If so, why not include one more copy of the init
>> file under /opt/csw/etc/cswinitsmf/$PKGINST so that it can be used by
>> admins of an NFS client system?
>>
>
> We seem to be mostly agreeing in principle, and just discussing implementations.
> I am actually not sure if you are agreeing with my prior suggestion of
> "have the CAS duplicate it into /opt/csw/etc/cswinitsmf", or whether
> you are proposing an actual duplicate ship in the package itself.
> Please clarify.

For the simplest solution, I suggest shipping duplicates, just because
it's easy to implement.  It has some drawbacks, but now show stoppers.
 Things underneath /etc are mostly about triggering script execution,
and giving them data (init script paths).  The convenience lies in
pkgadd understanding the concept of zones and abstracting that away.

>
>
> There is also potentialy a third option, which I have not tested yet
> (and need to run out the door soon :)
>
> In theory, if we had no prior installs/use of /etc/opt/csw/init.d, the
> straightforward thing to do might be "always put one file, in
> /opt/csw/etc/cswinitsmf"
> That gives the cleanliness of single-file use, and with a well written
> CAS, will work for everyone.
>
> So it seems the main question is how to handle our "legacy"
> /etc/opt/csw/init.d packages, without having to force rebuild of quite
> a few.

Adding a duplicate in /opt/csw/etc/cswinitsmf would avoid those problems.

> I had an "interesting" thought: svr4 hackery ;-)
>
> Perhaps we can have the CAS script, dynamically RELOCATE, rather than
> copy, init scripts from /etc/opt/csw/init.d, to /opt/csw/etc/[...]
>
> By judicious use of  removef, rm, and installf, I think this may be possible.
>
> Then, packages deployed after the new CSW installation, woudl have a
> uniform install location, even if the package itself was pre-standard.

Can you tell more about this idea? What kind of code would handle
that?  (A shell script? Where would it be?)

My last thought is that if we want there to be a single location of
the init scripts, perhaps we shouldn't use CAS, but just postinstall
scripts.  For convenience, we could use some sort of automation around
pulling SMF handling function from a common source and pasting them
into the individual package's postinstall.

In any case, I'm weary of throwing away or significantly modifying
what we have right now, just because of the NFS case.  I'd rather add
whatever NFS setup needs, without disturbing the existing solution.

Maciej