<div dir="ltr">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 <br><br>echo "$PRGNAME failed to start because it requires a group/user $GRPNAME/$USRNAME"<br>
exit 1<div><br></div><div style>miguel<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 18, 2013 at 9:45 AM, Niels Horn <span dir="ltr"><<a href="mailto:niels.horn@gmail.com" target="_blank">niels.horn@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div><div>The manual method is fine if you build-once / install once.<br>
</div>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.<br>
<br></div>In this case, one might forget to create the user / group on the box where you're installing it.<br><br></div>I have this same issue and never found a nice & clean solution.<br></div>I'm also against automatic user creation and just throwing out a warning after installation (in doinst.sh) might not be very effective.<br>
<br></div>As an administrator of several servers and desktops, I use a local solution:<br></div>- a shell script wrapper that calls installpkg<br></div>- 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)<br>
</div>But this is for local administration and I see no way to implement this in the SlackBuilds.<br><br></div>But, as Robby, I'm open to suggestions to make my life easier :)<br><br></div><div class="gmail_extra"><br clear="all">
<div>--<br>Niels Horn</div><div><div class="h5">
<br><br><div class="gmail_quote">On Tue, Jun 18, 2013 at 1:35 PM, King Beowulf <span dir="ltr"><<a href="mailto:kingbeowulf@gmail.com" target="_blank">kingbeowulf@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'll vote for the manual method already used in some SBo scripts:<br>
1. Note default settings In README, instructing user to set up<br>
user/group before running script<br>
2. Option such as GRP=blah ./script as needed to set up rc etc<br>
<br>
I think this is the most generic, easiest to avoid stomping on settings.<br>
<br>
Ed<br>
<div><div><br>
<br>
<br>
On 6/18/13, Robby Workman <<a href="mailto:rworkman@slackbuilds.org" target="_blank">rworkman@slackbuilds.org</a>> wrote:<br>
> On Tue, 18 Jun 2013 03:17:43 -0700<br>
> Miguel De Anda <<a href="mailto:miguel@thedeanda.com" target="_blank">miguel@thedeanda.com</a>> wrote:<br>
><br>
>> what's the best practice for server/daemon apps that we want to run<br>
>> as an unprivileged user/group? for example, apache often runs as<br>
>> apache.apache and mysql as mysql.mysql.<br>
>><br>
>> i found one build script that has a grep for /etc/passwd<br>
>> and /etc/group and has some hard-coded uid/gid's in the suggested<br>
>> user/groups. my concern with this method is that if you archive the<br>
>> tgz file (to install on a remote machine for example) you have to<br>
>> remember that you ran some commands against the buidl system. do we<br>
>> want to add a similar check in the doinst.sh script? maybe a warning?<br>
><br>
><br>
> I've been bitten by this on some of my own systems, but I'm not<br>
> convinced that there's a *good* solution to it.<br>
><br>
> A note in doinst.sh is likely (almost sure) to be missed by many<br>
> admins (e.g. me) who do "batch installs" of add-ons to newly<br>
> deployed systems, so the extra work of adding notes there isn't<br>
> really something I want to commit to doing.<br>
><br>
> I also don't really like the idea of checking for existence of<br>
> any required user/group and automatically creating it/them if<br>
> it/they do not already exist, and again I'll draw on my own<br>
> experience for that: I like to keep my UIDs and GIDs in sync<br>
> across all of my systems, so I'd rather have something fail<br>
> horribly due to a missing user/group than have a stealthily<br>
> created (and wrong/inconsistent) user and uid present. I use<br>
> NFS locally so UID/GID consistency is a big deal for me.<br>
><br>
> All that said, I'm not against doing all of this in a better<br>
> way, but I'll have to be convinced that it's actually better :-)<br>
><br>
> -RW<br>
><br>
<br>
</div></div><span><font color="#888888">--<br>
Sent from my mobile device<br>
<br>
You! What PLANET is this!<br>
-- McCoy, "The City on the Edge of Forever", stardate 3134.0<br>
_______________________________________________<br>
SlackBuilds-users mailing list<br>
<a href="mailto:SlackBuilds-users@slackbuilds.org" target="_blank">SlackBuilds-users@slackbuilds.org</a><br>
<a href="http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" target="_blank">http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br>
Archives - <a href="http://lists.slackbuilds.org/pipermail/slackbuilds-users/" target="_blank">http://lists.slackbuilds.org/pipermail/slackbuilds-users/</a><br>
FAQ - <a href="http://slackbuilds.org/faq/" target="_blank">http://slackbuilds.org/faq/</a><br>
<br>
</font></span></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
SlackBuilds-users mailing list<br>
<a href="mailto:SlackBuilds-users@slackbuilds.org">SlackBuilds-users@slackbuilds.org</a><br>
<a href="http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" target="_blank">http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br>
Archives - <a href="http://lists.slackbuilds.org/pipermail/slackbuilds-users/" target="_blank">http://lists.slackbuilds.org/pipermail/slackbuilds-users/</a><br>
FAQ - <a href="http://slackbuilds.org/faq/" target="_blank">http://slackbuilds.org/faq/</a><br>
<br>
<br></blockquote></div><br></div>