On Wed, May 28, 2003 at 09:16:53AM +1000, Matthew Palmer wrote:
> On Tue, 27 May 2003, Zed Pobre wrote:
>
> > > Could you elaborate on what ways yours works better than the original
> > > adduser? I'm sure Roland would love to hear about functionality
> > > improvements, and I'd certainly be keen for any improvements to the
> > > LDAP-specific code...
> >
> > My version will iterate through a list of users, has a "quiet"
> > mode that fills in only minimal information automatically, and instead
>
> Bulk creation would probably be a good thing for adduser to have anyway, and
> the "quiet" mode (not really quiet, I'd say non-intrusive, perhaps <g>)
No, it's genuinely quiet. The only thing you get asked for is the
LDAP bind password (and the prompt to that goes to STDERR instead of
STDOUT), and you only get output if you request a summary. I just
finished the automatic password generation (and --generate-password
implies --summary or you can't find out what the passwords are), and
this is what you can get out of it:
singularity:~# ldapadduser --quiet --gid 500 --generate-password --simulate account1 account2 account3 account4 account5
LDAP Bind Password:
account1 sIrikiPi
account2 QuFAHU
account3 SOVEkoPA
account4 fawYmUf
account5 jObAJiJ
Remove the --simulate and those accounts would have been created and
immediately live. Pipe the output to a file, and you get one prompt
for the bind password and no other output, and you have a file
containing starting account names and passwords that you can mail off
to someone to chop up and divvy out. If I could combine this with a
setting to enforce that the passwords be changed within 72 hours, I'd
be a very happy man. As it is, I'm feeling inordinately pleased with
myself :)
> would be a good complement to that. If you can turn them into patches to
> adduser, I'm sure Roland would be appropriately interested. I don't have a
> need for them directly myself, and I'm a bit snowed to be triaging general
> patches for adduser at the moment.
Okay, this is going to take quite a bit of time. I started my own
from scratch because I was using this as an excuse to learn perl as
much as to scratch an itch, and what I've written doesn't neatly drop
into the standard adduser. I'll see what I can do. It may actually
be easier for me to simply incorporate the adduser code into what I
have and just present you with a complete rewrite fait accompli.
> > of calling chfn, produces questions that better represent the kind of
> > information you can store with the cosine and inetorgperson schemas
> > (first name and surname are split up, for instance, and you can tell
> > it to ask additional questions about departmental code, title, etc.).
>
> Now *that* might be something to integrate into the LDAP support. It does
> suck mightily that you've got to install a hacked chfn from ldap-utils to
> make adduser work, and the superior user info storage in LDAP *should* be
> utilised better. I'd be interested in your scripts for that functionality,
> if nothing else.
I'm happy enough at the moment that I'll just make this open to
the public, warts, novice writing and all:
http://people.debian.org/~zed/ldapadduser
See sub getinfo. Setting --detail to 0 cuts it down to just
firstname and lastname. Setting it to 1 gets you nearly identical
behaviour to chfn, except that it splits up firstname and lastname.
Setting it to 2 gets you an extended version. Running it with --quiet
doesn't ask anything at all. Since it's a subroutine, you can
probably drop it into adduser without too much pain, as long as you
add a few global variables.
Incidentally, I might have discovered a Perl bug while writing
this, but since it's much more common for someone learning a language
to find a personal bug than a language bug, I'm not confident enough
to write a bug report. If you have spare time, poke at the if(defined
$opt_gid) code (around line 325) and tell me why calling getgrgid with
exactly the same argument into the same variable fails in the second
pass of a loop and exits silently with return value 141?
> > Since I still have a need to better handle bulk account creation,
> > I'm contemplating adding in support for automatic password generation
> > in the next day or two as well.
>
> I've never had to deal with bulk accounts myself, but wouldn't it generally
> be better to either have the password specified in the list of accounts, or
> leave the account disabled until it's manually enabled by an admin or
> someone?
Not when you have a hundred accounts to generate in a day that are
going to be used for 5 months in a not-particularly-secure environment
and then discarded, especially when the person handing out the
accounts and passwords to the user is not the person who is going to
be generating the accounts and doesn't (and shouldn't) have root.
This is an absolutely needed feature for me; back when I was using
flat password files and NIS, I wrote a shell script to do this just
using adduser and standard unix tools to parse /etc/passwd and my job
suddenly got a lot easier at the beginning of semesters. I wasn't
going to lose this ability when I migrated to LDAP.
> > Okay, should I be sending my scripts to you to look at, then?
>
> I'll certainly have a look at them, but I probably couldn't do too much with
> anything except the LDAP support.
Well, it's out in the open now. I welcome critiques of the code
from anyone interested, but I'd appreciate a little gentleness if I've
done something remarkably stupid since I only started looking at Perl
in earnest about a week ago.
--
Zed Pobre <zed@debian.org> a.k.a. Zed Pobre <zed@resonant.org>
PGP key and fingerprint available on finger; encrypted mail welcomed.
Attachment:
pgp9Ord3kRv0E.pgp
Description: PGP signature