I. Before We Start

We need to obtain our basic network configuration from our provider. Or, if we are running our own host node, we need to assign basic network configuration to ourselves. Our basic network configuration might look something like this:

For IPv6, one might expect something like:

But occasionally, IPv6 could be something like:

Notes:

• The /28 in the IPv4 address and the longer netmask are different ways of providing the same information about the size of the local, directly connected network. It suffices for us to have this information in one format or the other. We don't need both formats because the information is the same. Also, the broadcast IP might not be provided, since it isn't strictly necessary.
• For the second format of the IPv6 address, what happened to the /64? 😱 The /128 in the second form of the IPv6 address might seem clueless to IPv6 fans expecting a /64. Also, the second format of the IPv6 address includes a gateway6 address. The gateway6 address might seem strange to some IPv6 fans, but we need the gateway6 for our minimal, static configuration. More on all this below.

II. Introduction

In the previous post of this series we finished using the Proxmox web GUI to install our new Debian KVM VPS via the Debian netinst installer iso image. The final step in Part II was removing the netinst install iso image from the emulated cdrom and then reooting our new VM, which came up from its own internal filesystem:

In today's post, we continue from this exact place where we left Part II -- connected to our newly installed and newly rebooted KVM via the Proxmox web GUI. In this post, we will accomplish the networking configuration which was skipped in Part II because the Debian netinst iso doesn't automatically configure out of band IP addresses.

There are three network configuration and related tasks we will accomplish today:

• First, we go "inside" our VM through the Proxmox web GUI's emulated "physical" console connection and set up networking. In Debian, networking setup requires that we adjust the file /etc/network/interfaces to tell our VM its network address and the address of its gateway to the internet.
• Second, we edit the file /etc/resolv.conf to tell our VM the numerical addresses of Domain Name System ("DNS") servers it can use to translate human readable Uniform Resource Identifiers (URI) into numerical Internet Protocaol ("IP") addresses.
• Third, we set up /etc/apt/sources.list to tell our system's Aptitude software package manager ("APT") where to get software updates and the additional software packages we will want to install.

Section III, Quick Setup, runs quickly through all three of today's tasks in "recipe style."

Section IV offers additional context on our setup environment.

Sections V, VI, and VII provide additional details on today's three setup tasks.

Section VIII discusses security.

Section IX discusses backup.

When we finish the Quick Setup, our new Debian KVM VPS should be connected to the internet, DNS should work, and we should be able to use the Debian package system to add whatever additional software we want.

When we finish all of today's post, we should have reasonable context within which to understand our Debian VM's networking setup.

III. Quick Setup

Logged into our VM through the Proxmox web GUI, we run the command ip link show. This command will give us the name of our network interface, probably something like "ens18."

As root or with sudo, we edit the text of the file /etc/network/interfaces so that it contains the minimum necessary information:

auto ens18
iface ens18 inet static
  address IPv4_ADDRESS/CIDR
  gateway GATEWAY_ADDRESS

iface ens18 inet6 static
  address IPv6_ADDRESS/CIDR
  gateway GATEWAY6_ADDRESS

Using our example network configuration, our minimal /etc/network/interfaces looks like this:

auto ens18
iface ens18 inet static
  address 172.16.165.97/28
  gateway 172.16.164.1

iface ens18 inet6 static
  address fe80:xxxx:xxxx:xxxx::97/128
  gateway fe80:xxxx:xxxx:xxxx::3

Second, we edit the /etc/resolv.conf file so that it looks like this:

nameserver 1.1.1.1
nameserver 8.8.8.8
nameserver 2606:4700:4700::1111
nameserver 2001:4860:4860::8888

Third, we edit /etc/apt/sources.list so that it looks like this:

deb http://deb.debian.org/debian buster main contrib non-free

deb http://deb.debian.org/debian-security/ buster/updates main contrib non-free

deb http://deb.debian.org/debian buster-updates main contrib non-free

Finally, we restart networking so that our new configuration takes effect:

