Linux's default scheduler (CFS/EEVDF, depending on kernel version and configuration) is a strong general-purpose choice. Still, a single scheduler cannot be optimal for every workload: interactive desktops, low-latency audio, latency-sensitive gaming, build servers, and throughput-heavy batch systems often want different trade-offs.

The sched_ext framework (often referred to as SCX) changes the game: it allows you to run a scheduler implemented as an eBPF program. The scx-tools project ships tooling and reference schedulers; scx-scheds is commonly used to describe the set of sched_ext scheduler implementations you can run and experiment with.

This article focuses on Arch Linux: what you gain with SCX schedulers, what options exist, and how to install, configure, and enable them as a service.

Why use an SCX scheduler? (Benefits)

1) Workload-specific tuning without patching the kernel

With sched_ext, you can switch schedulers (or update them) without maintaining kernel patch sets. In many cases you can:

• keep your standard Arch kernel (as long as it supports sched_ext),
• install a userspace scheduler binary,
• enable/disable it like any other service.

2) Faster iteration and experimentation

Schedulers can be developed and tuned much faster than traditional in-kernel scheduling code. This makes SCX attractive for:

• desktop responsiveness experiments,
• new heuristics for heterogeneous CPUs,
• latency reduction under load,
• research and benchmarking.

3) Better latency / responsiveness for certain setups

Many users try SCX schedulers for perceptible improvements in:

• UI smoothness during compilation or heavy background tasks,
• gaming frame-time consistency under load,
• audio production (glitch resistance),
• interactive shells and editors.

Actual results vary by kernel, CPU topology, power settings, and the chosen scheduler.

4) Observability and control via eBPF

The eBPF ecosystem makes it practical to introspect behavior and iterate on policies. Some schedulers expose parameters, logging, or statistics that can be monitored.

What options do you have? (Schedulers and approaches)

There is no single “best” SCX scheduler. Instead, pick a policy that matches your goals.

Common categories

• Balanced / general-purpose: aims to be a drop-in alternative focused on smoothness while staying robust across workloads.
• Latency-focused: prioritizes interactive tasks and wake-up latencies, often at some throughput cost.
• Throughput / batch: focuses on maximizing overall throughput for build servers and compute-heavy workloads.
• Experimental / research: meant for exploration, not necessarily daily-driver stability.

A quick “which one should I try first?” guide

Use this as a starting point, not as a universal truth:

Examples you will likely encounter

Depending on your installed package version, binaries may include schedulers such as:

• scx_rusty (often considered a good “daily driver” starting point)
• scx_lavd (commonly discussed for latency-focused behavior)
• scx_simple (often used for testing, debugging, or as references)

If your build includes scx_bpfland, it is often positioned as a desktop/gaming-oriented option. Treat it like any other scheduler: validate stability and benchmark on your own hardware.

Names and available schedulers differ by release. On your system, list what is installed:

ls -1 /usr/bin/scx_* 2>/dev/null
# or with scx-tools installed
scxctl list

If you see a loader or manager tool in your package (some releases include helpers), prefer that for starting/stopping schedulers. Otherwise, you can run a scheduler binary directly.

Prerequisites on Arch Linux

1) Kernel support for sched_ext

You need a kernel that includes sched_ext and has it enabled.

In practice, this usually means running a recent Arch kernel (or an alternative kernel package) that includes sched_ext. If sched_ext is missing, installing newer kernels (or trying an alternative kernel flavour) is the first step.

Quick checks:

uname -r

If CONFIG_IKCONFIG_PROC is enabled, you can check the running kernel config:

zgrep -E 'CONFIG_SCHED_CLASS_EXT|CONFIG_SCHED_EXT' /proc/config.gz

If that file does not exist on your system, check your kernel’s config in /usr/lib/modules/$(uname -r)/build/.config (if available) or consult the kernel package documentation.

2) eBPF capabilities

Schedulers typically need elevated privileges to load eBPF programs. Expect to run them as root via systemd.

3) Keep a fallback plan

