Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] An update to shadow

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Jeremy Blosser <jblosser-smgl AT firinn.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] An update to shadow
  • Date: Fri, 2 Mar 2007 11:29:45 -0600

On Mar 02, "Andra?? 'ruskie' Levstik" [ruskie AT mages.ath.cx] wrote:
> On 05:35:13 2007-03-02 Jeremy Blosser <jblosser-smgl AT firinn.org> wrote:
> > On Feb 24, "Andra?? 'ruskie' Levstik" [ruskie AT mages.ath.cx] wrote:
> > > I had the following lying around on my hdd for a few weeks and today
> > > decided to finalize it.
> > >
> > > Here's the idea(as used in the nano system-wide config install):
> > >
> > > provide a way to be able to pick what add/deluser scripts to install
> > > provide a way to not install any such scripts
> > > make it easily extensible by having them in a dir
> >
> > I see the point to this but I'm skeptical. Assuming there's a wider
> > need for something like this, do we really want to implement them as
> > spell menus all over the place and push more queries in front of users
> > just because some people might like some custom scripts? There should
> > be a more generic way to do this.
> >
>
> Provide one and I'll use that. We could just have a simple query do you
> want to use the default add/dell user scripts? if the users answers no
> they get the list if not we don't ask them about it again.
>
> And as for a wider need. Well it's extra user choice. Especialy since
> last I checked shadow didn't provide any upstream defaults for it. I'd be
> just as happy if we didn't install and add/del user scripts then and
> stick to what we ussualy have... only upstream defaults.
>
> Both solutions are fine by me but I doubt many others would be equaly
> pleased.

I'd agree with at least prompting before installing our default scripts, we
should do that.

I think we should provide (optionally) a single default script for things
like this, if someone writes and maintains one. For additional ones we
start heading into the "contrib/" area and as a user I usually prefer
projects keep their "contrib/" labelled and separate. Maybe something like
a set of contrib spells or even a contrib grimoire, with optional
dependencies where appropriate or something.

I don't really think it's up to me to "provide" a full way to do it; if
it's your itch, it's up to you to propose something people can agree with.
And these are just my opinion, someone else may have a different idea.

> > Even inside this implementation, I have questions...
> >
> > - I don't think we want to start introducing system files with IRC
> > nicks in them. We should keep more abstraction than that between the
> > user systems and the developer preferences.
> >
>
> Well we do the same for nano. But if you have a better alternative
> please...

I don't use nano, I didn't know that. I don't really agree with it there
either.

> > - Using internal sorcery API calls like this is not recommended,
> > especially when you have to hack around the prompt delay like that.
> > What's wrong with a regular read -p ?
> >
>
> That can easily be replaced by own query_string implementation etc...
> I simply used what was available at the time I wrote them and didn't
> bother with being extra carefull. And they don't touch our default ones.
> I still need to update the default ones to workaround the changed base
> directory problem i.e. /home/users/ instead of /home.

Being careful or not is kind of the point. If these are just your own
scripts you provide via non-official channels in case people want to use
them, you can of course do what you want with them. If the distro starts
providing them as part of the official grimoire then we're responsible for
any bugs/etc. And user creation scripts are pretty high-profile when they
break.

If you want a way to be less careful with them and own them yourself and
still get them in front of users, think about a way to facilitate a
"contrib" grimoire or something for contributed admin scripts and config
files.

Attachment: pgpDOKDS66Gns.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page