Below my personal settings -as of today- for LibreDNS using systemd-resolved service for DNS resolution.
sudo vim /etc/systemd/resolved.conf
basic settings
[Resolve]
DNS=116.202.176.26:854#dot.libredns.gr
DNSOverTLS=yes
FallbackDNS=88.198.92.222
Cache=yes
apply
sudo systemctl restart systemd-resolved.service
verify
resolvectl query analytics.google.com
analytics.google.com: 0.0.0.0 -- link: eth0
-- Information acquired via protocol DNS in 144.7ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: yes
-- Data from: network
Explain Settings
DNS setting
DNS=116.202.176.26:854#dot.libredns.gr
We declare the IP of our DoT service. Using : as a separator we add the no-ads TCP port of DoT, 854. We also need to add our domain in the end to tell systemd-resolved that this IP should respond to dot.libredns.gr
Dns Over TLS
DNSOverTLS=yes
The usually setting is yes. In older systemd versions you can also select opportunistic.
As we are using Lets Encrypt systemd-resolved can not verify (by default) the IP inside the certificate. The type of certificate can verify the domain dot.libredns.gr but we are asking the IP: 116.202.176.26 and this is another type of certificate that is not free. In order to “fix” this , we added the #dot.libredns.gr in the above setting.
FallBack
Yes not everything has Five nines so you may need a fall back dns to .. fall. Be aware this is cleartext traffic! Not encrypted.
FallbackDNS=88.198.92.222
Cache
Last but not least, caching your queries can give provide you with an additional speed when browsing the internet ! You already asked this a few seconds ago, why not caching it on your local system?
Cache=yes
to give you an example
resolvectl query analytics.google.com
analytics.google.com: 0.0.0.0 -- link: eth0
-- Information acquired via protocol DNS in 144.7ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: yes
-- Data from: network
second time:
resolvectl query analytics.google.com
analytics.google.com: 0.0.0.0 -- link: eth0
-- Information acquired via protocol DNS in 2.3ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: yes
-- Data from: cachesystemd
Latest systemd version now contains the systemd-importd daemon .
That means that we can use machinectl to import a tar or a raw image from the internet to use it with the systemd-nspawn command.
so here is an example
machinectl
from my archlinux box:
# cat /etc/arch-release
Arch Linux releaseCentOS 7
We can download the tar centos7 docker image from the docker hub registry:
# machinectl pull-tar --verify=no https://github.com/CentOS/sig-cloud-instance-images/raw/79db851f4016c283fb3d30f924031f5a866d51a1/docker/centos-7-docker.tar.xz
...
Created new local image 'centos-7-docker'.
Operation completed successfully.
Exiting.we can verify that:
# ls -la /var/lib/machines/centos-7-docker
total 28
dr-xr-xr-x 1 root root 158 Jan 7 18:59 .
drwx------ 1 root root 488 Feb 1 21:17 ..
-rw-r--r-- 1 root root 11970 Jan 7 18:59 anaconda-post.log
lrwxrwxrwx 1 root root 7 Jan 7 18:58 bin -> usr/bin
drwxr-xr-x 1 root root 0 Jan 7 18:58 dev
drwxr-xr-x 1 root root 1940 Jan 7 18:59 etc
drwxr-xr-x 1 root root 0 Nov 5 2016 home
lrwxrwxrwx 1 root root 7 Jan 7 18:58 lib -> usr/lib
lrwxrwxrwx 1 root root 9 Jan 7 18:58 lib64 -> usr/lib64
drwxr-xr-x 1 root root 0 Nov 5 2016 media
drwxr-xr-x 1 root root 0 Nov 5 2016 mnt
drwxr-xr-x 1 root root 0 Nov 5 2016 opt
drwxr-xr-x 1 root root 0 Jan 7 18:58 proc
dr-xr-x--- 1 root root 120 Jan 7 18:59 root
drwxr-xr-x 1 root root 104 Jan 7 18:59 run
lrwxrwxrwx 1 root root 8 Jan 7 18:58 sbin -> usr/sbin
drwxr-xr-x 1 root root 0 Nov 5 2016 srv
drwxr-xr-x 1 root root 0 Jan 7 18:58 sys
drwxrwxrwt 1 root root 140 Jan 7 18:59 tmp
drwxr-xr-x 1 root root 106 Jan 7 18:58 usr
drwxr-xr-x 1 root root 160 Jan 7 18:58 var
systemd-nspawn
Now test we can test it:
[root@myhomepc ~]# systemd-nspawn --machine=centos-7-docker
Spawning container centos-7-docker on /var/lib/machines/centos-7-docker.
Press ^] three times within 1s to kill container.
[root@centos-7-docker ~]#
[root@centos-7-docker ~]#
[root@centos-7-docker ~]# cat /etc/redhat-release
CentOS Linux release 7.4.1708 (Core)
[root@centos-7-docker ~]#
[root@centos-7-docker ~]# exit
logout
Container centos-7-docker exited successfully.
and now returning to our system:
[root@myhomepc ~]#
[root@myhomepc ~]#
[root@myhomepc ~]# cat /etc/arch-release
Arch Linux release
Ubuntu 16.04.4 LTS
ubuntu example:
# machinectl pull-tar --verify=no https://github.com/tianon/docker-brew-ubuntu-core/raw/46511cf49ad5d2628f3e8d88e1f8b18699a3ad8f/xenial/ubuntu-xenial-core-cloudimg-amd64-root.tar.gz
# systemd-nspawn --machine=ubuntu-xenial-core-cloudimg-amd64-rootSpawning container ubuntu-xenial-core-cloudimg-amd64-root on /var/lib/machines/ubuntu-xenial-core-cloudimg-amd64-root.
Press ^] three times within 1s to kill container.
Timezone Europe/Athens does not exist in container, not updating container timezone.
root@ubuntu-xenial-core-cloudimg-amd64-root:~# root@ubuntu-xenial-core-cloudimg-amd64-root:~# cat /etc/os-release NAME="Ubuntu"
VERSION="16.04.4 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.4 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenialroot@ubuntu-xenial-core-cloudimg-amd64-root:~# exitlogout
Container ubuntu-xenial-core-cloudimg-amd64-root exited successfully.# cat /etc/os-release NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
ID_LIKE=archlinux
ANSI_COLOR="0;36"
HOME_URL="https://www.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://bugs.archlinux.org/"Systemd Timers
It’s time to see an example on timers in systemd.
Intro
Before we start, let’s clarify some things.
systemd’s Timers are units. Units are the simplest form of systemd files. Units are describing “when and if” a unit service “should or must” run, based on real or relative time.
-
A real time example is similar to a cron job entry. You can find out all the configuration settings/values for OnCalendar here.
-
A relative time example is more close to something like:
“Run this unit service, ten minutes after boot, before this service and also that services must have already been started cause I am depend on them.”
List of systemd-timers
To view the declared timers on a systemd, run the below command:
$ systemctl list-timers
we can see all timers, even the in-active ones, with:
# systemctl list-timers --all
one simple example
ok, let’s start with an example.
I’ll use the /usr/local/bin directory to store my custom scripts, as this directory is in the PATH enviroment variable and I can run these scripts from anywhere.
Our systemd unit files, must be under the /etc/systemd/system/ directory.
Part One: The Script
As an example, the script will mount some volumes after boot time.
The basic script contents the below lines:
# cat /usr/local/bin/mount.volumes.sh
#!/bin/sh
/usr/bin/mount /mnt/backup
/usr/bin/mount /var/lib/dockerand make it executable:
# chmod +x /usr/local/bin/mount.volumes.sh
You can run this script, once or twice to see if everything goes as planned.
Part Two: The Service
Now it’s time to create a systemd service unit:
# vim /etc/systemd/system/mount.volumes.service
[Unit]
Description=Mount Backup & Docker Volume Service
[Service]
Type=simple
ExecStart=/usr/local/bin/mount.volumes.sh
[Install]
WantedBy=multi-user.target
Part Three: The Timer
Now it is time to create the systemd timer unit:
# vim /etc/systemd/system/mount.volumes.timer
We have to decide when we want to service to run.
eg. Every day, but 45sec after boot
[Unit]
Description=Mount Backup & Docker Volume @ reboot
[Timer]
OnBootSec=45sec
OnUnitActiveSec=1day
Unit=mount.volumes.service
[Install]
WantedBy=multi-user.target-
Time to wait after booting before we run first time: OnBootSec
-
Time between running each consecutive time: OnUnitActiveSec
voila !
Part Four: Enable Service
Be aware, we havent finished yet!
Check that systemd can identify these files:
# systemctl list-unit-files | egrep mount.volumes
mount.volumes.service disabled
mount.volumes.timer disabled We can run the systemd service by hand:
# systemctl start mount.volumes.servicee
and see the ouput/results via journalct:
# journalctl -f
Part Five: Enable Timer
finally we need to start & enable (so that runs after reboot) the timer:
start
# systemctl start mount.volumes.timer
enable
# systemctl enable mount.volumes.timer
Created symlink /etc/systemd/system/multi-user.target.wants/mount.volumes.timer → /etc/systemd/system/mount.volumes.timer.after that:
# systemctl list-timers | egrep mount.volume
Sat 2018-01-27 09:51:01 EET 23h left Fri 2018-01-26 09:51:01 EET 1min 16s ago mount.volumes.timer mount.volumes.serviceverify
# systemctl list-unit-files | egrep mount.volume
systemctl list-unit-files | egrep mount.volume
mount.volumes.service disabled
mount.volumes.timer enabledTo all the systemd haters, I KNOW, its one line on crontab !
If you are not using your PC/laptop as a server, then 99,99% you dont need network at the boot time.
Disabling NetworkManager can speed up your machine.
> sudo systemctl disable NetworkManager
Of course we all need network, so tell your machine to start NetworkManager after your boot process. And you can do that by editing your crontab as root:
> sudo -s
# crontab -e
and typing
@reboot systemctl start NetworkManager
try this and measure the time you have saved by
systemd-analyze
before and after .
Wed 18 Sep 2013 19:00 @ http://hackerspace.gr
Intro Workshop for systemd !
systemd is a system and service manager for Linux, compatible with SysV and LSB init scripts
I’ve recently bought a new laptop.
It has a hybrid disk (470G HDD and a 30G SSD).
On the 30G ssd disk i’ve rsynced my archlinux from my previous laptop to the new one.
The boot process takes almost a full two minutes !
I thought i was drafting to the dark side and my sanity wasnt as good as a couple days ago.
After asking to archlinux forum, they suggest to use
# journalctl -b
I have found that there was an entry at /etc/crypttab (that doesnt exist) and the timeout was almost 90 seconds.
Comment that out and then 14sec to login !!!
I was thinking to convert to systemd for quite some time now
So every time someone mentioned something about systemd (on the internet), i was reading his/her story as my life depend on it.
I am using archlinux so when i’ve read Jason’s blog post,
i was very happy. After a few days, Allan post a similar post
and that was the moment i told my self: “It’s time, i can blame Allan for breaking my system”
I run this command
# pacman -S systemd systemd-arch-units systemd-sysvcompat
and removed sysvinit & initscripts also.
Noticed that /etc/rc.conf became /etc/rc.conf.pacsave
and rebooted my machine.
How difficult is that ?
There was also a few steps that i needed to do.
Your reading material is here: Archlinux systemd and
systemd services .
After that was trivial to enable my services.
I have only a few of them:
# grep DAEMONS /etc/rc.conf.pacsave
DAEMONS=(syslog-ng network crond dbus avahi-daemon cupsd xinetd)
I use static network at work.
Followed this link to create my network service.
vim /etc/conf.d/network
vim /etc/systemd/system/network.service
# systemctl status network
# systemctl enable network.service
# systemctl status syslog-ng
# systemctl enable syslog-ng.service
be aware that cron is cronie !
systemctl status crond.service
systemctl enable cronie.service
systemctl status avahi-daemon
systemctl enable avahi-daemon.service
dbus was already enabled
systemctl status dbus
be aware that cupsd is cups
systemctl status cupsd
systemctl enable cups.service
and finally
systemctl status xinetd
systemctl enable xinetd.service
It was simplest than converted from grub to grub2 !