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.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- Dynamic DNS—an Object Lesson in Problem Solving
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- Tech Tip: Really Simple HTTP Server with Python
- Roll your own dynamic dns
2 hours 9 min ago
- Please correct the URL for Salt Stack's web site
5 hours 20 min ago
- Android is Linux -- why no better inter-operation
7 hours 36 min ago
- Connecting Android device to desktop Linux via USB
8 hours 4 min ago
- Find new cell phone and tablet pc
9 hours 2 min ago
10 hours 31 min ago
- Automatically updating Guest Additions
11 hours 40 min ago
- I like your topic on android
12 hours 26 min ago
- This is the easiest tutorial
19 hours 2 min ago
- Ahh, the Koolaid.
1 day 40 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?