FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 04-15-2011, 11:07 AM
Roger Leigh
 
Default /run support for wheezy: final (I hope) call for testing

On Wed, Mar 30, 2011 at 11:20:45PM +0100, Roger Leigh wrote:
> On Wed, Mar 30, 2011 at 10:32:51PM +0200, Goswin von Brederlow wrote:
> > Tollef Fog Heen <tfheen@err.no> writes:
> >
> > > ]] Julien Cristau
> > >
> > > | On Wed, Mar 30, 2011 at 16:20:10 +0100, Roger Leigh wrote:
> > > |
> > > | > Given that Fedora are adopting /run, and it has been something
> > > | > we have wanted in the past, is anyone working on implementing
> > > | > /run in Debian?
> > > | >
> > > | > http://thread.gmane.org/gmane.linux.redhat.fedora.devel/146976
> > >
> > > Incidentially, I just sent a mail proposing this as a release goal.
>
> I've filed a bug (#620191) against initscripts containing a proposed
> patch for this.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620191

I've put a (hopefully final) version at

http://people.debian.org/~rleigh/run/sysvinit_2.88dsf-13.3.dsc
http://people.debian.org/~rleigh/run/sysvinit_2.88dsf-13.3.patch
http://people.debian.org/~rleigh/run/sysvinit_2.88dsf-13.3_amd64.changes
http://people.debian.org/~rleigh/run/sysvinit-utils_2.88dsf-13.3_amd64.deb

This has been tested on Linux (amd64, powerpc), kfreebsd (amd64),
hurd (i386) and linux vservers and lxc.

Changes since last time:
- usplash code removed (Michael Biebl)
- vserver environments should now upgrade correctly (autodetect and
treat like chroots)
- hurd portability fixes (Samuel Thibault)
- add /lib/init/tmpfs.sh to source /etc/default/tmpfs and include
defaults in case admin removes critical variables needed to start up;
hide _MODE variables in tmpfs.sh so they aren't directly visible in
/etc/default/tmpfs. These are both to decrease the chance of an
incautious sysadmin making their system unbootable.
- default.rcS defaults to separate mounts for /run/lock, /run/shm and
/tmp (new installs only). This is safe to do now we have limits in
place, and will allow read-only root once the /run migration is done
- update docs

Testing would be appreciated on all platforms, so we can be sure everything
is working correctly.

Documentation about the transition is here:
http://wiki.debian.org/ReleaseGoals/RunDirectory


Thanks again,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
 
Old 04-15-2011, 12:28 PM
Adam Borowski
 
Default /run support for wheezy: final (I hope) call for testing

On Fri, Apr 15, 2011 at 12:07:37PM +0100, Roger Leigh wrote:
> http://people.debian.org/~rleigh/run/sysvinit_2.88dsf-13.3.dsc
> http://people.debian.org/~rleigh/run/sysvinit_2.88dsf-13.3.patch
> http://people.debian.org/~rleigh/run/sysvinit_2.88dsf-13.3_amd64.changes
> http://people.debian.org/~rleigh/run/sysvinit-utils_2.88dsf-13.3_amd64.deb
>
> This has been tested on Linux (amd64, powerpc), kfreebsd (amd64),
> hurd (i386) and linux vservers and lxc.
>
> Changes since last time:
> - vserver environments should now upgrade correctly (autodetect and
> treat like chroots)

Sadly, it still seems to fail for me:

fakerunlevel: open("/var/run/utmp"): No such file or directory

/var/run -> /run is properly created in postinst, exists after shutdown,
disappears during an attempt to start it.


Not sure what kills it, lemme try to find it out. The host is squeeze but
had been repeatedly upgraded, so something might be different from fresh
installs.

--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
 
Old 04-15-2011, 12:39 PM
Adam Borowski
 
Default /run support for wheezy: final (I hope) call for testing

