On Mon, Jul 07, 2003 at 10:25:52PM +0200, Thomas Lotterer wrote:
>On Sun, Jun 29, 2003, Bill Campbell wrote:
>
>Re Bill,
>
>> While building and installing postgresql, I see that the rc control file
>> specifies the IP address for the host explicitly (i.e. 127.0.0.1).  It
>> seems to me that this should be someplace in the %{l_prefix}/etc/postgresql
>> directory, not in the startup control file itself,
>> 
>some applications allow certain paramters to be specified either in a
>configuration file or through command line options. The former has to be
>placed in the /etc subdirectory for the affected package, the latter has
>to be placed in a rc.%{name} file using a variable which can be
>overridden by the user in rc.conf. A config file under /etc should be
>tagged as such. The rc.%{name} file is not intended to be touched by the
>user so OpenPKG will overwrite it on any update. However, the rc.%{name}
>file should contain reasonable amount of configuration options through
>variables. The user can override the defaults hardcoded in the
>rc.%{name} by placing his own definition into the rc.conf file which is
>never overwritten by OpenPKG.

OK.  I hadn't realized the openpkg used the rc.conf file this way (I'm only
a recent FreeBSD user so this isn't second nature to me).

>We believe in RPMs logic of keeping or moving/replacing config files.
>The logic is close to perfection for a packaging system. There are many
>situations where the logic could be improved but we feel such
>intelligence is up to a configuration management system which OpenPKG is
>not.  So we see only few, if any, situations where config(noreplace)
>could/should be used.

I too believe in RPMs logic in handling config files.  That's why I believe
in using the %config(noreplace) specification for programs such as postfix
where these configuration files are usually modified extensively, and
changing them during an update can cause major problems if they're changed.

Changing the daemon/listen address will prevent the outside world from
accessing the program all right, and it will result in all the lights on
the customer support lines turning on at once if done with the MTA at a
busy ISP.  You would probably get a similar reaction by changing the samba
smb.conf file so none of the Windows users could access their data.

>We understand the issues associated with changed configurations, and we
>are currently fighting three battles to improve things:
>
>- daemon bind/listen address 
>  https://rt.openpkg.org/SelfService/Display.html?user=guest&pass=guest&id=176
>  the goal is to ensure that any daemon will bind/listen to 127.0.0.1 by
>  default which greatly reduces the risk of running a daemon on a live
>  system which reverted back to default configuration. Currently (or at
>  least not long ago) it was possible to upgrade postfix, revert to the
>  default config and have such a stupid config running on a live system.
>  This must not happen.

Agreed -- that it must not happen.  That's why I would much prefer to see a
%{l_prefix}/etc/postfix/main.cf.rpmnew file appear that can the be merged
with the old file when convenient.

Consider the case where one might be doing an ``openpkg build -Ua'' which
might take hours.  It's not reasonable to expect somebody to be sitting
there watching the build so they can jump in and quickly reconfigure
postfix as soon as its build is complete.

In my experience, it's very rare when a package's configuration files
change so radically that they render the system inoperative if run with the
old configuration files.

>- opServiceEnabled
>  https://rt.openpkg.org/SelfService/Display.html?user=guest&pass=guest&id=174
>  https://rt.openpkg.org/SelfService/Display.html?user=guest&pass=guest&id=175
>  https://rt.openpkg.org/SelfService/Display.html?user=guest&pass=guest&id=184
>  the goal is to ensure that all rc.%{name} files acutally use the
>  opServiceEnabled function (#175), the return code and environmental
>  changes of any package does not influence other packages (#174,
>  currently the first exit breaks the rc chain) and the function is
>  enhanced to disable a service when a .*\.rpm(save|orig|new) file is
>  found under the package's /etc subdirectory (#184).
>
>- rpmlint
>  is currently under construction and checks RPMs like speclint checks
>  spec files. One of the goals is to find config files which are not
>  tagged as those.

I've seen several references to rpmlint and speclint, but don't see them in
openpkg-tool.  Is this something that's only available within C&W or am I
just missing a package?

>Regarding your original inquiry about postgresql it will be checked for
>those issues.
>
>One point probably remains for voting. If an application supports both,
>setting the bind/listen address through config file and rc file aka
>command line option, which one is the preferred option? My idea is to
>prefer using the config file because i'll expect all configuration to be
>in one place - if possible.

That sounds right to me -- if you are referring to /etc/%{name} config
files, not the /etc/rc.d/rc.%{name} run control file.

As for not changing the rc.%{name} file, I would like to see some mechanism
to add user definable processing to the log rotation sections (e.g. we run
some extra mail summary reports in postfix).  One way to handle this would
be to look in the packages /etc/%{name} directory for a user defined log
processing program that would be called if it exists.  We've been doing
something similar to this with the hourly, daily, etc. maintanence programs
which live in the /sbin directory where each program looks in the /etc
directory for a program with the same name that's executed if it exists.

Bill
--
INTERNET:   [EMAIL PROTECTED]  Bill Campbell; Celestial Software LLC
UUCP:               camco!bill  PO Box 820; 6641 E. Mercer Way
FAX:            (206) 232-9186  Mercer Island, WA 98040-0820; (206) 236-1676
URL: http://www.celestial.com/

Intaxication: Euphoria at getting a refund from the IRS, which lasts until
you realize it was your money to start with.
______________________________________________________________________
The OpenPKG Project                                    www.openpkg.org
Developer Communication List                   [EMAIL PROTECTED]

Reply via email to