Your message dated Sun, 24 Feb 2008 19:02:06 +0000
with message-id <[EMAIL PROTECTED]>
and subject line Bug#466885: fixed in runit 1.8.0-3
has caused the Debian Bug report #466885,
regarding runit: no way to maintain non-default permissions on supervise 
directories
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
466885: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466885
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: runit
Version: 1.8.0-2
Severity: normal

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I think that the current practice of replacing any supervise
directories in the service directory with links to /var/run is
probably the right thing to do.  However, this has the adverse
consequence of not being able to maintain non-default permissions on
supervise directories (if, for instance, it is desired to set looser
permissions on service supervise directories so that non-privileged
users may be allowed to check the state of a service).

If using update-service, any permissions set on the supervise
directories before they are added are removed when update-service
removes the old supervise directories and replaces them with links to
/var/run.  When runit then creates the supervise directories in
/var/run, it then does so with default permissions.  At this point the
permissions could be manually changed, but if the service is later
removed from system-wide supervision and re-added with update-service,
then the permissions will again be reset.

Similarly, if /var/run is a tmpfs that is created at boot (as is the
case for systems that use the "RAMRUN=yes" option in /etc/init.d/rcS),
permissions set after the service has been added will not be retained
across reboot.  The supervise directories will be purged at shutdown
and recreated at boot with default permissions.

It occurs to me that the permission on the supervise directories
*could* be set by the run scripts themselves.  However, this kind of
futzing by a service on it's own supervision seems a little
undesirable to me.

I'm not sure what the proper way to handle this is, though.  The only
thing I can think of at the moment is a runit configuration directive
that can be placed in the service directory that tell the supervising
daemon the permissions to use when creating the supervise directory if
it's not there; something like:

$ cat <servicedir>/<service>/supervise_perms
0755
$

I would be happy to have a discussion on the issue.  I would like to
figure out a solution, since it is occasionally desirable to make the
supervise directories readable for non-privileged users (we use this
in cereal[0], for instance).

Thanks again for such great maintaining work on such a great package.

jamie.

[0] http://packages.debian.org/cereal

- -- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing'), (200, 'unstable'), (101, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

runit depends on no packages.

Versions of packages runit recommends:
ii  fgetty                        0.6-5      very small, efficient, console-onl

- -- no debconf information

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iQIVAwUBR7217e00zqvie6q8AQIXQA//dqiLfbl4gcxEJAdOAX5oow0EjfKU/iKg
OfCUIw+K9rclUbXUip9IaJuQ56oA171mgWfOn+KgqwpXpmdr9tJpB7zqJpOkPtOD
PP+BTuzpJUFhR3H9muImmINgwnCZuzRL5SsJ3n6swh3fv2ixk2CGVdFjeTmy2hjh
czOdmjqJDouyTFGLugrfge4yfTCd8lIvlp48s72r/rxu3aV59dB+zQe9qmwVALe1
DqAY0uYpee7ImwN5SfR1F1w+tNaIQHpPWBjvdhIs7T8sO1+gfzvj2UKZU7LSjoqj
lsq3jkCzFqwPKu3qwY//oAlyo3Ay7j8IOld9Mv22JjSwDRv4Hdqi0xrJfW9lTv1s
sQaO2jKGd1n0Jku73aO9aYol1497Whk5QZls484cOpqAqhq4AK5mVrzDHXoE6feQ
qOgFP9SAsSTEPVX+qE35pHIbwVaJsY2/GjxAH0NOKOpwEII2vgchZmB8PGIrw9DZ
XheorZqkrZPcDRGtqMd5QXO10lQ22xBpUmEI4tPXoUPmK/3Bnwrcf+ttol/lynrt
EedN6XZv0KHpc+U/oo8hXZ5RTIKa7k62RxTt4Y32FPdTa0g4bgFzkg8a5k7qnKw4
CN69/nGqDovsiyy2bqRuLq4JNxpCuYfJrzrOYYkcFmo0mlvNBMhoAiTB/jtjPPDD
H6/5Fhub5CQ=
=UpOe
-----END PGP SIGNATURE-----



