Commit b9ef7da1 authored by Leigh B. Stoller's avatar Leigh B. Stoller

Checkpoint (still neads testing and tweaking) vastly rewritten mkacct

script, which is now called tbacct, and lives in the account directory
instead of tbsetup (all account scripts are moving into this
directory). The command line is different:

	Usage: tbacct <add|del|mod|freeze|thaw|sfskey> <name>

However, it is not really intended to be called from the command line,
but if it is, it always does the right thing based on the DB. All of
the ssh commands are localized here as well (mkproj and others will
invoke this script instead of doing pw commands themselves on ops).

My experience with this indicates a couple of things.

* We should probably not invoke these backend scripts (which are
  setuid) as the user driving them from the web. This complicates
  things, especially in light of having to deal with users with no
  accounts (say, a new user, unapproved, who wants to change their
  password). Not sure what the right model is, but since the script
  always does the right thing, it really makes no difference who
  invokes it.

* The actual pw commands should be driven from a script on the other
  side. This would make it easy to retarget to linux or whatever. I
  thought about doing that, but the shell quoting is a pain in the
  butt, and its not like I'm supposed to be doing this stuff.
parent 1401ce90
This diff is collapsed.
#!/usr/bin/perl -w
# Copyright (c) 2000-2003 University of Utah and the Flux Group.
# All rights reserved.
use English;
# This gets invoked from the Web interface. Simply a wrapper ...
# Configure variables
my $TB = "@prefix@";
# Run the real thing, and never return.
exec "$TB/sbin/tbacct", @ARGV;
die("webmkacct: Could not exec tbacct: $!");
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment