Hostwinds Dedicated LAMP Server Tutorial

Restart Apache...

phpMyAdmin files are located at: /usr/share/phpmyadmin -- web site files. /etc/phpmyadmin and /etc/dbconfig-common -- config files. /etc/phpmyadmin/config.inc.php -- main configuration file.

phpMyAdmin requires the PHP mbstring extension to function (it may already be installed). Install and enable php-mbstring...

You may also need to uncomment the line below in php.ini: extension=mbstring

Restart Apache...

By default, phpMyAdmin is served out of the /var/www/html directory. If the FastCGI Process Manager handles PHP requests to your server, add the following to 000-default.conf: SetHandler "proxy:unix:/run/php/php7.3-fpm.sock|fcgi://localhost"

You can now access phpMyAdmin by visiting your server's IP address followed by "/phpmyadmin": http://111.222.333.4/phpmyadmin

Access phpMyAdmin from a Secure Domain URL (e.g., https://mydomain.com/phpmyadmin)

Because phpMyAdmin is popular, it's a frequent target of malevolent hackers. A few precautions will reduce your vulnerability.

By default, the initial setup of phpMyAdmin allows access through the IP address of your server (e.g., http://111.222.333.4/phpmyadmin). To enable access through a domain, edit /etc/phpmyadmin/apache.conf.

Wrap the config file in a VirtualHost directive that assigns a domain you control to the ServerName and ServerAlias: ServerName mydomain.com ServerAlias mydomain.com www.mydomain.com Alias /phpmyadmin /usr/share/phpmyadmin ....

Add Basic Authentication by inserting the following below the "Alias" line: AuthType Basic AuthName "Admin Access" AuthUserFile /var/mypasswords/phpmyadmin Require valid-user

Insert "AllowOverride All" under the "" directive: Options SymLinksIfOwnerMatch DirectoryIndex index.php AllowOverride All ....

Create a symlink to /etc/phpmyadmin/apache.conf and enable phpmyadmin.conf...

Restart Apache...

Now that you've assigned a domain to phpMyAdmin, the next step is to add encryption. I won't go into detail here about encrypted URLs. Instead, you'll want to follow the instructions below about generating a Let's Encrypt certificate for the domain serving phpMyAdmin (mydomain.com) and revising the apache.conf file.

DNS (Domain Name System)

DNS is often compared to a phonebook. It maps IP addresses to domain names. This means that visitors to your web site can find you by entering mydomain.com instead of 111.222.333.4.

Managing DNS records is complicated. Fortunately, Hostwinds provides a convenient web interface to manage DNS. The first step involves pointing your domains to Hostwinds' nameservers.

Registration and Nameservers

If you are registering new domain names, the process is simple. From the home page of the Client Area, go to Domains > Register a New Domain, and purchase an available domain.

If you are transferring a domain from another registrar to Hostwinds, go to Domains > Transfer Domains to Us. In addition to entering the domain name to be transferred, you'll need to enter an authorization code from the existing domain registrar (e.g., godaddy.com) to initiate the transfer. Also, be sure to "unlock" the domain name with the existing domain registrar. Be patient. The transfer process can take up to a week.

If Hostwinds is acting as your registrar, you can monitor the status in the Client Area at Domains > My Domains. If the status is "Active" (as opposed to "Pending"), you can select "Manage Nameservers" in the pulldown menu to the right of the domain name. Make sure the "Use custom nameservers (enter below)" radio button is highlighted. Enter nameserver records for the "Nameserver 1" (e.g., mdns5.hostwindsdns.com) and "Nameserver 2" (e.g., mdns6.hostwindsdns.com) fields, and click the "Change Nameservers" button.

If you are happy with your current registrar (e.g., godaddy.com), you need to repoint the domain's nameservers to Hostwinds' nameservers (e.g., mdns5.hostwindsdns.com and mdns6.hostwindsdns.com) and change the IP address of the "A" records to the primary IP of your Hostwinds server.

Next, you'll need to associate your domains with your server. In the Client Area, go to Domains > Manage DNS. (As you'll see, this takes you to the Cloud Control interface.) Click the "Create" button, select "Domain (Add a domain name)", enter the domain (e.g., mydomain.com) you want to host on your server, and click "Add Domain". The nameservers associated with your account will be your defaults.

Manage DNS Records with Hostwinds

If a domain is registered with Hostwinds and its status is "Active", you have the ability to add, edit, and delete DNS records in the Hostwinds interface. In the Client Area, go to Domains > Manage DNS (this takes you back to the Cloud Control interface). You should see a list of domains associated with your account. Assuming the status of the domain is "Active", clicking the "Actions" link will open a link to "Records".

The interface for adding records has four fields: the first field is the record "type" (e.g., A, TXT, CNAME, etc.); the second field is the "name" or "host"; the third field is the "value" or "points to"; and the fourth field is the "TTL" (time to live) or time in seconds until the record begins propagating.

A (address) Records
The most basic web hosting DNS record is the A record, which maps a domain name to an IP address. You'll need two of them. The default for the record type in the first field is "A". In the second field, enter "@" (which signifies the core domain name). In the third field, enter your primary IP address. The default TTL is 3600 seconds (one hour). Your second A record should match the first, except in the second field you'll enter "www" instead of "@". This record will point to "www.mydomain.com".

NS (nameserver) Records
Likewise, you'll need two NS records for your two nameservers. In the pulldown menu of the first field, select "NS". In the second field, enter "@". In the third field, enter your first nameserver (e.g., "mdns5.hostwindsdns.com"). Repeat the procedure to add a second NS entry for your second nameserver (e.g., "mdns6.hostwindsdns.com").

CNAME (canonical name) Records
If you need to create a subdomain, such as "blogs.mydomain.com", you should select "CNAME" in the first field. In the second field, enter "blogs". In the third field, enter "mydomain.com".

MX (mail exchange) Records
If you plan on sending email from your domain, three records are required.
Record 1. In the first field, select "CNAME". In the second field, enter "mail". In the third field, enter "mydomain.com". This creates a subdomain -- "mail.mydomain.com".
Record 2. In the first field, select "MX". In the second field, enter "@". In the third field, enter "10 mail.mydomain.com". The number indicates the priority of the record (the lower the number, the higher the priority).
Record 3. As a backup, repeat the procedure above to create another MX record. In the third field, enter "20 mail.mydomain.com". The other fields should match the first MX record.

PTR (pointer) Records
If you plan to send email on behalf of the domain name (i.e., entering "myname@mydomain.com" in the "From" field), you'll want to create a "pointer", or PTR, record, that maps an IP address to a domain. The PTR is used for reverse DNS (rDNS) lookup. Your Hostwinds account comes with a single primary IP address and several "assigned" IP addresses. The assigned IPs come in handy when PTR records need to be generated. Unlike other DNS records, the PTR is not created through the Cloud Control interface. Instead, you must return to the Client Area and go to Domains > Manage rDNS. There you'll see a list of your assigned IPs. Click on the edit icon of an IP address to map the IP address to a domain. (There's no need to create a separate PTR record in the DNS interface.)

Confirm that the PTR has been set...

SPF (Sender Policy Framework) Records
SPF records are intended to validate the email sent from your domain. Although the Sender Policy Framework is a complex subject, entering a basic SPF record is simple. Start by selecting "TXT" in the first field. In the second field, enter "@". In the third field, enter something like "v=spf1 mx ip4:111.222.333.4 include:_spf.google.com ~all" (in this case, you're allowing email to be sent from your IP address and from your Gmail account). You can check the syntax of your SPF record by plugging it into an SPF Validator (such as https://www.kitterman.com/spf/validate.html).

DKIM (DomainKeys Identified Mail) Records
Unlike SPF, creating a DKIM record is not simple. In fact, there's a separate section below titled "Create DKIM Keys". You can deal with that later.

DMARC (Domain-based Message Authentication, Reporting and Conformance) Records
DMARC is an email authentication protocol with the best of intentions. It gives owners of a domain name the ability to defend their domain against spoofers. A DMARC record instructs receiving email servers how an email from your domain should be authenticated based on your SPF and DKIM records. If you send email from your domain only from your server, you can construct a strict DMARC policy. On the other hand, if you send email with your domain in the "From" field from your Gmail, Yahoo, Hotmail (you name it) account, a strict DMARC policy will result in a lot of rejected email. In that case, you should create a lax DMARC record (i.e., something is better than nothing).

In the first field, select "TXT". In the second field, enter "_dmarc". In the third field, enter "v=DMARC1; p=none; pct=100; rua=mailto:webmaster@mydomain.com".

If you have a domain name that does not send emails, you should created a record with a "p=reject" policy (e.g., "v=DMARC1; p=reject; pct=100; rua=mailto:webmaster@mydomain.com").

One final word about DNS: don't worry if you make a mistake. You can delete the record and replace it with a new one. The new record may take some to propagate across the Internet, but you haven't done any lasting damage to your domain.

Virtual Hosting with Apache2

At this stage, you should have a functioning web server. Of course, the point of a functioning web server is to host a functioning web site. In this section, we'll get to the heart of the matter. You'll create a user, transfer files, and configure Apache to serve up your web site.

I'm assuming that you signed up for a dedicated server because you wanted the flexibility of hosting multiple domains on a single server. That's where Virtual Hosting comes in to play. For each virtually hosted domain, you'll repeat the process below.

Create a User and Transfer Files

Add a user for your domain...

The "adduser" command will prompt you to make several entries.
The "User Name" should match the core username of the account (e.g., mydomainuser).
If you are the sole admin on your server, you can enter your name for "Full Name" and accept the empty defaults for the other identifiers ("Room Number", "Work Phone", etc.).
The results of "adduser" will be the creation of a new directory for a virtually hosted account in the /home/ directory (e.g., /home/mydomainuser/).

The standard path for web files is the /var/www/html/ directory. In the example below, however, I'll use the /home/ directory to house my web files.

Create a "www" directory in the /home/mydomainuser/ directory...

From your Hostwinds server, use rsync to transfer files from your old server...

For convenience, add a symlink from / (the root directory) to the web content directory.

If you have a configuration file with passwords, email addresses, and other sensitive information, you should place it in a more remote, protected area of your server.

By default, "mydomainuser" is the owner of the directory created by running "adduser". That's fine if you edit your web files with one of Ubuntu's built-in text editors (such as nano or vm) and don't use SFTP to upload files. In my case, however, I prefer to edit web files with my favorite desktop text editor (UltraEdit), which connects to my server by SFTP. I also use WS_FTP to upload files on occasion. Because I rely on the SFTP protocol, I want to give my SFTP user easy access to my web files by changing the ownership of the files in the newly created /home/mydomainuser/ directory.

Change ownership...

Create a New Database (I'm assuming your web site is powered by MySQL)

Log in to phpMyAdmin.

To create and set up a new database, click the "New" link in the phpMyAdmin sidebar and enter a database name (e.g., "MyDatabase"). Accept the defaults and click "Create".

To grant privileges to a new user, update the "mysql" database that was automatically created when MySQL was installed. (To repeat, all of these steps could be accomplished by running MySQL from the command line. Using phpMyAdmin just makes them easier.)

Go to the "mysql" database and add a new user to the "user" table with the following SQL statement...

The fields for the newly created user "mydomainuser" in the "user" table will be set to "no" by default.

Next, set the privileges for the user "mydomainuser" in the "db" table...

Reload the grant tables...

Dump Database on Your Old Server and Rebuild It on Your New Server

Dump database on your old server (the path to mysqldump may need to be changed)...

From your Hostwinds server, transfer the database dump and rebuild the database...

Execute check, repair, optimize, and analyze the tables of your MyDatabase.

Configure Virtual Hosting

In past versions of Apache, you probably put all of your VirtualHost directives into a single configuration file. In Apache2.4, standard practice is to create a separate VirtualHost configuration file for each of your domains. The VirtualHost config files reside in the /etc/apache2/sites-available directory. A default file -- 000-default.conf -- serves as an example. (You'll want to make a back-up copy of the default file.)

Copy the default file...

The "mydomainuser" in "mydomainuser.conf" must match the username you created above with the "adduser" command.

Now it's time to open mydomainuser.conf in the text editor of your choice and plop in your VirtualHost directive. VirtualHost directives can be as simple or complex as you desire. In the example below, we'll keep things fairly simple, but with a nod to the use of PHP and Apache's mod_rewrite module: ServerName mydomain.com ServerAlias www.mydomain.com mydomain.com DocumentRoot /home/mydomainuser/www/mydomain.com ServerAdmin webmaster@mydomain.com ErrorLog /error.log CustomLog /access_log_mydomain combined SetHandler "proxy:unix:/run/php/php7.3-fpm.sock|fcgi://localhost" RewriteEngine on RewriteCond %{HTTP_HOST} !^www [NC] RewriteRule ^/(.*) https://www.mydomain.com/$1 [L,R=permanent] RewriteEngine on RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f RewriteRule ^.*$ /traffic_director.php [PT]

You'll notice that the VirtualHost directive uses a wildcard in place of an IP address (). The wildcard points the domain to your primary IP address. If the default doesn't work for you, you'll need to specify the IP address in the VirtualHost directive (e.g., ).

If the domain features a subdomain (e.g., blog.mydomain.com), you'll need to include a separate VirtualHost directive in the config file for the subdomain. The ServerName and ServerAlias must reflect the subdomain. Place VirtualHost directives for subdomains above the VirtualHost directive of the core domain (e.g., mydomain.com). Subdomains must be associated with a CNAME DNS record.

The example above assumes you're using FastCGI Process Manager to serve requests for PHP pages. The three lines of the directive instruct Apache to process files ending with a ".php" extension with the php7.3 version of the php-fpm extension: SetHandler "proxy:unix:/run/php/php7.3-fpm.sock|fcgi://localhost"

Below that are two rewrite rules. The first rewrites URL requests without "www" (e.g., http://mydomain.com) to http://www.mydomain.com. The second redirects all requests that are not for actual files to my traffic_director.php script, which, as the filename suggests, routes page requests to their proper destination.

Enable and Restart

Once you've finished editing mydomainuser.conf, you need to enable the configuration file. The a2ensite command creates a symlink in the /etc/apache2/sites-enabled directory...

Before restarting Apache, check the syntax of the new VirtualHost directive...

Restart Apache...

Once 000-default.conf is no longer needed, you should disable the default config file...

Let's Encrypt Certificates

Encryption is quickly becoming the standard on the web, with Google favoring sites that use the https protocol over http. Fortunately, there's Let's Encrypt -- a non-profit certificate authority that provides SSL certificates at no cost. To generate a Let's Encrypt certificate, you can use Certbot -- yet another free, open-source software tool.

To begin the process, go to https://certbot.eff.org/instructions.

Select your web server (e.g., Apache) and operating system (e.g., Ubuntu 18.04 LTS (bionic)). Certbot's web site presents command-line instructions for you to follow to install the most up-to-date version of certbot from the Certbot PPA. (Note that Python will be installed along with certbot if it's not already on your server.)

Once certbot is installed, you are in a position to generate Let's Encrypt certificates on your server. (Certificates can be created only if a domain's nameserver and A records resolve to your server.)

Create a certificate for mydomain.com...

The certificate generated above will encrypt requests for both https://mydomain.com and https://www.mydomain.com.

You will find several certificate-related files in the /etc/letsencrypt/ directory.

Edit Apache Config Files

Next, we need to reconfigure the Apache configuration file for your domain. You'll notice in the VirtualHost example above, the directive was instructed to listen to port 80. We need to change that to port 443:

Within the same VirtualHost directive, add the SSLCertificate section just below the ServerAdmin parameter. This tells Apache where to find the certificates you generated: SSLEngine on SSLCertificateFile /etc/letsencrypt/live/mydomain.com/cert.pem SSLCertificateKeyFile /etc/letsencrypt/live/mydomain.com/privkey.pem SSLCertificateChainFile /etc/letsencrypt/live/mydomain.com/chain.pem.

You also need to include a VirtualHost directive listening to port 80 that redirects requests from http://www.mydomain.com to https://www.mydomain.com. Insert the port 80 directive above the port 443 directive: ServerName mydomain.com ServerAlias www.mydomain.com mydomain.com DocumentRoot /home/mydomainuser/www/mydomain.com ServerAdmin webmaster@mydomain.com SSLEngine off RewriteEngine on RewriteRule ^/(.*) https://www.mydomain.com/$1 [R=permanent,L]

WARNING: Do not enable a domain that is listening to port 443 until the Let's Encrypt certificate has been generated and the SSLCertificate paths defined. Otherwise, Apache will throw a syntax error when you restart and ALL sites on your server listening to port 443 will fail to connect and instead trigger errors.

Let's Encrypt certificates expire in 90 days. Fortunately, all of your certificates can be renewed with a single command...

Even easier is to renew your certificates through a cron job, which is our next subject.

Cron Jobs

Cron is a utility included with Ubuntu and other Unix-based operating systems. The software is nothing more than a task scheduler. The power of cron derives from the scripts you choose to schedule.

Cron scripts can be scheduled to run as often as you like -- from every minute to once a year. They can execute single shell commands or lengthy scripts written in PHP or other programming languages. I use cron jobs to automate a variety of chores, such as renewing Let's Encrypt certificates, cleaning up temp files, optimizing my databases, sending emails to customers, settling credit card transactions, generating XML sitemaps, etc. You get the picture.

Cron is already installed on your server but you do need to enable it...

Cron responds to instructions in the crontab (short for cron table) file. You could edit crontab directly. However, for convenience I suggest you create a separate file that contains a schedule of your cron jobs and can be easily edited at /var/spool/cron/mycronjobs.

If you use PHP to write cron scripts, the top of the file needs a "shebang" line pointing to the CLI version of PHP required. #!/usr/bin/php7.3 -q

After editing mycronjobs, refresh crontab...

Check crontab to make sure your changes have been recorded...

Logrotate Configuration

Logrotate is installed and activated when you order your server. As the name suggests, it rotates the many types of log files found in the /var/log/ directory. The default configuration file is located at /etc/logrotate.conf. In addition, there are application-specific config files in the /etc/logrotate.d/ directory.

If you find that too many log backup files are being saved, you can edit the files in the /etc/logrotate.d/ directory. Lowering the value of the "rotate" parameter reduces the number of backup files saved in /var/log/.

By default, logrotate runs on a daily basis by executing the shell script /etc/cron.daily/logrotate.

Postfix Installation

Postfix is an open-source email server (or mail transfer agent). It was developed by Wietse Venema at IBM and debuted in 1998. Venema and others in the Postfix community continue to support its improvement. Postfix is the default email server in Ubuntu.

Postfix serves to both send and receive email. Personally, I'm very wary of hosting email accounts on my server. Past experience has taught me that email hosting brings non-stop headaches and few rewards. Instead, you should focus on making sure that email sent from your server reaches as many inboxes as possible.

Installing and configuring Postfix is a relatively lengthy process, with many optional detours. I opted for a fairly simple installation. It largely follows the instructions written by Xiao Guoan (aka, the Linux Babe). If you're looking for more detail, please visit https://www.linuxbabe.com/mail-server/setup-basic-postfix-mail-sever-ubuntu. (In general, Xiao's site is an outstanding resource for anyone working on an Ubuntu server, or other Debian-based systems.)

Install and Configure Postfix

Before you delve into Postfix, you need to set up a FQDN (fully qualified domain name) for your email server, such as mail.mydomain.com. Revisit the "MX (mail exchange) Records" heading in the DNS section to define the FQDN for your mail server.

Assign the domain as your FQDN...

If you installed the Apache mod-evasive module, Postfix was installed as well. Execute the command below to determine if a version of Postfix resides on your server...

If Postfix is not found or the version needs to be updated, install it...

Below are the key paths to managing Postfix on your server: /etc/postfix -- Postfix configuration files. /usr/sbin -- Postfix executables. /var/log/mail.log -- log file. /var/mail -- inboxes for each user.

Postfix uses port 25. Make sure it's not blocked by the UFW firewall...

To use an email client, such as Thunderbird, for email, you'll need to unblock additional ports from the firewall...

By default, the /etc/aliases file contains only one line -- postmaster: root. Generally, root is not used as an email address. Instead, the postmaster should use a login name alias to access emails. root: myemailuser

Implement changes to /etc/aliases...

Most of the configuration parameters you may want to adjust can be found in /etc/postfix/main.cf. As you'll see, Postfix gives you a lot of flexibility. For now, we'll begin with a few basic edits.

Change the "myhostname" parameter to your FQDN (e.g., mail.mydomain.com).

Edit the "TLS parameters" as follows (I'm assuming you've already created a Let's Encrypt certificate for mydomain.com): smtpd_tls_cert_file=/etc/letsencrypt/live/mail.mydomain.com/fullchain.pem smtpd_tls_key_file=/etc/letsencrypt/live/mail.mydomain.com/privkey.pem smtpd_tls_security_level=may smtpd_tls_loglevel = 1 smtpd_tls_session_cache_database = btree:/smtpd_scache smtp_tls_security_level = may smtp_tls_loglevel = 1 smtp_tls_session_cache_database = btree:/smtp_scache smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

By default, the /etc/postfix/main.cf file contains the following line to prevent your email server from acting as an open relay: smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination

To send email from an email client, such as Thunderbird, uncomment the "submission inet" section in /etc/postfix/master.cf.

Reload Postfix...

Install and Configure Dovecot

Dovecot works hand-in-hand with Postfix. It mainly acts as a mail storage server employing the IMAP and POP3 protocols. Notwithstanding my reluctance to host email accounts, you might as well install Dovecot in conjunction with Postfix (let's hope you can avoid becoming a serious Dovecot admin).

Install the IMAP and POP3 versions of Dovecot...

Edit the main Dovecot config file at /etc/dovecot/dovecot.conf by adding the following at the end of the file: protocols = imap protocols = imap pop3

Open /etc/dovecot/conf.d/10-mail.conf to check if the "mail_location" and "mail_privileged_group" parameters are properly set.
By default, "mail_location" is already set to /var/mail (mail_location = mbox:~/mail:INBOX=/var/mail/%u), which is fine.
The other important line -- mail_privileged_group = mail -- is also present by default.

Add dovecot to the mail group so that Dovecot can read the INBOX...

Edit the authentication file at /etc/dovecot/conf.d/10-auth.conf.
Uncomment the following line: disable_plaintext_auth = yes
Add the following line to require a full email address (myusername@mydomain.com) to log in: auth_username_format = %n

Make the following changes in the SSL/TLS config file at /etc/dovecot/conf.d/10-ssl.conf: ssl = required (from "yes") ssl_cert =
Disable SSLv3, TLSv1 and TLSv1.1 by adding the following line: ssl_protocols = !SSLv3 !TLSv1 !TLSv1.1

In /etc/dovecot/conf.d/10-master.conf, change the "service auth" section to the following: unix_listener /var/spool/postfix/private/auth { mode = 0660 user = postfix group = postfix }

Restart Dovecot and confirm that it's running...

Restart Postfix...

If you get sucked into hosting email accounts, you'll need to set up a cron job to delete email from the "Junk" and "Trash" folders of your email users. Below are examples of commands that delete emails in the "Junk" and "Trash" folders at least two weeks (2w) old...

Install and Configure PostfixAdmin

PostfixAdmin is a web-based application for managing Postfix. It's written in PHP and requires integration with MySQL. The PostfixAdmin interface is a little clunky and dated, but it gets the job done.

Because PostfixAdmin relies on MySQL, you first need to prevent the installation from reconfiguring your database...

Install PostfixAdmin...

Remove dbconfig-no-thanks...

Run the PostfixAdmin Configuration Wizard...

The wizard will prompt you to enter a few responses: Reinstall database: yes MySQL database connection: Unix socket Database name: postfixadmin (default) MySQL username for postfixadmin database: postfixadmin Database password: *********** Database admin user: debian-sys-maint

The wizard will install two new databases: "information_schema" and "postfixadmin".

Edit /etc/dbconfig-common/postfixadmin.conf to integrate MySQL: dbc_dbtype='mysqli'

Edit /etc/postfixadmin/dbconfig.inc.php to integrate MySQL: ='mysqli'

The web files are installed under /usr/share/postfixadmin/ directory, which is owned by root. You need to give the "www-data" user read, write, and execute permissions on the Smarty template compile directory. Grant permissions...

In the Client Area, go to Domains > Manage DNS and create a new CNAME record for your mydomain.com domain: postfixadmin.mydomain.com

Create a new VirtualHost directive at /etc/apache2/sites-available/postfixadmin.conf: ServerName postfixadmin.mydomain.com DocumentRoot /usr/share/postfixadmin/ ErrorLog /postfixadmin_error.log CustomLog /postfixadmin_access.log combined Options FollowSymLinks AllowOverride All Options FollowSymLinks MultiViews AllowOverride All Order allow,deny allow from all

Enable the config file...

Restart Apache...

You should be able to access the PostfixAdmin web-based install wizard at http://postfixadmin.mydomain.com/setup.php.

The set-up process populates the postfixadmin database. The three most important tables are: domain -- contains information on the domains that are using your mail server to send and receive email. mailbox -- contains information on every email address, including hashed passwords and the location of mail files. alias -- contains the alias of each email address.

Configure Postfix and Dovecot to Use the MySQL Database

By default, Postfix delivers emails only to users with a local account on your server. To make it deliver emails to virtual users whose information is stored in the database, you need to configure Postfix to use virtual mailbox domains. At this point, the postfix-mysql module should have been already installed.

virtual_mailbox_domains points to a file that will tell Postfix how to look up domain information from the database.
virtual_mailbox_maps points to files that will tell Postfix how to look up email addresses from the database.
virtual_alias_maps points to files that will tell Postfix how to look up aliases from the database.

You'll need to create several config files in the /etc/postfix/sql/ directory. Start by creating the directory...

Create the files below in the /etc/postfix/sql/ directory by following the instructions at https://www.linuxbabe.com/mail-server/postfixadmin-ubuntu: mysql_virtual_domains_maps.cf mysql_virtual_mailbox_maps.cf mysql_virtual_alias_domain_mailbox_maps.cf mysql_virtual_alias_maps.cf mysql_virtual_alias_domain_maps.cf mysql_virtual_alias_domain_catchall_maps.cf

Restrict access to /etc/postfix/sql...

Edit /etc/postfix/main.cf

Since we are using virtual mailboxes, we need to remove the core domain name (mydomain.com) from the "mydestination" parameter.

Add the following lines to the end of the file: virtual_mailbox_base = /var/vmail virtual_minimum_uid = 2000 virtual_uid_maps = static:2000 virtual_gid_maps = static:2000

The first line defines the base location of mail files. The remaining three lines define which user ID and group ID Postfix will use when delivering incoming emails to the mailbox. We use the user ID 2000 and group ID 2000.

Restart Postfix...

Create a user named "vmail" with ID 2000 and a group with ID 2000...

Create the mail base location with vmail as the owner of the directory...

Configure Dovecot to use MySQL by installing the dovecot-mysql module...

Edit /etc/dovecot/conf.d/10-mail.conf:
Change: mail_location = maildir:/var/vmail/%d/%n
Add: mail_home = /var/vmail/%d/%n

Edit /etc/dovecot/conf.d/10-auth.conf:
Change: auth_username_format = %u
Uncomment: !include auth-sql.conf.ext
Add: auth_debug = yes auth_debug_passwords = yes

Set the parameters below in /etc/dovecot/dovecot-sql.conf.ext: driver = mysql connect = host=localhost dbname=postfixadmin user=postfixadmin password=********* default_pass_scheme = ARGON2I password_query = SELECT username AS user,password FROM mailbox WHERE username = '%u' AND active='1' user_query = SELECT maildir, 2000 AS uid, 2000 AS gid FROM mailbox WHERE username = '%u' AND active='1' iterate_query = SELECT username AS user FROM mailbox

Restart Dovecot...

DKIM and SPF

Before we get completely lost in the weeds, lets remind ourselves that the main purpose of Postfix is to send email from your server into the inboxes of your recipients. To repeat, we want our email to land in the inbox. Not spam, not junk, not trash, and certainly not out in the ether. That's the reason we are once again addressing the issues of SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) in the Postfix section. For now, follow along. There is light at the end of the tunnel.

SPF Policy Agent

Install the SPF Policy Agent...

Edit /etc/postfix/master.cf by adding the following lines at the end of the file: policyd-spf unix - n n - 0 spawn user=policyd-spf argv=/usr/bin/policyd-spf

Edit /etc/postfix/main.cf by adding the following lines at the end of the file: policyd-spf_time_limit = 3600 smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_policy_service unix:private/policyd-spf

Restart Postfix...

OpenDKIM

Install OpenDKIM...

Add postfix user to opendkim group...

Edit /etc/opendkim.conf by uncommenting the following lines, replacing "simple" with "relaxed/simple": Canonicalization relaxed/simple Mode sv SubDomains no

Add the following lines below "SubDomains no": AutoRestart yes AutoRestartRate 10/1M Background yes DNSTimeout 5 SignatureAlgorithm rsa-sha256

Add the following lines at the end of the file: # Map domains in From addresses to keys used to sign messages KeyTable refile:/etc/opendkim/key.table SigningTable refile:/etc/opendkim/signing.table # Hosts to ignore when verifying signatures ExternalIgnoreList /etc/opendkim/trusted.hosts # A set of internal hosts whose mail should be signed InternalHosts /etc/opendkim/trusted.hosts

Create a directory for opendkim keys...

Change the owner and permissions for the newly created directory...

Change the OpenDKIM Unix socket file so Postfix can communicate with it.

Create a directory to hold the OpenDKIM socket file and allow only "opendkim" user and "postfix" group to access it...

Edit /etc/opendkim.conf and replace: Socket local:/var/run/opendkim/opendkim.sock
with Socket local:/var/spool/postfix/opendkim/opendkim.sock

Add the following lines to the end of /etc/postfix/main.cf: # Milter configuration milter_default_action = accept milter_protocol = 6 smtpd_milters = local:opendkim/opendkim.sock non_smtpd_milters =

Restart opendkim and postfix service...

Create DKIM Keys

Now that opendkim is installed and configured, we can finally generate DKIM records for your domains.

Create/edit the signing table at /etc/opendkim/signing.table and add entries for each domain that requires a DKIM key: *@mydomain.com default._domainkey.mydomain.com *@myotherdomain.com default._domainkey.myotherdomain.com

Create/edit /etc/opendkim/key.table and add entries for each domain that requires a DKIM key: default._domainkey.mydomain.com mydomain.com:default:/etc/opendkim/keys/mydomain.com/default.private default._domainkey.myotherdomain.com myotherdomain.com:default:/etc/opendkim/keys/myotherdomain.com/default.private

Create/edit /etc/opendkim/trusted.hosts and add the following: 127.0.0.1 localhost *.mydomain.com *.myotherdomain.com

For each domain, you will generate a private key for signing and a public key for remote verification. The public key will be published in your DNS records.

Create a separate directory for each domain...

Generate keys for each domain using opendkim-genkey tool...

Change the owner of the private keys...

Display the public key for the domain...

Publish Your DKIM Record

In the Client Area, go to Domains > Manage DNS to create a DKIM record for each domain. In the first field, select "TXT". In the second field, enter "default._domainkey," which will default to default._domainkey.mydomain.com. For CNAME domains (e.g., mail.mydomain.com), type out the second field in full (e.g., default._domainkey.mail.mydomain.com). In the third field, enter everything displayed by the above command that lies within the parentheses. This can be tricky, because you also have to remove all double quotes, line breaks, and tabs from the display.

Restart opendkim...

Test the key...

The results should look like the following: opendkim-testkey: using default configfile /etc/opendkim.conf opendkim-testkey: checking key 'default._domainkey.mydomain.com' opendkim-testkey: key not secure opendkim-testkey: key OK

Don't worry about "key not secure". That means DNSSEC isn't enabled on your domain name.

Test your DKIM, SPF, and DMARC records at https://www.mail-tester.com.

To pass a DMARC check, an email needs to meet one of the following requirements:
1. Score an SPF "pass" with the Return-Path domain name being the same as the header.from domain.
2. Score a DKIM "pass" with the domain of the DKIM-Signature (d=mydomain.com) being the same as the header.from domain.