--- End Message ---
--- Begin Message ---
Source: runit
Source-Version: 1.8.0-3

We believe that the bug you reported is fixed in the latest version of
runit, which is due to be installed in the Debian FTP archive:

runit_1.8.0-3.diff.gz
  to pool/main/r/runit/runit_1.8.0-3.diff.gz
runit_1.8.0-3.dsc
  to pool/main/r/runit/runit_1.8.0-3.dsc
runit_1.8.0-3_powerpc.deb
  to pool/main/r/runit/runit_1.8.0-3_powerpc.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to [EMAIL PROTECTED],
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Gerrit Pape <[EMAIL PROTECTED]> (supplier of updated runit package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [EMAIL PROTECTED])


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sun, 24 Feb 2008 18:34:35 +0000
Source: runit
Binary: runit
Architecture: source powerpc
Version: 1.8.0-3
Distribution: unstable
Urgency: low
Maintainer: Gerrit Pape <[EMAIL PROTECTED]>
Changed-By: Gerrit Pape <[EMAIL PROTECTED]>
Description: 
 runit      - a UNIX init scheme with service supervision
Closes: 466579 466885
Changes: 
 runit (1.8.0-3) unstable; urgency=low
 .
   * debian/update-service: enforce argument; enforce <service-name> must
     not start with a dot and must not contain a slash.
   * debian/update-service: prefix fatal and warn message with progname;
     only warn on --remove if service is not registered, still fatal if it
     is not a symlink.
   * debian/2, debian/rules, debian/runit.README.Debian,
     debian/runsvdir-start.8, debian/update-service, debian/update-service.8:
     switch directory for services from /var/service/ to /etc/service/
     (#461478).
   * debian/runit.postrm: purge: adapt paths in /var/run/, remove ./supervise/
     subdirectories (or symlinks) in getty-5 service directory.
   * debian/update-service: when successfully adding a service simply print
     "Service <service-name> added." (thx Daniel Kahn Gillmor, closes:
     #466579).
   * debian/runit.preinst, debian/runit.postinst: move away from /var/service/
     to /etc/service/; restart runsvdir; retain backward compatibility symlink
     /var/service -> /etc/service until rdepends have adopted (#461478).
   * debian/update-service, debian/update-service.8: create symbolic links for
     ./supervise/ directories only if the service-directory resides in /etc/;
     don't re-create ./log/supervise/ symlink if it already is a symlink, just
     as already done for ./supervise/ (thx Jameson Rollins, closes: #466885).
   * debian/update-service, debian/update-service.8: symbolic links for
     ./supervise/ directories now point into /var/lib/supervise/ instead of
     /var/run/, so that they survive a reboot.
   * debian/rules: install /var/lib/supervise/.
   * debian/update-service: don't get confused if service-directory ends with
     a slash.
   * debian/runit.postrm: purge: remove /var/service compatibility symlink.
   * debian/diff/0001-runit-s-directory-for-services-on-Debian-is-etc-ser.diff:
     new: runit's directory for services on Debian is /etc/service/, not
     /var/service/.
   * debian/rules: target unpack: apply patch debian/diff/0001-*.
Files: 
 2844aabdbac5501094516a0171c3574d 627 admin optional runit_1.8.0-3.dsc
 0631bf1e161d02a720a71cb76a500fd3 11883 admin optional runit_1.8.0-3.diff.gz
 233f238883aaf579ea438828a41a1bba 112892 admin optional 
runit_1.8.0-3_powerpc.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHwbnzGJoyQbxwpv8RAuLDAJ9rgRtSJX+aAjaaiDS0pZAIO7oLhACeKW/Z
l9yrJupUO75JaxGO7SyS7Rs=
=VKIp
-----END PGP SIGNATURE-----



--- End Message ---

Reply via email to