On Fri, Apr 15, 2011 at 02:28:35PM +0200, Adam Borowski wrote:
> On Fri, Apr 15, 2011 at 12:07:37PM +0100, Roger Leigh wrote:
> > http://people.debian.org/~rleigh/run/sysvinit_2.88dsf-13.3.dsc
> >
> > Changes since last time:
> > - vserver environments should now upgrade correctly (autodetect and
> > treat like chroots)
>
> Sadly, it still seems to fail for me:
>
> /var/run -> /run is properly created in postinst, exists after shutdown,
> disappears during an attempt to start it.
>
>
> Not sure what kills it, lemme try to find it out. The host is squeeze but
> had been repeatedly upgraded, so something might be different from fresh
> installs.

Got it:

/usr/lib/util-vserver/vserver.start includes the following function:

## Usage: prepareInit <vserver-directory>
function prepareInit
{
pushd "$1/vdir" >/dev/null
case "$INITSTYLE" in
sysv)
{ find var/run ! -type d -print0;
find var/lock ! -type d -print0; } | xargs -0r $_CHROOT_SH rm
;;
plain)
$_CHROOT_SH rm .autofsck forcefsck 2>/dev/null || :
: | $_CHROOT_SH truncate fastboot 2>/dev/null || :
;;
minit)
;;
esac
"${INITCMD_PREPARE[@]}"
popd >/dev/null
}

A symlink to a directory is not a directory...

Not sure how to fix it, especially considering that typically the host is
stable or oldstable even if specific guests run unstable.

--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
 
Old 04-15-2011, 01:55 PM
Roger Leigh
 
Default /run support for wheezy: final (I hope) call for testing

On Fri, Apr 15, 2011 at 02:39:40PM +0200, Adam Borowski wrote:
> On Fri, Apr 15, 2011 at 02:28:35PM +0200, Adam Borowski wrote:
> > On Fri, Apr 15, 2011 at 12:07:37PM +0100, Roger Leigh wrote:
> > > http://people.debian.org/~rleigh/run/sysvinit_2.88dsf-13.3.dsc
> > >
> > > Changes since last time:
> > > - vserver environments should now upgrade correctly (autodetect and
> > > treat like chroots)
> >
> > Sadly, it still seems to fail for me:
> >
> > /var/run -> /run is properly created in postinst, exists after shutdown,
> > disappears during an attempt to start it.
> >
> > Not sure what kills it, lemme try to find it out. The host is squeeze but
> > had been repeatedly upgraded, so something might be different from fresh
> > installs.
>
> Got it:
>
> /usr/lib/util-vserver/vserver.start includes the following function:
>
> { find var/run ! -type d -print0;
> find var/lock ! -type d -print0; } | xargs -0r $_CHROOT_SH rm
>
> A symlink to a directory is not a directory...
>
> Not sure how to fix it, especially considering that typically the host is
> stable or oldstable even if specific guests run unstable.

Just add a trailing slash to ensure it follows the link:

{ find var/run/ ! -type d -print0;
find var/lock/ ! -type d -print0; } | xargs -0r $_CHROOT_SH rm

I'm afraid this will need fixing in util-vserver(?) though. We can't
work around this in initscripts postinst, I'm afraid, since it worked
correctly, and this happened after the migration.


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
 
Old 04-15-2011, 11:59 PM
Henrique de Moraes Holschuh
 
Default /run support for wheezy: final (I hope) call for testing

On Fri, 15 Apr 2011, Roger Leigh wrote:
> { find var/run/ ! -type d -print0;
> find var/lock/ ! -type d -print0; } | xargs -0r $_CHROOT_SH rm
>
> I'm afraid this will need fixing in util-vserver(?) though. We can't
> work around this in initscripts postinst, I'm afraid, since it worked
> correctly, and this happened after the migration.

The proper fix would be to use bind mounts, or always use multiple tmpfs
(which is safer, anyway).

There could be many more examples of this sort of problem, including in
local admin scripts. As a rule, it is not safe to go around replacing
system directories and replacing them with symlinks, for exactly this
reason: symlinks are anything but transparent.

