awesome. this is just what i was originally looking for, tells me what i need
to know, and some why.
one minor nit though, there should probably be some mention that building as a
normal user is now preferred and sometimes necessary (as of 5.6? i don't know
how recent these changes were made, but think before the release was cut),
since for instance you CAN'T build groff as root anymore at all.
in fact this snag at building groff is the reason for my original question,
as i decided maybe it was about time to not build as root anyway, which caused
other problems, and the information was not readily available. not everyone
can keep up day to day with many changes, even experience users, and they will
see this first. i think was just one of the first to fall into this pit, since
i have been following -current recently, so i thought a sign should be posted...
i was also toying with that paragraph you so despised:
In the following list, each target will run the preceding targets in
order automatically. That is, build will be run (if necessary) by
install, and so on all the way to fetch. In typical use, one will only
run install explicitly (as normal user, with SUDO defined in
/etc/mk.conf), or build (as user), then install (as root).
the best i could come up with was:
In the following list, each target will run the preceding targets in
order automatically. That is, build will be run (if necessary) by
install, and so on all the way to fetch. In typical use, one should
build packages as a normal user, but install requires the SUDO variable
to be set (in the environment or in /etc/mk.conf), or you can run install
as root after having built the package as a normal user.
still has some of the problems you mentioned before, and is still incomplete,
but i think it is clearer wording of what was already there (i didn't add
anything.)
ultimately, i think this is an epistemological problem...
On Wed, 22 Oct 2014 12:34:15 +0200 Ingo Schwarze <schwa...@usta.de> wrote:
> Hi Nick,
>
> here is a patch better explaining sudo(8) configuration for ports.
>
> I'm not just asking for an OK to commit; i also hope for a cluestick
> to understand what's up with faq15.html versus ports/ports.html.
> Both seem largely duplicate, and the text i'm patching is in both.
> Should one of the copies be deleted or merged into the other?
> If so, which way?
>
> thev...@openmailbox.org wrote on Tue, Oct 21, 2014 at 11:11:26PM -0400:
> > thev...@openmailbox.org wrote on Tue, Oct 21, 2014 at 06:12:08PM -0400:
>
> >> i had a problem recently with compiling ports as a normal user,
> >> and it was pointed out to me i needed to be in group wsrc.
>
> > the only issue i really have is that this information should be
> > accessable *somewhere*, otherwise you are going to get more dumb
> > questions like my first one. perhaps this should then be in the faq?
>
> That makes some sense to me, given that it is an issue of the type
> "I want to do X and don't know which tools to use" rather than of
> the type "How does tool Y work?". Probably, no single manual is
> an appropriate place since the answer involves multiple tools:
> sudo(8), sudoers(5) User Specification, sudoers(5) env_keep, group(5),
> bsd.port.mk(5), mk.conf(5).
>
> THEvoid, thanks for insisting, i hope we get this fixed somehow...
>
> Yours,
> Ingo
>
>
> Index: faq15.html
> ===================================================================
> RCS file: /cvs/www/faq/faq15.html,v
> retrieving revision 1.101
> diff -u -r1.101 faq15.html
> --- faq15.html 1 May 2014 15:01:14 -0000 1.101
> +++ faq15.html 22 Oct 2014 10:34:40 -0000
> @@ -884,11 +884,35 @@
> <li>You can set up
> <a
> href="http://www.openbsd.org/cgi-bin/man.cgi?query=sudo&sektion=8";>sudo(8)</a>
> and have the ports system use it for tasks requiring superuser permissions.
> -Just add a line to <tt>/etc/mk.conf</tt> containing
> +This requires granting three permissions:
> +
> + <ul>
> + <li>The user who is going to build ports needs permission
> + to run arbitrary commands as the superuser,
> + see the "User Specification" subsection in the
> + <a
> href="http://www.openbsd.org/cgi-bin/man.cgi?query=sudoers&sektion=5";>sudoers(5)</a>
> manual.
> +
> + <li>The user who is going to build ports needs permission
> + to pass certain environment variables used by the ports system
> + from the shell calling sudo to the privileged shell,
> + see the <tt>env_keep</tt> variable in
> + <a
> href="http://www.openbsd.org/cgi-bin/man.cgi?query=sudoers&sektion=5";>sudoers(5)</a>.
> + The default file <tt>/etc/sudoers</tt> already provides an appropriate
> + list of variables for members of the <tt>wsrc</tt> group, so it is
> + usually sufficient to add the user who is going to build ports to that
> + <a
> href="http://www.openbsd.org/cgi-bin/man.cgi?query=group&sektion=5";>group(5)</a>.
> +
> + <li>The ports system needs permission to invoke sudo.
> + This can be granted by setting the <tt>SUDO</tt> variable defined in
> + <a
> href="http://www.openbsd.org/cgi-bin/man.cgi?query=bsd.port.mk&sektion=5";>bsd.port.mk(5)</a>
> + in the environment, which can be made permanent
> + by adding the following line to to
> + <a
> href="http://www.openbsd.org/cgi-bin/man.cgi?query=mk.conf&sektion=5";>mk.conf(5)</a>:
>
> <blockquote><pre>
> SUDO=/usr/bin/sudo
> </pre></blockquote>
> + </ul>
>
> <li>You can modify the ownerships of the ports tree so that you can write
> there as a regular user.