systemctl restart networking

At this point, we should have both IPv4 and IPv6 connectivity, and DNS and APT both should work.

IV. More Context

• Virtualized Console Connection

The Proxmox web GUI virtualizes a wired console connection. In other words, our web browser does connect over the internet to our Proxmox server, but, the view from inside our new KVM is the same as though a wired connection was attached. Our new KVM thinks it's talking over a wired connection to a physical console. From inside our new KVM, there is, as yet, no network connection.

By default, the Proxmox web GUI works via VNC. In the Proxmox wiki on serial terminal Proxmox warns that VNC might

not have the features you need (i.e. easy copy/paste between other terminals)

or it might be

impossible to capture all [kernel messages, standard output, or error] messages on [the] VNC screen.

Yep, copy / paste commands do not seem to work in the Proxmox KVM virtual console.

Also, if you enjoy using the vi editor, you might find what looks like a "Send-Esc" button among the set of choices within the set exposed by the top button on the console VNC control bar. Use of the real keyboard Escape key results in exiting full screen. However, a second real Esc seems to produce the expected mode change, despite that maybe we no longer can see too well without returning to full screen.

• No DHCP, No SLAAC

These days most network setups use Dynamic Host Configuration Protocol (DHCP) to autoconfigure IPv4 networking. The machine on which networking is to be configured asks for and receives from a DHCP server all the needed information for the networking setup.

It is possible to configure DHCP so that it always returns the same IP address to each VM, but, since our entire Proxmox network is static, it may be simpler to set up networking manually--the traditional way for servers.

Stateless Address Autoconfiguration ("SLAAC") provides automatic configuration of IPv6 addresses. SLAAC requires a /64, which is why people say, for IPv6, that a /64 is expected and that less than a /64 is clueless. However, it remains possible to hand configure a single static IPv6 address, as we are doing here.

What if, for whatever reason, we simply do not want to use SLAAC? What if our provider doesn't receive enough IPv6 addresses from his provider to allow passing on to each VPS its own /64? What if our provider's provider charges an extra fee for extra IPv6 addresses, but we do not want to pay our provider's pass through of his provider's extra fee? What if we simply choose to use single, static IPs as is traditional for servers?

• No Cloud-Init

As mentioned in the previous post of this series, most VM network setups these days are done with Cloud-Init. Proxmox supports Cloud-Init, which enables both networking and ssh access to virtual machines to be set up on the Proxmox hypervisor and outside of the VM. Cloud-init can use DHCP. Here, however, we have chosen the simplest possible manual configuration with static IPs.

• Our Static, Routed Configuration And Out of Band Gateway From Our Provider's Provider

Here, our single, static IPv4 and single, static IPv6 are each derived from a routed subnet assigned to our server node. However, our internet gateway IPv4 address is not included among our server's routed group of IPv4s. This is called an "out of band" gateway.

Besides routed subnets, it also is possible for a datacenter to assign to servers non-routed, individual IP addresses. Data for these non-routed IPs moves between the datacenter switch and server nodes via the "link layer." Hetzner has a tutorial on Debian network configuration which includes discussion of "bridged configuration" for non-routed IPs.

• Systemd in Debian Networking

Since about 2014, networking is setup on Debian with systemd. The choice of systemd initially was and has continued to be divisive. Nevertheless systemd has remained as the Debian default.

There are at least two basic variations of Debian's systemd network arrangement. The first--which seems to be the default variation for Debian systemd network configuration--at least with the netinst iso--is using systemd's networking.service. For example, by using systemctl, we can confirm that networking.service is what is being used on our Node:

root@Proxmox-VE ~ # systemctl status networking.service
● networking.service - Raise network interfaces
   Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: 
   Active: active (exited) since Wed 2021-06-02 19:13:13 UTC; 1 weeks 2 days ago
     Docs: man:interfaces(5)
 Main PID: 791 (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 4915)
   Memory: 0B
   CGroup: /system.slice/networking.service

 [ . . . ]
root@Proxmox-VE ~ # 

Our test KVM also seems to think its networking is controlled by systemd:

root@debian-kvm:~# systemctl status networking
● networking.service - Raise network interfaces
   Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
   Active: active (exited) since Wed 2021-06-16 01:20:45 UTC; 4min 51s ago
     Docs: man:interfaces(5)
  Process: 448 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=0/SUCCESS)
 Main PID: 448 (code=exited, status=0/SUCCESS)

Jun 16 01:20:45 debian-kvm systemd[1]: Starting Raise network interfaces...
Jun 16 01:20:45 debian-kvm systemd[1]: Started Raise network interfaces.
root@debian-kvm:~#

As we can see, systemd networking.service calls the traditional debian ifup and ifdown.

root@debian-kvm:~# cat /lib/systemd/system/networking.service
[Unit]
Description=Raise network interfaces
Documentation=man:interfaces(5)
DefaultDependencies=no
Requires=ifupdown-pre.service
Wants=network.target
After=local-fs.target network-pre.target apparmor.service systemd-sysctl.service systemd-modules-load.service ifupdown-pre.service
Before=network.target shutdown.target network-online.target
Conflicts=shutdown.target

[Install]
WantedBy=multi-user.target
WantedBy=network-online.target

[Service]
Type=oneshot
EnvironmentFile=-/etc/default/networking
ExecStart=/sbin/ifup -a --read-environment
ExecStop=/sbin/ifdown -a --read-environment --exclude=lo
RemainAfterExit=true
TimeoutStartSec=5min
root@debian-kvm:~# 

The second Debian systemd possibility--not the default on Debian netinst.iso and not used here--is systemd-networkd. Sahitya Maruvada has a simple, clear, Debian systemd-networkd introduction, Working with systemd-networkd. The systemd-networkd wiki page and the systemd.network manpage also are available.

• Official Debian Network Setup Instructions

Official Debian network setup instructions include the Wiki, the Handbook, manual pages such as man interfaces, /etc/network/interfaces examples online, and sometimes locally:

# less /usr/share/doc/ifupdown/examples/network-interfaces

• The ip Command Usually Is Available Even Though Networking Setup Varies Among Linux Distributions

Setting up networking, DNS name resolution, and software package management is very different in different Linux distributions. Therefore, we should not assume that the steps taken below would be exactly the same with a different Linux distribution than Debian.

Nevertheless, despite the different distributions' differing network setup systems, the ip command, supplied by the iproute2 collection, usually is available these days. Please see also Red Hat's IP Command Cheat Sheet

Because the ip command often is available, networking can be configured in many distributions, including Debian, by running a sequence of ip commands. The net effect of the sequence of ip commands can be to get the network functioning on most distributions without touching that individual distribution's network setup scheme.

Here's an example of the ip command used in the context of an iPXE boot. Note that the first command in the linked example requires knowledge of the name of the interface. We can list the names of the interfaces on our system by running the ip link show command.

One issue with using a sequence of ip commands is that the network setup fails to persist across reboots. However, we can place the ip command sequence inside a script which will be run automagically every time the server reboots. The sequence of ip commands in a script reminds us of the days before systemd, when scripts controlled all parts of the boot process including network setup.

Our KVM VPS's internal network configuration that we will be using below is similar to how LXC containers are configured in Proxmox. As will be seen below, Proxmox's LXC containers' network configuration adopts a variant of the "scripted ip command" approach, which also works inside Proxmox's KVM VPSes.

V. Our VM's Network Setup

• Interfaces

Our original /etc/network/interfaces file, the one installed by the netinst.iso, might look like this:

debian@debian-kvm:~$ cd /etc/network
debian@debian-kvm:/etc/network$ cat interfaces.original
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback
debian@debian-kvm:/etc/network$ 

Note that, in the default from the netinst.iso, /etc/network/interfaces.d is empty, so sourcing its files does nothing to the configuration.

debian@debian-kvm:/etc/network$ ls interfaces.d
debian@debian-kvm:/etc/network$ 

