[Slackbuilds-users] on creating users

[Niels Horn]

Miguel,

This is not an issue.
If the script creates a package with a file owned by user ABC with UID xyz,
it will be installed with that UID.
If the user does not exist on the box where you're installing the package,
the file will still have that UID.
Listing the files it won't show a user name, just the UID as the owner.

I hope I managed to make it clear :)


--
Niels Horn


On Tue, Jun 18, 2013 at 3:13 PM, Miguel De Anda <miguel at thedeanda.com>wrote:

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