Create a mail server with Postfix, Dovecot, SpamAssassin and OpenDKIM

Note that this is mostly for personal use, so there’s no user/authentication control other than that of SSH. Also, most if not all commands here are run as root.

Prerequisites

I might get tired of saying this (it’s just copy paste, basically)… but similar as before (check my website and mail entries):

I might get tired of saying this (it’s just copy paste, basically)… but you will need the same prerequisites as before (check my website and mail entries), with the extras:

git server

Git

You’re basically done. Now you should be able to push/pull repositories to your server… except, you haven’t created any repository in your server, that’s right, they’re not created automatically when trying to push. To do so, you have to do the following sequence (assuming you’re “cd‘ed” into the /home/git directory):

Dovecot

Dovecot is an IMAP and POP3 server, which is what lets an email application retrieve the mail.

As Luke stated, dovecot comes with a lot of “modules” (under /etc/dovecot/conf.d/ if you copied that folder) for all sorts of configurations that you can include, but I do as he does and just edits/creates the whole dovecot.conf file; although, I would like to check each of the separate configuration files dovecot provides I think the options Luke provides are more than good enough.

I’m working with an empty dovecot.conf file. Add the following lines for SSL and login configuration (also replace {yourcertdir} with the same certificate directory described in the Postfix section above, note that the < is required):

As Luke stated, dovecot comes with a lot of “modules” (under /etc/dovecot/conf.d/ if you copied that folder) for all sorts of configurations that you can include, but I do as he does and just edit/create the whole dovecot.conf file; although, I would like to check each of the separate configuration files dovecot provides I think the options Luke provides are more than good enough.

Lastly (for dovecot at least), the plugin configuration for sieve (pigeonhole):

Lastly (for Dovecot at least), the plugin configuration for sieve (pigeonhole):

And more, make sure to include your server IP and something like subdomain.domainname.

Next, edit /etc/opendkim/opendkim.conf to reflect the changes (or rather, additions) of these files, as well as some other configuration. You can look up the example configuration file located at /usr/share/doc/opendkim/opendkim.conf.sample, but I’m creating a blank one with the contents:

Next, edit /etc/opendkim/opendkim.conf to reflect the changes (or rather, addition) of these files, as well as some other configuration. You can look up the example configuration file located at /usr/share/doc/opendkim/opendkim.conf.sample, but I’m creating a blank one with the contents:

I’m using root:opendkim so opendkim doesn’t complain about the {yoursubdomani}.private being insecure (you can change that by using the option RequireSafeKeys False in the opendkim.conf file, as stated here).

That’s it for the general configuration, but you could go more in depth and be more secure with some extra configuration as described in the Arch Wiki entry for OpenDKIM.

That’s it for the general configuration, but you could go more in depth and be more secure with some extra configuration.

Wrapping up

We should have a working mail server by now. Before continuing check your journal logs (journalctl -xe --unit={unit}, where {unit} could be spamassassin.servicefor example) to see if there was any error whatsoever and try to debug it, it should be a typo somewhere (the logs are generally really descriptive) because all the settings and steps detailed here just (literally just finished doing everything on a new server as of the writing of this text) worked (((it just werks on my machine))).

We should have a working mail server by now. Before continuing check your journal logs (journalctl -xe --unit={unit}, where {unit} could be spamassassin.service for example) to see if there was any error whatsoever and try to debug it, it should be a typo somewhere (the logs are generally really descriptive) because all the settings and steps detailed here just (literally just finished doing everything on a new server as of the writing of this text) worked (((it just werks on my machine))).

Now, to actually use the mail service: first of all, you need a normal account (don’t use root) that belongs to the mail group (gpasswd -a user group to add a user user to group group) and that has a password.

Next, to actually login into a mail app/program/whateveryouwanttocallit, you will use the following settings, at least for thunderdbird(I tested in windows default mail app and you don’t need a lot of settings):

All that’s left to do is test your mail server for spoofing, and to see if everything is setup correctly. Go to DKIM Test and follow the instructions (basically click next, and send an email with whatever content to the email that they provide). After you send the email, you should see something like:

(Yes, I blurred a lot in the picture just to be sure, either way what’s important is the list on the bottom part of the image)

Finally, that’s actually it for this entry, if you have any problem whatsoever you have my info down below.

Finally, that’s actually it for this entry, if you have any problem whatsoever you can contact me.

By David Luévano

