portupgrade -s and NFS /usr/ports?

Scott Mitchell scott+lists.freebsd at fishballoon.org
Sun Feb 26 14:38:00 PST 2006

Hi all,

Just wondering if anyone else out there has a similar setup to this and can
offer any hints on improving it:

- NFS-exported /usr/ports, permissions set so it's writable by anyone in
  the 'ports' group.

- Mount this on various client machines where portupgrade will be run to
  build ports and generate packages.  The pkgtools.conf file is set up so
  that packages will be written to /usr/ports/packages-<pkg_branch>,
  e.g. packages-5-stable.

- I was hoping to be able to avoid root access to /usr/ports by using the
  -s flag to portupgrade, but portupgrade seems to want to be root whenever
  it invokes a make command on a port.  I can move the actual build onto a
  local filesystem by setting WRKDIRPREFIX - I did this anyway for
  performance reasons.  However, I want downloaded distfiles and built
  packages to go in /usr/ports where other machines can see them, but there
  doesn't seem to be a way to prevent portupgrade from fetching distfiles
  or building packages as root in every situation.

The best workaround I've come up with is to maproot=some_user on the NFS
export, where some_user is a member of the 'ports' group.  This _almost_
works, except when trying to overwrite a package that is owned by someone
else (the ports framework doesn't move/delete the old package first - but a
wrapper script around pkg_create fixes that) or if I run portupgrade on the
NFS server and end up with files owned by root that need to be fixed up
manually afterwards.  I could use maproot=root, but /usr/ports shares a
filesystem with a bunch of other stuff, and I'd rather not have the whole
lot be remotely root-writable.

Is anyone else running a setup like this and found a better workaround for
these problems?



Scott Mitchell           | PGP Key ID | "Eagles may soar, but weasels
Cambridge, England       | 0x54B171B9 |  don't get sucked into jet engines"
scott at fishballoon.org | 0xAA775B8B |      -- Anon

More information about the freebsd-questions mailing list