Virtualmin has dozens of configurable options in the Module Config section of the module. To edit the module configuration click on the Module Config link in the upper left corner of the Virtualmin Virtual Servers module page.

NOTE: Many users will not need to edit the module configuration. The defaults are sensible for many environments, and this documentation assumes default configuration of the module. However, Virtualmin strives to be the most successful virtual host administration tool available and so almost every aspect of Virtualmin can be customized. Also be aware that configuration details can sometimes be overridden by Server Templates, so making a change here may not effect all server templates on your system.

This enables or disables the configuration of the local name server. If you already have domain management configured elsewhere, or will not be creating many new domains (if, for example, you are using Virtualmin primarily for email account generation within one or a small set of domains), you may choose to disable this. Note that even if you wish to host primary and secondary DNS on separate machines, you will still want this option enabled, so that the Cluster DNS Slaves feature can be used to propogate the new zones out to your master servers automatically.

This option enables or disables the configuration of mailboxes. If you do not wish to provide email accounts on your server, for example if you operate a website-only hosting service, you can disable the email features. If you wish to host email on another server that supports LDAP, you will not disable this feature, you will instead configure Virtualmin to create LDAP users.

This option enables or disables the creation of Apache VirtualNameHost entries and sets up all of the other virtual host features in your Apache configuration file. If you are using an alternative web server, you may disable this option. It may be possible to use the plugin module interface to create support for your preferred server (though no other web servers are supported at this time), or you may choose to call an outside script along with variables drawn from the information provided to Virtualmin at domain creation time to setup your preferred webserver.

This option enables or disables the configuration of Webalizer for created domains. When enabled, domains will have a "/stats" directory that contains access log analysis reports.

If enabled, an SSL website will be created for every new domain. If set to "Yes, but not by default" it will be possible to choose to create an SSL website upon domain creation. Note that SSL websites require an IP all to themselves, so it is not enabled for all sites by default. Many websites will not need SSL security, and so they can share a single IP with hundreds or thousands of other websites.

Enables or disables the creation of a new MySQL user and database when a domain is created. Disable this feature if you do not want to permit MySQL database usage by your domain owners.

Enables or disables the creation of a new PostgreSQL user and database when a domain is created. Disable this feature if you do not want to permit PostgreSQL database usage by your domain owners.

Enables or disables a new FTP virtual host. Note that FTP requires a new IP for anonymous virtual domain hosting. The vast majority of website owners do not need this feature, and it is not required for authenticated FTP access to the domain owners files. However, if some domains will require virtual hosted anonymous FTP access (i.e. if they are operating an FTP file server for software or file downloads for non-logged in users), you may wish to set it to "Yes, but not by default".

Enables or disables log rotation for newly created domains. Unless you have an alternative system for dealing with logs it is unlikely that you will want to disable this feature.

Enables or disables the ability to enable SpamAssassin configuration on a per-domain basis. With this enabled, you may disable spam filtering for some domains while enabling it for others. You may wish to disable this, if you will enforce spam filtering for all users, or if you are using an alternate spam preventative system on a system-wide basis. Note that server-wide configuration is not handled by Virtualmin. You will need to enable it using the SpamAssassin Webmin module, if you prefer server-wide spam filtering.

Enables or disables the ability to enable ClamAV virus filtering on a per-domain basis. If you do not want to provide ClamAV filtering, or have configured a system-wide virus scanning system, you may wish to disable this feature.

Enables or disables the creation of status monitors in the System and Server Status Webmin module. If disabled, a service monitor will not be automatically created for your new domain. A status monitor can notify you via email if a service goes down, or it can run a command to perform some action to try to automatically rectify the problem.

Enables or disables a Webmin login for the domain owner. If disabled, the domain owner will not have administrative capabilities over their domain. This may be useful in managed hosting environments, where the customer has no administrative capabilities and performs all account modifications through support queries to the hosting provider.

