cvs commit: doc/en_US.ISO8859-1/books/porters-handbook book.sgml

[Thomas-Martin Seck]

* Kris Kennaway (kris at obsecurity.org):

> On Mon, Feb 23, 2004 at 10:27:05PM +0000, Thomas-Martin Seck wrote:
> > 
> > I'm sorry, I did not obey this -- which uid/gid should I use instead?  I
> > do not need a fixed uid like qmail, just a starting point, pkg-install
> > will try to assign squid to the first free uid starting from there. The
> > same applies for the gid. It seems that I get slapped left and right
> > today for www/squid :(
> 
> Ports should always use fixed uids and gids.  Suppose that squid
> assigns itself one that is currently free on my machine, but is
> actually listed in the porters handbook as claimed by another port.
> Then later I try and install that port.  The results of this will be
> unpredictable, but not good.

Understood.

> You should choose a fixed uid and gid that is currently free, register
> it in the porter's handbook and use it.  Unfortunately since the 3128
> uid has already been deployed, you'll have to provide an upgrade path
> for people who have a squid installation from the port with files
> owned by that uid.  For example, a 'make upgrade' target that chowns
> the files to the new user, removes the old uid and gid and does
> whatever other transition work might be needed.  This would not be run
> by default, but pkg-message should suggest using it if the 3128 uid
> exists.

OK, I'd like to register the uid 100 then. I'll implement a uid
transition mechanism from 3128 to 100 and include it in the next
maintainer update.

> > btw: Is implementing something like WANT_UID/WANT_USER in bsd.port.mk
> > something worth pursuing? There are a lot of hand-made solutions of
> > varying quality in the ports system for this problem now.
> 
> What would that do?

It should create a pseudo-user with name=WANT_USER with uid=WANT_UID in
a unified way to reduce the chance of a maintainer doing something silly
in Makefile or pkg-install when hand-rolling this. The problem I see
with this proposal is that this is hard to implement this with make(1)
since ideally this should be something like 'makeuser(username, uid,
gid, homedir[, loginshell if we want to make this customizable])'. An
added bonus would be that the user/uid demand is clearly visible in the
Makefile (if that is of any value).

If implementing this in bsd.port.mk is not feasible, we should have at
least a known working reference for cut-and-pasting in the porters
handbook since there are at least three different implementations for
the problem of creating a user/group on the fly in the ports tree.