There is, however, an unofficial package distributed on the webmin.com website. Contrary to the packages included in Sarge, this package is monolithic; all of its configuration modules are installed and activated by default, even if the corresponding service is not installed on the machine.
SECURITY Changing the root password
On first login, identification is conduced with the root username and its usual password. It is recommended to change the password used for webmin as soon as possible, so that if it is compromised, the root password for the server will not be involved, even if this confers important administrative rights to the machine.
Beware! Since webmin has so many features, a malicious user accessing it could compromise the security of the entire system. In general, interfaces of this kind are not recommended for important systems with strong security constraints (firewall, sensitive servers, etc.).
Webmin is used through a web interface, but it does not require Apache to be installed. Essentially, this software has its own integrated mini web server. This server listens by default on port 10000 and accepts secure HTTP connections.
Included modules cover a wide variety of services, among which:
all base services: creation of users and groups, management of crontab files, init scripts, viewing of logs, etc.
bind: DNS server configuration (name service);
postfix: SMTP server configuration (e-mail);
inetd: configuration of the inetd super-server;
quota: user quota management;
dhcpd: DHCP server configuration;
proftpd: FTP server configuration;
samba: Samba file server configuration;
software: installation or removal of software from Debian packages and system updates.
The administration interface is available in a web browser at https://localhost:10000. Beware! Not all the modules are directly usable. Sometimes they must be configured by specifying the locations of the corresponding configuration files and some executable files (program). Frequently the system will politely prompt you when it fails to activate a requested module.
ALTERNATIVE gnome-system-tools
The GNOME project also provides a graphical administration interface in the gnome-system-tools package. Installed by default for a desktop system, it includes applications that can be found in the menu at System → Administration. Easy to use, these applications cover only a limited number of base services: user and group management, time configuration, network configuration, disk management, and management of startup services.
9.4.2. Configuring Packages: debconf
Many packages are automatically configured after asking a few questions during installation through the Debconf tool. These packages can be reconfigured by running dpkg-reconfigure package.
For most cases, these settings are very simple; only a few important variables in the configuration file are changed. These variables are often grouped between two “demarcation” lines so that reconfiguration of the package only impacts the enclosed area. In other cases, reconfiguration will not change anything if the script detects a manual modification of the configuration file, in order to preserve these human interventions (because the script can't ensure that its own modifications will not disrupt the existing settings).
DEBIAN POLICY Preserving changes
The Debian Policy expressly stipulates that everything should be done to preserve manual changes made to a configuration file, so more and more scripts take precautions when editing configuration files. The general principle is simple: the script will only make changes if it knows the status of the configuration file, which is verified by comparing the checksum of the file against that of the last automatically generated file. If they are the same, the script is authorized to change the configuration file. Otherwise, it determines that the file has been changed and asks what action it should take (install the new file, save the old file, or try to integrate the new changes with the existing file). This precautionary principle has long been unique to Debian, but other distributions have gradually begun to embrace it.
The ucf program (from the Debian package of the same name) can be used to implement such a behavior.
9.5. syslog System Events
9.5.1. Principle and Mechanism
The rsyslogd daemon is responsible for collecting service messages coming from applications and the kernel, then distributing them into log files (usually stored in the /var/log/ directory). It obeys the /etc/rsyslog.conf configuration file.
SUPPLEMENTS Moving from sysklogd to rsyslog
Debian Squeeze installs rsyslog by default, while older versions (up to Etch, but not Lenny) used sysklogd. The transition was not automatic, and in the case of an upgrade from Etch, rsyslog should be installed manually if you want to keep in sync with Debian's default choice.
Migration from one to the other is painless, since the default configuration is very similar, and the syntax of the older /etc/syslog.conf is compatible with the new /etc/rsyslog.conf.
Each log message is associated with an application subsystem (called “facility” in the documentation):
auth and authpriv: for authentication;
cron: comes from task scheduling services, cron and atd;
daemon: affects a daemon without any special classification (DNS, NTP, etc.);
ftp: concerns the FTP server;
kern: message coming from the kernel;
lpr: comes from the printing subsystem;
maiclass="underline" comes from the e-mail subsystem;
news: Usenet subsystem message (especially from an NNTP — Network News Transfer Protocol — server that manages newsgroups);
syslog: messages from the syslogd server, itself;
user: user messages (generic);
uucp: messages from the UUCP server (Unix to Unix Copy Program, an old protocol notably used to distribute e-mail messages);
local0 to local7: reserved for local use.
Each message is also associated with a priority level. Here is the list in decreasing order:
emerg: “Help!” There's an emergency, the system is probably unusable.
alert: hurry up, any delay can be dangerous, action must be taken immediately;
crit: conditions are critical;
err: error;
warn: warning (potential error);
notice: conditions are normal, but the message is important;
info: informative message;
debug: debugging message.
9.5.2. The Configuration File
The syntax of the /etc/rsyslog.conf file is detailed in the rsyslog.conf(5) manual page, but there is also HTML documentation available in the rsyslog-doc package (/usr/share/doc/rsyslog-doc/html/index.html). The overall principle is to write “selector” and “action” pairs. The selector defines all relevant messages, and the actions describes how to deal with them.
9.5.2.1. Syntax of the Selector
The selector is a semicolon-separated list of subsystem.priority pairs (example: auth.notice;mail.info). An asterisk may represent all subsystems or all priorities (examples: *.alert or mail.*). Several subsystems can be grouped, by separating them with a comma (example: auth,mail.info). The priority indicated also covers messages of equal or higher priority; thus auth.alert indicates the auth subsystem messages of alert or emerg priority. Prefixed with an exclamation point (!), it indicates the opposite, in other words the strictly lower priorities; auth.!notice, thus, indicates messages issued from auth, with info or debug priority. Prefixed with an equal sign (=), it corresponds to precisely and only the priority indicated (auth.=notice only concerns messages from auth with notice priority).