Selects the mailserver that is configured. Postfix, Sendmail and QMail (in several variants) are supported. Postfix is the default in Virtualmin Professional systems, and all documentation is focused on Postfix. The other mail servers are fully supported by Virtualmin, however, so if you have a strong reason to choose an alternative to Postfix, you can do so here.

If enabled, the /etc/genericstable (for Sendmail) or /etc/mail/canonical (for Postfix) files are updated when adding and modifying mailboxes. These are used to map Unix usernames to email addresses, and can be handy if users send email from scripts.

Enables or disables disk usage quotas for domain and user accounts.

Hard quotas are strictly enforced by the system, and will prevent users from using any more than the allowed disk space. Soft quotas are only advisory, and will merely generate a warning when exceeded.

If your server has multiple interfaces, you may choose which interface to use for your virtual domains. If SSL or FTP virtual hosts are enabled, a new IP will be required for each domain on which the feature is enabled. Unless configured otherwise during domain creation, the new addresses will be created on the interface specified here.

Virtualmin can automatically calculate new virtual host IP addresses for you, based on incrementing up from the last used address. By default it starts with the primary address on the interface selected in the previous option.

Virtual servers without SSL or FTP virtual host features enabled will all reside on a single IP address. This option specifies that address. If left at its default Virtualmin will use the primary address on the interface specified by the *Network interface for virtual addresses above.

DNS records are automatically generated for new virtual hosts, and in normal circumstances you will want them to match the virtual server IP provided above. However, if you operate a proxy server, a load balancing server, or some other type of device that leads to your server operating on a different address than the world sees when talking to your virtual domains, you may wish to alter the value here. Another instance where you may wish to change this is if you are adding domains to a development server that will have different addresses when it goes into production. You can fill in the production or public IP address here rather than having Virtualmin use the local IP address.

Virtualmin allows you to disable a domain account without deleting it or otherwise removing user data. You can choose to leave some services active (like email), if you want to be able to disable an account for some reason, such as past due bills or violation of terms of service, but do not want to cause the customer seriou heartache due to lost mail. You may disable any or all features.

It is possible for additional subdomains to be created by Virtualmin or the Apache module or hand-editing of the configuration file. This option selects whether all virtual hosts within the domain will be removed on deletion of a virtual server account.

This option, if enabled, removes the possibility of putting domains onto a different IP address. It also makees SSL domain creation unavailable, as an IP per domain is required for SSL domains. ===== Store users and groups ===== Virtualmin supports storage of users in either local files, like passwd, shadow and group in the /etc directory, or in an LDAP database. LDAP must already be configured correctly in the *LDAP Users and Groups Webmin module.

At the top of the Virtualmin module page, there is a list of domains configured on the server. You may choose to limit the number of domains that will be displayed, if more domains exist a search option is displayed instead.

If enabled, the features that are configured for the domain will be displayed in the row of data for that domain. It can lead to rather wide tables, so if screen real estate is at a premium, not displaying all of the information may be preferred. Clicking on the domain will always show all of the configured options for the server (and allow changing them).

If disk usage quotas are enabled, enabling this will cause the disk usage for each virtual server account to be displayed in the servers list on the front page.

If enabled, the domain owner can create and edit a file containing a list of aliases or an auto-reply in her home directory and use it as a special alias destination.

If enabled, the domain owner can choose to give users a different home directory than the default. It may be useful if domain owners can install additional services, like an application server (i.e. Zope, Webrick, etc.), and they'd like to be able to use a different user for the app server. Generally, only users that have a relatively high level of trustworthiness will need this kind of flexibility.

FTP users are users that can login via FTP and upload files to or download files from the server. If virtual servers will often be administered by one user and the website content managed by another, it can be useful to allow multiple FTP user accounts.

If enabled the domain owner can impose a quota on the disk usage of mail users. The server quota will apply to the aggregate of all domain data, regardless of the state of this setting.

