[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FHS (Re: translator for /dev/random and /dev/urandom)
From: |
Joshua Rosen |
Subject: |
FHS (Re: translator for /dev/random and /dev/urandom) |
Date: |
Sun, 24 Jun 2001 13:56:04 -0400 |
Marcus Brinkmann wrote:
>
> On Sat, Jun 23, 2001 at 06:47:12PM +0200, Oystein Viggen wrote:
> > Quoth Marcus Brinkmann:
> >
> > > Use --seed-file to store a seed file across reboots (in /var/run).
> >
> > At least in Debian GNU hurd, the boot scripts seem to do this:
> >
> > if test -d /var/run; then
> > (cd /var/run && { rm -rf -- *; cp /dev/null utmp; chmod 644 utmp; })
> > fi
>
> This is a bug and will be fixed in the next version.
>
> > Wouldn't this make /var/run an exceptionally bad place for storing stuff
> > across reboots?
>
> The next version will excempt random-seed (and directories, and innd.pid and
> utmp). I should add an excemption for urandom-seed, too.
Do we (should we) pay attention to the Filesystem Hierarchy Standard?
Of /var/run, the FHS says:
5.13.1 Purpose
This directory contains system information data describing the
system
since it was booted. Files under this directory must be cleared
(removed or truncated as appropriate) at the beginning of the
boot
process.
(also stated is that utmp should be kept in /var/run, implying that it
should *not* be reserved across reboots...)
It seems that /var/lib is a much more suitable place for storing seeds,
as the associated text is:
5.8 /var/lib : Variable state information
5.8.1 Purpose
This hierarchy holds state information pertaining to an
application or
the system. State information is data that programs modify while
they
run, and that pertains to one specific host. Users must never
need to
modify files in /var/lib to configure a package's operation.
State information is generally used to preserve the condition of
an
application (or a group of inter-related applications) between
invocations and between different instances of the same
application.
State information should generally remain valid after a reboot,
should
not be logging output, and should not be spooled data.