Background

I recently bought a DELL OptiPlex 7040 Micro desktop computer and wanted to operate it as a dedicated server.
I installed Debian 11 on the computer, and placed it into the closet to be accessed over SSH only.
To keep the host machine stable, I decide to run most workloads in LXC containers, which are said to be Fast-as-Metal.
Since I operate my own video streaming website, I have an LXC container for encoding the videos.

The computer comes with an Intel Core i5-6500T processor.
It has 4 hardware cores running at 2.50GHz frequency, and belongs to the Skylake family.
FFmpeg is happily encoding my videos on this CPU.

As I read through the processor specification, I noticed this section:

• Processor Graphics: Intel® HD Graphics 530

  • Processor Graphics indicates graphics processing circuitry integrated into the processor, providing the graphics, compute, media, and display capabilities.

• Intel® Quick Sync Video: Yes

  • Intel® Quick Sync Video delivers fast conversion of video for portable media players, online sharing, and video editing and authoring.

It seems that I have a GPU!
Can I make use of this Intel GPU and accelerate video encoding workloads?

Story

If you just want the solution, skip to the TL;DR Steps to Enable VAAPI in LXC section at the end.

Testing VAAPI with Docker

I read FFmpeg HWAccelIntro and QuickSync pages, and learned:

• FFmpeg supports hardware acceleration on various GPU brands including Intel, AMD, and NVIDIA.
• Hardware encoders typically generate outputs of significantly lower quality than good software encoders, but are generally faster and do not use much CPU resource.

• On Linux, FFmpeg may access Intel GPU through libmfx, OpenCL, or VAAPI.
  Among these, encoding is possible with libmfx or VAAPI.

• Each generation Intel processors has different video encoding capabilities.
  For the Skylake family that I have, the integrated GPU can encode to H.264, MPEG-2, VP8, and H.265 formats.

I decided to experiment with VAAPI, because it has the shortest name 🤪.
I quickly found jrottenberg/ffmpeg Docker image.
Following the example commands on FFmpeg VAAPI page, I verified that my GPU can successfully encode videos to H264 format:

docker run \
    --device /dev/dri \
    -v $(pwd):/data -w /data \
  jrottenberg/ffmpeg:4.1-vaapi \
    -loglevel info -stats \
    -vaapi_device /dev/dri/renderD128 \
    -i input.mov \
    -vf 'hwupload,scale_vaapi=w=640:h=480:format=nv12' \
    -preset ultrafast \
    -c:v h264_vaapi \
    -f mp4 output.mp4

The renderD128 Device

This above docker run command tells me that the /dev/dri/renderD128 device is likely the key of getting Intel GPU to work in an LXC container.
It is a character device with major number 226 and minor number 128.

sunny@sunnyD:~$ ls -l /dev/dri
total 0
drwxr-xr-x 2 root root         80 Jan 22 11:04 by-path
crw-rw---- 1 root video  226,   0 Jan 22 11:04 card0
crw-rw---- 1 root render 226, 128 Jan 22 11:04 renderD128

Inside the container, this device does not exist.
Naively, I tried mknod, but it returns an "operation not permitted" error:

ubuntu@video:~$ ls -l /dev/dri
ls: cannot access '/dev/dri': No such file or directory

ubuntu@video:~$ sudo mkdir /dev/dri

ubuntu@video:~$ sudo mknod /dev/dri/renderD128 c 226 128
mknod: /dev/dri/renderD128: Operation not permitted

I searched for this problem over several weeks, found several articles regarding how to get Plex or Emby media server to use VAAPI hardware encoding from LXC containers, but they are either using Proxmox or LXD (unavailable on Debian), both differ from the plain LXC that I'm trying to use.
From these articles, I gathered enough hints on what's needed:

• LXC container cannot mknod arbitrary devices for security reasons.

