--u3/rZRmxL6MmkK24
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Johnny Lam writes:
> Krzysztof Raczkowski wrote:
> >
> >I'm using pksrc on Solaris. I've got one question about how pkgsrc create
> >new users and groups. It just takes first available UID and GID instead =
of
> >using fixed numbers. So I have:
> >1-st server: uid=3D55001(postfix) gid=3D101(postfix)
> >2-nd server: uid=3D55002(postfix) gid=3D101(postfix)
=20
[..]
> If the users and groups already exist on the machine, then these have no=
=20
> effect, and the package will use the pre-existing uids and gids=20
> allocated for these users and groups on the system.

Which is a very good thing.

> If there was a true desire by admins for this to be generally tunable, I=
=20
> suppose I would extend the pkginstall framework to allow PKG_UID.<user>=
=20
> and PKG_GID.<group> variables to easily set these values.  Do people=20
> really want this?

No. Creating groups and users is an administrative task of a=20
completely different flavour than package compilation or=20
installation. These should *not* be intermixed. The same goes=20
for making executables suid or sgid (which is an even more=20
serious matter). A package which needs special accounts or=20
needs certain executables to be suid or sgid to function=20
properly, should provide a short shell script which reflects=20
these desires. The system administrator can then review the=20
script (after installation of the package) and decide which=20
parts of it to execute and maybe to change something about it.=20
Maybe he knows that some executables do not have to be suid=20
for his purposes? For example, cdrecord often is installed=20
suid root, but in my experience, this is not needed. Hence I=20
would *not* install it suid root on my machines.

I know that some packages require certain accounts to exist=20
prior to compilation, and they incorporate information about=20
these accounts into the binary package (leafnode does this for=20
example). This is heavily broken design. What if I'd like to=20
run several instances of leafnode on one machine under=20
different accounts? I will have to compile several different=20
leafnode packages then.

My point is that we should not adapt Pkgsrc to the needs of=20
such packages to more extent than that of a workaround. Maybe=20
we can even patch such packages to behave better, i.e., in the=20
way described above: provide a (sample) script for creating=20
accounts, etc. in order to configure *one* *instance* of this=20
service. (I tried this with leafnode once but realized that=20
it's more work than for one afternoon, at least for someone=20
not familiar with the code. YMMV, I hope.)

Best regards,
lk

--u3/rZRmxL6MmkK24
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)

iD8DBQFENW6l1gObwed86AkRAnDuAKDG7EEj0g45ktrDhXFERddZBAfWCwCeMFyS
RwQJxb6iB0e0k9UyCctUKr8=
=hA0q
-----END PGP SIGNATURE-----

--u3/rZRmxL6MmkK24--