Your message dated Mon, 11 Oct 2010 23:37:16 +0200
with message-id <[email protected]>
and subject line Re: [pkg-lighttpd] Bug#597643: lighttpd: Permissions break on 
upgrade when running as non www-data user
has caused the Debian Bug report #597643,
regarding lighttpd: Permissions break on upgrade when running as non www-data 
user
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.)


-- 
597643: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597643
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: lighttpd
Version: 1.4.28-1
Severity: normal


I run lighttpd as a regular user, instead of the www-data user.  This is 
primarily due to the concern in bug #573320, and since it this is one user 
machine, I'd rather have them run 
as themselves than letting them ftp, etc. as www-data.

That all works fine, however, I upgraded the other day, and the upgrade script 
must include a 
chown -R www-data.www-data /var/log/lighttpd and 
chmod -R wwww-data.www-data /var/cache/lighttpd

as everything broke after the upgrade.

The log directory was easy to spot, but I didn't notice that the cache 
permissions had been reset until I was debugging a 413 Request Too Large error, 
which turned out to be the 
permissions were wrong and nothing to do with the size of the request.

Perhaps the chown should only happen on install, and not on upgrade?
Or maybe check the server.username/group?
Or at least warn the user that you are changing permissions, so he can manually 
put them back.

-- System Information:
Debian Release: squeeze/sid
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32.9-rscloud (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash

Versions of packages lighttpd depends on:
ii  libattr1                1:2.4.44-2       Extended attribute shared library
ii  libbz2-1.0              1.0.5-4          high-quality block-sorting file co
ii  libc6                   2.11.2-5         Embedded GNU C Library: Shared lib
ii  libgamin0 [libfam0]     0.1.10-2+b1      Client library for the gamin file 
ii  libldap-2.4-2           2.4.23-5         OpenLDAP libraries
ii  libpcre3                8.02-1.1         Perl 5 Compatible Regular Expressi
ii  libssl0.9.8             0.9.8o-2         SSL shared libraries
ii  libterm-readline-perl-p 1.0303-1         Perl implementation of Readline li
ii  lsb-base                3.2-23.1         Linux Standard Base 3.2 init scrip
ii  mime-support            3.48-1           MIME files 'mime.types' & 'mailcap
ii  zlib1g                  1:1.2.3.4.dfsg-3 compression library - runtime

Versions of packages lighttpd recommends:
ii  spawn-fcgi                    1.6.3-1    A fastcgi process spawner

Versions of packages lighttpd suggests:
pn  apache2-utils                 <none>     (no description available)
ii  openssl                       0.9.8o-2   Secure Socket Layer (SSL) binary a
ii  rrdtool                       1.4.3-1    time-series data storage and displ

-- Configuration Files:
/etc/lighttpd/conf-available/10-fastcgi.conf changed:
(not relevant to bug)

/etc/lighttpd/lighttpd.conf changed:
** Relevant changes:
server.username            = "george"
server.groupname           = "george"


-- no debconf information



--- End Message ---
--- Begin Message ---
On Tue, Sep 21, 2010 at 6:48 PM, Jon Daley <[email protected]> wrote:
> On Tue, 21 Sep 2010, Olaf van der Spek wrote:
>>
>> Don't chmod/chown system-owned dirs, use other dirs. ;)
>
>        Ok, did that.  perhaps a comment should be put in the config file
> next to the user/system changing vars, mentioning that it is required to
> also change other values when changing those vars.

Maybe, maybe not. I'll think about it.

Olaf


--- End Message ---

Reply via email to