Created: Sun, Mar 21, 2021 @ 04:05 UTC

Modified: Sun, Jun 06, 2021 @ 00:24 UTC

Modified: Tue, Jun 08, 2021 @ 06:27 UTC

Tags: english, server, tools, tutorial

diff --git a/blog/dst/a/website_with_nginx.html b/blog/dst/a/website_with_nginx.html index 7e5bd99..caf756f 100644 --- a/blog/dst/a/website_with_nginx.html +++ b/blog/dst/a/website_with_nginx.html @@ -95,14 +95,18 @@

Nginx

Nginx is a web (HTTP) server and reverse proxy server.

You have two options: nginx and nginx-mainline. I prefer nginx-mainline because it’s the “up to date” package even though nginx is labeled to be the “stable” version. Install the package and enable/start the service:

pacman -S nginx-mainline
 systemctl enable nginx.service
 systemctl start nginx.service

And that’s it, at this point you can already look at the default initial page of nginx if you enter the ip of your server in a web browser. You should see something like this:

Nginx welcome page

As stated in the welcome page, configuration is needed, head to the directory of nginx:

And that’s it, at this point you can already look at the default initial page of Nginx if you enter the IP of your server in a web browser. You should see something like this:

As stated in the welcome page, configuration is needed, head to the directory of Nginx:

cd /etc/nginx

Here you have several files, the important one is nginx.conf, which as its name implies, contains general configuration of the web server. If you peek into the file, you will see that it contains around 120 lines, most of which are commented out and contains the welcome page server block. While you can configure a website in this file, it’s common practice to do it on a separate file (so you can scale really easily if needed for mor websites or sub-domains).

@@ -125,7 +129,7 @@ http { types_hash_max_size 4096; } -

Next, inside the directory /etc/nginx/ create the sites-available and sites-enabled, and go into the sites-available one:

Next, inside the directory /etc/nginx/ create the sites-available and sites-enabled directories, and go into the sites-available one:

mkdir sites-available
 mkdir sites-enabled
 cd sites-available
@@ -144,28 +148,32 @@ cd sites-available
     }
 }

Note several things:

That could serve as a template if you intend to add more domains.

Note some things:

listen: we’re telling nginx which port to listen to (ipv4 and ipv6, respectively).
listen: we’re telling Nginx which port to listen to (IPv4 and IPv6, respectively).
root: the root directory of where the website files (.html, .css, .js, etc. files) are located. I followed Luke’s directory path /var/www/some_folder.
server_name: the actual domain to “listen” to (for my website it is: server_name luevano.xyz www.luevano.xyz; and for this blog is: server_name blog.luevano.xyz www.blog.luevano.xyz).
server_name: the actual domain to “listen” to (for my website it is: server_name luevano.xyz www.luevano.xyz; and for this blog is: server_name blog.luevano.xyz www.blog.luevano.xyz;).
index: what file to serve as the index (could be any .html, .htm, .php, etc. file) when just entering the website.

location: used in case of different configurations across different URL paths.

try_files: tells what files to look for, don’t look into this too much for now.
location: what goes after domain.name, used in case of different configurations depending on the URL paths (deny access on /private, make a proxy on /proxy, etc).
- try_files: tells what files to look for.

Then, make a symbolic from this config file to the sites-enabled directory:

Then, make a symbolic link from this configuration file to the sites-enabled directory:

ln -s /etc/nginx/sites-available/your_config_file.conf /etc/nginx/sites-enabled

This is so the nginx.conf file can look up the newly created server config. With this method of having each server configuration file separate you can easily “deactivate” any website by just deleting the symbolic link in sites-enabled and you’re good, or just add new configuration files and keep everything nice and tidy.

All you have to do now is restart (or enable and start if you haven’t already) the nginx service (and optionally test the configuration):

This is so the nginx.conf file can look up the newly created server configuration. With this method of having each server configuration file separate you can easily “deactivate” any website by just deleting the symbolic link in sites-enabled and you’re good, or just add new configuration files and keep everything nice and tidy.

All you have to do now is restart (or enable and start if you haven’t already) the Nginx service (and optionally test the configuration):

nginx -t
 systemctl restart nginx

If everything goes correctly, you can now go to your website by typing “domain.name” on a web browser. But you will see a “404 Not Found” page like the following (maybe with different nginx version):

Nginx 404 page

That’s no problem, because it means that the web server it’s actually working. Just add an index.html file with something simple to see it in action. If you keep seeing the 404 page make sure your root line is correct and that the directory/index file exists.

If everything goes correctly, you can now go to your website by typing domain.name on a web browser. But you will see a “404 Not Found” page like the following (maybe with different Nginx version):

That’s no problem, because it means that the web server it’s actually working. Just add an index.html file with something simple to see it in action (in the /var/www/some_folder that you decided upon). If you keep seeing the 404 page make sure your root line is correct and that the directory/index file exists.

I like to remove the .html and trailing / on the URLs of my website, for that you need to add the following rewrite lines and modify the try_files line (for more: Sean C. Davis: Remove HTML Extension And Trailing Slash In Nginx Config):

server {
     ...
@@ -175,27 +183,26 @@ systemctl restart nginx
     try_files $uri/index.html $uri.html $uri/ $uri =404;
     ...

For more: Arch Linux Wiki: nginx.

Certbot

The only “bad” (bloated) thing about certbot, is that it uses python, but for me it doesn’t matter too much. You may want to look up another alternative if you prefer. Install the packages certbot and certbot-nginx:

Certbot is what provides the SSL certificates via Let’s Encrypt.

The only “bad” (bloated) thing about Certbot, is that it uses python, but for me it doesn’t matter too much. You may want to look up another alternative if you prefer. Install the packages certbot and certbot-nginx:

pacman -S certbot certbot-nginx

After that, all you have to do now is run certbot and follow the instructions given by the tool:

certbot --nginx

It will ask you for some information, for you to accept some agreements and the names to activate https for. Also, you will want to “say yes” to the redirection from http to https. And that’s it, you can now go to your website and see that you have https active.

It will ask you for some information, for you to accept some agreements and the names to activate HTTPS for. Also, you will want to “say yes” to the redirection from HTTP to HTTPS. And that’s it, you can now go to your website and see that you have HTTPS active.

Now, the certificate given by certbot expires every 3 months or something like that, so you want to renew this certificate every once in a while. Using cron, you can do this by running:

crontab -e

And a file will be opened where you need to add a new rule for certbot, just append the line: 1 1 1 * * certbot renew (renew on the first day of every month) and you’re good. Alternatively use systemd timers as stated in the Arch Linux Wiki.

For more: Arch Linux Wiki: Certbot.

And a file will be opened where you need to add a new rule for Certbot, just append the line: 1 1 1 * * certbot renew (renew on the first day of every month) and you’re good. Alternatively use systemd timers as stated in the Arch Linux Wiki.

That’s it, you now have a website with SSL certificate.

By David Luévano

Created: Fri, Mar 19, 2021 @ 02:58 UTC

Modified: Sun, Jun 06, 2021 @ 00:23 UTC

Modified: Tue, Jun 08, 2021 @ 06:11 UTC

Tags: english, server, tools, tutorial

diff --git a/blog/dst/rss.xml b/blog/dst/rss.xml index 248050b..94e819c 100644 --- a/blog/dst/rss.xml +++ b/blog/dst/rss.xml @@ -13,9 +13,9 @@ Copyright 2021 David Luévano Alvarado david@luevano.xyz (David Luévano Alvarado) david@luevano.xyz (David Luévano Alvarado) - Sun, 06 Jun 2021 19:08:48 GMT - Sun, 06 Jun 2021 19:08:48 GMT - pyssg v0.5.7 + Tue, 08 Jun 2021 06:57:28 GMT + Tue, 08 Jun 2021 06:57:28 GMT + pyssg v0.5.9 https://validator.w3.org/feed/docs/rss2.html 30 @@ -81,20 +81,13 @@ My git server is all I need to setup to actually kill my other server (I’ve been moving from servers on these last 2-3 blog entries), that’s why I’m already doing this entry. I’m basically following git’s guide on setting up a server plus some specific stuff for (btw i use) Arch Linux (Arch Linux Wiki: Git server and Step by step guide on setting up git server in arch linux (pushable)).

Note that this is mostly for personal use, so there’s no user/authentication control other than that of SSH. Also, most if not all commands here are run as root.

Prerequisites

I might get tired of saying this (it’s just copy paste, basically)… but similar as before (check my website and mail entries):

I might get tired of saying this (it’s just copy paste, basically)… but you will need the same prerequisites as before (check my website and mail entries), with the extras:

(This time, optional) A domain name if you want to have a “front end” to show your repositories. Got mine on Epik (affiliate link, btw).
- With a CNAME for “git” and (optionally) “www.git”, or some other name for your sub-domains.
- (Optional, if you want a “front-end”) A CNAME for “git” and (optionally) “www.git”, or some other name for your sub-domains.
- An SSL certificate, if you’re following the other entries, add a git.conf and run certbot --nginx to extend the certificate.
-
A VPS or somewhere else to host. I’m using Vultr (also an affiliate link).
- ssh configured.
- (Optionally, if doing the domain name thingy) With nginx and certbot setup and running.
- Of course, git already installed (it should be a must have always).
-

git server

Git

Git is a version control system.

If not installed already, install the git package:

pacman -S git

@@ -125,14 +118,15 @@ ExecStart=-/usr/lib/git-core/git-daemon --inetd --export-all --base-path=/home/g

systemctl start git-daemon.socket
 systemctl enable git-daemon.socket

mkdir {repo_name}.git
-cd {repo_name}.git
+You’re basically done. Now you should be able to push/pull repositories to your server… except, you haven’t created any repository in your server, that’s right, they’re not created automatically when trying to push. To do so, you have to run (while inside /home/git):
+git init --bare {repo_name}.git
+chown -R git:git repo_name.git
 
 Those two lines above will need to be run each time you want to add a new repository to your server (yeah, kinda lame… although there are options to “automate” this, I like it this way).
-After that you can already push/pull to your repository. I have my repositories (locally) set up so I can push to more than one remote at the same time (my server, GitHub, GitLab, etc.), which is detailed here.
-cgit
-This bit is optional if you only wanted a git server (really easy to set up), this is so you can have a web application. This is basically a copy paste of Arch Linux Wiki: Cgit so you can go there and get more in-depth configurations.
+After that you can already push/pull to your repository. I have my repositories (locally) set up so I can push to more than one remote at the same time (my server, GitHub, GitLab, etc.); to do so, check this gist.
+Cgit
+Cgit is a fast web interface for git.
+This is optionally since it’s only for the web application.
 Install the cgit and fcgiwrap packages:
 pacman -S cgit fcgiwrap
 
@@ -140,7 +134,7 @@ cd {repo_name}.git
 systemctl start fcgiwrap.socket
 systemctl enable fcgiwrap.socket
 
-Next, the way I configure nginx is creating a separate file {module}.conf (git.conf in this case) under /etc/nginx/sites-available and create a symlink to /etc/nginx/sites-enabled as stated in my nginx setup entry. Add the following lines to your git.conf file:
+Next, create the git.conf as stated in my nginx setup entry. Add the following lines to your git.conf file:
 server {
     listen 80;
     listen [::]:80;
@@ -161,7 +155,6 @@ systemctl enable fcgiwrap.socket
 Where the server_name line depends on you, I have mine setup to git.luevano.xyz and www.git.luevano.xyz. Optionally run certbot --nginx to get a certificate for those domains if you don’t have already.
 Now, all that’s left is to configure cgit. Create the configuration file /etc/cgitrc with the following content (my personal options, pretty much the default):
 css=/cgit.css
-source-filter=/usr/lib/cgit/filters/syntax-highlighting-edited.sh
 logo=/cgit.png
 
 enable-http-clone=1
@@ -183,8 +176,26 @@ repo.owner=luevano
 repo.desc=These are my personal dotfiles.
 ...
 
-Otherwise you could let cgit to automatically detect your repositories (you have to be careful if you want to keep “private” repos) using the option scan-path and setup .git/description for each repository. I will add more to my actual configuration, but for now it is useful as it is. For more, you can check cgitrc(5).
-Finally, if you want further support for highlighting, other compressed snapshots or support for markdown, checkout the optional dependencies for cgit and also the Arch Wiki goes in detail on how to setup highlighting with two different packages.]]>
+Otherwise you could let cgit to automatically detect your repositories (you have to be careful if you want to keep “private” repos) using the option scan-path and setup .git/description for each repository. For more, you can check cgitrc(5).
+By default you can’t see the files on the site, you need a highlighter to render the files, I use highlight. Install the highlight package:
+pacman -S highlight
+
+Copy the syntax-highlighting.sh script to the corresponding location (basically adding -edited to the file):
+cp /usr/lib/cgit/filters/syntax-highlighting.sh /usr/lib/cgit/filters/syntax-highlighting-edited.sh
+
+And edit it to use the version 3 and add --inline-css for more options without editing cgit‘s CSS file:
+...
+# This is for version 2
+# exec highlight --force -f -I -X -S "$EXTENSION" 2>/dev/null
+
+# This is for version 3
+exec highlight --force --inline-css -f -I -O xhtml -S "$EXTENSION" 2>/dev/null
+...
+
+Finally, enable the filter in /etc/cgitrc configuration:
+source-filter=/usr/lib/cgit/filters/syntax-highlighting-edited.sh
+
+That would be everything. If you need support for more stuff like compressed snapshots or support for markdown, check the optional dependencies for cgit.]]>
     
     
       Create a mail server with Postfix, Dovecot, SpamAssassin and OpenDKIM
