Re: RFC: New required package: libblkid1
* Theodore Ts'o <tytso@mit.edu> [030320 20:52]:
> For some systems, /etc/resolv.conf is a static configuration file.
> For those systems, putting it in /run is a problem, since (at least
> according to some poeple; some of the proposals are a bit confused on
> this point), /run will get blown away at reboot.
>
> But the whole point of the FHS is that programs can be compiled with
> looking for files in a consistent location. So it can't be
> /etc/resolv.conf on some systems, and /run/resolv.conf on other
> systems. For those systems that care, you could use a symlink --- but
> if the vast majority of the systems out there have either a writable
> root, or a static configuration ---
As stated before, the main problem with /etc/resolv.conf is that it
only supports a static nameserver setting. The current situation is
merely a crude hack to make nameserver choosen by dhcp or ppp possible.
As there is no other place, state-information is placed in a
configuration file. Configuration files changed by the system are
counter-intuitive alone, done so all the time even worse.
Wheather changing libresolv to read two files, linking /etc/resolf.conf
to a state file initialised by a config file or a local caching
dns-server (which seems to be the best possibility with look at
changing the information even while running, though a fitting program
might still to be written) is the solution to go has nothing to
do with the problem of chaning content in /etc.
> why does this have to be something
> which Debian has a whole have to torque itself over? Those people
> with wierd corner cases (embedded systems, et. al.), that want a
> read-only root *AND* who are using ppp can set up their system with a
> symlink to /run, or /var/run, or /tmp (assuming that /tmp is mounted
> as a memory tmpfs filesystem), or whatever else is appropriate. Why
> does it have to be a Debian-wide decision?
Because Debian is (beside other things) about "getting things right"?
Because theese corner cases point to a weakness in the overall system?
> I see this read-only root question as one where a few vocal people
> care about, but *not* something which is generally applicable.
Its an option, that can not be choosen. If having / readonly
is suitable for a special system is another question. But it has
some advantages: unintended changes to the configuration is not possible,
the filesystem can not corrupt and does not need checking when apruptly
rebooted, and it may even defeat some strange forms of exploits.
This option (that may even a prerequisuite for a other corner cases) beeing
impossible because of a inconsistency in the current system -
state-files in /etc - is a pity. It bited only few, but is a very
unsatisfied situation.
> So I
> ask again --- why should we torque the entire system just to satisfy
> what might be a very tiny corner case? Let's optimize for the common
> case, not for the uncommon case. People who care about read-only
> roots can set up symlinks today.
\begin{sarkasm}
So why not elminate /etc/fstab and only support one large partition
everything. Everything works quite out of the box. Installation would
be much simpler (the installer could simple repartition the hard-disk
and create a file-system - no more confusing questions about such
things). And people wanting something else can still write some
mount-commands in some script running at boot time.
\end{sarkasm}
Hochachtungsvoll,
Bernhard R. Link
--
Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.
Reply to: