Developers of Sympa

[IKEDA Soji <address@concealed>]

Hi,

On Thu, 13 Mar 2014 13:57:02 +0100
Guillaume Rousse <address@concealed> wrote:

> Le 12/03/2014 17:16, IKEDA Soji a écrit :
> > Hi,
> >
> > On Wed, 12 Mar 2014 16:48:12 +0100
> > Guillaume Rousse <address@concealed> wrote:
> >
> >> Le 12/03/2014 16:19, IKEDA Soji a écrit :
> >>> Developers,
> >>>
> >>> I'm trying to catch up systemd(1) support that was adopted by Fedora
> >>> and will be shipped with coming RHEL7.  I wish to add it to 6.2 if
> >>> possible (See attachments).
> >> No need to reinvent the wheel, systemd is perfectly able to manage
> >> services based on multiple individual components, such as nfs for 
> >> instance.
> >>
> >> Here is the current implementation in mageia, in usage since july 2012:
> >> http://svnweb.mageia.org/packages/cauldron/sympa/current/SOURCES/
> >
> > It is close to what I seeked.  I didn't come to realize using
> > "forking" type.  I want to know how to control which daemons would
> > be run --- by customizing "Wants" lines?
> If you need to, yes. However, this is not a systemd issue: you can't do 
> it with the current initscript either.

E.g. if a user doesn't wish archiving or bounce processing, they
may also wish to stop archived or bounced.  Currently, they would
do it by editing init script.

With systemd, users may override setting of each unit.  I feel
such improvement is desirable.

> > However, since current init script uses non-general method to find
> > running processes, some kind of improvement may be desirable.

BTW,

> > Anyhow, where would such files be placed in source tree, if we
> > adopt them?
> Alongside current init script, which is currently located in source tree 
> (src/etc/script), with a sample logrotate configuration file and a spec 
> file. As previously discussed, this is an unfortunate mix between main 
> Sympa code, and some peripheral concerns.
> 
> First relocation proposal:
> A new top-level directory, called 'misc', 'other', or whatever else, 
> that would contains multiple subdirectories for various kind of files, ie:
> misc
> ├── conf: logrotate, initscript, systemd units
> ├── ext
> │   └── oauth: OAuth extension from M. Overmeer
> └── utils: ldap_alias_manager.pl, mysql_alias_manager.pl, and similar 
> poorly-coded stuff from src/bin/

I wish to put this proposal aside for a while.  Careful examination
seems needed to decide which things are "miscellaneous".

> Second relocation proposal:
> Consider than those logrotate, initscript and systemd units are just 
> generic samples, and ship them as documentation under doc/samples
> 
> In both case, dropping automatic installation and customisation support 
> from the build system in favor of a manual procedure, explicitely 
> described in installation documentation would provides the following 
> benefits:
> 1) configure script simplification (no need for --with-piddir, 
> --with-lockdir and --with-initdir switches anymore)
> 2) more consistency in setup-related configuration (PIDDIR is defined as 
> a constant in Sympa::Constant, while tmpdir is defined as a normal 
> configuration variable in sympa.conf)

Each OS/distribution has specific policy on these kind of paths.
The initdir would be /usr/local/etc/rc.d/ for FreeBSD ports; lockdir
is /var/lock/subsys/ for most of Linux distributions; some systems
prefer to /var/run/ or /var/run/sympa/ for piddir.
These are enforced (especially on security-enhanced environments) or
recommended by each systems, regardless to --prefix path chosen
by administrators.

Another point is that these three kinds of paths should be
"hardcoded": They must be fixed at the time of invokation and must
not be changed.  That's why some configuration parameters such as
"pidfile" have been removed.
OTOH "tmpdir" and so on may be configurable during execution.

> If you're targetting sysadmins installing sympa from sources (rather 
> than from a distribution package), it doesn't seem unreasonable to 
> transfer them the responsability of performing those specific 
> post-installation duties.

I'll investigate a bit more which kind of paths installation process
should take care.  Roughly say, location of init script would
probably be taken care, because it is general method over all
systems.  The smrsh path and so on possibly may not.


Regards,

--- Soji

-- 
株式会社 コンバージョン  セキュリティ&OSSソリューション部   池田荘児
〒231-0004　神奈川県横浜市中区元浜町3-21-2 ヘリオス関内ビル7F
e-mail address@concealed  TEL 045-640-3550
http://www.conversion.co.jp/