Heck, bind mounts would already cause severe problems in many situations (cp
-x in backup scripts, etc), but fortunately /var/lock and /var/run are
already defined as ephemeral, and unlikely to cause problems because of
that.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110415235901.GC12829@khazad-dum.debian.net">http://lists.debian.org/20110415235901.GC12829@khazad-dum.debian.net
 
Old 04-16-2011, 12:16 AM
Roger Leigh
 
Default /run support for wheezy: final (I hope) call for testing

On Fri, Apr 15, 2011 at 08:59:01PM -0300, Henrique de Moraes Holschuh wrote:
> On Fri, 15 Apr 2011, Roger Leigh wrote:
> > { find var/run/ ! -type d -print0;
> > find var/lock/ ! -type d -print0; } | xargs -0r $_CHROOT_SH rm
> >
> > I'm afraid this will need fixing in util-vserver(?) though. We can't
> > work around this in initscripts postinst, I'm afraid, since it worked
> > correctly, and this happened after the migration.
>
> The proper fix would be to use bind mounts, or always use multiple tmpfs
> (which is safer, anyway).

We have now fixed this issue by never moving /var/run or /var/lock
in postinst. In the case of a chroot/vserver, we simply create a
symlink from the new location (/run) to the old (/var/run) so that
both paths are functional. In consequence, /var/run and /var/lock
will remain directories in a vserver environment.

If a host environment, we do create symlinks at the next boot, but
vserver won't trip up in this situation.


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
 
Old 04-16-2011, 12:58 AM
Henrique de Moraes Holschuh
 
Default /run support for wheezy: final (I hope) call for testing

On Sat, 16 Apr 2011, Roger Leigh wrote:
> On Fri, Apr 15, 2011 at 08:59:01PM -0300, Henrique de Moraes Holschuh wrote:
> > On Fri, 15 Apr 2011, Roger Leigh wrote:
> > > { find var/run/ ! -type d -print0;
> > > find var/lock/ ! -type d -print0; } | xargs -0r $_CHROOT_SH rm
> > >
> > > I'm afraid this will need fixing in util-vserver(?) though. We can't
> > > work around this in initscripts postinst, I'm afraid, since it worked
> > > correctly, and this happened after the migration.
> >
> > The proper fix would be to use bind mounts, or always use multiple tmpfs
> > (which is safer, anyway).
>
> We have now fixed this issue by never moving /var/run or /var/lock
> in postinst. In the case of a chroot/vserver, we simply create a
> symlink from the new location (/run) to the old (/var/run) so that
> both paths are functional. In consequence, /var/run and /var/lock
> will remain directories in a vserver environment.

Now, scripts that work outside of vservers and want /run might croak when
run inside a vserver.

Symlinks in system path components REALLY are best avoided.

We CAN afford four tmpfs in the first place, */run and */lock can be very
strictly limited (e.g. 10MB-100MB), so even in a bug/local attack scenario,
they are not a large problem. And that's only needed if bind mounts are
really such an horrible alternative in the first place (are they?).

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110416005858.GD12829@khazad-dum.debian.net">http://lists.debian.org/20110416005858.GD12829@khazad-dum.debian.net
 
Old 04-16-2011, 08:07 AM
Lars Wirzenius
 
Default /run support for wheezy: final (I hope) call for testing

On pe, 2011-04-15 at 21:58 -0300, Henrique de Moraes Holschuh wrote:
> Symlinks in system path components REALLY are best avoided.

Out of curiosity: why?

--
Blog/wiki/website hosting with ikiwiki (free for free software):
http://www.branchable.com/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1302941257.2921.74.camel@havelock.liw.fi">http://lists.debian.org/1302941257.2921.74.camel@havelock.liw.fi
 
Old 04-16-2011, 09:49 AM
Roger Leigh
 