• To have a device inode in an LXC container, the container config must:

  • grant permission with lxc.cgroup.devices.allow directive, and
  • mount the device with lxc.mount.entry directory.

• In addition to ffmpeg, it's necessary to install vainfo i965-va-driver packages (available on both Debian and Ubuntu).

nobody:nogroup

With these configs in place, the device showed up in the container, but it does not work:

ubuntu@video:~$ ls -l /dev/dri
total 0
crw-rw---- 1 nobody nogroup 226, 128 Jan 22 16:04 renderD128
ubuntu@video:~$ vainfo
error: can't connect to X server!
error: failed to initialize display
ubuntu@video:~$ sudo vainfo
error: XDG_RUNTIME_DIR not set in the environment.
error: can't connect to X server!
error: failed to initialize display

One suspicious thing is the nobody:nogroup owner on the renderD128 device.
It differs from the root:render owner as seen on the host machine.
Naively, I tried chown, but it returns an "invalid argument" error and has no effect:

ubuntu@video:~$ sudo chown root:render /dev/dri/renderD128
chown: changing ownership of '/dev/dri/renderD128': Invalid argument

ubuntu@video:~$ ls -l /dev/dri
total 0
crw-rw---- 1 nobody nogroup 226, 128 Jan 22 16:04 renderD128

A Reddit post claims that running chmod 0666 /dev/dri/renderD128 from the host machine would solve this problem.
I gave it a try and it was indeed effective.
However, I know this isn't a proper solution because you are not supposed to change permission on device inodes.
So I continued searching.

idmap

The last piece of the puzzle lies in user and group ID mappings.
In an unprivileged LXC container, user and group IDs are shifted, so that the root user (UID 0) inside the container would not gain root privilege on the host machine.
lxc.idmap directive in the container config controls these mappings.
In my container, the relevant config was:

# map container UID 0~65535 to host UID 100000~165535
lxc.idmap = u 0 100000 65536
# map container GID 0~65535 to host GID 100000~165535
lxc.idmap = g 0 100000 65536

Notably, the root user (UID 0) and render group (GID 107) on the host user aren't mapped to anything in the container.
The kernel uses 65534 to represent a UID/GID which is outside the container's map.
Hence, the renderD128 device, when mounted into the container, has owner UID and GID being 65534:

ubuntu@video:~$ ls -ln /dev/dri
total 0
crw-rw---- 1 65534 65534 226, 128 Jan 22 16:04 renderD128

65534 is the UID of nobody and the GID of nogroup, which is why this device appears to be owned by nobody:nogroup.

To make the renderD128 owned by render group, the correct solution is mapping the render group inside the container to the render group on the host.
This, in turn, requires two ingredients:

• /etc/subgid must authorize the host user who starts the container to map the GID of the host's render group into child namespaces.
• The container config should have an lxc.idmap directive that maps the GID of the container's render group to the GID of the host's render group.

So I added lxc:107:1 to /etc/subgid, in which lxc is the ordinary user on the host machine that starts the containers, and 107 is the GID of render group on the host machine.
Then I modified the container config as:

# map container UID 0-65535 to host UID 100000-165535
lxc.idmap = u 0 100000 65536
# map container GID 0-65535 to host GID 100000-165535
lxc.idmap = g 0 100000 65536
# map container GID 109 to host GID 107
lxc.idmap = g 109 107 1

However, the container fails to start:

lxc@sunnyD:~$ lxc-unpriv-start -F video
Running scope as unit: run-r611f1778b87645918a2255d44073b86b.scope
lxc-start: video: conf.c: lxc_map_ids: 2865 newgidmap failed to write mapping "newgidmap: write to gid_map failed: Invalid argument": newgidmap 5297 0 100000 65536 109 107 1
             lxc-start: video: start.c: lxc_spawn: 1726 Failed to set up id mapping.

Re-reading user_namespaces(7) manpage reveals the reason:

Defining user and group ID mappings: writing to uid_map and gid_map