@@ -197,25 +208,16 @@ repo.desc=These are my personal dotfiles.
       Tutorial
       How to create mail server using Postfix, Dovecot, SpamAssassin and OpenDKIM. This is a follow up on post about creating a website with Nginx and Certbot.
       The entry is going to be long because it’s a tedious process. This is also based on Luke Smith’s script, but adapted to Arch Linux (his script works on debian-based distributions). This entry is mostly so I can record all the notes required while I’m in the process of installing/configuring the mail server on a new VPS of mine; also I’m going to be writing a script that does everything in one go (for Arch Linux), that will be hosted here.
-This configuration works for local users (users that appear in /etc/passwd), and does not use any type of SQL. And note that most if not all commands executed here are run with root privileges.
-More in depth configuration is detailed in the Arch Wiki for each package used here.
+This configuration works for local users (users that appear in /etc/passwd), and does not use any type of SQL Database. And note that most if not all commands executed here are run with root privileges.
 Prerequisites
-Basically the same as with the website with Nginx and Certbot:
+Basically the same as with the website with Nginx and Certbot, with the extras:
 
-A domain name. Got mine on Epik (affiliate link, btw).
-Later we’ll be adding some MX  and TXT records.
-You also need a CNAME for “mail” and (optionally) “www.mail”, or whatever you want to call the sub-domains (although the RFC 2181 states that it NEEDS to be an A record, fuck the police), to actually work and to get SSL certificate (you can also use the SSL certificate obtained if you created a website following my other notes on nginx and certbot) with certbot (just create a mail.conf for nginx, similar to how we created it in the website entry).
-
-
-A VPS or somewhere else to host. I’m using Vultr (also an affiliate link).
-ssh configured.
-Ports 25, 587 (SMTP), 465 (SMTPS), 143 (IMAP) and 993 (IMAPS) open on the firewall (I use ufw).
-With nginx and certbot setup and running.
-
-
+You will need a CNAME for “mail” and (optionally) “www.mail”, or whatever you want to call the sub-domains (although the RFC 2181 states that it NEEDS to be an A record, fuck the police).
+An SSL certificate. You can use the SSL certificate obtained following my last post using certbot (just create a mail.conf and run certbot --nginx again).
+Ports 25, 587 (SMTP), 465 (SMTPS), 143 (IMAP) and 993 (IMAPS) open on the firewall.
 
 Postfix
-Postfix is a “mail transfer agent” which is the component of the mail server that receives and sends emails via SMTP.
+Postfix is a “mail transfer agent” which is the component of the mail server that receives and sends emails via SMTP.
 Install the postfix package:
 pacman -S postfix
 
@@ -251,7 +253,7 @@ smtpd_sasl_path = private/auth
 smtpd_sasl_security_options = noanonymous, noplaintext
 smtpd_sasl_tls_security_options = noanonymous
 
-Specify the mailbox home (this is going to be a directory inside your user’s home):
+Specify the mailbox home (this is going to be a directory inside your user’s home containing the actual mail files):
 home_mailbox = Mail/Inbox/
 
 Pre-configuration to work seamlessly with dovecot and opendkim:
@@ -295,7 +297,7 @@ spamassassin unix - n n - - pipe
 smtps 465/tcp
 smtps 465/udp
 
-Before starting the postfix service, you need to run newaliases first (but you can do a bit of configuration beforehand). Edit the file /etc/postfix/aliases and edit accordingly. I only change the root: you line (where you is the account that will be receiving “root” mail). Check the Arch Wiki for more info and other alternatives/options. After you’re done, run:
+Before starting the postfix service, you need to run newaliases first, but you can do a bit of configuration beforehand editing the file /etc/postfix/aliases. I only change the root: you line (where you is the account that will be receiving “root” mail). After you’re done, run:
 postalias /etc/postfix/aliases
 newaliases
 