Now, let's edit /etc/network/interfaces to match our example network information from the above Before We Start section.

debian@debian-kvm:/etc/network$ cat interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

auto ens18
iface ens18 inet static
  address 172.16.165.97/28
  gateway 172.16.164.1

iface ens18 inet6 static
  address fe80:xxxx:xxxx:xxxx::97/128
  gateway fe80:xxxx:xxxx:xxxx::3

debian@debian-kvm:/etc/network$ 

The minimum required information does not include comments (lines beginning with #). Maybe we can make the rash and short-sighted assumption that we are not going to install anything which will want a file included from interfaces.d. The loopback interface might no longer be required (please see lines 17 and 18 in this file from Debian sources). Thus, for our example setup, the minimum /etc/network/interfaces might be:

debian@debian-kvm:/etc/network$ cat interfaces

auto ens18
iface ens18 inet static
  address 172.16.165.97/28
  gateway 172.16.164.1

iface ens18 inet6 static
  address fe80:xxxx:xxxx:xxxx::97/128
  gateway fe80:xxxx:xxxx:xxxx::3

debian@debian-kvm:/etc/network$ 

When configuring Debian LXC containers, Proxmox configures their /etc/network/interfaces files using added post-up and pre-down routes. Similarly, just for fun, instead of giving the gateway addresses in our /etc/network/interfaces,, we can manually add routes. Except for the initial post-up and pre-down these added lines mirror ip route commands that we could run manually to set up or take down networking without touching the /etc/network/interfaces file.

debian@debian-kvm:/etc/network$ cat interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

auto ens18
iface ens18 inet static
  address 172.16.165.97/28
     post-up ip route add 172.16.164.1 dev ens18
     post-up ip route add default via 172.16.164.1 dev ens18
     pre-down ip route del default via 172.16.164.1 dev ens18
     pre-down ip route del 172.16.164.1 dev ens18

iface ens18 inet6 static
  address fe80:xxxx:xxxx:xxxx::97/128
     post-up ip route add fe80:xxxx:xxxx:xxxx::3  dev ens18
     post-up ip route add default via fe80:xxxx:xxxx:xxxx::3  dev ens18
     pre-down ip route del default via fe80:xxxx:xxxx:xxxx::3  dev ens18
     pre-down ip route del fe80:xxxx:xxxx:xxxx::3  dev ens18

debian@debian-kvm:/etc/network$ 

VI. Our VM's DNS

We might want to add more or different nameservers to /etc/resolv.conf. Our Quick Setup configuration, above, includes IPs from Cloudflare and from Google.

VII. Our VM's Apt Setup

The Debian wiki instructions for configuring apt are at https://wiki.debian.org/SourcesList. There also is a man page. The configuration shown above, in Section III Quick Setup, is from the SourcesList Debian wiki page.

The Debian Security Information page says:

You can use apt to easily get the latest security updates. This requires a line such as
deb http://security.debian.org/debian-security buster/updates main contrib non-free

Many of the larger providers offer Debian mirrors. For example, Debian packages and security updates are available from the Hetzner Debian Mirror

After /etc/sources.list is edited, we update our system's package repositories as follows:

apt-get upgrade && apt-get dist-upgrade -y

We can see exactly which packages are installed by looking at the logs in /var/log/apt.

We may wish to install openssh-server so that we can connect to our VM via ssh in addition to our Proxmox VNC connection. With ssh we regain cut and paste functionality while enjoying lower apparent latency!

apt-get install openssh-server

The Kennedy article, mentioned below in Section VII, has some good tips for ssh server configuration.

VIII. Security

Google suggests its first choice among essential server security articles. This article from 2013, by Bryan Kennedy, seems to provide still-good advice, except that, nowadays, many people prefer to use ed25519 keys

IX. Backup

After all this work, we certainly want to make an offline backup of our new VM. We can use Proxmox to make the backup and then download a a copy from the host node's /var/lib/vz/dump directory.

When installing software on your VPS you will end up with both empty files and empty directories, often these are used as placeholders/lock files/socket files for communication.

This short guide will give you some examples on how to find those empty files/directories.

The command we are going to use is the “find” command. To find empty directories/files in the current directory, you use the parameter “-empty“.

You also have to use the parameter “-type” to define if you are looking for directories (d) or files (f).

Examples

Here is the command to find empty directories in the current directory:

find ./ -type d -empty

And here is the command to find empty files in the current directory:

find ./ -type f -empty

If you need to know how many empty files you have in the current directory, pipe the find command to “wc -l“:

find ./ -type f -empty | wc -l

Similarly, to recursivly count how many how many files are located under the current directory and sub-directories,  you can use the following command:

find ./ -type f -not -empty | wc -l 

To remove all empty directories in the current directory, the command you can use is:

find ./ -type d -empty -exec rmdir {} \;

– In all the commands above, the  (./) means the current directory or folder, if you want to perform actions in other directories, just replace the  (./) with the path to the new directory.

– In system directories such as /etc/, there are many empty files and directories.

But it is strongly recommended to not remove them.

What is Docker?

If you're reading this, most probably you already know Docker or have at least heard about it a lot. But still, for the uninitiated, Docker is an open platform for developing, shipping, and running applications and it enables you to separate your applications from your infrastructure so you can deliver software quickly. Find Docker interesting and want to know more? Head over to their docs and you can find all the information you need!

What is Portainer?

So, talking about the elephant in the room, Portainer is a fully-featured web based GUI management tool for Docker. It runs locally, giving developers a rich UI to build and publish container images, deploy and manage applications and leverage data persistence and horizontal scaling for their applications.
Worried about the cost? Portainer Community Edition is open source, free forever and used by more than 500,000 developers worldwide.

What can I use Portainer for?

1. Visualize your server's docker environment on your web browser. (I know that you don't fear the terminal, but hey, a little help won't harm anybody!)
2. Aggregate view of Docker Swarm clusters (Yeah, it's that fancy!)
3. Deploy containers with some pre-built templates, right from inside the Portainer.
4. Start, Stop, Kill, Restart, Pause, Resume and Remove the containers easily with the web-GUI.
5. Facing any issue while deploying containers? Don't worry, Portainer to rescue! You can inspect the logs for any containers directly from the GUI and see what is stopping you from conquering the world.

How do I install Portainer?

So, you're happy to give Portainer a go and want to know how can you install it? I have got you covered:

1. Make sure you have Docker Engine installed on your server. You can follow the install instructions given here.
2. Run the following command to create a docker volume which should give output as portainer_data indicating the command was successfully executed:

sudo docker volume create portainer_data

3. Once the volume is created, run the following command to create and run the Portainer container:

sudo docker run -d -p 8000:8000 -p 9000:9000 --name=portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce

The above command should create and run the Portainer container on your server's port number 9000, which can be generally accessed in following ways:

a) By opening http://your_server_ip:9000 in your favorite browser.
b) If you have a domain name pointed towards your server's IP, by opening yourdomain.com:9000 in your browser.

Note: If you want to access Portainer over a subdomain instead of every time typing yourdomain.com:9000, you can put it behind a reverse proxy with the help of any web server, like Caddy.

4. Alright, once the container is up and running, access it via any of the above methods and you will be greeted by the following initial setup screen of Portainer:

Set the username and password for admin user here and click on Create User.

5. Next, select Docker as the container management environment you want Portainer to connect to (yes Portainer can connect to Kubernetes too, but that's a story for another day):

6. Voila! now you have successfully connected your local Docker environment to Portainer and you should be able to see below screen:

7. Click on the local endpoint to see all the containers, images, volumes, networks etc. in your Docker environment:

8. You can also deploy app templates containers right from inside the Portainer:

This is it! Go on, play around a bit and I'm sure you'll love how easy Portainer makes it to manage Docker containers. Given how many of the self-hosted apps can be deployed using Docker containers, Portainer is a must-have tool in your arsenal.

Following up on the bonus tip posted on Resize your KVM VPS disk partition, 2 methods and bonus tip to reclaim disk space – Easy mode, here is a longer explanation and guide how to reclaim your reserved disk space.

Joe Dougherty from SecureDragon.net (great guy running a great company) sent me a tip about this thread and asked if I could write something about this “weird trick”. Actually it’s not a wierd trick, it’s a built in security feature. The information in this post will only work on dedicated servers or Virtual Servers that utilize full virtualization, meaning that this won’t work on OpenVZ.

On a newly created filesystems (Ext [2/3/4]) some of the space will be allocated for the system superuser (root) as “system reserved”. The default of 5% is meant for system partitions. If something goes wrong and your server consumes all its free disk space, the root user could still log in and check logs/crashdumps/etc and generally fix the situation.

For example, if your disk space fills up, the system logs (/var/log) and root’s mailbox (/var/mail/root) can still receive important information. For a /home or general data storage partition, there’s no need to leave any space for root. For very special needs, you can even change the user that gets this emergency space.

There’s another reason to not allow an ext[23] filesystem to get full, which is fragmentation. Ext4 should be better at this, as explained by Linux filesystem developer/guru Theodore Ts’o:

If you set the reserved block count to zero, it won't affect performance much except if you run for long periods of time (with lots of file creates and deletes) while the filesystem is almost full (i.e., say above 95%), at which point you'll be subject to fragmentation problems.  Ext4's multi-block allocator is much more fragmentation resistant, because it tries much harder to find contiguous blocks, so even if you don't enable the other ext4 features, you'll see better results simply mounting an ext3 filesystem using ext4 before the filesystem gets completely full.If you are just using the filesystem for long-term archive, where files aren't changing very often (i.e., a huge mp3 or video store), it obviously won't matter.

Theodore Tso

If you have a VPS with small disk size the 5% won’t mean much but if you have a 100GB drive or bigger, it quickly adds up to a vaste amount of unused space. In those cases we could lower the amount of reserved space in order to claim and use a few more GB.

At the time of writing the original post, I actually had an unused XEN VPS so lets have a look at what we can do about this by using that as a real life example.

first we confirm the filesystem parameters by running this command:

# tune2fs -l /dev/xvda1

it will list all information about the disk. This is the output I got from my server:

tune2fs 1.42.5 (29-Jul-2012)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          50fd54e4-7740-4683-b1e5-64e93d6d1e92
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              9830400
Block count:              39321600
Reserved block count:     1966080
Free blocks:              38473681
Free inodes:              9799099
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1014
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
RAID stride:              1
RAID stripe width:        80
Filesystem created:       Mon Nov 10 19:05:08 2014
Last mount time:          Sun Dec 14 17:25:37 2014
Last write time:          Sun Dec 14 17:25:13 2014
Mount count:              12
Maximum mount count:      34
Last checked:             Mon Nov 10 19:05:08 2014
Check interval:           15552000 (6 months)
Next check after:         Sat May  9 19:05:08 2015
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      e2ccf267-28ea-4e34-9df0-a349d06f0247
Journal backup:           inode blocks

The ineresting part from the output above:

Reserved block count:     1966080
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)

