thanks. i guess the safest answer is to not automatically create the user. i'm thinking of adding a note in the slack-desc and possibly in the rc script as well. something along the lines of
echo "$PRGNAME failed to start because it requires a group/user $GRPNAME/$USRNAME" exit 1 miguel On Tue, Jun 18, 2013 at 9:45 AM, Niels Horn <[email protected]> wrote: > 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 <[email protected]>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 <[email protected]> wrote: >> > On Tue, 18 Jun 2013 03:17:43 -0700 >> > Miguel De Anda <[email protected]> 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 >> [email protected] >> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users >> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ >> FAQ - http://slackbuilds.org/faq/ >> >> > > _______________________________________________ > SlackBuilds-users mailing list > [email protected] > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > > >
_______________________________________________ SlackBuilds-users mailing list [email protected] http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