@@ -304,7 +306,7 @@ newaliases
 systemctl enable postfix.service

Dovecot

Dovecot is an IMAP and POP3 server, which is what lets an email application retrieve the mail.

Install the dovecot and pigeonhole (sieve for dovecot) packages:

pacman -S dovecot pigeonhole

@@ -313,8 +315,8 @@ systemctl enable postfix.service cp /usr/share/doc/dovecot/example-config/dovecot.conf /etc/dovecot/dovecot.conf cp -r /usr/share/doc/dovecot/example-config/conf.d /etc/dovecot -

As Luke stated, dovecot comes with a lot of “modules” (under /etc/dovecot/conf.d/ if you copied that folder) for all sorts of configurations that you can include, but I do as he does and just edit/create the whole dovecot.conf file; although, I would like to check each of the separate configuration files dovecot provides I think the options Luke provides are more than good enough.

ssl = required
 ssl_cert = <{yourcertdir}/fullchain.pem
 ssl_key = <{yourcertdir}/privkey.pem
@@ -378,7 +380,7 @@ namespace inbox {
         }
 }

Lastly (for dovecot at least), the plugin configuration for sieve (pigeonhole):

Lastly (for Dovecot at least), the plugin configuration for sieve (pigeonhole):

protocol lda {
     mail_plugins = $mail_plugins sieve
 }
