I have scripts to update accounts, and need to have the password file locked while they run to avoid having a user change their password at the same time and losing one of the updates. Since vipw already does most of what needs to be done, I've modified it so that when invoked as "pw_lock", instead of running vi, it runs the specified command, but still does all the locking and database updating. How-To-Repeat: N/A
On Fri, Sep 07, 2001 at 03:34:37PM -0700, alan@batie.org wrote: > > >Number: 30424 > >Category: bin > >Synopsis: Generalization of vipw to lock pwdb while being edited by a script > >Originator: Alan Batie > >Release: FreeBSD 4.3-STABLE i386 > >Organization: > RainDrop Laboratories > >Environment: > System: FreeBSD aggie.rdrop.com 4.3-STABLE FreeBSD 4.3-STABLE #3: Wed Sep 5 13:36:38 PDT 2001 root@aggie.rdrop.com:/usr/src/freebsd/sys/compile/AGORA i386 > > > >Description: > I have scripts to update accounts, and need to have the password > file locked while they run to avoid having a user change their > password at the same time and losing one of the updates. Since > vipw already does most of what needs to be done, I've modified it > so that when invoked as "pw_lock", instead of running vi, it runs > the specified command, but still does all the locking and database > updating. Good idea! [snip] > + if (!(pid = vfork())) { > + execl(argv[0], progname, tempname, (char *)NULL); > + warn("Command '%s' failed", argv[0]); > + pw_error((char *)NULL, 0, 0); > + } I think you should check pid for -1 here, though.. > *************** > *** 83,88 **** > --- 85,95 ---- > at very large sites could take several minutes. Until this update > is completed, the password file is unavailable for other updates > and the new information is not available to programs. > + .Pp > + If invoked as > + .Nm pw_lock > + , the user database ... This might be written better as If invoked as .Nm pw_lock , the user database ... Other than that, good work! G'luck, Peter -- If there were no counterfactuals, this sentence would not have been paradoxical.
Is there any reason you need a special option in vipw(8) to run (in effect) a different editor, when temporarily changing the EDITOR environment variable would do the same? Also, the pw(8) utility may be useful, allowing various modifications to the passwd database more easily. -- Jilles Tjoelker
On 7/29/10 4:50 PM, Jilles Tjoelker wrote: > Is there any reason you need a special option in vipw(8) to run (in > effect) a different editor, when temporarily changing the EDITOR > environment variable would do the same? > > Also, the pw(8) utility may be useful, allowing various modifications to > the passwd database more easily. Those would have been (and, yes, were available) useful alternatives 9 years ago ;-) The EDITOR hack makes me nervous for gettings args and stdin to the script, though I'm pretty sure they would work; pw is probably the "right" solution to the problem I was solving, though it's inefficient: I was (actually, still am --- that script is still in use) reading in the password file, making several updates to it in memory, then writing it back out. We're talking numbers you can count on fingers and toes though, so efficiency really isn't a factor in this case, though it's conceivable. Well, I'm not sure an application where it would be a factor *is* conceivable, and any setup that large would probably be using a db backend of some sort, but still, that's the sort of operation where pw_lock is useful, and it's trivial to support.
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped