splitting configuration from the spool/queue

splitting configuration from the spool/queue

[Søren Boll Overgaard]

Hi,

This may or may not have been covered earlier, but I couldn't seem to find
anything in the list archive, so here goes.

Is there any particular reason why the list configuration is situated in the
same directory structure as the list queue and archive? According to the FHS[1],
list configuration should be somewhere under /etc while the queue and archive
should be somewhere under /var. This would have the added benefit that list
configuration could be stored on a read-only file system for added security.

Comments? Thoughts? Flames?

[1] http://www.pathname.com/fhs/


-- 
Søren O.                                           ,''`.
                                                   : :' :
GPG key id: 0x1EB2DE66                             `. `'
GPG signed mail preferred.                           `-

Re: splitting configuration from the spool/queue

[Morten K. Poulsen]

On Tue, Sep 07, 2004 at 10:35:20AM +0200, Søren Boll Overgaard wrote:
> Is there any particular reason why the list configuration is situated
> in the same directory structure as the list queue and archive?

I think there where two reasons for this decision: The first is that
having the configuration in /etc would make a chroot'ed environment
impossible, and the second is to have each list in a single directory.

If you want to store it in /etc you can do so, and just make symlinks in
/var/spool/mlmmj.

Morten

-- 
Morten K. Poulsen <morten@afdelingp.dk>
http://www.afdelingp.dk/

Re: splitting configuration from the spool/queue

[Christian Laursen]

Søren Boll Overgaard <boll+mlmmj@fork.dk> writes:

> Is there any particular reason why the list configuration is situated in the
> same directory structure as the list queue and archive? According to the FHS[1],
> list configuration should be somewhere under /etc while the queue and archive
> should be somewhere under /var. This would have the added benefit that list
> configuration could be stored on a read-only file system for added security.

Personally I find it convenient to have everything related to a list located
under the same directory.

I don't see a problem in adding optional support for having the control dir
located in a seperate location but the current directory layout should continue
to be the default to avoid breaking existing configurations.

-- 
Christian Laursen

Re: splitting configuration from the spool/queue

[Mads Martin Joergensen]

* Christian Laursen <xi@borderworlds.dk> [Sep 07. 2004 10:51]:
> > Is there any particular reason why the list configuration is
> > situated in the same directory structure as the list queue and
> > archive? According to the FHS[1], list configuration should be
> > somewhere under /etc while the queue and archive should be somewhere
> > under /var. This would have the added benefit that list
> > configuration could be stored on a read-only file system for added
> > security.
> 
> Personally I find it convenient to have everything related to a list
> located under the same directory.

Ditto. Also backups, moving lists etc. are simplified.

> I don't see a problem in adding optional support for having the
> control dir located in a seperate location but the current directory
> layout should continue to be the default to avoid breaking existing
> configurations.

We might add that if it's really needed, but as morten said, it's
entirely possible to symlink to a readonly place in /etc. Will make
the webinterfaces useless though.

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                -- A. P. J.

Re: splitting configuration from the spool/queue

[Søren Boll Overgaard]

Hey,

On Tue, Sep 07, 2004 at 10:45:03AM +0200, Morten K. Poulsen wrote:
> > Is there any particular reason why the list configuration is situated
> > in the same directory structure as the list queue and archive?
> 
> I think there where two reasons for this decision: The first is that
> having the configuration in /etc would make a chroot'ed environment
> impossible, and the second is to have each list in a single directory.

Would you be interested in a patch for mlmmj-make-ml.sh which requires the user
to decide if she wants to make links from /etc/mlmmj/lists/<listname> to
/var/spool/mlmmj/control or some such? 

> If you want to store it in /etc you can do so, and just make symlinks in
> /var/spool/mlmmj.

Well, making the symlinks from /var to /etc would break future introductions of
calls to chroot(), so symlinks, if used, should probably be from /etc to /var,
and not vice-versa.

-- 
Søren O.                                           ,''`.
                                                   : :' :
GPG key id: 0x1EB2DE66                             `. `'
GPG signed mail preferred.                           `-

Re: splitting configuration from the spool/queue

[Mads Martin Joergensen]

* Søren Boll Overgaard <boll+mlmmj@fork.dk> [Sep 07. 2004 11:09]:
> > > Is there any particular reason why the list configuration is
> > > situated in the same directory structure as the list queue and
> > > archive?
> >
> > I think there where two reasons for this decision: The first is that
> > having the configuration in /etc would make a chroot'ed environment
> > impossible, and the second is to have each list in a single
> > directory.
>
> Would you be interested in a patch for mlmmj-make-ml.sh which requires
> the user to decide if she wants to make links from
> /etc/mlmmj/lists/<listname> to /var/spool/mlmmj/control or some such?

I think such a patch belongs with the distributions, since FHS is Linux
specific, and mlmmj is not. It's just like the patch to mlmmj-make-ml.sh
to make it know where the listtexts are installed.

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                -- A. P. J.

Re: splitting configuration from the spool/queue

[Mads Martin Joergensen]

* Søren Boll Overgaard <boll+mlmmj@fork.dk> [Sep 07. 2004 11:09]:
> Well, making the symlinks from /var to /etc would break future
> introductions of calls to chroot(), so symlinks, if used, should
> probably be from /etc to /var, and not vice-versa.

If the symlinks go from /etc to /var, how can the config files be on a
read-only mounted filesystem?

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                -- A. P. J.

Re: splitting configuration from the spool/queue

[Søren Boll Overgaard]

On Tue, Sep 07, 2004 at 11:34:00AM +0200, Mads Martin Joergensen wrote:
> > Well, making the symlinks from /var to /etc would break future
> > introductions of calls to chroot(), so symlinks, if used, should
> > probably be from /etc to /var, and not vice-versa.
> 
> If the symlinks go from /etc to /var, how can the config files be on a
> read-only mounted filesystem?