• The range of user IDs (group IDs) specified in each line cannot overlap with the ranges in any other lines.

The above container config defines two group ID mappings that overlaps at the GID 109, which causes the failure.
Instead, it must be split to three ranges: 0-108 mapped to 100000-100108, 109 mapped to 107, 110-65535 mapped to 100110-165535.

Another idea I had, changing the GID of the render group to a large number greater than 65535 and thus dodge the overlap, turns out to be a bad idea, as it causes an error during system upgrades:

ubuntu@video:~$ sudo apt full-upgrade
Setting up udev (245.4-4ubuntu3.15) ...
The group `render' already exists and is not a system group. Exiting.
dpkg: error processing package udev (--configure):
 installed udev package post-installation script subprocess returned error exit status 1

Hence, I must carefully calculate the GID ranges and write three GID mapping entries.
With this final piece in place, success!

ubuntu@video:~$ vainfo 2>/dev/null | head -10
vainfo: VA-API version: 1.7 (libva 2.6.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Skylake - 2.4.0
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Simple            : VAEntrypointEncSlice
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP

Encoding speed comparison on one of my videos:

• h264, ultrafast, 640x480 resolution

• Intel GPU VAAPI encoding:

  frame= 2900 fps=201 q=-0.0 Lsize=   18208kB time=00:01:36.78 bitrate=1541.2kbits/s speed=6.71x
  video:16583kB audio:1528kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.533910%
  

• Skylake CPU encoding:

  frame= 2900 fps=171 q=-1.0 Lsize=   18786kB time=00:01:36.78 bitrate=1590.1kbits/s speed=5.71x
  video:17177kB audio:1528kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.434900%
  

• GPU encoding was 17.5% faster than CPU encoding.

TL;DR Steps to Enable VAAPI in LXC

1. Confirm that the /dev/dri/renderD128 device exists on the host machine.

   lxc@sunnyD:~$ ls -l /dev/dri/renderD128
   crw-rw---- 1 root render 226, 128 Jan 22 11:04 /dev/dri/renderD128
   

   If the device does not exist, you do not have an Intel GPU or it is not recognized by the kernel.
   You must resolve this issue before proceeding to the next step.

2. Find the GID of the render group on the host machine:

   lxc@sunnyD:~$ getent group render
   render:x:107:
   

   On my computer, the GID is 107.

3. Authorize the host user who starts LXC containers to map the GID to child namespaces.

   1. Run sudoedit /etc/subgid to open the editor.

   2. Append a line:

      lxc:107:1
      

   Explanation:

   • lxc refers to the host user account.
   • 107 is the GID of the render group, as seen in step 2.
   • 1 means authorizing just one GID.

4. Create and start an LXC container, and find out the GID of the container's render group.
   I'm using a Ubuntu 20.04 template, but the same procedure is applicable to other templates.

   lxc@sunnyD:~$ export DOWNLOAD_KEYSERVER=keyserver.ubuntu.com
   
   lxc@sunnyD:~$ lxc-create -n video -t download -- -d ubuntu -r focal -a amd64
   Using image from local cache
   Unpacking the rootfs
   
   You just created an Ubuntu focal amd64 (20211228_07:42) container.
   
   To enable SSH, run: apt install openssh-server
   No default root or user password are set by LXC.
   
   lxc@sunnyD:~$ lxc-unpriv-start video
   Running scope as unit: run-re7a88541bd5d42ab92c9ea6d4cd2a19f.scope
   
   lxc@sunnyD:~$ lxc-unpriv-attach video getent group render
   Running scope as unit: run-reaad3e4a549a420bacb160fd8cbc87a8.scope
   render:x:109:
   

5. Edit the container config.

   1. Run editor ~/.local/share/lxc/video/config to open the editor.

   2. Delete existing lines that start with lxc.idmap = g.

      However, do not delete lines that start with lxc.idmap = u.

   3. Append these lines:

      lxc.idmap = g 0 100000 109
      lxc.idmap = g 109 107 1
      lxc.idmap = g 110 100110 65426
      lxc.cgroup.devices.allow = c 226:128 rwm
      lxc.mount.entry = /dev/dri/renderD128 dev/dri/renderD128 none bind,optional,create=file
      

   Explanation:

   • The lxc.idmap = g directive defines a group ID mapping.

     • 109 is the GID of the container's render group, as seen instep 4.
     • 107 is the GID of the host's render group, as seen in step 2.

   • The lxc.cgroup.devices.allow directive exposes a device to the container.

     • 226:127 is the major number and minor number of the renderD128 device, as seen in step 1.

   • The lxc.mount.entry directive mounts the host's renderD128 device into the container.

   You may use this handy idmap calculator to generate the lxc.idmap directives:
   (read original article https://yoursunny.com/t/2022/lxc-vaapi/ to use the JavaScript calculator)

6. Restart the container and attach to its console.

   lxc@sunnyD:~$ lxc-stop video
   
   lxc@sunnyD:~$ lxc-unpriv-start video
   Running scope as unit: run-r77f46b8ba5b24254a99c1ef9cb6384c3.scope
   
   lxc@sunnyD:~$ lxc-unpriv-attach video
   Running scope as unit: run-r11cf863c81e74fcfa1615e89902b1284.scope
   

7. Install FFmpeg and VAAPI packages in the container.

   root@video:/# apt update
   
   root@video:/# apt install --no-install-recommends ffmpeg vainfo i965-va-driver
   0 upgraded, 148 newly installed, 0 to remove and 15 not upgraded.
   Need to get 79.2 MB of archives.
   After this operation, 583 MB of additional disk space will be used.
   Do you want to continue? [Y/n]
   

8. Confirm that the /dev/dri/renderD128 device exists in the container and is owned by render group.

   root@video:/# ls -l /dev/dri/renderD128
   crw-rw---- 1 nobody render 226, 128 Jan 22 16:04 /dev/dri/renderD128
   

   It's normal for the owner user to show as nobody.
   This does not affect operation as long as the calling user is a member of the render group.
   The only implication is that, the container's root user cannot access the renderD128 unless it is added to the render group.

9. Add container's user account(s) to render group.
   These users will have access to the GPU.

   root@video:/# /sbin/adduser ubuntu render
   Adding user `ubuntu' to group `render' ...
   Adding user ubuntu to group render
   Done.
   

10. Become one of these users, and verify the Intel iGPU is operational in the LXC container.

    root@video:/# sudo -iu ubuntu
    
    ubuntu@video:~$ vainfo
    error: XDG_RUNTIME_DIR not set in the environment.
    error: can't connect to X server!
    libva info: VA-API version 1.7.0
    libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
    libva info: va_openDriver() returns -1
    libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
    libva info: Found init function __vaDriverInit_1_6
    libva info: va_openDriver() returns 0
    vainfo: VA-API version: 1.7 (libva 2.6.0)
    vainfo: Driver version: Intel i965 driver for Intel(R) Skylake - 2.4.0
    vainfo: Supported profile and entrypoints
          VAProfileMPEG2Simple            : VAEntrypointVLD
          VAProfileMPEG2Simple            : VAEntrypointEncSlice
          VAProfileMPEG2Main              : VAEntrypointVLD
          VAProfileMPEG2Main              : VAEntrypointEncSlice
          VAProfileH264ConstrainedBaseline: VAEntrypointVLD
          VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
          VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
          VAProfileH264ConstrainedBaseline: VAEntrypointFEI
          VAProfileH264ConstrainedBaseline: VAEntrypointStats
          VAProfileH264Main               : VAEntrypointVLD
          VAProfileH264Main               : VAEntrypointEncSlice
          VAProfileH264Main               : VAEntrypointEncSliceLP
          VAProfileH264Main               : VAEntrypointFEI
          VAProfileH264Main               : VAEntrypointStats
          VAProfileH264High               : VAEntrypointVLD
          VAProfileH264High               : VAEntrypointEncSlice
          VAProfileH264High               : VAEntrypointEncSliceLP
          VAProfileH264High               : VAEntrypointFEI
          VAProfileH264High               : VAEntrypointStats
          VAProfileH264MultiviewHigh      : VAEntrypointVLD
          VAProfileH264MultiviewHigh      : VAEntrypointEncSlice
          VAProfileH264StereoHigh         : VAEntrypointVLD
          VAProfileH264StereoHigh         : VAEntrypointEncSlice
          VAProfileVC1Simple              : VAEntrypointVLD
          VAProfileVC1Main                : VAEntrypointVLD
          VAProfileVC1Advanced            : VAEntrypointVLD
          VAProfileNone                   : VAEntrypointVideoProc
          VAProfileJPEGBaseline           : VAEntrypointVLD
          VAProfileJPEGBaseline           : VAEntrypointEncPicture
          VAProfileVP8Version0_3          : VAEntrypointVLD
          VAProfileVP8Version0_3          : VAEntrypointEncSlice
          VAProfileHEVCMain               : VAEntrypointVLD
          VAProfileHEVCMain               : VAEntrypointEncSlice
    

