What is Peregrine?
Peregrine is a collection perl scripts, C programs, and database tables that allow
centralization of Unix account management. The system runs on a Mysql database, and uses the perl DBI module as its primary
interface. Peregrine provides the ability to manage login accounts across multiple server groups, all through a web interface.
Features:
- Username conflict protection.
- Uid conflict protection.
- Support for multiple servers using the same account list or slight variants of it.
- Support for multiple servers with different account lists.
- Ability to provide username conflict protection across different logical system clusters.
- Built in password expiration.
- Random temporary password generation.
- Changable administration levels allowing multiple administrators to have differing access to different clusters.
- Ability to disable an account and not lose any information concerning it.
- Quota management.
- Email forwarding.
- Pretty modular. What is tracked and what is not tracked is pretty much completely configurable...
- Sleek and sexy web interface.
Why is this an alpha release?
Well I am pretty sure it works. The main problem is there is no documentation or fully automated installation routine yet. If you want to go ahead and try to get it working
you probably will need a fairly good talent of putting a lot of pieces together. Make sure you have Mysql, and the DBI packages installed, then look at the following files:
- lib/Peregrine.pm
- backend/install/install.pl
- backend/pereServ/src/*.[c|h]
- backend/pereClient/pereClient.pl
If you are good you might be able to figure out what all the pieces do, and how to use them. Also the quota modification program that this was built with was not included,
I didn't write it and I have to ask the guy who did if I can use it. It basically just calls the quotactl function a bunch of times, so writing your own should be doable
if you really want it that bad. Also the way the files get worked with is just downright icky, it would probably be a good idea to disable the file routines for now (Hint: look for '$EUID = 0;').
Also the server traffic that handles the account updates is incomplete in that it is _very_ insecure. Currently it depends on configurable passphrase,
encryption is not yet implemented. That might not sound so bad, but all that is standing between some stranger and a complete passwd file dump is ~16 characters that is sent
in the clear every update. Its good enough for a machine in a high school on a fake network sitting behind a firewall, but I would hesitate before hooking it up in a setting
where real dollars are on the line. Of course I have to think it is far more secure than NIS.
How much testing has this thing gone through?
Ok, so the question is "Does this really work?". Version 2 was written for my old high school, and was extremely custom built for their environment.
The only changes between that and 3 have been to abstract the functions out to work in any cluster configuration or with any number of clusters.
But let me just explain the environment that I _know_ it works under.
In the setting of a high school with 223 faculty members, and 760 students. The server cluster used by the faculty consisted of 3 machines.
One mail server that allowed shell logins, a web server that served faculty homepages and the main website, and a fileserver that maintained quotas.
The system managed ~220 accounts across the three boxes, restricted logins to one of them, and managed quotas on the fileserver.
The cluster for the students was made of two machines and housed 760 accounts, one machine managed web/mail and the other handled file services.
Same as with the faculty setup, logins were restricted to one, and quotas were managed on the other. Because we wanted everyone to have a @kinkaid.org
email address (as opposed to @student.kinkaid.org) the system protected against username conflicts across both clusters. Students and faculty had
the ability to request a login shell, change their passwords, and forward their email from a web interface. Administrators could change just about everything
including usernames, real names, gids, uids, passwords, email forward addresses, quota sizes, disabled accounts, and home directory locations.
Administrators could also add users in mass or one at a time, and also had the ability to delete users from the system. The cluster servers would query the
peregrine server nightly to update the passwd files, update quotas, etc.
License?
Do what you want with it, just keep my name on it. Or more precisely.... Leave my name in all source files.
If you can't have it on the html pages, I'll understand. Just leave the link to this site.
Contacting me
Well currently I am the only person working on this project. So any correspondences, questions, comments should be directed at me.
Just send an email to jarusl@artifex.org with the word peregrine somewhere in the subject,
and I will try to get back to you as soon as I can.
|