Before we move on to the amount of reserved space, take a moment to reflect on what user who is allowed to use the reserved space. By default it is root unless changed by the system administrator.

if you multiply the Reserved Block Count with the current Block Size (also found in the tune2fs output above)

Block size:               4096

we get how much space in bytes that is reserved by the system:

Doing the same operation using the Block Count value:

Block count:              39321600

will give you the Total Disk space of the drive

As you can see (7,5GB out of 150GB) exactly 5% of the disk is reserved space.

As previously mentioned, if you don’t have a large disk it would be wise to not change that 5% value since it could mean that you wont have enough “system reserved space” to recover from a full disk problem.

In my case, 7,5 GB of reserved space is a bit much and I would benefit if this was available for me to store my backups instead. So, how do we change the amount of reserved space?

Since my disk is in total 150GB each percentage is 1,5GB and I think that 1,5GB will be enough for this server, the command to set the reserved space to 1 percent would therefor look like this:

# tune2fs -m 1 /dev/xvda1

The returned result :

Setting reserved blocks percentage to 1% (393216 blocks)

Keeping in mind that each block is 4096 bytes the above result means the reserved space is:

393216 * 4096 = 1,5 GB

Before you jump of joy I would like to end this article with a few words of caution;

While this is a nice way to get some extra space on your server TAKE EXTREME CARE if you decide to change the settings on the drive that has the / volume or you could end up with a server that even root can’t save when the disk runs out of space. If you have a secondary drive that only holds data, may it be your mp3 collection or family photos, you can set the reserved space to 0percent on that drive. As long as it is NOT the system drive.

Introduction

In Part I of this series, we downloaded the Debian netinst install iso. We then created a KVM VPS with the iso attached, and, finally, we successfully booted the iso.

In today's post, we're going to install our KVM with Debian 10 from the newly booted iso. But first, a bit of context on installing.

Context

• Why the Debian minimal netinst iso?

Debian themselves say, "we think that in many cases the minimal CD image is better — above all, you only download the packages that you selected for installation on your machine. . . ."

What we gain from this series is a well-proven, widely used, minimal, highly extensible, open-source server operating system.

• What about networking?

The biggest difference between installing on our VPS and installing on our personal laptop or desktop might be network configuration. On personal devices, we are used to automatic network configuration happening behind the scenes via Dynamic Host Configuration Protocol (DHCP). We turn on our device, it gets its own IP address and internet connection without our having to do much.

On servers, however, the server's IP address and internet connection sometimes are set by hand instead of automatically via DHCP. Traditionally, server network settings are done from a console physically connected to the running server. Obviously, however, if our server is at a remote location, we cannot have a wired connection. Also, since networking hasn't yet been set up inside the server, we can't connect directly to our remote server over the internet, either.

As might be expected, the Debian minimal netinst iso is set up to configure networking automatically via DHCP. Thus, when we try the networking step of the install, that step will fail. The netinst iso will succeed, however, in installing a minimal Debian system without networking. In Part III of this series, covering Post Install Configuration, we will use the Proxmox web GUI and VNC to go inside our minimal system and set up networking by hand.

• Alternative installation methods

It might be worth mentioning a few of the many other excellent methods of server installation which, although frequently used, are not selected here because they might be even more complex than our "simple" method.

• First, Debian unattended Installation using a preseed file will not work here because no networking is set up to use for obtaining the preseed file.
• Cloud-init is "the industry standard multi-distribution method for cross-platform cloud instance initialization." However, the Proxmox Cloud-Init Support wiki article says, despite the convenience of ready-made images, "we usually recommended to prepare the images by yourself," because "you will know exactly what you have installed." Also, for a special perspective on Cloud-Init, you might enjoy watching Cloud-Init: The Good Parts.
• Proxmox supports Templates. It's possible to create templates with Packer. If interested, you can check Creating proxmox templates with packer.

Before We Start

We need to begin today at the exact stage where we left Part I. Our Debian Installer should be booted and running on our VPS.

We also will need the server's hostname (which can be Debian) plus the username (which also can be Debian) and the real name for the user account which the installer will create. It's also convenient to have on hand two previously generated good passwords, one for the root account and another for the new user account.

Debian Installer Steps

• Select Install

• Language

• Location

• Keyboard

• DHCP Tries and Fails

• Select "Do Not Configure Network at this Time"

• Hostname

• Enter and Confirm the Root Password

• User's Real Name

• Username

• User Password

• Time Zone

• Partitioning Method

• Disk to Partition

• Partitioning Scheme

• Confirm Partitioning

• Write Changes to Disks

• Confirm No Additional Install Media

• Confirm No Network Mirror

• Package Usage Survey

• Choose Additional Software