Conclusion

This article explores how to make use of Intel processor's integrated GPU in an unprivileged LXC 4.0 container, on Debian 11 bullseye host machine without Proxmox or LXD.
The key points include mounting the renderD128 device into the container, configuring idmap for the render group, and verifying the setup with vainfo command.
The result is an LXC container that can encode videos to H.264 and other formats in the GPU with Intel Quick Sync Video feature, which is 17.5% faster than CPU encoding.

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.

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

Would you mind sharing advice?
Which one(s) should I try first?

• Free is preferred of course but I'm okay to make them pay
• VPS is and always will be under Debian.

Thanks

Do you know any backup plugins for Direct Admin that supports FTP Backups which runs on Debian 10 ?
JetBackup - Not Supported
Dabackup- No remote ftp backup

I bought a few Virtual Private Servers (VPS) on Black Friday, and have been busy setting them up.
Nowadays, most VPS comes with an IPv6 subnet that contains millions of possible addresses.
Initially, only one IPv6 address is assigned to the server, but the user can assign additional addresses as desired.
Given that I plan to run multiple services within a server, I added a few more IPv6 addresses so that each service can have a unique IPv6 address.

One of my servers is using OpenVZ 7 virtualization technology, in which I installed Debian 10 operating system.
Commonly, OpenVZ 7 uses virtual network device (venet) that does not have a MAC address.
venet devices are not fully IPv6 compliant, but still works if you statically assign IPv6 addresses.
Moreover, every IP address used in a container must be configured from the host node, because venet would drop ip-packets from the container with a source address, and in the container with the destination address, which is not corresponding to an ip-address of the container.
Therefore, I must use the VPS control panel, in this case SolusVM, to assign IPv6 addresses to my server:

In the Add IP section, the IPv6 subnet prefix 2001:db8:f1c1:8454:0964: is already shown.
Notice that I am putting a colon (:) in front of the suffix beef, so that they concatenate to the full address 2001:db8:f1c1:8454:0964::beef.
Forgetting this colon would cause "Invalid Entry" error.

After making this change in the SolusVM control panel, the /etc/network/interface file on my server is updated automatically:

# This configuration file is auto-generated.
# WARNING: Do not edit this file, otherwise your changes will be lost.
# Please edit template /etc/network/interfaces.template instead.
auto lo
iface lo inet loopback
# Auto generated venet0 interfaces
auto venet0
iface venet0 inet static
        address 127.0.0.1
        netmask 255.255.255.255
        broadcast 0.0.0.0
        up route add default dev venet0
