also sprach kbo:
> Peter Green wrote:
> > also sprach wuebben:
> > > If so, why is this so? It makes assembling RPM packages much harder.
> >
> > qmail does the same thing for the same reason, I think: security. However,
> > there are ways of getting around this when packaging RPMs. Easiest might be
> > patching vpopmail to get uid/gid from a file (directory is much harder) and
> > see if Ken will incorporate it. Otherwise, provide the patch with the RPM
> > and apply it first thing after unpacking the tarball.
> >
> > RPMs (as well as .deb's) have had to deal with this for some time with
> > qmail; it's tricky, but not impossible.
>
> Two reasons:
> 1) security
>
> 2) efficency: it removes the need to do a file I/O to get the UID/GID.
Ah yes, the patch to qmail to break the uids into files works with daemons,
IIRC. Thus, the file I/O is done once: at startup.
It would make sense why this model would be less-than-optimal for vpopmail,
as the file I/O would be incurred with *every* *delivery*. Yuck.
> There is an alternative to building an RPM with precompiled UID/GID.
> Pick a infrequently used uid/gid and compile those in. Then have
> the RPM check for the uid/gid before installing and print an error
> if it finds them. Best of both worlds
Except that it's a fairly significant *hack*, more than an elegant solution.
I think compiling in the uid/gid is acceptable.
/pg
--
Peter Green : Gospel Communications Network, SysAdmin : [EMAIL PROTECTED]
---
If you get invited to your first orgy, don't just show up nude. That's a
common mistake. You have to let nudity happen.
(Jack Handey)