If you are experimenting on a production machine, have a way to revert quickly:

• keep SSH access,
• keep a known-good kernel in the bootloader,
• know how to disable the service from a TTY.

Installation on Arch Linux

Option A: Install from official repos (if available)

Package availability changes over time. Start by searching:

pacman -Ss scx

If you find scx-tools / scx-scheds packages in your configured repositories, install them with pacman -S ….

Option B: Install from the AUR

If packages are not in the official repos, they are commonly provided via the AUR (often as -git variants).

Example using an AUR helper:

yay -S scx-tools-git scx-scheds-git

If you do not use an AUR helper, build using makepkg in the usual Arch way.

If you build from source, expect typical eBPF build dependencies (compiler toolchain and libbpf-related components). Package recipes usually document the exact list for Arch.

Verify installation

command -v scx_rusty || true
ls -1 /usr/bin/scx_* 2>/dev/null

Configuration and setup

SCX schedulers usually accept command-line flags for tuning. Because these flags can change by version, always consult the built-in help:

scx_rusty --help

A practical approach: start with defaults

1) Start one scheduler manually (root):

sudo scx_rusty

2) Use your system normally for a while (desktop use, compile something, game, etc.).

3) If it feels good and stable, move to a systemd service.

Tuning

Schedulers differ in what they expose:

• latency/throughput knobs
• CPU selection, NUMA or SMT considerations
• logging/telemetry levels

Treat tuning like performance engineering:

• change one setting at a time,
• benchmark under repeatable conditions,
• keep notes of kernel version, microcode, power governor, and BIOS settings.

Enable as a systemd service (recommended)

The cleanest method on Arch is a dedicated service that starts your chosen scheduler at boot.

Option A: Use scx_loader.service (preferred when available)

Many Arch packages ship scx-loader, a small manager that starts the configured sched_ext scheduler for you. When present, it is usually the easiest and most maintainable approach.

1) Understand the configuration search order

scx_loader typically looks for a configuration file in the following locations (first match wins):

1. /etc/scx_loader/config.toml
2. /etc/scx_loader.toml
3. /usr/share/scx_loader/config.toml
4. /usr/share/scx_loader.toml

On Arch, a vendor example (or an empty placeholder) is often installed under /usr/share/scx_loader/. Do not edit vendor files; create your own config under /etc/.

Useful command:

# Find packaged examples and paths
pacman -Ql scx-tools | grep -E 'scx_loader|config\.toml'

2) Create a minimal config

Create /etc/scx_loader/config.toml and start with a conservative scheduler choice. The exact schema can change; always verify against upstream documentation.

Upstream configuration reference:

• https://github.com/sched-ext/scx-loader/blob/main/crates/scx_loader/configuration.md

3) Start and enable the service

sudo systemctl enable --now scx_loader.service

4) Verify status and logs

systemctl status scx_loader.service
journalctl -u scx_loader.service -b

5) Disable (fallback)

sudo systemctl disable --now scx_loader.service

Option B: Run a scheduler binary directly (simple but less flexible)

If you do not have scx_loader, you can create a small systemd unit that runs a scheduler binary (for example, scx_rusty) with your desired flags.

For general systemd background on Arch, see:

• https://wiki.archlinux.org/title/systemd

Benchmarking: how to measure improvements

Scheduler changes can improve “feel” (responsiveness) while leaving traditional throughput benchmarks unchanged—or vice versa. Use a mix of metrics.

Recommended tools

• schbench (scheduler benchmark focused on latency)
• stress-ng (load generation, includes latency-related tests)
• perf and bpftrace (observability)
• Phoronix Test Suite (repeatable macro benchmarks)

Examples:

# Example: install benchmarking tools
sudo pacman -S --needed perf stress-ng

If schbench is not packaged in your repos, look for it in the AUR.

A simple methodology

1) Pick a baseline (default scheduler; disable SCX service). 2) Run 3–5 iterations of your chosen tests. 3) Enable the SCX scheduler. 4) Repeat the same tests. 5) Compare medians (not best runs).

What to watch