Default /run support for wheezy: final (I hope) call for testing

On Fri, Apr 15, 2011 at 09:58:58PM -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 16 Apr 2011, Roger Leigh wrote:
> > On Fri, Apr 15, 2011 at 08:59:01PM -0300, Henrique de Moraes Holschuh wrote:
> > > On Fri, 15 Apr 2011, Roger Leigh wrote:
> > > > { find var/run/ ! -type d -print0;
> > > > find var/lock/ ! -type d -print0; } | xargs -0r $_CHROOT_SH rm
> > > >
> > > > I'm afraid this will need fixing in util-vserver(?) though. We can't
> > > > work around this in initscripts postinst, I'm afraid, since it worked
> > > > correctly, and this happened after the migration.
> > >
> > > The proper fix would be to use bind mounts, or always use multiple tmpfs
> > > (which is safer, anyway).
> >
> > We have now fixed this issue by never moving /var/run or /var/lock
> > in postinst. In the case of a chroot/vserver, we simply create a
> > symlink from the new location (/run) to the old (/var/run) so that
> > both paths are functional. In consequence, /var/run and /var/lock
> > will remain directories in a vserver environment.
>
> Now, scripts that work outside of vservers and want /run might croak when
> run inside a vserver.

Why would they? In both situations, /run, /run/lock and /run/shm
are all valid paths, be they real directories or symlinks. In the
postinst and init scripts, we've taken care to ensure that the old
and new paths are valid (and the same) in all circumstances.

> We CAN afford four tmpfs in the first place, */run and */lock can be very
> strictly limited (e.g. 10MB-100MB), so even in a bug/local attack scenario,
> they are not a large problem. And that's only needed if bind mounts are
> really such an horrible alternative in the first place (are they?).

On a host system, we can bind mount /run on /var/run and /run/lock
on /var/lock easily enough. We already do this if we can't create a
symlink. But a symlink works just as well, and is less likely to
result in inconsistency if the original directory is replaced with
another mount, unmounted, or otherwise changed (mount options).
Since it's just a pointer, it doesn't itself hold separate state,
which a bind mount does (given that they are independent vfsmounts).

On a guest system, we can never use bind mounts: rcS is either not
run, might run, or is replaced by other scripts, so we have to set
up the symlinks in postinst. If we used bind mounts in postinst
they would be lost and never recreated on system restart. Symlinks
are the only reliable choice here.


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
 
Old 04-16-2011, 06:03 PM
Adam Borowski
 
Default /run support for wheezy: final (I hope) call for testing

On Fri, Apr 15, 2011 at 09:58:58PM -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 16 Apr 2011, Roger Leigh wrote:
> > On Fri, Apr 15, 2011 at 08:59:01PM -0300, Henrique de Moraes Holschuh wrote:
> > > On Fri, 15 Apr 2011, Roger Leigh wrote:
> > > > { find var/run/ ! -type d -print0;
> > > > find var/lock/ ! -type d -print0; } | xargs -0r $_CHROOT_SH rm
> > > >
> > > > I'm afraid this will need fixing in util-vserver(?) though. We can't
> > > > work around this in initscripts postinst, I'm afraid, since it worked
> > > > correctly, and this happened after the migration.
> > >
> > > The proper fix would be to use bind mounts, or always use multiple tmpfs
> > > (which is safer, anyway).
> >
> > We have now fixed this issue by never moving /var/run or /var/lock
> > in postinst. In the case of a chroot/vserver, we simply create a
> > symlink from the new location (/run) to the old (/var/run) so that
> > both paths are functional. In consequence, /var/run and /var/lock
> > will remain directories in a vserver environment.
>
> Now, scripts that work outside of vservers and want /run might croak when
> run inside a vserver.

Only if the symlink says "/run". If it leads to "../run", an outside script
will still work.

The last version I tested produced absolute ones, it might be better to make
them relative.

--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
 

Thread Tools




All times are GMT. The time now is 07:07 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org