• Dual Boot

• Grub

• Installation Complete

In the Proxmox web GUI, we select VPS > Hardware > CD/DVD Drive. Press edit and select "Do not use any media." Then, we return to our "Installation Complete" screen by selecting Console, which should reappear just as we left it. Finally, we click the "Continue" button, which should reboot the VPS.

In Part I, we did not install Qemu Agent. Therefore, rebooting from the Proxmox web GUI (outside our VPS) as opposed to rebooting from the console (inside our VPS) might not work. However, if it is necessary to stop the server from the web GUI, we can use the web GUI's Stop command found on the drop-down menu of the Shutdown button.

• Successful Reboot

Following up on the post on how to loop thru a file and perform an action per line, which you can find here

https://lowendspirit.com/how-to-loop-through-a-file-and-perform-an-action-per-line/

There is a case when this is useful, adding IPs from a text file into iptables and block their access to your VPS or dedicated server.

if you break down this command with its parameters (iptables being the command)

iptables -A INPUT -s XXX.XXX.XXX.XXX -p udp -m udp --dport 28960:28965 -j DROP

Parameter: Explanation
-A: Append this to existing rules
INPUT: The chain where the rule should be added into
-s XXX.XXX.XXX.XXX: -s Sets the source for a particular packet, in this case the ip of XXX.XXX.XXX.XXX
-p udp: -p = Sets the IP protocol for the rule, which can be either icmp, tcp, udp, or all, to match every possible protocol. If this option is omitted when creating a rule, the all option is the default.
-m udp: -m = match option Different network protocols provide specialized matching options which may be set in specific ways to match a particular packet using that protocol. Of course, the protocol must first be specified in the iptables command, such as using -p tcp , to make the options for that protocol available.
–dport 28960:28965: –dport Specifies the destination port of the UDP packet, using the service name, port number, or range of port numbers. The –destination-port match option may be used instead of –dport. To specify a specific range of port numbers, separate the two numbers with a colon (:), such as our example. You may also use an exclamation point character (!) as a flag after the –dport option to tell iptables to match all packets which do not use that network service or port.
-j DROP: -j Tells iptables to jump to a particular target when a packet matches a particular rule. Valid targets to be used include the standard options, ACCEPT, DROP, QUEUE, and RETURN, as well as extended options that are available through modules loaded, such as LOG, MARK, and REJECT, among others. If no target is specified, the packet moves past the rule with no action taken. However, the counter for this rule is still increased by 1, as the packet matched the specified rule. in our example we use DROP — The system that sent the packet is not notified of the failure. The packet is simply removed from the rule checking the chain and discarded.

This command will DROP connections from IP XXX.XXX.XXX.XXX on udp port 28960:28965

If you want to block all connections from a specific IP, no matter what port it tries to connect to, omit the -p -m and --dport parameters. This will look like this

iptables -A INPUT -s XXX.XXX.XXX.XXX -j DROP

You might ask when are we going to loop thru the file?

#!/bin/sh

# This will loop thru the file /ban/banip.txt and add every IP in that 
# file with a DROP to the INPUT chain in iptables.
#
# change the path and file name if required

# you can re-run this file if you are not saving your iptables config 
# between reboots. 
while read blist
do
/sbin/iptables -A INPUT -s $blist -j DROP && sleep 2
echo $blist has been added to your iptables

done < /ban/banip.txt

To add a single IP to the block list in iptables and add the IP to your text file, you could use a simple shell script like this

#!/bin/sh
# Script to add ip
echo -n "Enter the IP to BAN and press [ENTER]:"
read ip
/sbin/iptables -A INPUT -s $ip -j DROP

#keep a record of the banned IP's if you want or comment out
echo $ip >> /ban/banip.txt
# Make sure you use the same path and filename as in the loop script

This is a quick and dirty way to keep a list of IPs you would like to block access from.

I'm sure that the readers have more sophisticated and innovative ways to add their own list of IPs to iptables.

Comment with how you do it and why you do it the way you do.