iface venet0 inet6 static
        address ::2
        netmask 128
        up ip -6 r a default dev venet0
        up ip addr add 2001:db8:f1c1:8454:0964::2/80 dev venet0
        up ip addr add 2001:db8:f1c1:8454:0964::beef/80 dev venet0
auto venet0:0
iface venet0:0 inet static
        address 10.10.23.159
        netmask 255.255.255.255

I'm also seeing two IPv6 addresses:

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
    link/void
    inet 127.0.0.1/32 scope host venet0
       valid_lft forever preferred_lft forever
    inet 192.0.2.30/32 brd 192.0.2.30 scope global venet0:0
       valid_lft forever preferred_lft forever
    inet6 2001:db8:f1c1:8454:0964::beef/80 scope global
       valid_lft forever preferred_lft forever
    inet6 2001:db8:f1c1:8454:0964::2/80 scope global
       valid_lft forever preferred_lft forever
    inet6 ::2/128 scope global
       valid_lft forever preferred_lft forever

I intend to host my secret beef recipes on its unique IPv6 address 2001:db8:f1c1:8454:0964::beef, and use the other address 2001:db8:f1c1:8454:0964::2 for outbound traffic such as pings and traceroutes.
However, I noticed that the wrong address is being selected for outgoing packets:

$ ping 2001:db8:9f16:8fc7::9

$ sudo tcpdump -n icmp6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
10:25:18.264905 IP6 2001:db8:f1c1:8454:0964::beef > 2001:db8:9f16:8fc7::9: ICMP6, echo request, seq 1, length 64
10:25:18.265014 IP6 2001:db8:9f16:8fc7::9 > 2001:db8:f1c1:8454:0964::beef: ICMP6, echo reply, seq 1, length 64
10:25:19.264939 IP6 2001:db8:f1c1:8454:0964::beef > 2001:db8:9f16:8fc7::9: ICMP6, echo request, seq 2, length 64
10:25:19.265013 IP6 2001:db8:9f16:8fc7::9 > 2001:db8:f1c1:8454:0964::beef: ICMP6, echo reply, seq 2, length 64

I started searching for a solution, and learned that:

• Default Address Selection for Internet Protocol version 6 (IPv6) is a very complicated topic.

• An application can explicitly specify a source address.
  For example, I can invoke ping -I 2001:db8:f1c1:8454:0964::2 2001:db8:9f16:8fc7::9 to use the desired source address.

• Each local IPv6 address can be either "preferred" or "deprecated".
  If the application does not specify a source address, the system would prefer to use a "preferred" address instead of a "deprecated" address.

As shown in the ip addr output above, currently both addresses are "preferred" on my server.
This means, both addresses are equally possible of being used as the default source address.
If I can make 2001:db8:f1c1:8454:0964::2 "preferred" and all other addresses "deprecated", I would achieve my goal of making 2001:db8:f1c1:8454:0964::2 the default source address for outbound traffic.

How can I set an IPv6 address as "deprecated"?
After some digging, I found that it is controlled by the preferred_lft (preferred lifetime) attribute.
This attribute indicates the remaining time an IP address is to remain "preferred".
Unless it is set to "forever", preferred_lft counts down every second, and the IP address becomes "deprecated" when it reaches zero.
If the IP address was added with preferred_lft set to zero, it would be "deprecated" since the beginning.

The command to change preferred_lft of an existing IPv6 address is:

sudo ip addr change 2001:db8:f1c1:8454:0964::beef/80 dev venet0 preferred_lft 0

This change takes effect immediately, and outgoing packets start using 2001:db8:f1c1:8454:0964::2 as source address, as I wanted.
However, after a reboot, both IPv6 addresses would become "preferred" again.

As we have seen, the /etc/network/interfaces file is adding IPv6 addresses in a post-up command that runs after ifupdown package brings the interface up.
Can we change this command and set preferred_lft to zero?