• frame-time consistency (for games)
• audio XRUNs/glitches (for pro audio)
• wake-up latency and tail latencies under load
• compile time vs interactive responsiveness trade-off

Troubleshooting

Service fails to start

• Check journalctl -u scx_loader.service -b for verifier errors or missing capabilities.
• Verify you are running a kernel with sched_ext support.
• Remove systemd hardening temporarily to rule out permission issues.

System feels worse

• Switch back to the default scheduler (stop the service).
• Try a different SCX scheduler (balanced vs latency-focused).
• Re-test with CPU governor settings fixed (e.g., avoid mixed power profiles during benchmarking).

External links (docs, code, discussion, and benchmarks)

• sched_ext / SCX upstream project (code and documentation):
  • https://github.com/sched-ext/scx
• scx-tools (repository entry points and tooling live in the same upstream org):
  • https://github.com/sched-ext
• Arch Wiki (systemd basics and service management):
  • https://wiki.archlinux.org/title/systemd
• Linux kernel scheduler documentation (general background):
  • https://docs.kernel.org/scheduler/index.html
• eBPF documentation (background and tooling):
  • https://docs.kernel.org/bpf/index.html
• Benchmarking and comparisons (independent sources):
  • https://www.phoronix.com/
  • https://www.phoronix.com/search/scx
  • https://www.phoronix.com/search/sched_ext
  • https://openbenchmarking.org/
  • https://flightlesssomething.ambrosia.one/
• Community discussion and background (useful for understanding trade-offs):
  • https://lwn.net/Search/DoSearch?words=sched_ext
  • https://wiki.cachyos.org/de/configuration/sched-ext/

Conclusion

SCX schedulers (sched_ext) give Arch Linux users a practical way to tune scheduling policy to their workload—whether your priority is desktop responsiveness, lower latency under load, or throughput for batch tasks. Start with a conservative scheduler, validate stability, enable it via scx_loader.service when available, and benchmark methodically before drawing conclusions.

Heute habe ich meinen Filemanager, an dem ich seit einem Jahr arbeite, als Development Snapshot öffentlich gestellt. Ich hoffe, dass er auf Zustimmung trifft und weitere Entwickler zum Mitmachen begeistern kann.

NEF bedeutet „Noch Ein Filemanager“ und ich habe ihn geschrieben, weil ich unter Linux einen Filemanager vermisse, den ich so gestalten kann, wie ich möchte, ohne einen zehnten Norton-Commander-Klon zu schaffen.

Er befindet sich noch im Alpha-Status, ist aber an sich schon gut benutzbar. Allerdings existiert noch kein „make install“ oder sonstige Desktop-Integration, aber das ist auch nur eine Frage der Zeit.

Wer ihn ausprobieren möchte, kann ihn gerne aus dem Git-Repository auschecken und starten. Die nötigen Schritte stehen in der README.

Viel Spaß beim Testen.

Screenshots

NEF-Filemanager Einzelansicht

NEF-Filemanager Dual-Lister

NEF-Filemanager Multi-Lister

Links

• NEF-Filemanager Git-Repository bei codeberg.org

After every major PostgreSQL update, you need to migrate the database to the new version. Fortunately, on Arch Linux, this process is quite smooth with these commands.

Workflow

Install Old PostgreSQL

yay postgresql-old-upgrade

Stop Server

systemctl stop postgresql

Upgrade as Root

# Get last DB version
cat /var/lib/postgres/data/PG_VERSION

# Move current data to olddata
mv /var/lib/postgres/data /var/lib/postgres/olddata
mkdir /var/lib/postgres/data /var/lib/postgres/tmp
chown postgres:postgres /var/lib/postgres/data /var/lib/postgres/tmp

# Initialize a new database as the postgres user and migrate the old data to the new database
su postgres
initdb -D /var/lib/postgres/data --locale=C.UTF-8 --encoding=UTF8 --data-checksums
# Replace PG_VERSION with the old version number from the first step
pg_upgrade -b /opt/pgsql-PG_VERSION/bin -B /usr/bin -d /var/lib/postgres/olddata -D /var/lib/postgres/data

# If you get the error: "old cluster does not use data checksums but the new one does", enter the following command and repeat pg_upgrade
pg_checksums --disable --pgdata /var/lib/postgres/data

exit # Exit your su session

Start Server

systemctl stop postgresql

Optimize

su postgres
/usr/bin/vacuumdb --all --analyze-in-stages --missing-stats-only
/usr/bin/vacuumdb --all --analyze-only
exit

Links

• ArchWiki: PostgreSQL — Upgrading PostgreSQL
• Arch Linux BBS: postgres: old cluster does not use data checksums but..

Ich suchte für eine Sync Lösung für meine Notizen und wurde bei Obsidian fündig. Obsidian hat einen Großen Pool an Add-ons und einer der Spannenden ist wohl LiveSync.

Zum aufsetzten, habe ich mich für die Self Hosting Version entschieden, bei der man eine Docker mit CouchDB aufsetzt und in meinem Fall hinter einen Nginx für https betreibt.

docker-compose.yml

Für den CouchDB docker habe ich mich für diesen entschieden docker-obsidian-livesync-couchdb und lege eine docker-compose.yml in einem Directory an was für die Daten der DB gedacht ist.

services:
  couchdb-obsidian-livesync:
    image: docker.io/oleduc/docker-obsidian-livesync-couchdb:master
    container_name: couchdb-obsidian-livesync
    restart: always
    environment:
      SERVER_URL: $example.domain
      COUCHDB_USER: myadminuser
      COUCHDB_PASSWORD: mytopsecretadminpw
      COUCHDB_DATABASE: obsidian
    ports:
      - "127.0.0.1:5984:5984"
    volumes:
      - "${LD_HOST_DATA_DIR:-./data}:/opt/couchdb/data"

Systemd service

Erzeugen eines Services der beim Reboot gestartet wird. Dazu legen wir das File oder Symlink nach /etc/systemd/system/obsidian-livesync-couchdb.service an.

[Unit]
Description=%p container

PartOf=docker.service
After=network.target docker.service
StartLimitIntervalSec=0

[Service]
Type=oneshot
RemainAfterExit=true
User=user
WorkingDirectory=/$dataLocationpath$/obsidian-livesync-couchdb/

ExecStart=/usr/bin/docker compose up -d --remove-orphans
ExecStop=/usr/bin/docker compose down

[Install]
WantedBy=multi-user.target

$dataLocationpath$ muss durch den Path ersetzt werden in dem das docker-compose.yml File liegt und in den unter /data die DB Daten liegen werden.

User=user ist der Service User unter dem die File rechte liegen und kann angepasst werden.

Starten des Services

systemctl start obsidian-livesync-couchdb.service
systemctl enable obsidian-livesync-couchdb.service

Nginx VHost

server {
    server_name $example.domain;


        root /dummy/default/root;

        # Add index.php to the list if you are using PHP
        index index.html index.htm;

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass http://127.0.0.1:5984;
    }


    listen 80;
}

Let's Encrypt

Und nach dem nun noch das SSL Certificat mit Let's Encrypt

certbot --nginx -d $example.domain

Nun sollte man auf die DB zugreifen können die Url ist:

https://$example.domain/_utils

Die aktuell Config ist hier zu finden:

https://$example.domain/_node/_local/_config

DB Setup

Für das Setup der CouchDB gibt es ein init Script welsches die erste schritte übernimmt, wenn der Docker dies noch nicht von selber erledigt hatte.

export hostname=https://$example.domain
export username=myadminuser
export password=mytopsecretadminpw

curl -s https://raw.githubusercontent.com/vrtmrz/obsidian-livesync/main/utils/couchdb/couchdb-init.sh | bash

Setup-URI Generieren

Mit der Setup URI kann man den Server und die Obsedian APP Verheiraten damit man nicht alles Manuel eintragen muss. Zusätzliche env variable zu den obere von DB Setup.

export passphrase=enryptpassword

Erzeugen der Setup-URI

deno run -A https://raw.githubusercontent.com/vrtmrz/obsidian-livesync/main/utils/flyio/generate_setupuri.ts

Mit diesen Script bekommt man jetzt ein password und eine obsidian://setuplivesync?settings= welsche man in das Obsidian Add-on eingeben muss.

Obsidian Setup

Jetzt geht man bei Obsidian in Preference → Extrenal Add-ons, sucht dort nach Lifesync und installiert es.

Jetzt kann man die setuplivesync URI dort bei Optionen hinzufügen und wird nach dem Setup-URI Password gefragt und danach kommen ein wichtiges Setup Wizard, den man je nach Client richtig durchspielen muss, damit man ja nicht seine alten Daten verliert. Genau dasselbe muss man dann auch bei allen anderen Client durchspielen und aufpassen das man Merge verwendet um somit auf allen Clients denselben stand hat.

Viel Spaß

Links

Obsidian.md

Self-hosted LiveSync on github.com

docker-obsidian-livesync-couchdb

Heute beschreibe ich, wie ich einen Mailserver mit IMAP, validen SSL-Zertifikat mithilfe von nginx, Let’s Encrypt, Antispam mit Spamassassin, DNS-Blacklist und IMAP via Dovecot aufbaue.

Installieren der Grundpackete

apt install exim4-daemon-heavy sa-exim spamassassin spf-tools-perl bind9-dnsutils swaks libnet-ssleay-perl dovecot-core dovecot-imapd nginx-light python3-certbot-nginx python3-certbot net-tools

SSL-Zertifikat via nginx für Exim4

Als Erstes werde ich mir ein SSL-Zertifikat für Exim4 via nginx und dem Certbot erzeugen. Dafür brauche ich einen Vhost, der weiterhin existieren muss und zum Zertifikat updaten genutzt wird.

mkdir -p /var/www/serverdummy
$ cd /etc/nginx/sites-available
touch  $domainname
nano $domainname

server {
    server_name $domainname;

        root /var/www/serverdummy;

        # Add index.php to the list if you are using PHP
        index index.html index.htm;
}

Symlink zum Einschalten des Vhosts und nginx restarten:

cd ../sites-enabled
ln -s ../sites-available/$domainname ./
service nginx restart

Let’s Encrypt Zertificat für Exim4

Jetzt bauen wir uns einen Script, der uns beim Updaten das neue SSL-Zertificat in unser Exim-Directory kopiert.

mkdir -p /etc/letsencrypt/renewal-hooks/post/
nano  /etc/letsencrypt/renewal-hooks/post/exim_key.sh

Jetzt fügen wir dieses Script dort ein, "$domainnam durch deine Domain ersetzten":

#!/bin/sh

cp /etc/letsencrypt/live/$domainname/fullchain.pem /etc/exim4/exim.crt
cp /etc/letsencrypt/live/$domainname/privkey.pem /etc/exim4/exim.key

chown root:Debian-exim /etc/exim4/exim.crt
chown root:Debian-exim /etc/exim4/exim.key

chmod 640 /etc/exim4/exim.crt
chmod 640 /etc/exim4/exim.key

service exim4 restart

Das Script müssen wir nun ausführbar machen und beantragen ein neues Zertifikat mit nginx und forcieren mit --force-renewal das unser Script getestet wird.

chmod +x /etc/letsencrypt/renewal-hooks/post/exim_key.sh
certbot --nginx -d $domainname
certbot renew --force-renewal

Wenn jetzt in 'ls /etc/exim' unser exim.crt und exim.key Files existieren, hat alles geklappt :)

Exim4 Konfigurieren

update-exim4.conf.conf

"$serverip durch Deine Server-IP ersetzen"

dc_eximconfig_configtype='internet'
dc_other_hostnames='$domainname;noch-eine-domain.tld
dc_local_interfaces='127.0.0.1;$serverip'
dc_readhost=''
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost=''
CFILEMODE='644'
dc_use_split_config='true'
dc_hide_mailname=''
dc_mailname_in_oh='true'
dc_localdelivery='maildir_home'

Virtuelle Domains

Weil dieser Server mehr als eine Domain handhaben soll, aber auch nicht alle User auf jeder Domain einen Account haben sollen, mache ich mir den Umweg über Domainlisten mit User-Listen in denen man als alias so wie eine Weiterleitung konfigurieren kann.

mkdir /etc/exim4/domains
touch /etc/exim4/domains/$domainname
nano /etc/exim4/domains/$domainname

Die Syntax ist jetzt "Mail-Username: localname" oder "Mail-Username: Mailalias"

user1: user1
postmaster: user1
user2: klauspeter@externedomain[.]com

Und jetzt braucht es noch einen Router für unsere virtuellen Mails.

Dafür legen wir das File /etc/exim4/conf.d/router/090_exim4-config_virtuals mit diesem Inhalt an:

virtuals:
    driver = redirect
    allow_defer
    allow_fail
    data = $local_part_data
    domains = dsearch,ret=full;//etc/exim4/domains
    local_parts = wildlsearch;$domain_data
    retry_use_local_part
# no_more

Damit gehen jetzt Mails an user1@$domainname z.b. an den User user1 und Mails an user2@$domainname werden an user2@externedomain[.]com weitergeleitet, wobei der Mailserver von externedomain[.]com unseren Server jetzt natürlich als relay akzeptieren muss.

Durch wildlsearch gehen auch wildcard aliase wie *+test : username was alle Mails mit +test am ende weiterleitet wie shopname+test@domain.

00_localconfig

Für unsere lokale Konfiguration legen wir jetzt ein eigenes File an, in dem wir alle möglichen Regeln festlegen.

nano /etc/exim4/conf.d/main/00_localconfig

# https://wiki.debian.org/Exim

MAIN_TLS_ENABLE = true
CHECK_RCPT_SPF = true

daemon_smtp_ports = 25 : 465
tls_on_connect_ports = 465

MAIN_TLS_ADVERTISE_HOSTS=*
MESSAGE_SIZE_LIMIT=50M

REMOTE_SMTP_SMARTHOST_HOSTS_REQUIRE_TLS = *
TLS_ON_CONNECT_PORTS = 465
REQUIRE_PROTOCOL = smtps

disable_ipv6=true
dns_ipv4_lookup='*'

MAIN_IGNORE_BOUNCE_ERRORS_AFTER = 12h
MAIN_TIMEOUT_FROZEN_AFTER = 1d

Ich schalte ipv6 ab, weil Spamprotektion zum großteils über DNS-Blacklisten läuft und die sind für ipv6 nicht wirklich effektiv. Wenn es keine Spamer oder Betrüger geben würde, wäre die Welt einfacher.

00_exim4-config_header

In /etc/exim4/conf.d/acl/00_exim4-config_header schalten wir jetzt ein paar Checks ein, damit das gröbste weggefiltert werden kann.

nano /etc/exim4/conf.d/acl/00_exim4-config_header

######################################################################
#                       ACL CONFIGURATION                            #
#         Specifies access control lists for incoming SMTP mail      #
######################################################################
# https://www.dnsbl.info/dnsbl-list.php

# https://www.spamhaus.org/zen/
# http://www.sorbs.net/mailsystems/exim4.shtml
# http://www.usenix.org.uk/content/rbl.html#exim
# https://abuse.ch/?p=532

CHECK_RCPT_IP_DNSBLS = zen.spamhaus.org:dnsbl.sorbs.net:all.s5h.net:combined.abuse.ch
CHECK_MAIL_HELO_ISSUED=true
CHECK_RCPT_REVERSE_DNS=true

begin acl

25_exim4-config_check_rcpt_reject_RDNS_fail

Wenn man, wie z.z. Google es auch macht, alle Mails von Servern ignorieren will, die keinen Reverse-DNS-Eintrag haben, geht das mit dieser Regel:

nano /etc/exim4/conf.d/acl/25_exim4-config_check_rcpt_reject_RDNS_fail