@@ -406,20 +408,20 @@ if header :contains "X-Spam-Flag" "YES" {
 grep -q "^vmail:" /etc/passwd || useradd -m vmail -s /usr/bin/nologin
 chown -R vmail:vmail /var/lib/dovecot
 
-Note that I also changed the shell for vmail to be /usr/bin/nologin. After that, run:
+Note that I also changed the shell for vmail to be /usr/bin/nologin. After that, to compile the configuration file run:
 sievec /var/lib/dovecot/sieve/default.sieve
 
-To compile the configuration file (a default.svbin file will be created next to default.sieve).
+A default.svbin file will be created next to default.sieve.
 Next, add the following lines to /etc/pam.d/dovecot if not already present (shouldn’t be there if you’ve been following these notes):
 auth required pam_unix.so nullok
 account required pam_unix.so
 
-That’s it for dovecot, at this point you can start/enable the dovecot service:
+That’s it for Dovecot, at this point you can start/enable the dovecot service:
 systemctl start dovecot.service
 systemctl enable dovecot.service
 
 OpenDKIM
-OpenDKIM is needed so services like G**gle (we don’t mention that name here [[[this is a meme]]]) don’t throw the mail to the trash. DKIM stands for “DomainKeys Identified Mail”.
+OpenDKIM is needed so services like G**gle (we don’t mention that name here [[[this is a meme]]]) don’t throw the mail to the trash. DKIM stands for “DomainKeys Identified Mail”.
 Install the opendkim package:
 pacman -S opendkim
 
@@ -448,7 +450,7 @@ localhost
 ...

And more, make sure to include your server IP and something like subdomain.domainname.

Domain {yourdomain}
 Selector {yoursubdomain}
 
@@ -463,7 +465,7 @@ Socket inet:8891@localhost
 chmod g+r /etc/postfix/dkim/*

That’s it for the general configuration, but you could go more in depth and be more secure with some extra configuration as described in the Arch Wiki entry for OpenDKIM.

That’s it for the general configuration, but you could go more in depth and be more secure with some extra configuration.

Now, just start/enable the opendkim service:

systemctl start opendkim.service
 systemctl enable opendkim.service
@@ -485,9 +487,9 @@ systemctl enable opendkim.service
 SPF entry: just @ as the “Host” and "v=spf1 mx a:{yoursubdomain}.{yourdomain} - all" as the “TXT Value”.


 
-And at this point you could test your mail for spoofing and more, but you don’t know -yet- how to login (it’s really easy, but I’m gonna state that at the end of this entry).
+And at this point you could test your mail for spoofing and more.
 SpamAssassin
-SpamAssassin is just a mail filter to identify spam.
+SpamAssassin is just a mail filter to identify spam.
 Install the spamassassin package (which will install a bunch of ugly perl packages…):
 pacman -S spamassassin
 
@@ -540,7 +542,7 @@ ExecStart=/usr/bin/vendor_perl/spamd -x -u spamd -g spamd --listen=/run/spamd/sp
 systemctl enable spamassassin.service

Wrapping up

We should have a working mail server by now. Before continuing check your journal logs (journalctl -xe --unit={unit}, where {unit} could be spamassassin.service for example) to see if there was any error whatsoever and try to debug it, it should be a typo somewhere (the logs are generally really descriptive) because all the settings and steps detailed here just (literally just finished doing everything on a new server as of the writing of this text) worked (((it just werks on my machine))).

Password: your user password (as in the password you use to login to the server with that user)

DKIM Test successful

(Yes, I blurred a lot in the picture just to be sure, either way what’s important is the list on the bottom part of the image)

Finally, that’s actually it for this entry, if you have any problem whatsoever you have my info down below.

Finally, that’s actually it for this entry, if you have any problem whatsoever you can contact me.

Create a website with Nginx and Certbot @@ -586,14 +590,18 @@ systemctl enable spamassassin.service

Nginx

Nginx is a web (HTTP) server and reverse proxy server.

pacman -S nginx-mainline
 systemctl enable nginx.service
 systemctl start nginx.service

And that’s it, at this point you can already look at the default initial page of nginx if you enter the ip of your server in a web browser. You should see something like this:

Nginx welcome page

As stated in the welcome page, configuration is needed, head to the directory of nginx:

And that’s it, at this point you can already look at the default initial page of Nginx if you enter the IP of your server in a web browser. You should see something like this:

As stated in the welcome page, configuration is needed, head to the directory of Nginx:

cd /etc/nginx

@@ -616,7 +624,7 @@ http { types_hash_max_size 4096; } -

Next, inside the directory /etc/nginx/ create the sites-available and sites-enabled, and go into the sites-available one:

Next, inside the directory /etc/nginx/ create the sites-available and sites-enabled directories, and go into the sites-available one:

mkdir sites-available
 mkdir sites-enabled
 cd sites-available
@@ -635,28 +643,32 @@ cd sites-available
     }
 }

Note several things:

That could serve as a template if you intend to add more domains.

Note some things:

listen: we’re telling nginx which port to listen to (ipv4 and ipv6, respectively).
listen: we’re telling Nginx which port to listen to (IPv4 and IPv6, respectively).
root: the root directory of where the website files (.html, .css, .js, etc. files) are located. I followed Luke’s directory path /var/www/some_folder.
server_name: the actual domain to “listen” to (for my website it is: server_name luevano.xyz www.luevano.xyz; and for this blog is: server_name blog.luevano.xyz www.blog.luevano.xyz).
server_name: the actual domain to “listen” to (for my website it is: server_name luevano.xyz www.luevano.xyz; and for this blog is: server_name blog.luevano.xyz www.blog.luevano.xyz;).
index: what file to serve as the index (could be any .html, .htm, .php, etc. file) when just entering the website.
location: used in case of different configurations across different URL paths.
- try_files: tells what files to look for, don’t look into this too much for now.
- location: what goes after domain.name, used in case of different configurations depending on the URL paths (deny access on /private, make a proxy on /proxy, etc).
  - try_files: tells what files to look for.
-
Then, make a symbolic from this config file to the sites-enabled directory:
+
Then, make a symbolic link from this configuration file to the sites-enabled directory:
```
ln -s /etc/nginx/sites-available/your_config_file.conf /etc/nginx/sites-enabled
 
```
-
This is so the nginx.conf file can look up the newly created server config. With this method of having each server configuration file separate you can easily “deactivate” any website by just deleting the symbolic link in sites-enabled and you’re good, or just add new configuration files and keep everything nice and tidy.
-
All you have to do now is restart (or enable and start if you haven’t already) the nginx service (and optionally test the configuration):
+
This is so the nginx.conf file can look up the newly created server configuration. With this method of having each server configuration file separate you can easily “deactivate” any website by just deleting the symbolic link in sites-enabled and you’re good, or just add new configuration files and keep everything nice and tidy.
+
All you have to do now is restart (or enable and start if you haven’t already) the Nginx service (and optionally test the configuration):
```
nginx -t
 systemctl restart nginx
 
```
-
If everything goes correctly, you can now go to your website by typing “domain.name” on a web browser. But you will see a “404 Not Found” page like the following (maybe with different nginx version):
-
-
That’s no problem, because it means that the web server it’s actually working. Just add an index.html file with something simple to see it in action. If you keep seeing the 404 page make sure your root line is correct and that the directory/index file exists.
+
If everything goes correctly, you can now go to your website by typing domain.name on a web browser. But you will see a “404 Not Found” page like the following (maybe with different Nginx version):
+
+ +
Nginx 404 Not Found page
+
+
That’s no problem, because it means that the web server it’s actually working. Just add an index.html file with something simple to see it in action (in the /var/www/some_folder that you decided upon). If you keep seeing the 404 page make sure your root line is correct and that the directory/index file exists.

I like to remove the .html and trailing / on the URLs of my website, for that you need to add the following rewrite lines and modify the try_files line (for more: Sean C. Davis: Remove HTML Extension And Trailing Slash In Nginx Config):
```
server {
     ...
@@ -666,20 +678,19 @@ systemctl restart nginx
     try_files $uri/index.html $uri.html $uri/ $uri =404;
     ...
 
```
-
For more: Arch Linux Wiki: nginx.

Certbot
-
The only “bad” (bloated) thing about certbot, is that it uses python, but for me it doesn’t matter too much. You may want to look up another alternative if you prefer. Install the packages certbot and certbot-nginx:
+
Certbot is what provides the SSL certificates via Let’s Encrypt.
+
The only “bad” (bloated) thing about Certbot, is that it uses python, but for me it doesn’t matter too much. You may want to look up another alternative if you prefer. Install the packages certbot and certbot-nginx:
```
pacman -S certbot certbot-nginx
 
```
After that, all you have to do now is run certbot and follow the instructions given by the tool:
```
certbot --nginx
 
```
-
It will ask you for some information, for you to accept some agreements and the names to activate https for. Also, you will want to “say yes” to the redirection from http to https. And that’s it, you can now go to your website and see that you have https active.
+
It will ask you for some information, for you to accept some agreements and the names to activate HTTPS for. Also, you will want to “say yes” to the redirection from HTTP to HTTPS. And that’s it, you can now go to your website and see that you have HTTPS active.

Now, the certificate given by certbot expires every 3 months or something like that, so you want to renew this certificate every once in a while. Using cron, you can do this by running:
```
crontab -e
 
```
-
And a file will be opened where you need to add a new rule for certbot, just append the line: 1 1 1 * * certbot renew (renew on the first day of every month) and you’re good. Alternatively use systemd timers as stated in the Arch Linux Wiki.
-
For more: Arch Linux Wiki: Certbot.
+
And a file will be opened where you need to add a new rule for Certbot, just append the line: 1 1 1 * * certbot renew (renew on the first day of every month) and you’re good. Alternatively use systemd timers as stated in the Arch Linux Wiki.

That’s it, you now have a website with SSL certificate.
]]> diff --git a/blog/dst/sitemap.xml b/blog/dst/sitemap.xml index bf22510..40b3af4 100644 --- a/blog/dst/sitemap.xml +++ b/blog/dst/sitemap.xml @@ -22,19 +22,19 @@ https://blog.luevano.xyz/a/git_server_with_cgit.html - 2021-06-04 + 2021-06-08 weekly 1.0 https://blog.luevano.xyz/a/mail_server_with_postfix.html - 2021-06-06 + 2021-06-08 weekly 1.0 https://blog.luevano.xyz/a/website_with_nginx.html - 2021-06-06 + 2021-06-08 weekly 1.0 @@ -53,43 +53,43 @@ https://blog.luevano.xyz/tag/@english.html - 2021-06-06 + 2021-06-08 daily 0.5 https://blog.luevano.xyz/tag/@server.html - 2021-06-06 + 2021-06-08 daily 0.5 https://blog.luevano.xyz/tag/@short.html - 2021-06-06 + 2021-06-08 daily 0.5 https://blog.luevano.xyz/tag/@spanish.html - 2021-06-06 + 2021-06-08 daily 0.5 https://blog.luevano.xyz/tag/@tools.html - 2021-06-06 + 2021-06-08 daily 0.5 https://blog.luevano.xyz/tag/@tutorial.html - 2021-06-06 + 2021-06-08 daily 0.5 https://blog.luevano.xyz/tag/@update.html - 2021-06-06 + 2021-06-08 daily 0.5 -- cgit v1.2.3-70-g09d2