[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ifupdown writes to /etc... a bug?

Steve Langasek <vorlon@netexpress.net> writes:

> On Sat, Mar 29, 2003 at 12:52:55AM +0100, Goswin Brederlow wrote:
> > last call for complains about where to mount a writeable filesystem
> > when a RO / is to be used. The mountpoint is only to appear when a RO
> > / is actually used so all you RW / users are totally unafected.
> > Opions so far have been (in order of my preference): (did I miss any
> > sensible ones?)
> > /etc/volatile
> > /run
> My preferences are reversed for the first two.  These files aren't
> configuration at all, so the only justification for their inclusion under
> /etc is "historical reasons".  It took me a while to even notice that tab
> completion would be screwed up for /root, so I think tab completion is a
> minor issue for this specific instance -- though it's one more reason why
> all but the first two options are unsuitable.
> Implementing /etc/volatile is a fairly innocuous change, and it would be
> possible to move the contents to /run with a minimum of difficulty at a
> later date if it becomes clear that the FHS would incorporate such a
> change.  I still think it's best to put forth the additional effort to
> get these files in /run straightaway, but I don't find /etc/volatile
> completely inappropriate.

So far its only checkroot.sh that has any notice of where the RW
medium should be mounted. All other packages just follow the symlinks
wherever they point.

One could even just make the mountpoint a configure option at the top
of the script or in /etc/volatile.conf or something.

> If we were to move on /run, however, I think the appropriate course of
> action would be to change all Debian packages to use /run as the
> *authoritative* location for these files, and provide
> backwards-compatible symlinks in /etc only for the benefit of admins and
> local software.  The FHS specifically addresses the matter of where the
> *system* looks for the software, so nothing else would be suitable for a
> proposed amendment to the standard, IMHO.

There is one thing that realy breaks everything so far and thats
"/etc/nologin". Changing it affects several packages so it needs a
standard place to be moved to.

I see three options:
A. /etc/volatile.conf says where volatile data can be found, look
there for a "nologin" file.

B. symlink /etc/nologin on RO /. Patch software to check if
/etc/nologin is a symlink and then check if it is dangling as check
for nologin.

C. move /etc/nologin and patch software to look at the new place.

A would mean that the place can change depending of the admins likes
and dislikes or changes in fhs or policy.

B has the advantage that every unpatched software will probably think
that /etc/nologin exists and will get noticed. A sysvint introducing
the link should probably conflict on all known packages that need to
be updated first.

On top of that the questions remains if the old /etc/nologin should be
checked as well as the new one to keep compatibility with the historic
way. Option B would check for /etc/nologin anyway but A and C would
require two checks.


Reply to: