Account Administration for K-12 School Systems
The k12admin-client package contains the files necessary to update a machine using information from the k12admin-server machine.
Install the k12admin-client package by running:
dpkg -i k12admin-server*deb
rpm -i k12admin-server*deb(use -U instead of -i if you are upgrading) in the directory where you have the package. If this is an initial install, you will be asked to run k12admin-client.setup as root.
If you are installing the package from a tar file, unpack the archive, go (cd) to the k12admin-client* directory and run make install to install the package.
You will be asked for the name of the k12admin-server and the root password of that machine. The name of the k12admin-server can be an IP address or a host name (as long as the host name can be resolved to an IP address, of course). Once you supply the server's host name, the post-installation script will try to connect to the server using ssh to inform the server that it has a new client and copy the client's ssh key to the server. The ssh program will ask you for the root password of the server machine. The root password is not stored anywhere by the post-installation script. If you ever wish to connect your k12admin-client computer to a different k12admin-server machine, simply rerun the k12admin-client.setup program.
After the post-installation script completes, the server will take up to five minutes to notice the new client and register the new ssh key. Configure the new client by using a web browser to access the account administration system. From the main menu, select “Domain Tools”, then “Edit Servers”. Your new client should appear in the list of servers. Select your new client server and click on the Edit Server button, then configure appropriately.
Every five minutes, the data in the MySQL database on the server is converted to plaintext files which can be copied to the clients and used to update their local files. This process is accomplished by the /var/k12admin/scripts/server/k12.updateserver script. This script is run by cron every five minutes as the k12admin user. It can also be run manually, but it must be run by the k12admin user and not by root. When this script is run, it generates several files in the /var/k12admin/serverdata/ directory that are used by the clients. This script also uses a lock file in the /var/k12admin/lock/ directory to prevent multiple instances of k12.updateserver from running simultaneously and to prevent clients from performing their updates while the files are still being generated.
There is another key file in the /var/k12admin/serverdata/ directory, called “setup”. This file contains all the code used for updating and auditing the clients. This file is copied to the clients before the clients are updated, so do not edit this file on the clients if you are trying to add new features—edit it on the server.
On the client machines, updates are done once an hour. The script that does the updating is /usr/bin/k12.updateclient. Since this script must modify key system files, it is run as root from the system crontab file.
If run interactively, this script executes /var/k12admin/clientdata/setup with no command-line arguments. To avoid any delay in the menu coming up, the rsync is not performed. One option on the menu is to perform the rsync, if the latest data from the server is desired.
If run with command-line arguments, the script first runs rsync (using ssh as the transport agent) to sync all the files from the /var/k12admin/serverdata/ directory on the server to the /var/k12admin/clientdata/ directory on the client, then executes /var/k12admin/clientdata/setup with the same command-line arguments it received.
If the script is run without arguments, it will enter an interactive mode and present a menu of options from which to pick. It will also show progress information that is not displayed in the batch (non-interactive) mode. In batch mode, the following arguments can be supplied:
k12.updateclient auto: performs all client update routines.
k12.updateclient passwd: updates all password files (passwd/group/shadow/gshadow/smbpasswd/ squid.auth/apache.auth).
k12.updateclient audit: performs security audit on the client. The generated information is copied to the server, where it is inserted into the audit table in the database.
k12.updateclient homedirs: creates new home directories and cleans up old home directories.
The setup program contains the following subroutines:
auto: runs the passwd, homedirs and audit subroutines. This is the subroutine that is called from the crontab file.
rsync: syncs the data from the /var/k12admin/serverdata/ directory on the server to the /var/k12admin/clientdata/ directory on the client. When setup is run interactively, this syncing is not done before the menu is brought up, so if you need the latest data from the server, choose this option first.
passwd: updates the passwd, group, shadow, gshadow, smbpasswd, squid.auth and apache.auth files, depending on the configuration of the server.
homedirs: creates new home directories and cleans up old ones. Old home directories can either be left alone, deleted or moved to a temporary holding area (/var/k12admin/oldhomedirs/) where they are deleted when they are 30 days old.
audit: run a security audit on the local server. This goes through various log files and determines which accounts have been used. This information is copied to the server, where it is added to the audit table in the database, so any user can review where and when their account has been used.
atalktable: generates a mapping of AppleTalk nodes to AppleTalk computer names.
squid: audit of the Squid proxy authentication files.
apache: audit of any authenticated access to an Apache web server.
netatalk: audit of access to AppleTalk services (logins from a Macintosh computer).
samba: audit of access to Samba services (logins from a Windows workstation).
ssh: audit of ssh (secure shell) connections.
squidmonitor: not really a security audit, this searches through the proxy logs for any potentially inappropriate web browsing and also sends this information back to the server computer for review by school staff.
Steve Tonnesen (firstname.lastname@example.org) works at Coast Mountains School District in Hazelton, BC, Canada. Coast Mountains School District has 30 schools and 5,000 students.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- August 2015 Issue of Linux Journal: Programming
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- Huge Package Overhaul for Debian and Ubuntu
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- KDE Reveals Plasma Mobile
- Embed Linux in Monitoring and Control Systems
- General Relativity in Python