Configuring Usermin is done, perhaps paradoxically, from within Webmin. Clicking on the Usermin Configuration icon under the Webmin tab displays a few rows of icons of Usermin options, that is very similar in form and function to those of the Webmin Configuration module. There are far fewer configurable options, of course, but because Usermin is based on the same webserver framework as Webmin (miniserv.pl, specifically) it provides all of the same access control, and security mechanisms.
On first entering this module, all that is displayed is a dropdown selection menu listing all of the Usermin modules that have configurable options. Selecting a module name, and clicking Edit config for module will reload the page and and add the configuration options for the selected module under the dropdown menu.
GnuPG (Gnu Privacy Guard, or gpg for short) is a complete and Free Software implementation of the encryption standards originally provided by PGP (Pretty Good Privacy, a commercial product). It does not rely on the patent-encumbered IDEA algorithm, so can be used with no restrictions for commercial or non-commercial purposes. GnuPG provides strong encryption and digital signatures of several types for email and files. Using GnuPG strong encryption it is possible to send a private email with confidence that only the recipient can decrypt the message. Additionally, a message may be digitally signed, allowing confirmation of sender identity and verification of the contents of the message (i.e. is this actually the message exactly as composed by the sender or has it been modified in some way during transit).
This module only has one configurable option, the keyserver that will be used for sending and receiving key files. If using GnuPG to confirm signatures, it is necessary to use central keyservers so that identities can be looked up in a centralized database. In this way, a web of trust can be woven between individuals who can confirm the identity of others. There are a large number of public keyservers available all over the world, and they synchronize their data so it is a good idea to choose one near you.
Webmin and Usermin support a number of different mail transfer agents (MTAs), specifically Sendmail, Postfix and Qmail. This option should be set to the mail transfer agent in use on your server. Postfix is not listed as an option, however, as Postfix is entirely Sendmail compatible from a user perspective. Simply select Sendmail if Postfix is the MTA, and all will work as expected.
The Usermin Read Mail module offers a complete, if basic, web based mail client for users. It allows the user to send and receive mail, as well as keep a simple address book, and digitally sign or encrypt messages. For this module there are a number of configurable options.
This is the hostname that will be included in the mail headers in the From field. If you wish all mail from your domain to be addressed from just the domain name (rather than, for example, mail.domain.com) you may enter it here. Entering domain.com will cause all mail sent from this machine using the Usermin mail client to appear to be from domain.com.
If Yes the user will be able to enter any address they choose in the From field. If no, all mail will be marked as originating from the domain you chose in the previous option. It may be appropriate to permit this change, if clients have their own domain names, or would like to be able to primarily use another address and do not won't to keep up with replies to another mailbox.
Like that of the Mail Forwarding configuration above, this selection should match the MTA that is running on your server. Choose Sendmail, if Postfix is the installed MTA.
Here you select the location of your mail storage directories. This is usually located in /var/spool/mail, and another common option is to deliver it to the users home directory into mbox. This depends on the configuration of your mail delivery system (which may or may not actually be Sendmail). Postfix may use Sendmail compatible mail delivery options and so requires no special configuration here.
This option is pretty much self explanatory. You may choose to display more or fewer messages, which can be useful if clients are using small display devices for using the web mail client and too many lines makes browsing messages in the inbox cumbersome.
Again, this is an option that may be of use for users of small displays, such as handheld computing devices. The tradition standard line wrap has been 80 characters, and that is the default.
Selects on which pages the Delete, Mark message as, and Forward buttons will be displayed at the top of the page, if any. By default, these buttons appear at the top and bottom on the mailbox pages, and only at the bottom on the view mail page. If large mails are common, users may find buttons at the top on both a convenience. Users with little screen real estate (palm-sized devices, for example) may find it best to have no top buttons on any page.
This option selects whether the mailbox page will display the To: field. Useful if a mailbox receives messages with different email addresses via mail aliases.
Selects how mail will be sent. It can be sent to any local mail transport agent. By default this is the sendmail executable, but several alternatives exist.
The location of your MTA executable. This is the command that will be called when sending mail.
This allows users to attach files that are located on the local machine (where Usermin is running). This could potentially be a minor security risk, because the user could then attach any file for which they have read permissions.
The Running Processes module in Usermin allows the user to view all of the processes they have running at a given time. There are a couple of configurable options here.
The options correlate to the modes of the ps command. Thus, it allows output forms, such as a process tree (where parent/child relationships are clear) as well as simpler process lists.
This option should match the OS on which Usermin is running, as it chooses how to parse the output of the ps command. However, if your system uses a custom variant of this command, you may need to modify this to an OS that provides a similar ps.
The Cron Jobs module allows users to create their own schedule tasks to be performed automatically by the system at a scheduled time. The commands are performed with the permissions of the user that configured them.
This should be set to the directory where cron looks for its crontab files.
Some crontab versions may use slightly different command line options, or you may use a special-purpose wrapper for cron. Here you can select the command and options for reading the user's crontab.
Similar to the above, except configures the command to edit a user's crontab.
crontab can usually also accept input from the standard input, if the - pseudo-filename is given on the command line.
This option sets the command Usermin will use to delete a users crontab.
This should be the path to your system wide crontab. Generally, /etc/crontab.
Many systems make use of an extra cron directory for program specific cron jobs to execute when cron runs. This is likely /etc/cron.d.
The run-parts command is often run in the system crontab file, and is used to specify other directories to run at specified times. For example, on a Red Hat Linux system the crontab contains:
SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # run-parts 01 * * * * root run-parts /etc/cron.hourly 02 4 * * * root run-parts /etc/cron.daily 22 4 * * 0 root run-parts /etc/cron.weekly 42 4 1 * * root run-parts /etc/cron.monthly
The above sets a few defaults in the cron environment, and then executes run-parts at a few specified times. Specifically, the /etc/cron.hourly file is excuted at 1 minute after every hour. run-parts is simply the program that processes the directory specified and executes all of the commands in it.
Much like the Webmin module selection page, this page allows you to select which modules will be available to users. If, for example, you do not want users to have any direct filesystem access, you could disable the Command Shell, File Manager, and SSH/Telnet Login. The SSH Configuration and Login Script are then useless, so may be disabled as well.
It has probably become quite clear that Usermin and Webmin are strikingly similar in many ways, and Usermin has very little that Webmin does not. So, why use it? Why not simply give everyone access to Webmin, and simplify life for everyone? There is no way to answer that question fully without analysing the environment in which the system is deployed. Under some circumstances, Usermin would be useless while requiring additional resources to install and run it. But in other circumstances, Usermin can be a valuable addition to an administrators toolkit.
Usermin is at its most useful when the server is being used by a large number of unprivileged users, and administration of those users needs to be simplified. Before Usermin, it was possible to grant users access to Webmin to read their mail, change passwords, and perform a few normal user functions, and that functionality is still there. One could use Webmin for the same purposes by constructing elaborate ACLs and groups and being careful to configure those new users with just those permissions. However, this leaves some room for administrator error, which could have dramatic consequences. Usermin, on the other hand leaves no room for error. A Usermin user has the permissions of the user that is logged in and no more. The user can't be accidentally granted additional rights and a careful selection of available modules is not needed to insure security and ease of use (because, let's face it, many users can become quite confused by too many complicated options).
Another good use for Usermin is to provide an easy method for travelling users to read their mail, and retrieve files from their own directories. By providing a web interface to the local machine (and via network fileservers, potentially all users data) telecommuters or travelling employees can do all of these things from any web enabled device in the world. In other words, users can login to the local network from an internet cafe, an internet kiosk at trade shows, or from a wireless web device. Doing so requires no specialized software to be installed on the client side system.
Another interesting use for Usermin would be in a shared hosting environment, allowing users the ability to view their own directory, upload files via a web browser, edit many of the basic features of their shell account, read mail, etc. It would be only slightly more than trivial to implement a few nifty extras like running a web log analysis tool and allowing users to view the results from within Webmin.