.ifdef CHECK_RCPT_REVERSE_DNS
  # Verify reverse DNS lookup of the sender's host.
  deny
    message = Reverse DNS lookup failed for $sender_host_address
    log_message = Reverse DNS lookup failed for $sender_host_address
    !authenticated = *
    !verify = reverse_host_lookup
    !hosts = ${if exists{CONFDIR/local_broken_dns_whitelist}\
                      {CONFDIR/local_broken_dns_whitelist} {}}
.endif

Exim SMTP Auth via dovecot

/etc/dovecot/conf.d/10-master.conf

Als Erstes müssen wir Dovecot so einrichten, damit er uns ein Auth-Socket anbietet. Dafür ändern wir die Config in /etc/dovecot/conf.d/10-master.conf, suchen hier die Sektion "service auth {" und fügen folgende Zeilen ein:

nano /etc/dovecot/conf.d/10-master.conf

#SASL
  unix_listener auth-client {
    mode = 0660
    user = Debian-exim
  }

/etc/exim4/conf.d/auth/20_exim4-config_dovecot

Und nun fügen wir den Auth-Part in Exim ein der das Socket von Dovecot zum Authentifizieren benutzt.

nano /etc/exim4/conf.d/auth/20_exim4-config_dovecot

dovecot_plain:
  driver = dovecot
  public_name = PLAIN
  server_socket = /var/run/dovecot/auth-client
  server_set_id = $auth1

dovecot_ntlm:
  driver = dovecot
  public_name = NTLM
  server_socket = /var/run/dovecot/auth-client
  server_set_id = $auth1

Restart Dovecot und Exim:

service dovecot restart
update-exim4.conf
service exim4 restart

Exim Router für virtuelle dovecot User

/etc/exim4/conf.d/router/950_exim4-config_dovecot

nano /etc/exim4/conf.d/router/950_exim4-config_dovecot

# Router to send any mail for who a dovecot user exists to the appropriate maildir box
# Routers are evaluated in order of configuration.
# You will want to place this after the remote router and before the
# localuser router in the default configuration.
# If you want to allow + addressing (ie having an address extension)
# then uncomment the suffix stanzas
dovecot_router:
  driver = accept
  local_parts = ! root
  require_files = +/home/virtual/${local_part}/
  transport = dovecot_transport

/etc/exim4/conf.d/transport/50_exim4-config_dovecot

nano /etc/exim4/conf.d/transport/50_exim4-config_dovecot

# Transport to send any mail for who a dovecot user exists to the appropriate maildir box
# Transports definitions are not order dependant - you just call a named transport
dovecot_transport:
  driver = appendfile
  user = vmail
  group = vmail
  mode = 0640
  directory=/home/virtual/${lc:$local_part}/Maildir/
  maildir_format = true
  mode_fail_narrower = false
  envelope_to_add = true
  return_path_add = true

Create vmail user and group

groupadd vmail
useradd -g vmail -s /usr/bin/nologin -d /home/virtual -m vmail

/etc/dovecot/conf.d/10-mail.conf

Die mail_location muss in Dovecot noch auf MailDir umgestellt werden. Als default Steht es auf mbox "mail_location = mbox:~/mail:INBOX=/var/mail/%u"

nano /etc/dovecot/conf.d/10-mail.conf

mail_location = maildir:~/Maildir

Virtuelle User in der Dovecot Config einrichten

nano /etc/dovecot/conf.d/auth-passwdfile.conf.ext

