On Fri, Jun 20, 2003, Bill Campbell wrote:
> I would like to suggest a few changes that I think would make openpkg
> builds and managements more useful:
>
> 1. Specify all configuration files that are essential to program
> operation ``%config(noreplace)'' (e.g. postfix's main.cf, samba's
> smb.conf, etc.) to avoid breaking production systems when doing
> updates.
>
The OpenPKG v1.3 way of doing it is:
1st) build the package (--rebuild --define 'feature yes')
2nd) rescue your configuration, unless it is build from an external source
3rd) upgrade the package (-Uvh)
4th) handle and remove all .rpm(save|old|orig) files
5th) start the service (%{l_prefix}/etc/rc service start)
6th) [ erase a package (-e) ]
The first step is not different from previous releases of OpenPKG.
The second step might be anything from nothing and restart from scratch,
copying, archiving or ignoring it completely because you have a
configuration management system which builds the configuration from a
source external to OpenPKG.
The third step upgrades the package and copies the files to the system.
This might include modification of configuration files which results in
.rpm(save|old|orig) copies/suggestions. This works exactly like previous
releases of OpenPKG. Now for the news in v1.3: all CORE and BASE
packages have been tuned to restart the service (= daemon that comes
within a package) after upgrade (find comment "after upgrade, restart
service" in %post section of the spec). A restart will keep stopped
services stopped and running services will experience a stop/start
combination. We found two categories of services. Regarding the restart
issue, a simple service can continue to run during the upgrade and only
requires a "rc service restart" after the upgrade (i.e. openssh). This
works for any service that only reads it's configuration during startup.
The majority of services falls into this category. Some complex ones
read their configuration while they are up and running (i.e. postfix)
based on new connections, timing, external signal, timestamp monitoring
or whatever. Or they require more complex upgrade activity like user
data conversion (i.e. postgresql). For the complex ones (find comment
"before upgrade, save status and stop service" of the %pre section in
the spec) the running state is saved before the upgrade, the service is
stopped using "rc service stop" and after the upgrade the state is
recovered, if possible, executing a "rc service start".
The fourth step is already tied closely to the the third one. In OpenPKG
v1.3, "rc" checks if it finds any .rpm(save|old|orig) files in or below
the package's %{l_prefix}/etc/%{name}/ directory. For %start and
%restart actions this situation is considered an error, a message is
printed to stderr (and sent to you via mail if it's executed by cron,
i.e. log file rotation in %daily scriptlet) and starting or restarting
is effectively inhibited. For all other sections, including
%status and %env, this situation is considered a warning, a message is
printed to stderr (...cron...) but execution will continue. This
behaviour is already true for the final %post scriptlet in the third
step discussed above. Simple services just won't restart and the old one
will continue to run (rc %restart is suppressed) until stopped somehow.
Complex services have been shut down in the %pre scriptlet (rc %stop)
and might not come up again after the upgrade (rc %start is suppressed).
This altogether leads to the point that after an upgrade, the new
service might not be startable. You have to move the .rpm(save|old|orig)
out of "rc" sight by renaming, moving or removing them somehow. This
could be done manually, it could also be done automatically by a 3rd
party configuration management. As a sidenote please understand the
default configuration of all CORE and BASE packages (except ntp and amd) were altered
to
force the daemon to listen on 127.0.0.1. This reduces interference with
other (system, different OpenPKG instance) similar services. It also
ensures that the service is not exposed to the outer world without your
explicit configuration, this enhances security (and increases travel
expenses if you forget to tweak your sshd_config!). Last but not least,
it means that services which do awkward (i.e. apache showing default
index page) or deadly (i.e. postfix rejecting incoming mails) things in
the default config won't do it without making you fully responsible :-)
The fifth step is only necessary if the running state should forcibly
change after an upgrade or the automatic run state recovery that
executed in the %post scriptlet before the configuration management
cleaned out things failed. After the blocking files have been removed,
further "rc start" or "rc restart" actions will succeed. Note that
simple services will have the old service up and running and require a
%restart (= %stop %start) while complex services were already stopped
and require a %start. Note that %restart will not do anything if the
service is not already running. Also note that %start will not do
anything if the service is already running. If you're in doubt, execute
"rc service restart start" after configuration management took place.
Just for completeness, the sixth step would be a package erase. All CORE
and BASE packages were tuned to shut down the service (find comment
"before erase, stop service" in %preun section of the spec), erase log
(including statistics and history) and run (pidfiles, UNIX domain socket
files) files without notice. If you want to keep them, refrain from
erasing or save that data first. User data like databases will not be
removed, of course (trusting this statement blindly and omitting backups
might result in an interesting experience of life :-)
I have made this letter longer than usual because I
lack the time to make it shorter. -- Blaise Pascal
--
[EMAIL PROTECTED]
Development Team, Operations Northern Europe, Cable & Wireless
______________________________________________________________________
The OpenPKG Project www.openpkg.org
Developer Communication List [EMAIL PROTECTED]
