-
Leigh B. Stoller authored
the web page to add/delete a key! Nodes were getting updated, but the SFS server was not cause there was no program to fire the new keys over there. The operation is currently simple. sfskey_update on boss constructs a new sfs_users file. Then it runs sfskey_update.proxy on ops (vis ssh of course), and gives it the new file via stdin. The proxy creates the .pub version from that file, and then moves the two new files into place in /etc/sfs. I employ the same locking stuff that Rob did in exports_setup and named_setup to prevent multiple updates from stacking up. Not likely, but might as well. Also note that the entire file is regenerated. When we get 5000 users this might have to change a little bit! Also changed mkacct slightly. Instead of doing a "sfskey register" on ops after generating the new key, just add it to the DB. Then fire off an sfskey_update to push the new keys over. Also add a -f flag to mkacct for use from the web page to indicate that the user has changed his SFS keys. Note that mkacct should probably take a series of flags since we have it as a wrapper for several things. Or maybe split all this stuff up.
cc1c4e54