Login Logs
Our next stop on our tour is the Login Logs item on the administrator's menu:
Manhattan's login logs are stored as text files in the users/logs directory of your Manhattan installation. The following events are recorded:
-
Successful logins - The user typed in both their username and their password correctly.
-
Unsuccessful logins - Someone tried to login using a username that exists on the server, but they got the password wrong.
-
Password changes by the user - The user changed their own password by clicking on one of the Change your Password buttons within Manhattan, or they were forced to do so because their password was the same as their username. (e.g. it was the first time they logged on, or someone just reset their password)
-
Password was reset by a teacher or a system administrator - In Manhattan, any teacher can reset the password for a student in their class. As system administrator, you can reset the password for any student or teacher on the system. In either case the password reset event is recorded in the logs, including information on who performed the reset.
The Login Logs item on the administrator's menu allows you to view and delete these log files. When you click on the link, you'll get a page that looks like this:
Your page will look slightly different (there will probably only be a "Current log" listed) if you're working through the tutorial.
How the logs get rotated
The login logs are stored as text files in the users/logs directory of your installation. In order to keep the size of the current log file reasonable, the file is automatically "rotated". This means that periodically a backup copy of the current active log file is made, and a new empty log file is started. Here's how the rotation works:
-
Whenever you or another administrator logs in to Manhattan's administrative system, the size of the current log file, named log.txt is checked.
-
If the current log file is greater that the default value of 250,000 bytes, the file is renamed and a new, empty log.txt is created. (The value of 250,000 bytes can be changed via the custom.h file during installation.) The name of the "rotated" file includes the day, month, year, hour, and minute of the time the file was rotated.
You can delete the log files one at a time by clicking on the Delete button. This Delete button only appears on the table row for the oldest log file, to make sure you can only clean up by throwing out the oldest log files first.
 |
You or another administrator must login for the log rotation to occur. Although as system administrator you should login frequently, no harm is done if the log file isn't frequently rotated. Also, if you know something about Unix cron and shell scripting, you can have your system automatically rotate the login logs at a particular time of the day or night if you prefer. |
All logs vs. individual logs
As shown in the screenshot below, the buttons labeled All log files: work on all of the log files, that is, the current log plus any and all older logs. The buttons on the rows of the table act only on that single log file.
Admin logins
The button labeled Admin Logins provides you with a plain text listing of the log data for system administrators. (System administrators are those with access to the administrative programs you are reading about now - including you.) Each record written to the log files by an administrator has the prefix ADMIN: before the username. This is needed because it is possible for an administrator to have the same username as a student or teacher.
Protecting the security of Manhattan administrative accounts is enormously important. One way to protect those accounts is to check the Admin Logins frequently to see whether an intruder is attempting to login as one of the administrators, or if he already has access to an administrative account.
Viewing raw log data
As shown in the above screenshot, you can view the raw log data for either all of the log files combined, or for one particular log file. When you click one of the Log Data buttons, a separate window opens displaying the raw data:
The records are sorted with the most recent events at the top of the list. Recall from Viewing Prof. Einstein's profile that if you want to look up a particular user's login records, you can use the View/modify/delete users option from the administrator's main menu. The "full record" for a user includes a Log Data button that shows, for all available log files, all of the records that match their username:
The ability to quickly check someone's login records as shown above is very useful when providing phone or email support for students and teachers. You can see when they've logged in (successfully or not), and if or when their password was reset by one of their teachers. You can also get an idea of the Internet service provider, web browser, and operating system they have used.
Login Graphs
The login graphs are really a "work in progress". At this time the buttons shown above open a separate window showing a graphical representation of two data items.
-
The browsers (e.g. Netscape, Internet Explorer, other) preferred by your users.
-
The operating system (e.g. Windows, Linux, Mac) they use.
Here's sample graphs from an active server:
The above screenshots show graphs for over 80,000 logins. The majority of users run Windows NT 5 (which is Windows XP) and use MS Internet Explorer as their browser. The graphing programs try to parse the lines in the raw log file, which look like this:
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) |
This data is provided to Manhattan by the web browser a person uses when they connect. Unfortunately, there is no firm standard for the data a browser must provide. We've done the best we can to parse the data into reasonable graphs. This portion of Manhattan will have to be updated as Microsoft and others come out with new versions of operating systems and browsers. Still, this graphical representation will help you understand what users are running when they connect to their classrooms, and help teachers know which browsers they need to support for any special content they provide within their classrooms.
|
The graphs only include data on "Successful Logins" and exclude logins for system administrators. |
On your own
If you're following along with the tutorial, feel free to experiment with the login logs. In particular, you may want to try to cause the following events to happen:
-
The super-user repeatedly logs in with the wrong password (but correct username).
-
A teacher resets a student's password.
-
A student (or teacher) changes their password.