For pieces of the past few weeks, I've been working on setting up Domtool 2 on our new servers. I have it in a fairly good state now. I'm not yet looking for volunteers to try anything, but the following things work:
* The Domtool server runs on deleuze, accepts configuration via the Domtool protocol over TCP from any host, and publishes configuration to its local daemons and to daemons on mire (the latter via connections to a slave server running on mire). * Admins can manage user privileges from anywhere via a domtool-admin program. * Anyone can use domtool-admin to query what privileges a user has, or to find out which users have rights to a domain, etc.. * All of this is working quite well storing all global data in our AFS cell. If we determine that it's sensible to let members mount our AFS cell on their local machines, then I believe it will be quite trivial to let members do domtool configuration without ever ssh'ing to a HCoop machine. This will include automatically taking into account changes to the standard library, which is store in AFS. * I've made some cursory tests related to configuring through Domtool 2 all of the daemons that the old Domtool supports, and the tests I've tried to date have worked. * This was also the first time I tested any automatic BIND configuration, since the old Domtool targets djbdns. It is quite refreshing to use the traditional DNS zone transfer protocol instead of rolling my own (as I did for transfers between fyodor and Abulafia now). Some important things left to do: * Implement a procedure for reloading all configuration from scratch, seeking it out in a designated subdirectory of each member's home directory. This is important insurance against bugs in the Domtool software and certain well-targeted kinds of data loss. * Consult with each of the new admins about Domtool's interaction with the daemons he has volunteered to be responsible for. In same cases, some small amount of integration code is still needed. * Create scripts or what have you to automate parts of getting a member set up in Domtool to begin with. The Domtool client-server system encapsulates some useful functionality, like custom access control lists and delegation of work to slave servers. For that reason, I think it makes sense to change some previously separate tools to be Domtool clients. * The Vmail system is a natural first choice, since the current version already does access control by checking Domtool domain ownership. * We probably want to move dbtool to use Domtool also, since we'll have members running dbtool commands on servers other than those where the associated database daemons run. On the plus side, some extra programs, like the one I wrote to make Apache log permissions match Domtool ownership information, will be unnecessary, since logs will be in AFS, and AFS permissions make all sorts of wonders possible easily. The other item I placed on my plate was the creation of a resource watchdog process to replace our current somewhat disappointing use of ulimits. We don't need to kill any processes until total system resource usage passes some threshhold, and ulimits don't provide any way that I know of for doing that. I welcome suggestions on that project on this mailing list, and indeed suggestions on anything that I or anyone else is doing to set up the new servers. I'm planning to work approximately full time on these items for at least the next three days, or less, if I finish sooner. _______________________________________________ HCoop-SysAdmin mailing list [email protected] http://hcoop.net/cgi-bin/mailman/listinfo/hcoop-sysadmin