So I modified the /etc/network/interfaces file, changing that line to:

up ip addr add 2001:db8:f1c1:8454:0964::beef/80 dev venet0 preferred_lft 0

However, modifying /etc/network/interfaces in an OpenVZ 7 container would not work.
Although I can see the modification right away, after a reboot, the file is automatically restored to the default state, reverting any changes.

After poking around for a while, I figured out the solution: create a systemd service to change the preferred_lft attribute.
The following commands will do the magic:

sudo apt install -y jq
sudo mkdir -p /usr/local/bin

sudo tee /usr/local/bin/network-preferredlft.sh > /dev/null <<'EOT'
#!/bin/bash
set -e
set -o pipefail

ip -j addr show dev $IFACE \
  | jq -r '
    .[] | select(.addr_info) | .addr_info[] |
    select(.family=="inet6" and .scope=="global") |
    select(.local | (endswith(":1") or endswith(":2")) | not) |
    "ip addr change "+.local+"/"+(.prefixlen|tostring)+" dev "+env.IFACE+" preferred_lft 0"' \
  | sh
EOT

sudo chmod +x /usr/local/bin/network-preferredlft.sh

sudo tee /etc/systemd/system/network-preferredlft.service > /dev/null <<'EOT'
[Unit]
Description=Change preferred_lft
Documentation=https://yoursunny.com/t/2020/preferred-lft-vz7/
After=network-online.target
Wants=network-online.target

[Service]
Environment="IFACE=venet0"
Type=oneshot
ExecStart=/usr/local/bin/network-preferredlft.sh

[Install]
WantedBy=multi-user.target
EOT

sudo systemctl daemon-reload
sudo systemctl enable network-preferredlft

The script /usr/local/bin/network-preferredlft.sh retrieves a list of IP addresses assigned to the network interface specified by the environment variable $IFACE.
For each global-scope IPv6 address that does not end with :1 or :2, the preferred_lft attribute is changed to zero.

After executing the above command and rebooting, I can see that the IPv6 address 2001:db8:f1c1:8454:0964::beef is correctly marked as "deprecated" and no longer selected as the default source address.
Now I can securely host my secret beef recipes on 2001:db8:f1c1:8454:0964::beef without worrying about others discovering this "deprecated" IPv6 address through my outbound network traffic.

$ ip addr show dev venet0
2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
    link/void
    inet 127.0.0.1/32 scope host venet0
       valid_lft forever preferred_lft forever
    inet 192.0.2.30/32 brd 192.0.2.30 scope global venet0:0
       valid_lft forever preferred_lft forever
    inet6 2001:db8:f1c1:8454:0964::beef/80 scope global deprecated
       valid_lft forever preferred_lft 0sec
    inet6 2001:db8:f1c1:8454:0964::2/80 scope global
       valid_lft forever preferred_lft forever
    inet6 ::2/128 scope global
       valid_lft forever preferred_lft forever

$ ping 2001:db8:9f16:8fc7::9

$ sudo tcpdump -n icmp6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
11:03:40.185496 IP6 2001:db8:f1c1:8454:0964::2 > 2001:db8:9f16:8fc7::9: ICMP6, echo request, seq 1, length 64
11:03:40.185598 IP6 2001:db8:9f16:8fc7::9 > 2001:db8:f1c1:8454:0964::2: ICMP6, echo reply, seq 1, length 64
11:03:41.187229 IP6 2001:db8:f1c1:8454:0964::2 > 2001:db8:9f16:8fc7::9: ICMP6, echo request, seq 2, length 64
11:03:41.187273 IP6 2001:db8:9f16:8fc7::9 > 2001:db8:f1c1:8454:0964::2: ICMP6, echo reply, seq 2, length 64

