[Slackbuilds-users] on creating users

Miguel De Anda miguel at thedeanda.com
Tue Jun 18 17:58:03 UTC 2013


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> 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>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/
>>
>>
>
> _______________________________________________
> 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/9fd863a1/attachment.html>


More information about the SlackBuilds-users mailing list