[csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update

[rupert THURNER]

2009/8/29 Trygve Laugstøl <trygvis at opencsw.org>:
> rupert THURNER wrote:
>>
>> On Mon, Aug 24, 2009 at 11:10, Maciej (Matchek)
>> Blizinski<maciej at opencsw.org> wrote:
>>>
>>> I've crafted new cups and unixodbc packages, but I started to loath to
>>> release them because of the migration from /opt/csw/etc to
>>> /etc/opt/csw. In my case it was a non-issue: update Puppet
>>> configuration definition, install packages, done. In a more general
>>> case, somebody will just do an update and... bang. The new cups will
>>> look for files in /etc/opt/csw/cups and won't find anything.
>>>
>>> There was a brief discussion in Oslo about this. The ideas I've
>>> collected so far:
>>>
>>> 1. Make the installation fail if the old config directory
>>> (/opt/csw/etc/cups) or files exist.
>>>
>>> Pros: It will make people (painfully) aware that there has been a
>>> change and they need to take action. They will have an opportunity to
>>> do the configuration move their way if they wish to.
>>>
>>> Cons: It's annoying and potentially time consuming: the need to look
>>> why the hell has the package failed, then go and devise a plan to move
>>> the configs. If someone does a mass upgrade, there will be a mass
>>> failure: CUPS will be uninstalled from everywhere and it won't be easy
>>> to install it. (not from current, using CSW tools, that is)
>>>
>>>
>>> 2. Move the config files automatically. Identify all the configuration
>>> files from the old /opt/csw/etc directory and move them to
>>> /etc/opt/csw.
>>>
>>> Pros: Smooth hands-off upgrade as expected (Quoting the website, our
>>> motto, is "to provide a straightforward, easy-to-use experience for
>>> the user").
>>>
>>> Cons: Something in the scripts could go wrong, causing a mass failure.
>>> (Probably not worse than in point 1, though.) There may be
>>> difficulties with figuring out how to copy the common inter-zone
>>> configuration from /opt to /etc. (CUPS didn't work in sparse
>>> non-global zones anyway, but it might be an issue in a general case.)
>>>
>>> Issues I see: how to deal with the non-global zones in the general case?
>>>
>>> - How to fork the existing shared configuration into a per-zone /etc
>>> directory?
>>> - How to identify which files to copy? A user might have created and
>>> used more files than the package provided. (It could be detected in
>>> some cases, but certainly not all.)
>>>
>>>
>>> 3. Create a classutils script to aid migrating the file. The package
>>> author would provide a description on how to migrate the config files,
>>> i.e. which old paths correspond to the new paths. The non-global zones
>>> would have no source files, so they would get the default
>>> configuration.
>>>
>>> Pros: Our motto is...
>>>
>>> Cons: non-global zones, if previously configured, would have their
>>> configuration reset.
>>>
>>>
>>> Thoughts?
>>
>> our configuration has one writable directory, /opt/csw, and we
>> appreciated a lot the isolated nature. putting the files in etc will
>> render opencsw unusable for us.
>
> Why do you have that requirement? Is it because of NFS deployments or zones?
> Lots of packages use /var already, how do you handle that?

three main reasons:

1. zones
most of the time we just cover deficiencies, so are in local zones. in
future it will be ldoms, so this problem might vanish.

2. failover / disaster recovery
we import the san storage to somewhere else, redirect dns and are
done. this will be of higher and higher importance to have "nearly no
downtime" service.

3. two opencsw environments on one box.
to make it work we use /opt/csw on a staging box to get the correct
packages, and put the whole /opt/csw in a single solaris package,
usually on developer/integration test stage. this then is used to
distribute to other servers (production test, production stage
usually) into a custom directory. to make it work we set the
LD_LIBRARY_PATH though for the non-/opt/csw install.

via this strategy we are able to quickly deliver the newest software
to somehow outdated operating systems versions in a clean and fail
over safe manner. our base operating system version changes quite
slowly. and, via this strategy the solaris platform is even more
maintainable than the linux platform, because such a "package
everything and deliver it quickly" does not exist there.

as we have too many servers and groups i do not have a complete
overview who is using what. the ones i am aware of are:
 * one group (ours) is running apache - trac - subversion - mercurial - git.
 * the other group is running the apache - php stack.
 * both run the  develepment environment sometimes.

we noticed the classutils trying to write somewhere else, but up to
now opencsw did not cease operating, the python stuff gets compiled
anyway. with the restricted set of packages we are using i am not
aware about a "var" problem. also, the var locations i am aware of
e.g. for postgres can be configured to be anywhere.

otoh, i can imagine scenarios where having the option of using /etc
instead of /opt/csw/etc may be favourable, in the clustering case.
then you have, just to take an example, two apache's listening on
different ip/ports using the same data directory and software. but
here we are not yet "amazon cloud capable" - even if the people work
hard on it :)

so, the principal issue i can see  is: how would we be able to
configure if /etc  or /opt/csw/etc is used ?

rupert.