In the create and edit aliases pages, domain owners can choose from any of the options selected here as alias destinations. Some are "special" and may introduce security problems, if your user is not reasonably trustworthy. For example, the "Addresses in file" option could be used as a spam relay, even if you have configured the server not to allow incoming email. This is only a problem in environments where you users are not reasonably trustworthy. Most users who can interact with Virtualmin should not be considered this type of user. "Delete" is also a somewhat dangerous destination as it is a rather vulgar abuse of the trust of the mail system (mail server claims to have delivered the message successfully when in fact it is simply deleted).

When you make changes in the configuration this option determines whether the changes will replicate across all of your already existing domain owners. Be careful with this option, as it can lead to existing domain owners losing features they previously had, or giving them new privileges you didn't intend.

Like the above option, this determines whether the additional Webmin ACLs (those privileges granted to domain owners outside of Virtualmin for other Webmin modules like Apache and BIND) will be updated after changes to the configuration. The same caveats as apply above apply here.

This option allows you to provide users with additional Webmin features beyond the normal domain modules (Apache, BIND, Read Mail, etc., discussed below in the *Feature modules available to domain owners* and *Extra modules available to domain owners*). Be very careful with this option, as most Webmin modules default to providing dangerously complete control over the services they manage. There are, however, occasions when it can be very useful. For example, if you have a custom module that provides some service specific to your environment, you may find this option very valuable. Further many modules can be configured with very strict access by default, or you could clone a module and configure it with a very specific set of functions to make it safe for use by all domain owners. You can selectively grant additional privileges to some domain users using the *Webmin Users module

You may select the default theme for domain owner Webmin logins. It defaults to the global Webmin default, which is the Virtualmin-Nuvola theme in Virtualmin Professional installations. You may find it useful to differentiate between color schemes for various privilege levels, like choosing a red-tinted theme for the administrative accounts, since those accounts are most dangerous when used carelessly, while using the standard soft grey-blue tinted theme for your domain owners and resellers. Purely a matter of taste.

This is the top-level directory where home directories will be created. If your Virtualmin installation shares a server with many other services or standard system users, it may be useful to use something other than /home. The default is gathered from the Users and Groups Webmin module, which defaults to /home. The Users and Groups module allows for complex extensions to this convention, such as "/home/v/virtualmin", which can make directories easier to navigate if you have many domains on a single server. The Users and Groups module documentation in either of the Webmin books covers this feature in more detail.

New domains (that are not owned by existing domain owners) will reside in a subdirectory within the home directory specified above. By default, the directory name will match the username and will reside directly in the base directory. You can also specify some special directory name, if for example, you'd like to keep standard system users separate from domain account users. In such a case, you might place the Virtualmin domains in "/home/domains/$USER".

This option specifies the shell configured for mailbox users. A mailbox user is the least privileged type of user, and normally should have very restricted access. However, if your Virtualmin server is only used by trusted users, or users that must have shell access, you could alter this from the default of /dev/null to one of the real system shells. Note that /bin/false is a special shell that will close remote SSH logins but will still allow FTP logins.

Like the above, this specifies the shell that FTP users will be assigned. By default /bin/false is used.

As in the above, but applies to users who are jailed into their own home directory on login.

This is the shell that the domain owner account will receive when logging in via SSH. Normally, domain owners require some form of shell, unless their account is extremely limited and no CGI scripts or other complex features are permitted.

This option selects how usernames will be generated. By default, Virtualmin will use the base username requested, but if it clashes with an existing username it will append the domainname in the manner specified in the next option. If consistency is preferable, set this to "Always", and all usernames within subdomains will have the domainname appended.

When a username has the domain name appended, this option selects the format. Not all options are available on all OS platforms, as some characters are not allowed in usernames. Whether the domain name is the full username, i.e. "virtualmin.com", or just the first part, i.e. "virtualmin", is dictated by the next option.

This option determines whether the domain name used in usernames that contain the domain will be the full domain name, i.e. "virtualmin.com", or just the first part, i.e. "virtualmin". In some environments, it may be easier for users to understand a username like "joeuser@virtualmin.com" for their POP/IMAP or FTP login name than "joeuser.virtualmin".

