The following patches allow distccd run as a "distccd" user instead of nobody. This also allowes to save the PID file in /var/run for consistancy. Reproducible: Always Steps to Reproduce: 1. 2. 3. Portage 2.0.46-r9 (default-x86-1.4, gcc-3.2.1, glibc-2.3.1-r2) ================================================================= System uname: 2.4.20 i686 Pentium III (Coppermine) GENTOO_MIRRORS="ftp://ftp.ucsb.edu/pub/mirrors/linux/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share /config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="/usr/local/portage" USE="x86 oss 3dnow avi cups encode gif jpeg kde libg++ libwww mmx mpeg ncurses pdflib png qtmt quicktime sdl spell truetype xml2 xv zlib berkdb readline arts java pam ssl python oggvorbis motif opengl alsa dvd ldap mozilla pic samba tiff -perl -apm -cdr -crypt -gdbm -gnome -gpm -gtk -imlib -mikmod -nls -qt - slang -svga -tcpd -usb -X -xmms" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -O3 -pipe" CXXFLAGS="-march=pentium3 -O3 -pipe" ACCEPT_KEYWORDS="x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox ccache buildpkg"
Created attachment 7883 [details, diff] patch to the ebuild described in the bug report
Created attachment 7884 [details, diff] patch to the rc script described in the report
oops! sorry about the first hunk of the ebuild patch. forgot to remove the KEYWORDS change. Please ignore that.
And how you defined the distccd user? My /var/run doesn't give write access to other than the owner and the owner is root drwxr-xr-x 11 root root 4096 Jan 29 09:38 run
I simply changed /etc/init.d/distccd to start as nobody:users and it works. But I am unsure of the security consequence... So you leave the script as is and change the -c nobody to -c nobody:users and the /var/tmp I believe is already set drwxrwxr-x 8 root users 4096 Feb 6 10:00 tmp
The same way that bind defines the "named" user and mysql defines the "mysql" user. Those services get around the /var/run owner restrictions by creating a subdirectory that the respective accounts can write their PID files to. The ebuild patch presented provides the same consistant functionality. Aside from that, there may be other tweaks to add to the rc script -- one is that the new versions of distcc (1.1) allow for a --user flag, which maybe cleaner.
I have been meaning to do this for a long time, as it really isn't a good idea to run distccd as -nobody :) I'll pass all the distcc stuff on to u now that I see u want it :)
And so this falls into my lap. I like the idea this change. Let me check in the latest distcc-1.1-r7 and we can tackle this in -r8. See bug 13897 for the saga describing the changes that will be included. In the future, please generate unified diffs (using diff -u); if you had done so, your ebuild patch would probably still apply to the -r7 ebuild. As it is, please merge your changes with -r7 once it's available and resubmit your changes using diff -u. Thanks. Well, okay, after looking a little closer, I think it will be best to have the user and group added to baselayout, which can be justified now that portage has better integration with the latest distcc ebuilds. Also, the /var/run/distccd should probably be done in install with: dodir /var/run/distccd && touch ${D}/var/run/distccd/.keep. These two things would eliminate the need for the pre/postinst routines, if I am not mistaken. Let me know what you think.
Right after posting my last comment, I began thinking about the future. Given the current PATH hack when starting distccd, wouldn't it be nice to be able to start the daemon on a per-user basis? This plays into the overall distcc plans for allowing each user to set their gcc-config settings independently from the system setting. As such, they could simply run gcc-config to set the compiler, then run a distccd on a private (but specified by the user) port. The distcc package already supports this, it's just a matter of putting the remaining pieces in place - and there aren't many of those. What do ya'll think?
Note that distcc CVS supports automatically changing to the username "distcc". Please change to use the standard name.
I have fixed this in CVS in the latest -r10 release. It seems to work well, but let me know if it breaks anything for you.
Sorry to keep being a bother with this, but I don't think its entirely solved. In src_install() we now create the /var/run/distccd directory and try to make it owned by the distcc user (which doesn't yet exist -- it gets created at pkg_preinstall() step) resulting in this error: install: invalid user `distcc' touch: creating `/var/tmp/portage/distcc-1.1-r10/image//var/run/distccd/.keep': No such file or directory I don't know of a correct way of fixing this other than having distcc user added to baselayout (I'm not sure if this has happened already). Aside from this, we are using the diropts() function after dodir(). is this the correct way? wouldn't it make more sense to do something like this (pardon my ignorance if I am wrong). diropts -m0755 -o distcc -g daemon keepdir /var/run/distccd
Okay, this explains the 'install it twice and it works' phenomenon I've heard. Doing what should have been done before, I've submitted bug 15969 to have the distcc user added to baselayout and added it here as a dependency. So the saga continues.
Adding another chapter to this saga: Is it necessary to make /usr/lib/distcc a keepdir? When unmerging, portage ignores this directory and leaves all the links which remain pointing to a /usr/bin/distcc that no longer exists. (Should this be filed as a separate bug?)
That is a portage problem, I believe. the same thing happens in gcc-config >1.2.9 ebuilds when unmerged.
Really, the process of building symlinks should be left to distcc-config, which would be run as a side-effect of gcc-config (if if the former was detected) after a new cross-compiling toolchain is installed/uninstalled to rebuild the symlinks. distcc-config should have an --uninstall feature that deletes this directory as a side-effect.
Okay, all of this should be fixed in the latest distcc-1.2.ebuild. A distcc-config script is now included, its --install-links option used by the ebuild; uninstall is not done right now but is possible manually. Also now allows for a future gcc-config to run this tool when installing/uninstalling cross-compilers. Also, fixed up the distcc user install silliness, I hope. Please verify everything is kosher.
While having distcc run as user distcc is a good idea, it horks up the default log file location, since it can't write to /var/log/distcc.log (using the masked 2.0.1 version). To fix it, I made a directory for the lof file, just like the /var/run/distcc stuff. It seems to work fine, but I'm not sure if this is thge right way to fix it. Should this be added to the ebuild too?
