[Slackbuilds-users] on creating users

[Miguel De Anda]

I just realized something... I'm looking at the jboss and tomcat scripts as
they need users as well... the build script chown's some files under that
user/group. I think this would cause the package to fail if the gid/uid on
the target system doesn't match the build system right? Should the rc
script chown files as needed each time it starts?


On Tue, Jun 18, 2013 at 10:58 AM, Miguel De Anda <miguel at thedeanda.com>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> 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/ea9d75af/attachment.html>