Virtualmin can also manage local users on your server, which can be useful if you'd like to use Virtualmin just to manage mail and home websites. With a little re-configuration, Virtualmin can provide an easy to use interface for adding mailbox/website users whose website can be reached via "http://www.domain.com/~username". This is not the primary focus of Virtualmin, but it can make mailbox and website maintenance for ISPs easier.

If you would like for mailbox users to have one or more files copied into their home directory on user creation, you may specify that directory here. This is much like the traditional /etc/skel directory, but can be customized just for limited mailbox users.

Virtualmin supports domain "parking" with forwarding to another website. With this option you can choose whether the forwarding will be done with ProxyPass rules in Apache, via a frame around the destination site, or disable the feature entirely.

Mailbox users home directories are created within the domain owner account home directory. It can be named whatever you like as long as it doesn't clash with an existing name like "cgi-bin" or "public_html". The default is "homes".

This option determines whether Virtualmin will generate a strong random password or accept a manually entered password. If using random passwords, it is probably wise to enable sending of the new setup email so that the user can be notified of his password.

If not specified by a server template, the mailbox quota specified here will apply to new mailboxes.

This option determines whether a user with database creation privileges can name the database anything he likes.

Alias domains are domains that point to an existing domain for some or all services. If you wish to consider alias domains as part of the domain they alias for quota purposes, select yes here. If the account limits will be specified separately, select no. Alias domains are normally quite small, as they merely direct all traffic to the domain they are aliases of, but with appropriate privileges a domain owner could use the alias domain account for other purposes.

This option selects the theme that reseller account logins will have by default.

This option allows you to provide reseller users with additional Webmin features beyond the *Virtualmin Virtual Servers* module. Be very careful with this option, as most Webmin modules default to providing dangerously complete control over the services they manage. There are, however, occasions when it can be very useful. For example, if you have a custom module that provides some service specific to your environment, you may find this option very valuable. Further many modules can be configured with very strict access by default, or you could clone a module and configure it with a very specific set of functions to make it safe for use by all resellers. You can selectively grant additional privileges to some reseller users using the *Webmin Users module.

Virtualmin sends email to users for a number of reasons, such as disk uage quota overage, bandwidth usage overage, account creation, etc. You may choose what address will be used in the From: field of these messages. This can be useful if you'd like for all replies to come to a support ticket system, for example. ===== Template file for email to new mailboxes ===== If new mailboxes created should automatically be sent a message, you may specify it here. It can be the default, which can be edited using the *New Mailbox Email page of Virtualmin, or you can provide another text file anywhere on the system. Variable substitution using the following variables: $\{MAILBOX}, $\{USER}, $\{DOM}, $\{FTP}, and $\{HOME}. You may also use the special logic block operators $\{IF-MAIL}...$\{ENDIF-MAIL} and $\{IF-WEB}...$\{ELSE-WEB}...$\{ENDIF-WEB} to allow your message to create an appropriate message based on the features the user has access to. If you are using DAV, the $\{IF-VIRTUALMIN-DAV}..$\{ENDIF-VIRTUALMIN-DAV} block can be used to make different text appear depending on whether or not the user has DAV active.

Local users are users that do not belong to a Virtualmin domain, for example, if they only have mail and/or web service within the native domain of the system. You may send the default new user email, or you may specify a different template file. The standard Virtualmin template variables are available within the template.

If bandwidth monitoring and limits are configured, Virtualmin can notify a domain owner if the bandwidth usage for the domain has surpassed the quota. You may use the default message, or create your own and specify it here. The standard Virtualmin template variables are available within the template.

If bandwidth monitoring and limits are configured, Virtualmin can notify a domain owner if the bandwidth usage for the domain is approaching the quota. You may use the default message, or create your own and specify it here. The standard Virtualmin template variables are available within the template.

