[Slackbuilds-users] on creating users

Tue Jun 18 18:37:02 UTC 2013

Just throwing it out there, so don't judge me harshly :P

Why not have the post-install script create user/group automagically,
but have the slackbuild process variables, say, PKG_USER, PKG_GROUP,
PKG_UID, and PKG_GID, and that way you can build your package with
custom credentials which jive with your setup. If either variable is
undefined, skip user/group creation.

On 06/18/2013 01:58 PM, Miguel De Anda wrote:
> 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 <niels.horn at gmail.com 
> <mailto:niels.horn at gmail.com>> 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 <kingbeowulf at gmail.com 
> <mailto: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 
> <mailto:rworkman at slackbuilds.org>> wrote:
>> On Tue, 18 Jun 2013 03:17:43 -0700 Miguel De Anda <miguel at thedeanda.com
>> <mailto: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
> <mailto: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/
> 
> 
> 
> _______________________________________________ SlackBuilds-users mailing
> list SlackBuilds-users at slackbuilds.org
> <mailto: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/
> 
> 
> 
> 
> 
> _______________________________________________ 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20130618/6937d264/attachment-0001.asc>