Peter Green wrote:
>
> also sprach wuebben:
> > Hi!
> > Am I assuming correctly that VPOPMAILUID, VPOPMAILGID and VPOPMAILDIR are
> > statically compiled into the binaries?
>
> Yep.
Yep ;]
>
> > 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.
There is some code in vpopmail to get the uid/gid from
users/assign(cdb)
file. So at least that code is fairly disk i/o efficent.
My personal opinion is that I need to squeeze out as much efficency
as possible, especially for high volume systems. If that means the
UID/GID need to be compiled in, so be it.
In terms of the ease of installing from source versus RPM
RPM: 10 seconds
source: 10 minutes (configure, make, make install-strip)
And with the source I get the flexiblity of turning on or off
any of the available options. 10 minutes isn't that much extra
time to me. If you have to install on a large number of machines,
it's farily easy to tar up the binaries and write a short script
to add the user/group and untar the files.
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
Ken Jones