If you want to perform some action before altering a domain (creation, alteration, or deletion) you may specify a command to run here. If multiple actions are to be performed the command to run can be a script. The command has access to special environment variables specific to the domain, such as $\{VIRTUALSERVER_DOM}, $\{VIRTUALSERVER_IP}, $\{VIRTUALSERVER_USER}, $\{VIRTUALSERVER_HOME}, $\{VIRTUALSERVER_PASS}, and more. Any variable found in the /etc/webmin/virtual-server/domains/$\{DOM} file will be available as an environment variable.

If you want to perform some action after altering a domain (creation, alteration, or deletion) you may specify a command to run here. If multiple actions are to be performed the command to run can be a script. The command has access to special environment variables specific to the domain, such as $\{VIRTUALSERVER_DOM}, $\{VIRTUALSERVER_IP}, $\{VIRTUALSERVER_USER}, $\{VIRTUALSERVER_HOME}, $\{VIRTUALSERVER_PASS}, and more. Any variable found in the /etc/webmin/virtual-server/domains/$\{DOM} file will be available as an environment variable.

Webmin and Virtualmin modules can provide functions to be run in the event a user is changed. This feature can be used by module developers to synchronize passwords in different locations, remove users from other services, or otherwise alter data about the user in other modules. If this option is disabled, other modules will not be notified, and additions, subtractions, and changes will not be replicated out to other modules. This option applies only to server users, which are users that own one or more domains or virtual servers.

Webmin and Virtualmin modules can provide functions to be run in the event a user is changed. This feature can be used by module developers to synchronize passwords in different locations, remove users from other services, or otherwise alter data about the user in other modules. If this option is disabled, other modules will not be notified, and additions, subtractions, and changes will not be replicated out to other modules. This option applies only to mailbox users, which are users that have mailbox/FTP/shell accounts within virtual domains.

If using LDAP users with QMail, specify the LDAP server name here.

If using LDAP users with QMail, specify the port on which your LDAP server is running.

Login name to use when connecting to the LDAP server.

Password for the account used to connect to the LDAP server.

Specify the search base within your LDAP directory for mail user accounts.

If users within the LDAP database will also have UNIX user accounts, select yes. Users must have UNIX system accounts in order to use shell or FTP services, though in many environments this level of access is unnecessary and undesirable.

Specify the location of the users mail directory. If users do not have local accounts, this option cannot refer to the $HOME variable, as users will not have a home directory.

If there are multiple object classes for users in your directory, you may specify them here.

If users created by Virtualmin should have additional attributes, specify them here.

VPOPMail uses a balanced directory tree that grows as needed. The base of that directory is specified here.

User account under which the VPOPMail server will run. This should not be an account with privileges beyond what is necessary to operate and deliver mail to the directory specified in the previous option.

Group under which the VPOPMail server will run.

If the autorespond program is installed, specify its location here.

If SpamAssassin is enabled for user accounts, messages that have been judged to be spam by the processor can be delivered (with optional marking, configured in the SpamAssassin module), deleted, or delivered to a special folder named Spam within the users mail directory. While false positives are extremely rare with SpamAssassin in its default configuration, it may be wise to retain messages for some period of time and allow users to check the spam folder using Usermin webmail, or via IMAP folders (if IMAP is available to your users).

If the ClamAV anti-virus filter is installed, set the path to the clamscan executable here.

If ClamAV marks a message as containing a virus, it can be deleted or delivered to a special folder named Virus, within the users mail directory. Deleting emails containing viruses is generally recommended, and false positives in the default ClamAV configuration are extremely unlikely.

Enable this if the domain owner account should have the ability to edit DNS records for his domain. Depending on configuration, the domain owner may create new subdomain records, modify existing domain records, modify MX records, and more. Inexperienced users may not want or need this much flexibility.

Enable this if the domain owner account should have the ability to create, edit or delete new mailboxes and mail aliases.

Enable this if the domain owner account should have the ability to edit the Apache configuration for his domain. The privileges granted by this option can be intimidating for inexperienced users, but experienced users will find the flexibility very powerful. It is also possible, through modifications to the default access control configuration, to allow direct access to the virtual domains section of the configuration file for Apache. Protections are in place to prevent malicious behavior, but it is unlikely to be perfect. By default the privileges granted are generally safe for use in a shared hosting environment.

