Summary: | www-servers/lighttpd - tbz2 should set up user/group on target filesystem | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Rafal Lalik <rafallalik> |
Component: | [OLD] Server | Assignee: | Alex Alexander (RETIRED) <wired> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | dev-portage, hwoarang |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Rafal Lalik
2013-08-19 23:09:02 UTC
Maybe the lighttpd ebuilds should simply repeat these lines from pkg_setup() in pkg_preinst(): enewgroup lighttpd enewuser lighttpd -1 -1 /var/www/localhost/htdocs lighttpd No, it will not help - I have checked this. IMHO problem lays in portage (that is why I refer bug to it). Please check /usr/portage/eclass/user.eclass. Inside you can find function enewuser which you have proposed to use. Firstly, to check whether user exists tgetent is used, which is a wrapper for system getent, which then reads database from /etc. Secondly, to add user it uses system commands like useradd which will touch /etc, not $SYSROOT/etc Thus I would say this is general problem of portage, not of the ebuild. Could I ask to restore original title - to bring more attention to this bug? As I explained before, I am rather convinced that bug is related to the portage, not to lighttpd. Rafal I am not 100% certain how to solve this so CC'ing portage (In reply to Rafal Lalik from comment #2) > IMHO problem lays in portage (that is why I refer bug to it). Please check > /usr/portage/eclass/user.eclass. Inside you can find function enewuser which > you have proposed to use. Yes it's bug 53269. I think I found some solution, kind of work around. Lets take an example of lighttpd: - we need to add user to the system, - set proper owners for /var/{lib.log}/lighttpd, - our sysroot is in $SYSROOT (wherever it points). Example of solution: 1) lets create temporary chroot environment, for example in SR=/tmp/sysroot: mkdir $SR mount --bind / $SR mount --bind $sysroot/etc $SR/etc mount --bind $sysroot/var/lib $SR/var/lib mount --bind $sysroot/var/llog $SR/var/log 2) create user/group (all sys-apps/shadow apps support chrooting) useradd --root $SR lighttpd 3) set owners: /usr/bin/chroot $SR /bin/bash -c "chown -R lighttpd:lighttpd /var/{lib,log}/lighttpd 4) unmount all binds Binding can be dangerous if proper dir structure doesn't exists on the $SR, but it could be avoided by for example, temporary bind locations in, i.e. $SR/tmp/bind{1,2,3,...} Changes are mostly required is user.eclass Maybe additional use of trap will be need to prevent leaving binds mounted after crash. Another question is whether all architectures keeps passwd/shadow in the samo format, if using useradd of build machine will not corrupt files on SYSROOT machine. For chroot when cross-compiling for a different architecture, it could use binfmt_misc and qemu for emulation. It's kind of inefficient and ugly though. It's much nicer to take advantage of things like shadow's --root option which is mentioned in bug #53269, comment #49. But this requires to use 3rd hand software whereas normal binding and chroot use what is already in the basic system. What more, you would need to identify architecture of sysroot system, etc. In my opinion qemu is to problematic. I also found this propositions on the web but refused it as usable. |