This article explained how to change default IPv6 source address selection by marking an IPv6 address "deprecated" via a systemd service that invokes ip addr command after ifupdown brings up the network interface.
The described technique works in OpenVZ 7 and Debian 10, and has been tested in a VPS provided by Gullo's Hosting.
If you are using KVM and Ubuntu 20.04, check out How to Select Default IPv6 Source Address for Outbound Traffic with Netplan.

I would need your kind help. I have a DirectAdmin server here and would like to make WebDAV available securely to one user account. I have searched the DirectAdmin forums and the Interwebs, but most threads/instructions that I find are either horribly outdated or somehow unresolved and I, myself, have no experience with WebDAV besides using it from a client perspective.

Is there anybody here with a bit of experience to explain it to me or a link to a good and recent HowTo?
I am running DirectAdmin on a Linux/Debian 9 system...

Thank you so much in advance & kind regards
Amitz

EasyEngine looks interesting, but I'm always a bit cautious when it comes to scripts to be downloaded and piped to a root shell.
I might just look at the source and see what it does ...

Maybe any of you are using EasyEngine?
(Or tried and dropped it? If so, why?)

For anyone running Debian or Ubuntu in OpenVZ 7 containers, what has your experience been upgrading between OS versions, à la dist-upgrade/do-release-upgrade? Is it safe to assume it works these days, or would you rather reinstall a provided template?

@AnthonySmith At InceptionHosting in particular, is it safe to upgrade my servers without reinstalling?

Thanks.

Note 1: If you really need the GUI (interface), you can follow this article. I do not recommend installing GUI for large web servers. Once you've decided to use Linux / Unix based, you should learn to use about the command line.

Note 2: This tutorial is only for Debian OS and some Debian-based OS like Ubuntu. It works well inside an unprivileged LXC container VPS

# A little conceptual.

If you are wondering what the desktop environment is, you can simply think of it as the interface, which is what you see on the screen instead of just the command line. It makes it possible to run applications that require graphical user interfaces, or GUIs in short.

Read more about the Desktop environment at Wikipedia

VNC is a GUI sharing method for anyone to control your computer anywhere. That is, when someone has been granted access to our VNC server, the data (event) from that person's keyboard and mouse will transfer to our computer. Through that update the user interface on both sides.

Find out more at Wikipedia

# Install the LXDE desktop environment

In this section, I will show you the two most common ways to install LXDE. Before starting, you should update the system with the following command:

sudo apt update && sudo apt upgrade

1. Use Tasksel

Tasksel is a pre-written tool to help users install Desktop Environment, web server more quickly. To install Tasksel, run the following command:

sudo apt install tasksel

Next we install LXDE as follows:

sudo tasksel install lubuntu-core

2. Use APT

APT is a package management tool built into most Debian-based OS. When installing a package, run the following command:

apt install <package name>

Same as above, with LXDE we install with the following command:

apt install lxde

# Installing VNC Server

There are many vnc servers, but in this section I will install tightvncserver:

sudo apt install tightvncserver

Next, we will initialize vncserver for the first time:

vncserver

To proceed with configuring vnc server with LXDE, we need to kill the session on:

vncserver -kill: 1

Edit the VNC configuration to start the VNC Server will start the lXDE session, run the following command to edit the vnc configuration file:

nano ~/.vnc/xstartup

Edit the file to the following content:

#!/bin /bash
xrdb $HOME/.Xresources
exec startlxde &

Save the file and then restart vncserver.

vncserver

# Connecting with VNC Client

You need to have a VNC Client to connect to VNC Server. You can download the RealVNC Viewer here. Open VNC CLient to connect with the host:

<server IP> : <Port number>

The port number here is usually 5901. And here is the result:

Good luck!
Thanks @Not_Oles for helping me

Wonder if there was a bit more than I expected in the default template, or if I didn't pay attention when upgrading/installing. (Some CLI utils triggers weird deps sometimes.)
Or is Debian just becoming a large base install by default?
(Almost tempted to go for Alpine, but been a Debian user for so long.)