If enabled, Webalizer reporting configuration will be accessible to the domain owner. This is not the same as enabling report generation, instead this allows the domain owner to configure the Webalizer configuration for their log reports. For example, they may choose to exclude some segment of their site, or some user-agent, from reports.

If enabled, the domain owner account will have access to the MySQL Webmin module. It provides a friendly GUI to the databases that belong to the domain owner. With this module, and appropriate privileges, the domain owner can create new databases, edit existing databases, or perform queries on the data within the database.

If enabled, the domain owner account will have access to the PostSQL Webmin module. It provides a friendly GUI to the databases that belong to the domain owner. With this module, and appropriate privileges, the domain owner can create new databases, edit existing databases, or perform queries on the data within the database

If enabled, the domain owner account will have access to the SpamAssassin configuration module for his domain. With this module, the policies of SpamAssassin can be customized. Inexperienced users may be intimidated by this level of control of the spam filter, and could potentially cause an increase in false positives or reduce spam filter effectiveness accidentally.

The File Manager is an advanced Java applet that provides a dual-paned browsable view of the file system on the server. It is one of the most powerful features of Webmin, and allows even inexperienced users to manage files, directories and permissions, edit text files, upload and download files, and much more. By default, the domain owner will only be able to see his own directory, and subdirectories.

This option specifies whether the domain owner account can alter passwords for his own account and his mailbox user accounts, for only his own account, or for none.

This option specifies whether the user can use the Webmin Running Processes module. If enabled, the user will be able to see all of the processes that belong to him that are running on the server.

This option specifies whether the domain owner account can use the Cron Jobs Webmin module. A Cron Job is a scheduled event that can be used to periodically perform some task, such as sending out an email, backup or vacuum a database, check the status of a file or mailbox, etc. The Cron Jobs module provides and easy to use interface to the difficult to remember (and confusing to newbies) syntax of the crontab file. Cron Jobs will be executed as the domain owner user.

This option specifies whether the domain owner account can use the Scheduled Commands Webmin module. A Scheduled Command or at task is a scheduled event that can be used to perform a task once at the time specified. The Scheduled Commands module provides an easy to use interface to the difficult to remember (and confusing to newbies) syntax of the at command. Scheduled Commands will be executed as the domain owner user.

This option specifies whether the domain owner user can use the SSH/Telnet Login Webmin module. This module is a Java applet that logs into the server using SSH or Telnet. It does not work correctly with all browsers, due to Java incompatibilities. Note that disabling this does not prevent SSH access to the server by the domain owner, merely access to the SSH/Telnet Login module of Webmin.

This option specifies with the domain owner will have access to the Upload and Download Webmin module. The Upload and Download module provides a very simple mechanism for users to upload files to or download files from other websites to the server, without requiring the use of DAV, FTP, SSH, FISH, or any other file transfer protocol that might be intimidating for new users. It is entirely a web-based mechanism for getting data onto the system.

This option specifies whether the domain owner can alter the theme and language for his Webmin account.

This option specifies whether the domain owner will have access to the Protected Web Directories Webmin module, which allows creation of one or more directories that are password protected. This can, of course, be done using .htaccess files, but many users do not know how to create or use .htaccess files, and this module provides a web-based means of performing the same task.

This option determines whether the domain owner can use the Read User Mail module to read the mail of users within the domain.

This option specifies whether the domain owner will have access to the Custom Commands Webmin module. With the Custom Commands module you can extend Webmin without having to program a new module. A custom command can run any command on the system with any options you specify. Variable replacement is also available so that the user running the command can provide input or option arguments to the command, and it is possible to run the command as the logged in Webmin user, or as any user on the system (including root, but be careful with that!). This is a very powerful feature of Webmin, allowing you to add new "buttons" that perform functions specific to your environment, or that some of your users may need access to.