Obviously the system would need to be made read-write during configuration
changes. To my knowledge that's not unreasonable for /etc on a production 
server.

-- 
Søren O.                                           ,''`.
                                                   : :' :
GPG key id: 0x1EB2DE66                             `. `'
GPG signed mail preferred.                           `-

Re: splitting configuration from the spool/queue

[Søren Boll Overgaard]

On Tue, Sep 07, 2004 at 11:19:54AM +0200, Mads Martin Joergensen wrote:
> >
> > Would you be interested in a patch for mlmmj-make-ml.sh which requires
> > the user to decide if she wants to make links from
> > /etc/mlmmj/lists/<listname> to /var/spool/mlmmj/control or some such?
> 
> I think such a patch belongs with the distributions, since FHS is Linux
> specific, and mlmmj is not. It's just like the patch to mlmmj-make-ml.sh
> to make it know where the listtexts are installed.

That's fair enough. I will go ahead and build a set of debian specific patches.

-- 
Søren O.                                           ,''`.
                                                   : :' :
GPG key id: 0x1EB2DE66                             `. `'
GPG signed mail preferred.                           `-

Re: splitting configuration from the spool/queue

[Mads Martin Joergensen]

* Søren Boll Overgaard <boll+mlmmj@fork.dk> [Sep 07. 2004 11:37]:
> > > Well, making the symlinks from /var to /etc would break future
> > > introductions of calls to chroot(), so symlinks, if used, should
> > > probably be from /etc to /var, and not vice-versa.
> > 
> > If the symlinks go from /etc to /var, how can the config files be on
> > a read-only mounted filesystem?
> 
> Obviously the system would need to be made read-write during
> configuration changes. To my knowledge that's not unreasonable for
> /etc on a production server.

Yeah, that's pretty normal I think.

Disclaimer: it's entirely possible I've gotten this messed up in my
            head--it's know to happen before :)

What I meant is: if the symlinks are in /etc pointing to the actual
files below /var/.../control holding the data, then the config files are
not on the read-only file system, are they?

But that's only a problem in the case of chroot environments of course.

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                -- A. P. J.

Re: splitting configuration from the spool/queue

[Søren Boll Overgaard]

On Tue, Sep 07, 2004 at 11:45:38AM +0200, Mads Martin Joergensen wrote:
> > > > Well, making the symlinks from /var to /etc would break future
> > > > introductions of calls to chroot(), so symlinks, if used, should
> > > > probably be from /etc to /var, and not vice-versa.
> > > 
> > > If the symlinks go from /etc to /var, how can the config files be on
> > > a read-only mounted filesystem?
> > 
> > Obviously the system would need to be made read-write during
> > configuration changes. To my knowledge that's not unreasonable for
> > /etc on a production server.
> 
> Yeah, that's pretty normal I think.
> 
> Disclaimer: it's entirely possible I've gotten this messed up in my
>             head--it's know to happen before :)
> 
> What I meant is: if the symlinks are in /etc pointing to the actual
> files below /var/.../control holding the data, then the config files are
> not on the read-only file system, are they?
> 
> But that's only a problem in the case of chroot environments of course.

I think we agree, even if the terminology is a little fuzzy :)

If the actual files are in /etc and symlinks are made from /var/.. to /etc,
then problems will arise if chroot'ing is introduced. This is easily fixed
though, as one can just make the links hard, and thus accessible from with a
chroot. I find this option the most appealing, and according to the FHS it
appears to be the most correct one.

If the situation was reversed, it's as you describe it.
What's your opionion on this?

Either way, sorry for the confusion.


-- 
Søren O.                                           ,''`.
                                                   : :' :
GPG key id: 0x1EB2DE66                             `. `'
GPG signed mail preferred.                           `-

Re: splitting configuration from the spool/queue

[Morten K. Poulsen]

On Tue, Sep 07, 2004 at 11:54:20AM +0200, Søren Boll Overgaard wrote:
> > What I meant is: if the symlinks are in /etc pointing to the actual
> > files below /var/.../control holding the data, then the config files are
> > not on the read-only file system, are they?
> > 
> > But that's only a problem in the case of chroot environments of course.
> 
> I think we agree, even if the terminology is a little fuzzy :)
> 
> If the actual files are in /etc and symlinks are made from /var/.. to /etc,
> then problems will arise if chroot'ing is introduced. This is easily fixed
> though, as one can just make the links hard

No, you can not make hard links across partitions, and you can not make
only some part of a partition read-only.

So:
- All files in /var, symlinks in /etc, chroot
- Some files in /var, some in /etc, symlinks in /var, NO chroot

Morten

-- 
Morten K. Poulsen <morten@afdelingp.dk>
http://www.afdelingp.dk/

Re: splitting configuration from the spool/queue

[Søren Boll Overgaard]

On Tue, Sep 07, 2004 at 12:00:19PM +0200, Morten K. Poulsen wrote:
> 
> No, you can not make hard links across partitions, and you can not make
> only some part of a partition read-only.

My bad.

> So:
> - All files in /var, symlinks in /etc, chroot
> - Some files in /var, some in /etc, symlinks in /var, NO chroot

Strictly speaking, you could delay the call to chroot() until after the
configuration had been loaded from /etc/.. That would require verification that
the actual loading routine couldn't cause errors, but still.
Anyway, if you are happy with having stuff under /var, I won't argue with you
:)

-- 
Søren O.                                           ,''`.
                                                   : :' :
GPG key id: 0x1EB2DE66                             `. `'
GPG signed mail preferred.                           `-