[Slackbuilds-users] on creating users

[Niels Horn]

The manual method is fine if you build-once / install once.
But if I understood correctly, Miguel's question is about build-once /
install-many, storing the created package centrally and then installing it
on several boxes.

In this case, one might forget to create the user / group on the box where
you're installing it.

I have this same issue and never found a nice & clean solution.
I'm also against automatic user creation and just throwing out a warning
after installation (in doinst.sh) might not be very effective.

As an administrator of several servers and desktops, I use a local solution:
- a shell script wrapper that calls installpkg
- a centralized file with pre- & post- commands to run (pre- like checking
for a user I need, post- like copying some standard configuration files I
use for a specific package)
But this is for local administration and I see no way to implement this in
the SlackBuilds.

But, as Robby, I'm open to suggestions to make my life easier :)


--
Niels Horn


On Tue, Jun 18, 2013 at 1:35 PM, King Beowulf <kingbeowulf at gmail.com> wrote:

> I'll vote for the manual method already used in some SBo scripts:
> 1. Note default settings In README, instructing user to set up
> user/group before running script
> 2. Option such as GRP=blah ./script as needed to set up rc etc
>
> I think this is the most generic, easiest to avoid stomping on settings.
>
> Ed
>
>
>
> On 6/18/13, Robby Workman <rworkman at slackbuilds.org> wrote:
> > On Tue, 18 Jun 2013 03:17:43 -0700
> > Miguel De Anda <miguel at thedeanda.com> wrote:
> >
> >> what's the best practice for server/daemon apps that we want to run
> >> as an unprivileged user/group? for example, apache often runs as
> >> apache.apache and mysql as mysql.mysql.
> >>
> >> i found one build script that has a grep for /etc/passwd
> >> and /etc/group and has some hard-coded uid/gid's in the suggested
> >> user/groups. my concern with this method is that if you archive the
> >> tgz file (to install on a remote machine for example) you have to
> >> remember that you ran some commands against the buidl system. do we
> >> want to add a similar check in the doinst.sh script? maybe a warning?
> >
> >
> > I've been bitten by this on some of my own systems, but I'm not
> > convinced that there's a *good* solution to it.
> >
> > A note in doinst.sh is likely (almost sure) to be missed by many
> > admins (e.g. me) who do "batch installs" of add-ons to newly
> > deployed systems, so the extra work of adding notes there isn't
> > really something I want to commit to doing.
> >
> > I also don't really like the idea of checking for existence of
> > any required user/group and automatically creating it/them if
> > it/they do not already exist, and again I'll draw on my own
> > experience for that: I like to keep my UIDs and GIDs in sync
> > across all of my systems, so I'd rather have something fail
> > horribly due to a missing user/group than have a stealthily
> > created (and wrong/inconsistent) user and uid present.  I use
> > NFS locally so UID/GID consistency is a big deal for me.
> >
> > All that said, I'm not against doing all of this in a better
> > way, but I'll have to be convinced that it's actually better :-)
> >
> > -RW
> >
>
> --
> Sent from my mobile device
>
> You! What PLANET is this!
>         -- McCoy, "The City on the Edge of Forever", stardate 3134.0
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - http://slackbuilds.org/faq/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20130618/7bd8f578/attachment-0001.html>