Folgende Zeile in den userdb { Bereich eintragen:

default_fields = uid=vmail gid=vmail home=/home/virtual/%u

Und jetzt muss man das Laden des Files noch einkommentieren in:

nano /etc/dovecot/conf.d/10-auth.conf

Am Ende des Files !include auth-passwdfile.conf.ext die Raute entfernen und den Dienst restarten.

Neuen Mailuser in Dovecot anlegen

User kann man jetzt mit doveadm anlegen, indem man ein Password mit doveadm generiert und den User dann in /etc/dovecot/users einträgt.

Ein Password generieren.

doveadm pw -s SHA512-CRYPT

nano /etc/dovecot/users
chown root:dovecot /etc/dovecot/users
chmod 640 /etc/dovecot/users

Und ein User ist dann z.b. so aufgebaut.

name:passwd:::/ome/virtual/name:::

Also für den User: user1 mit dem Password ‚geheim‘:

user1:{SHA512-CRYPT}$6$LYd4Ss8kxrEYK6to$1SEvEKLuwhSNdN3IVSKJgfGZ1zqs7Q4lHXv4gsmuTyM37sxwSEpmHM5N4zumbV1ZWER2CD1J8xM9IQEhDr4yh0:::/home/virtual/user1:::
user2:{PLAIN}secret:::/home/virtual/user2:::

Lokaluserdaten ausgeben

doveadm user user1 user2 email@mail.com

Maildir Ordner anlegen

sudo -u vmail mkdir -p /home/virtual/testuser/Maildir

service dovecot restart

User zur Exim-virtuellen-Domain hinzufügen

Nun muss man den User in eine oder mehrere Domains hinzufügen in /etc/exim4/domains/. Man kann also einen Username, bei diesem Setup nur einmal im System haben.

Spamassassin Setup

sa-exim.conf

Damit Spamassassin in Exim funktioniert, muss man noch die sa-exim Config anpassen. Als Erstes muss man die Zeile mit "SAEximRunCond: 0" auskommentieren:

# SAEximRunCond: 0

Um lokale Scanns zu verhindern, fügen wir jetzt diese Zeile hinzu:

SAEximRunCond: ${if and {{def:sender_host_address}{!eq{$acl_m0}{noscan}}}}

add noscan in 30_exim4-config_check_rcpt

Und ändern noch ein paar Sachen an der Exim Config, damit ‚noscan‘ auch gesetzt wird:

nano /etc/exim4/conf.d/acl/30_exim4-config_check_rcpt

acl_check_rcpt: anspassen

Hier muss die Zeile mit "set acl_m0 = noscan" hinzugefügt werden:

acl_check_rcpt:

  # Accept if the source is local SMTP (i.e. not over TCP/IP). We do this by
  # testing for an empty sending host field.
  accept
    hosts = :
    control = dkim_disable_verify
    set acl_m0 = noscan

Und so suchen wir jetzt noch mehr Sektionen mit "control = dkim_disable_verify" und wenn sie in einem accept-Sektion sind, fügen wir "set acl_m0 = noscan" hinzu. Z.Z habe ich insgesamt 3* "set acl_m0 = noscan" in meiner Config.

1. acl_check_rcpt
2. hosts = +relay_from_hosts
3. authenticated = *

Enabel Update via Cronjob

nano /etc/default/spamassassin

Hier gibt es jetzt eine Zeile mit CRON=0 wo man die 0 durch eine 1 ersetzen muss:

CRON=1

Spamassassin Service

Per default wird Spamassassin nicht als Service gestartet. Um das einzuschalten, muss man dieses Kommando ausführen:

update-rc.d spamassassin enable
service spamassassin restart

Config übernehmen und Service restarten

update-exim4.conf
service exim4 restart

SMTP testen

swaks -a -tls -q HELO -s localhost -au username -ap '<>'

Exim live log

Alle log-Files ohne einen Punkt anzeigen in der bash :)

shopt -s extglob
tail -f /var/log/exim4/!(*\.*)

Exim Kommandos

Statistiken

eximstats /var/log/exim4/mainlog

Mails in der Warteschlange

exim4 -bpru
exim -bp | exiqsumm

oder

mailq
mailq | exiqsumm

Konfig Testen

Testen, was mit einer Mail passiert.

exim -bt tarfet@mail.net

Viel Spaß beim Nachbauen.

Links

• DNS-Blacklisten gegen Spam
• Dovecot als Authenticator für Exim
• Ein paar Nützliche commands
• Simple Sirtual Users in Dovecot
• Exim Doku Single-key lookup types