Wiki source code of Configuring a VPS machine from scratch

Version 10.1 by Alexandru Pentilescu on 2024/07/22 21:05

version	line-number	content
1.1	1	(% class="jumbotron" %)
	2	(((
	3	(% class="container" %)
	4	(((
	5	= Starting out =
	6	When starting with a clean linux VPS, the first thing you must ensure is that you have access to the root account (either that or are part of the sudoers file in such a way that you can make administrative changes to your system). If you don't have these access rights on the target system, you must first contact the administrator of this system and ask them for such priviliges. Otherwise, this article will be of no use to you.
	7
	8	)))
	9	)))
	10
4.2	11	(% class="col-xs-12 col-sm-4" %)
	12	(((
	13	{{box title="Contents"}}{{toc /}}{{/box}}
	14	)))
	15
1.1	16	(% class="row" %)
	17	(((
	18	(% class="col-xs-12 col-sm-8" %)
	19	(((
	20	= Creating a new user =
	21
	22	If you don't have an active user just yet, please do the following:
	23
	24	{{code language="bash"}}
3.1	25	sudo adduser <newuser>
1.1	26	{{/code}}
	27
3.1	28	Please replace <newuser> with your username.
1.1	29	Then, to make them part of the sudoers file, just do:
	30
	31	{{code language="bash"}}
3.1	32	sudo usermod -aG sudo <newuser>
1.1	33	{{/code}}
	34
3.2	35	== Using root vs. using a sudoers user ==
1.1	36
3.2	37	There's an argument to be made between just logging in as root on the system directly or using a separate users which is part of the sudoers file.
	38	Both are viable options for administrators to make configuration changes on the target system.
	39	Some people argue that adding other users to a system is just adding complexity and, especially if you plan to be the sole administrator of the VPS, it makes little sense not to use the already built-in root user. After all, root starts out with all the priviliges and, most importantly, you'll never have to remember to keep invoking "sudo" whenever you need to run administrative commands in the terminal. Because of this, this is seen as the superior approach.
1.1	40
3.2	41	However, others make the argument that constantly running as root is a security risk for the system as a whole. When running as root, any terminal command issued will also run with absolute privileges, which runs the risk of amplifying any human error to disastruous proportions.
	42	Granted, this risk also exists for sudoers users too, but only with the commands which are ran with "sudo". Having the extra step of manually prefixing each command with "sudo" is seen as a preventative measure of avoiding system damage.
	43	Moreover, if the administrator is diligent, they may retroactively change the sudoers users' permissions manually to only allow privilege escalation for commands which they deem safe to run, effectively blocking any risk for overly dangerous commands such as "dd" or "rm -Rf".
1.1	44
3.2	45	Ultimately, the argument for or against using root access is mostly a philosophical one, rather than a technical one. There is no right or wrong answer to this question. Rather, each answer brings its own advantages and disadvantages to the table. What really matters is what you're more comfortable with using in the end.
	46	Moreover, using a sudoers user rather than root is not inherently a guarantee for system safety either and should not be taken as a leeway for running suspicious executable files from the internet either, as privilege escalation bugs have existed in the Linux kernel since its own inception.
1.1	47
8.1	48	= Install the necessary utilities =
	49	Install docker, postfix and nginx, which are all utilities you will be using consistently, from this point on.
	50
	51	Afterwards, install the certbot-plugin-gandi plugin to enable automatic certificate renewals using gandi. This may require you to install pip3 as well, first.
	52
	53	One the plugin is installed, just do:
	54
	55	{{code language="bash"}}
	56	certbot certonly --authenticator dns-gandi --dns-gandi-credentials /etc/letsencrypt/gandi/gandi.ini -n -d 'transistor.one,*.transistor.one' --agree-tos --email=alexandru.pentilescu@disroot.org
	57	{{/code}}
	58
9.1	59	The contents of /etc/lets/encrypt/gandi/gandi.ini should look like the following:
	60	# live dns v5 api key
	61	dns_gandi_api_key=<gandi_api_key>
	62
	63	The <gandi_api_key> token should be replaced with the actual API key generated from the Gandi website for your account.
	64
4.3	65	= Setting up an SMTP server =
	66	This will be required for all the future things you will be doing on the server.
	67
7.1	68	Moreover, this is not an easy task and will be a little time consuming. Please consult the documentation [[here>>https://wiki.transistor.one/bin/view/Guides/How%20to%20setup%20a%20postfix%20SMTP%20server/]]
4.4	69
3.2	70	= Setting up automatic updates =
1.1	71
3.2	72	System updates are a necessity for modern day operating systems and on linux, especially, there's a constant need to run such updates regurarly to avoid the risk of running vulnerable software that can be exploited by rogue malware.
1.1	73
3.2	74	Linux, in particular, is an attractive target for malware writers in recent years, due to the fact that corporate servers owned by renowned companies are seen as a more profitable compromise target for malicious actors who may wish to extort money from unpatched systems.
1.1	75
3.2	76	After all, large corporations running unpatched systems are more likely to pay significant amounts of money than lone private users if their systems were to be compromised.
1.1	77
3.2	78	As such, it's imperative to protect our systems from such damage by preventing the attacks in the first place. The first step in achieving this goal is by constantly patching the system. And a good way to do this without requiring manual intervention is setting up automatic updates.
1.1	79
3.2	80	Debian based systems have an official package known as unattended-upgrades which can do just this. To install this package, please run the following command:
	81
	82	{{code language="bash"}}
	83	sudo apt-get install unattended-upgrades
	84	{{/code}}
	85
	86	This will install the package from the official repositories. After this, the package should be configurable to the administrator by editing the /etc/apt/apt.conf.d/50unattended-upgrades file. This file should be generated automatically after installing the package.
	87
	88	There's a lot of stuff which can be configured in this file. Some of the options which I personally prefer to activate by uncommenting are the following:
	89
	90	{{code language="none"}}
	91
	92	// This option controls whether the development release of Ubuntu will be
	93	// upgraded automatically. Valid values are "true", "false", and "auto".
	94	Unattended-Upgrade::DevRelease "auto";
	95
	96	// Send email to this address for problems or packages upgrades
	97	// If empty or unset then no email is sent, make sure that you
	98	// have a working mail setup on your system. A package that provides
	99	// 'mailx' must be installed. E.g. "user@example.com"
	100	Unattended-Upgrade::Mail "Alexandru.Pentilescu@disroot.org";
	101	{{/code}}
	102
	103	This lets the system know that I want for email notifications with respect to updates need to be delivered to that specific email address. This is important because, every time updates occur, this lets me know via email. Of course, you need to have an SMTP server running locally, as described in the previous step.
	104
	105	Then:
	106
	107	{{code language="none"}}
	108	// Remove unused automatically installed kernel-related packages
	109	// (kernel images, kernel headers and kernel version locked tools).
	110	Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
	111
	112	// Do automatic removal of newly unused dependencies after the upgrade
	113	Unattended-Upgrade::Remove-New-Unused-Dependencies "true";
	114	{{/code}}
	115
	116	These configuration options will instruct the package to remove obsolete files which become stale as updates come in.
	117
	118	{{code language="none"}}
	119	// Automatically reboot WITHOUT CONFIRMATION if
	120	// the file /var/run/reboot-required is found after the upgrade
	121	Unattended-Upgrade::Automatic-Reboot "true";
	122	{{/code}}
	123
	124	This will instruct the package to automatically reboot the system. This is necessary after specific kernel updates are installed that need to be installed in memory and replace the old ones.
	125
	126	Finally:
	127
	128	{{code language="none"}}
	129	// If automatic reboot is enabled and needed, reboot at the specific
	130	// time instead of immediately
	131	// Default: "now"
	132	Unattended-Upgrade::Automatic-Reboot-Time "02:00";
	133	{{/code}}
	134
	135	This instructs the package to reboot the whole system, automatically, whenever an update requires it, the next time the system clock reaches this specific configured time. I set mine to reboot the system, whenever an update requires it, at 2AM. You may change the time to whichever fits your needs.
	136
5.1	137	= Installing docker =
1.1	138
5.1	139	Docker is almost an irreplaceable piece of software that will be critical to your whole infrastructure. Docker needs to be installed on the system properly. In order to do so, please follow the guide [[here>>https://docs.docker.com/engine/install/ubuntu/]]
	140
6.1	141	= Force postfix to bind to non-local IP addresses on start =
	142
	143	If we plan on using our SMPT server to relay emails coming from our docker containers, we will have to force postfix to bind to an IP address that's different from localhost. This needs to be done because, if we configure postfix to only bind to localhost, it will effectively be unreachable to our docker containers and they will not be able to use it as a relay.
	144	In order to allow for postfix to bind to non-local addresses, we have to add the following configuration file /etc/sysctl.d/80-network.conf with the following contents:
	145
	146	{{code language="ini"}}
	147	net.ipv4.ip_nonlocal_bind = 1
	148	net.ipv6.ip_nonlocal_bind = 1
	149	{{/code}}
	150
	151	Honestly, the "ipv6" line is unnecessary for our purposes, but I'm adding it anyway. After this file is added, after reboot, postfix will be able to bind itself to nonlocal addresses successfully.
10.1	152
	153	= Installing Grafana and all the other necessary components =
	154	System monitoring is genuinely important. As such, having some pretty graphs to look at that monitor various stats of the server can be quite useful.
	155	To this end, we will set up Grafana as our graphs dashboard where we will visualize all of the relevant metrics of the system, as well as Prometheus as the data aggregator and Node Exporter, as the data collector.
	156
	157	Let's get started!
	158
	159	== Installing node exporter ==
	160	Use wget or any other utility to grab the latest version of node exporter.
	161
	162	{{code language="bash"}}
	163	wget https://github.com/prometheus/node_exporter/releases/download/v0.15.2/node_exporter-0.15.2.linux-amd64.tar.gz
	164	{{/code}}
	165
1.1	166	)))
10.1	167
	168
	169