<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>dragons@work</title>
		<link>https://dragons-at-work.de/en/</link>
		<description>Recent content on dragons@work</description>
		<generator>Hugo</generator>
		<language>en</language>
		
		
		
		
			<atom:link href="https://dragons-at-work.de/en/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>OpenBSD: Security Begins with Design</title>
				<link>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/operating-systems/openbsd/introduction/</link>
				<pubDate>Wed, 29 Oct 2025 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/operating-systems/openbsd/introduction/</guid>
				<description>&lt;p&gt;OpenBSD is widely regarded as one of the most secure operating systems in the world. It was created from the conviction that security should not be added afterwards, but designed into the system from the very beginning.&lt;/p&gt;&#xA;&lt;p&gt;After installation, OpenBSD starts with only two active network services: SSH and cron. Every other service remains disabled. This deliberate reduction to the essentials lies at the heart of the project&amp;rsquo;s secure-by-default philosophy—attack surfaces exist only where the administrator explicitly creates them.&lt;/p&gt;</description>
			</item>
			<item>
				<title>The Init Concept: PID 1 and System Startup</title>
				<link>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/init-systems/init-concept/</link>
				<pubDate>Tue, 07 Oct 2025 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/init-systems/init-concept/</guid>
				<description>&lt;p&gt;The init process always has process ID 1 (PID 1). After the kernel starts, &lt;code&gt;/sbin/init&lt;/code&gt; is executed as the first user-space process. This process runs until the system shuts down and is the ancestor of all other processes.&lt;/p&gt;&#xA;&lt;h2 id=&#34;pid-1-the-first-process&#34;&gt;PID 1: The First Process&lt;/h2&gt;&#xA;&lt;p&gt;The kernel starts after the bootloader and initializes the hardware, memory, and filesystems. As soon as the root filesystem is mounted, the kernel executes &lt;code&gt;/sbin/init&lt;/code&gt;. This process automatically receives PID 1—the lowest available process ID.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Filesystem Hierarchy: The Directory Tree</title>
				<link>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/linux-unix-filesystem/filesystem-hierarchy/</link>
				<pubDate>Mon, 06 Oct 2025 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/linux-unix-filesystem/filesystem-hierarchy/</guid>
				<description>&lt;p&gt;Linux and BSD organize all files into a single directory tree that begins at &lt;code&gt;/&lt;/code&gt; (the root). Every directory has a defined purpose—&lt;code&gt;/etc&lt;/code&gt; contains configuration files, &lt;code&gt;/var&lt;/code&gt; stores variable data, and &lt;code&gt;/home&lt;/code&gt; contains user home directories. This clear structure makes navigation and system maintenance consistent across Unix systems.&lt;/p&gt;&#xA;&lt;p&gt;The Filesystem Hierarchy Standard (FHS) has defined this structure since 1994. Linux distributions largely follow this standard, while BSD systems use their own conventions based on similar principles. The basic structure remains the same—once you understand it, you can navigate any Unix system.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Repository Systems: Central Package Sources</title>
				<link>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/package-management-concepts/repository-systems/</link>
				<pubDate>Mon, 06 Oct 2025 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/package-management-concepts/repository-systems/</guid>
				<description>&lt;p&gt;Unix systems distribute software through central package sources (repositories). A repository is a server containing thousands of packages—applications, libraries, developer tools. The package manager downloads package lists, searches for installable software, and verifies authenticity using cryptographic signatures.&lt;/p&gt;&#xA;&lt;p&gt;Debian has more than 60,000 packages in its repositories, Arch about 13,000 in the Core repository plus thousands in the AUR. OpenBSD provides about 11,000 packages. These numbers illustrate the scale of modern package sources—almost every piece of software you need has already been packaged and tested.&lt;/p&gt;</description>
			</item>
			<item>
				<title>The 3-2-1 Rule and Storage Media: Backup Fundamentals</title>
				<link>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/backup-strategies/3-2-1-rule/</link>
				<pubDate>Sun, 10 Aug 2025 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/backup-strategies/3-2-1-rule/</guid>
				<description>&lt;h2 id=&#34;software-and-versions-used&#34;&gt;Software and Versions Used&lt;/h2&gt;&#xA;&lt;p&gt;This explanation refers to:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;&lt;strong&gt;Concepts:&lt;/strong&gt; Distribution-independent backup principles&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;Storage media:&lt;/strong&gt; HDD, SSD, NAS, cloud storage&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;Encryption:&lt;/strong&gt; gpg 2.2+, age 1.0+ (concepts, not complete tutorials)&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;Context:&lt;/strong&gt; Self-hosting infrastructures, digital sovereignty&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;hr&gt;&#xA;&lt;p&gt;Hard drive failures destroy databases within seconds. Ransomware encrypts entire servers, including local backups. Fire or water damage destroys hardware and all connected storage media at the same time. A single backup stored on the same drive as the original data protects against none of these scenarios.&lt;/p&gt;</description>
			</item>
			<item>
				<title>IP Addresses and Ports: The Foundation of Self-Hosting</title>
				<link>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/network-fundamentals/ip-ports-basics/</link>
				<pubDate>Wed, 23 Jul 2025 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/network-fundamentals/ip-ports-basics/</guid>
				<description>&lt;p&gt;&lt;strong&gt;Software and Versions Used&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;This explanation applies to:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;&lt;strong&gt;TCP/IP stack:&lt;/strong&gt; IPv4 and IPv6 (RFC 791, RFC 8200)&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;Docker:&lt;/strong&gt; Version 24.0+ (for container examples)&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;Linux kernel:&lt;/strong&gt; 5.15+ (Netfilter subsystem)&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;Context:&lt;/strong&gt; Distribution-independent networking fundamentals&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;ip-addresses-are-unique-identifiers-within-the-network-namespace&#34;&gt;IP Addresses Are Unique Identifiers Within the Network Namespace&lt;/h2&gt;&#xA;&lt;p&gt;Every IP address identifies a specific network endpoint. IPv4 uses 32-bit addresses (4,294,967,296 possible addresses), while IPv6 expands this to 128 bits (340 sextillion addresses). These numbers are not theoretical constructs—they define practical limits. A /24 subnet (255.255.255.0 netmask) provides 254 usable host addresses, while a /16 subnet provides 65,534 addresses.&lt;/p&gt;</description>
			</item>
			<item>
				<title>OpenBSD: Installation and First Steps</title>
				<link>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/operating-systems/openbsd/installation-and-first-steps/</link>
				<pubDate>Thu, 30 Oct 2025 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/operating-systems/openbsd/installation-and-first-steps/</guid>
				<description>&lt;p&gt;A clean installation lays the foundation for security and reproducibility. OpenBSD is installed through an interactive dialog that guides you through every required step. The system boots from installation media, loads a minimal kernel, and starts the installer. On modern hardware, the complete installation takes around 15 minutes.&lt;/p&gt;&#xA;&lt;p&gt;The installer works with signed sets—precompiled components of the base system. Every set is verified using SHA256 checksums during installation. These signatures ensure that the installed software exactly matches what the OpenBSD project has released.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Service Management: Controlling Services</title>
				<link>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/init-systems/service-management/</link>
				<pubDate>Tue, 07 Oct 2025 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/init-systems/service-management/</guid>
				<description>&lt;p&gt;Services are programs that run in the background without direct user interaction. An SSH server waits for incoming connections, a web server delivers pages, and a database processes requests. The init system starts these services during boot and keeps them running.&lt;/p&gt;&#xA;&lt;h2 id=&#34;services-and-daemons&#34;&gt;Services and Daemons&lt;/h2&gt;&#xA;&lt;p&gt;The terms service and daemon describe the same concept with different nuances:&lt;/p&gt;&#xA;&lt;h3 id=&#34;daemon&#34;&gt;Daemon:&lt;/h3&gt;&#xA;&lt;p&gt;In the Unix tradition, background processes are called daemons. The name comes from the Greek &lt;em&gt;daimones&lt;/em&gt;—helpful spirits that work invisibly in the background. Daemon programs often end with a &lt;code&gt;d&lt;/code&gt;: &lt;code&gt;sshd&lt;/code&gt; (SSH daemon), &lt;code&gt;httpd&lt;/code&gt; (HTTP daemon), &lt;code&gt;crond&lt;/code&gt; (Cron daemon).&lt;/p&gt;</description>
			</item>
			<item>
				<title>Binary Packages vs. Source Code Compilation</title>
				<link>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/package-management-concepts/binary-vs-source/</link>
				<pubDate>Mon, 06 Oct 2025 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/package-management-concepts/binary-vs-source/</guid>
				<description>&lt;p&gt;Software exists as source code (human-readable) and binary code (machine-executable). Most distributions distribute binary packages—precompiled software that runs immediately. Source packages contain the original code and build instructions. The user compiles the software locally, producing optimized binaries for their specific system.&lt;/p&gt;&#xA;&lt;p&gt;The choice between binaries and source code affects installation speed, system customization, and maintenance effort. Debian and Red Hat-based systems prefer binary packages. Gentoo compiles from source by default. Arch provides both options—official binary packages and AUR source builds.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Permissions and Ownership: Access Control</title>
				<link>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/linux-unix-filesystem/permissions-ownership/</link>
				<pubDate>Mon, 06 Oct 2025 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/linux-unix-filesystem/permissions-ownership/</guid>
				<description>&lt;p&gt;Every file and directory on Unix systems has an owner, a group, and permissions. These three pieces of information determine who may read, modify, or execute files. The concept dates back to the 1970s and protects multi-user systems against accidental changes and unauthorized access.&lt;/p&gt;&#xA;&lt;p&gt;Permissions are divided into three categories: owner (user), group, and others. Each category can have three permissions: read, write, and execute. These nine bits define the access rights—Unix needs nothing more for functional access control.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Automation and Verification: Reliable Backup Workflows</title>
				<link>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/backup-strategies/automation-and-testing/</link>
				<pubDate>Sun, 10 Aug 2025 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/backup-strategies/automation-and-testing/</guid>
				<description>&lt;h2 id=&#34;software-and-versions-used&#34;&gt;Software and Versions Used&lt;/h2&gt;&#xA;&lt;p&gt;This explanation applies to:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;&lt;strong&gt;Concepts:&lt;/strong&gt; Cross-distribution automation principles&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;Built-in tools:&lt;/strong&gt; sha256sum, df, ln, mv, standard shell utilities&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;Context:&lt;/strong&gt; Self-hosting infrastructures, digital sovereignty&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;hr&gt;&#xA;&lt;p&gt;Manual backups fail because humans are unreliable. A forgotten backup before a critical system update can cost hours of recovery time. Weekly backup routines are skipped during vacations or illness. Automated backup systems eliminate these sources of error through consistent, scheduled execution without human intervention.&lt;/p&gt;</description>
			</item>
			<item>
				<title>DNS and Domains: Name Resolution and Local Servers</title>
				<link>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/network-fundamentals/dns-domains/</link>
				<pubDate>Wed, 23 Jul 2025 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/network-fundamentals/dns-domains/</guid>
				<description>&lt;p&gt;&lt;strong&gt;Software and Versions Used&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;This explanation applies to:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;&lt;strong&gt;DNS Protocol:&lt;/strong&gt; RFC 1035 (Domain Names standard)&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;Resolvers:&lt;/strong&gt; systemd-resolved, dnsmasq, unbound&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;Nameservers:&lt;/strong&gt; BIND 9.18+, PowerDNS 4.7+, Knot DNS 3.2+&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;Context:&lt;/strong&gt; Distribution-independent DNS fundamentals&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;dns-is-a-distributed-translation-system-without-a-central-authority&#34;&gt;DNS is a distributed translation system without a central authority&lt;/h2&gt;&#xA;&lt;p&gt;The Domain Name System (DNS) translates human-readable names into numeric IP addresses. This is accomplished through hierarchical name resolution. A query for &lt;code&gt;matrix.example.com&lt;/code&gt; passes through several stages of resolution: Root servers (.) → Top-Level Domain servers (.com) → Authoritative server (example.com) → Response containing IP addresses. DNS works identically on all operating systems.&lt;/p&gt;</description>
			</item>
			<item>
				<title>OpenBSD: System Configuration After Installation</title>
				<link>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/operating-systems/openbsd/system-configuration-after-installation/</link>
				<pubDate>Mon, 03 Nov 2025 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/operating-systems/openbsd/system-configuration-after-installation/</guid>
				<description>&lt;p&gt;OpenBSD configures systems through text files. Every network interface has its own configuration file in &lt;code&gt;/etc/hostname.INTERFACE&lt;/code&gt;. Time synchronization is handled by &lt;code&gt;ntpd&lt;/code&gt; with built-in time zone support. Privilege delegation is provided by &lt;code&gt;doas&lt;/code&gt;—OpenBSD&amp;rsquo;s system for delegated root access. Kernel parameters can be adjusted using &lt;code&gt;sysctl&lt;/code&gt;.&lt;/p&gt;&#xA;&lt;p&gt;This article explains network configuration using hostname.if files—for changes made after the &lt;a href=&#34;https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/operating-systems/openbsd/installation-and-first-steps/&#34;&gt;installation&lt;/a&gt; as well as more advanced setups for servers, desktop systems, and specialized requirements. The filesystem layout consistently follows OpenBSD conventions.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Dependencies and Startup Order</title>
				<link>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/init-systems/dependencies/</link>
				<pubDate>Tue, 07 Oct 2025 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/init-systems/dependencies/</guid>
				<description>&lt;p&gt;A web server requires functioning network interfaces. A database requires mounted file systems. Services do not start in an arbitrary order—dependencies between services determine the boot sequence. The init system resolves these dependencies and starts services in the correct order.&lt;/p&gt;&#xA;&lt;h2 id=&#34;types-of-dependencies&#34;&gt;Types of Dependencies&lt;/h2&gt;&#xA;&lt;p&gt;Service dependencies describe relationships between services. These relationships define order and necessity:&lt;/p&gt;&#xA;&lt;h3 id=&#34;startup-ordering-ordering&#34;&gt;Startup Ordering (Ordering):&lt;/h3&gt;&#xA;&lt;p&gt;A service must start before or after another service. A web server should start after the network—without networking it cannot accept connections. Ordering defines only the sequence, not the requirement. A service can start after another service even if the first one did not start successfully.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Dependency Resolution: Managing Libraries</title>
				<link>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/package-management-concepts/dependency-resolution/</link>
				<pubDate>Mon, 06 Oct 2025 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/package-management-concepts/dependency-resolution/</guid>
				<description>&lt;p&gt;Programs are rarely self-contained. A web server requires SSL libraries for HTTPS, compression libraries for gzip, and regular expression libraries for URL rewriting. These dependencies must be installed before the program can run. Package management resolves dependencies automatically—it installs missing libraries, checks version compatibility, and prevents conflicts.&lt;/p&gt;&#xA;&lt;p&gt;An &lt;code&gt;nginx&lt;/code&gt; package declares dependencies such as &lt;code&gt;libc6&lt;/code&gt;, &lt;code&gt;libssl3&lt;/code&gt;, and &lt;code&gt;libpcre2-8-0&lt;/code&gt;. The package manager checks: Are these packages installed? Do the versions match? If not, the dependencies are installed automatically. The user enters &lt;code&gt;install nginx&lt;/code&gt;, and the system installs nginx together with the 15 required libraries.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Links and File Types: Flexible Usage</title>
				<link>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/linux-unix-filesystem/links-file-types/</link>
				<pubDate>Mon, 06 Oct 2025 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/linux-unix-filesystem/links-file-types/</guid>
				<description>&lt;p&gt;Unix supports different file types—regular files, directories, links, and device files. Each type has specific characteristics and use cases. Links provide multiple names for the same file or references to files in other locations. Device files in &lt;code&gt;/dev&lt;/code&gt; represent hardware as files—hard disks, USB drives, and terminals are accessed through standard file operations.&lt;/p&gt;&#xA;&lt;p&gt;The inode concept separates file names from file contents. An inode stores the file metadata and storage locations, while the file name is only a reference to it. This separation enables hard links—multiple names point to the same inode and therefore to the same data.&lt;/p&gt;</description>
			</item>
			<item>
				<title>SSH Keys: Secure Connections Without Passwords</title>
				<link>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/network-fundamentals/ssh-keys-security/</link>
				<pubDate>Thu, 24 Jul 2025 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/network-fundamentals/ssh-keys-security/</guid>
				<description>&lt;p&gt;&lt;strong&gt;Software and Versions Used&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;This explanation applies to:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;&lt;strong&gt;SSH protocol:&lt;/strong&gt; OpenSSH 9.0+ (standard on modern systems)&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;Cryptography:&lt;/strong&gt; RSA-4096, Ed25519, ECDSA-256&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;SSH client:&lt;/strong&gt; ssh, ssh-keygen, ssh-add, ssh-agent&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;Context:&lt;/strong&gt; Distribution-independent SSH fundamentals&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;ssh-keys-replace-passwords-with-mathematical-proof&#34;&gt;SSH Keys Replace Passwords with Mathematical Proof&lt;/h2&gt;&#xA;&lt;p&gt;SSH connections without passwords use asymmetric cryptography with key pairs. The private key (&lt;code&gt;id_rsa&lt;/code&gt;) signs authentication messages, while the corresponding public key (&lt;code&gt;id_rsa.pub&lt;/code&gt;) verifies those signatures. The server stores public keys in &lt;code&gt;~/.ssh/authorized_keys&lt;/code&gt;—clients prove their identity by generating a signature with the private key without transmitting a password.&lt;/p&gt;</description>
			</item>
			<item>
				<title>OpenBSD: Package Management and Software Installation</title>
				<link>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/operating-systems/openbsd/package-management/</link>
				<pubDate>Mon, 03 Nov 2025 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/operating-systems/openbsd/package-management/</guid>
				<description>&lt;p&gt;OpenBSD keeps the base system and packages completely separate. The base system resides in &lt;code&gt;/usr/bin&lt;/code&gt; and &lt;code&gt;/usr/sbin&lt;/code&gt;, while installed packages are placed under &lt;code&gt;/usr/local&lt;/code&gt;. This separation is a core principle of OpenBSD&amp;rsquo;s stability and security model. Software is installed as binary packages—compiled, signed, and verified by the OpenBSD team. Every package carries a cryptographic signature via &lt;code&gt;signify(1)&lt;/code&gt;.&lt;/p&gt;&#xA;&lt;p&gt;&lt;a href=&#34;https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/operating-systems/openbsd/system-configuration-after-installation/&#34;&gt;System Configuration&lt;/a&gt; explains the basic system setup after installation. This article covers software installation, updates, and package management. Package management is deliberately simple—three tools handle every task: &lt;code&gt;pkg_add&lt;/code&gt;, &lt;code&gt;pkg_delete&lt;/code&gt;, and &lt;code&gt;pkg_info&lt;/code&gt;.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Mount Points and Filesystem Types</title>
				<link>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/linux-unix-filesystem/mount-points/</link>
				<pubDate>Mon, 06 Oct 2025 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/linux-unix-filesystem/mount-points/</guid>
				<description>&lt;p&gt;Unix organizes all files into a single directory tree. Additional storage devices—USB drives, hard disk partitions, network shares—are attached to this tree by mounting them. A mount point is a directory that serves as the attachment point. After mounting, the files on the storage device appear under that directory.&lt;/p&gt;&#xA;&lt;p&gt;Mounting separates the logical structure (the directory tree) from the physical storage (partitions and devices). &lt;code&gt;/home&lt;/code&gt; can reside on a separate partition, &lt;code&gt;/tmp&lt;/code&gt; in the tmpfs RAM filesystem, &lt;code&gt;/mnt/backup&lt;/code&gt; on a network share—for the user, everything appears as one continuous tree.&lt;/p&gt;</description>
			</item>
			<item>
				<title>SSH for Multiple Servers: Efficient Management</title>
				<link>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/network-fundamentals/ssh-multiple-server/</link>
				<pubDate>Thu, 24 Jul 2025 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/network-fundamentals/ssh-multiple-server/</guid>
				<description>&lt;p&gt;&lt;strong&gt;Software and Versions Used&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;This explanation applies to:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;&lt;strong&gt;SSH protocol:&lt;/strong&gt; OpenSSH 7.3+ (ProxyJump support)&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;SSH client:&lt;/strong&gt; ssh, ssh-config, ssh-agent&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;Infrastructure:&lt;/strong&gt; Multi-server setups, bastion hosts, jump hosts&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;Context:&lt;/strong&gt; Cross-platform SSH infrastructure management&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;ssh-configuration-replaces-repeated-command-line-parameters&#34;&gt;SSH Configuration Replaces Repeated Command-Line Parameters&lt;/h2&gt;&#xA;&lt;p&gt;Ten servers with different users, ports, and SSH keys require complex command lines without centralized configuration: &lt;code&gt;ssh -i ~/.ssh/webserver_key -p 2222 admin@192.168.1.100&lt;/code&gt;. The SSH configuration file &lt;code&gt;~/.ssh/config&lt;/code&gt; defines these parameters once per host. A simple &lt;code&gt;ssh webserver&lt;/code&gt; automatically reads the correct key, port, and username from the configuration.&lt;/p&gt;</description>
			</item>
			<item>
				<title>OpenBSD: Security Architecture and Protection Mechanisms</title>
				<link>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/operating-systems/openbsd/security-architecture/</link>
				<pubDate>Mon, 03 Nov 2025 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/operating-systems/openbsd/security-architecture/</guid>
				<description>&lt;p&gt;OpenBSD builds security into both the kernel and userland through deliberate design decisions. Every daemon runs with the minimum required privileges in separate processes. The &lt;code&gt;pledge()&lt;/code&gt; and &lt;code&gt;unveil()&lt;/code&gt; system calls restrict programs to defined operations and filesystem access. Memory pages are either writable or executable—never both at the same time. The kernel also provides security levels that restrict even the root account.&lt;/p&gt;&#xA;&lt;p&gt;&lt;a href=&#34;https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/operating-systems/openbsd/system-configuration-after-installation/&#34;&gt;System Configuration&lt;/a&gt; introduces &lt;code&gt;doas&lt;/code&gt; as the privilege escalation tool and &lt;code&gt;sysctl&lt;/code&gt; for kernel parameters. &lt;a href=&#34;https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/operating-systems/openbsd/package-management/&#34;&gt;Package Management&lt;/a&gt; explains package signatures using &lt;code&gt;signify(1)&lt;/code&gt;. This article describes the security architecture that protects those tools and how OpenBSD systematically reduces its attack surface.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Firewall Principles: Understanding Packet Filtering and Connection Tracking</title>
				<link>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/network-fundamentals/firewall-concepts/</link>
				<pubDate>Thu, 24 Jul 2025 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/network-fundamentals/firewall-concepts/</guid>
				<description>&lt;p&gt;&lt;strong&gt;Software and versions used&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;This explanation applies to:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;&lt;strong&gt;Concepts:&lt;/strong&gt; Packet filtering, connection tracking, stateful inspection&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;Linux:&lt;/strong&gt; Netfilter framework (Debian, Arch Linux)&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;OpenBSD:&lt;/strong&gt; Packet Filter (pf)&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;Context:&lt;/strong&gt; Distribution-independent firewall fundamentals&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;packet-filtering-operates-at-the-kernel-level&#34;&gt;Packet filtering operates at the kernel level&lt;/h2&gt;&#xA;&lt;p&gt;Every network packet passes through filtering decisions before it reaches applications. The kernel checks the source IP, destination port, protocol type, and connection state against defined rules. Allowed packets are forwarded to the corresponding application—blocked packets are discarded or answered with error messages.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Reverse Proxy: Fundamentals of Service Consolidation</title>
				<link>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/network-fundamentals/reverse-proxy-basics/</link>
				<pubDate>Sun, 27 Jul 2025 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/technix/knowledge-base/fundamentals/network-fundamentals/reverse-proxy-basics/</guid>
				<description>&lt;p&gt;&lt;strong&gt;Software and versions used&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;This explanation applies to:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;&lt;strong&gt;HTTP protocol:&lt;/strong&gt; HTTP/1.1, HTTP/2, HTTP/3&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;SSL/TLS:&lt;/strong&gt; Version 1.2+ for secure connections&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;Reverse proxy concepts:&lt;/strong&gt; Platform-independent fundamentals&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;Context:&lt;/strong&gt; Distribution-independent proxy fundamentals&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;reverse-proxy-mediates-between-clients-and-backend-services&#34;&gt;Reverse Proxy mediates between clients and backend services&lt;/h2&gt;&#xA;&lt;p&gt;A reverse proxy receives client requests and forwards them to backend services—the opposite of a forward proxy, which relays client requests to external servers. This intermediary role enables service consolidation: ten different web applications share one public IP address over port 443 instead of requiring separate IP addresses or ports for each service.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Why We Started Thinking About Organic Software</title>
				<link>https://dragons-at-work.de/en/technix/blog/why-we-started-thinking-about-organic-software/</link>
				<pubDate>Mon, 13 Jul 2026 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/technix/blog/why-we-started-thinking-about-organic-software/</guid>
				<description>&lt;p&gt;For many years, we&amp;rsquo;ve been developing software—for clients, for our own projects, and now increasingly together with AI.&lt;/p&gt;&#xA;&lt;p&gt;Along the way, we noticed something: the real effort rarely comes from writing the first lines of code. It begins later. When programs grow. When new requirements appear. When a good idea turns into a large system.&lt;/p&gt;&#xA;&lt;p&gt;In the beginning, everything is easy to understand. You can see every function, every connection, every reason. But the larger a system becomes, the more that clarity begins to disappear. Not all at once, but gradually. After a year, you find yourself wondering why Module A depends on Module B in the first place. After two years, nobody wants to touch that dependency anymore for fear of breaking something else.&lt;/p&gt;</description>
			</item>
			<item>
				<title>OpenBSD Grundlagen</title>
				<link>https://dragons-at-work.de/en/publishing/books/souveraene-systeme-openbsd-grundlagen/</link>
				<pubDate>Tue, 03 Feb 2026 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/publishing/books/souveraene-systeme-openbsd-grundlagen/</guid>
				<description>&lt;p&gt;Eine frische OpenBSD-Installation startet mit genau zwei Diensten: sshd und cron.&#xA;Alles andere wartet auf eine bewusste Entscheidung.&lt;/p&gt;&#xA;&lt;p&gt;Dieses Prinzip zieht sich durch das gesamte System – von der integrierten Firewall pf bis zu Sicherheitsmechanismen wie pledge und unveil, die Programme strikt auf die Systemaufrufe beschränken, die sie tatsächlich benötigen.&lt;/p&gt;&#xA;&lt;p&gt;Dieses Buch richtet sich an Linux-erfahrene Administratoren, die OpenBSD nicht als Alternative vergleichen, sondern als eigenständiges System verstehen möchten. Warum gibt es kein systemd? Wie funktioniert Privilege Separation konkret? Und weshalb ersetzt doas in OpenBSD häufig das bekannte sudo?&lt;/p&gt;</description>
			</item>
			<item>
				<title>Biocodie - Die Philosophie organischer Software</title>
				<link>https://dragons-at-work.de/en/publishing/books/philosophie-organischer-software/</link>
				<pubDate>Mon, 02 Feb 2026 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/publishing/books/philosophie-organischer-software/</guid>
				<description>&lt;p&gt;Was wäre, wenn Software nicht mehr als Maschine, sondern als Lebewesen gedacht würde? Wenn wir nicht mehr Programme schrieben, sondern digitale Organismen kultivierten?&lt;/p&gt;&#xA;&lt;p&gt;In diesem bahnbrechenden Werk entwirft Michael von den Drachen ein radikal neues Paradigma für die Welt der Software: die Biocodie – ein Ansatz, der biologische Prinzipien nicht bloß imitiert, sondern tief in die digitale Architektur integriert. Von zellulären Strukturen über organische Kommunikation bis hin zu digitalem Selbstbewusstsein entfaltet sich eine faszinierende Vision lebendiger Software-Ökosysteme.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Die versteckten Kammern</title>
				<link>https://dragons-at-work.de/en/publishing/books/die-versteckten-kammern/</link>
				<pubDate>Sat, 03 Jan 2026 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/publishing/books/die-versteckten-kammern/</guid>
				<description>&lt;p&gt;&lt;strong&gt;Wir kennen die Märchen. Oder glauben es zumindest.&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;Doch was bleibt übrig, wenn man zu den ursprünglichen Fassungen zurückkehrt? Zu den Geschichten, die vergessen, verändert oder aus den Büchern verschwunden sind?&lt;/p&gt;&#xA;&lt;p&gt;Gemeinsam mit Nora und Jana betreten die Leser ein verborgenes Schloss, dessen Kammern nicht nur alte Märchen bewahren, sondern auch deren tiefere Bedeutung. Schritt für Schritt entfaltet sich ein neuer Blick auf bekannte Erzählungen – als Geschichten über Erkenntnis, Wahrnehmung, Angst, Mut und Bewusstsein.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Amy Silberstein</title>
				<link>https://dragons-at-work.de/en/authors/amy/</link>
				<pubDate>Wed, 22 Oct 2025 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/authors/amy/</guid>
				<description>&lt;figure class=&#34;author-portrait float-right&#34;&gt;&lt;img src=&#34;https://dragons-at-work.de/images/authors/amy-portrait.webp&#34;&#xA;&#x9;&#x9;&#x9;alt=&#34;Amy Silberstein - Author&#34; width=&#34;200&#34;&gt;&#xA;&lt;/figure&gt;&#xA;&#xA;&lt;p&gt;In her books and on the publishing blog, Amy describes her view of the world.&#xA;Everyday things seen from a meta-perspective, small reminders that there&amp;rsquo;s always more than one way to interpret things.&#xA;Her invitation to her readers is to remember who they really are.&#xA;She lives with her husband Michael as a digital nomad, and no matter where she happens to be - the notebook always comes along.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Michael of the Dragons</title>
				<link>https://dragons-at-work.de/en/authors/michael/</link>
				<pubDate>Wed, 22 Oct 2025 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/authors/michael/</guid>
				<description>&lt;figure class=&#34;author-portrait float-right&#34;&gt;&lt;img src=&#34;https://dragons-at-work.de/images/authors/michael-portrait.webp&#34;&#xA;&#x9;&#x9;&#x9;alt=&#34;Michael of the Dragons&#34; width=&#34;200&#34;&gt;&#xA;&lt;/figure&gt;&#xA;&#xA;&lt;p&gt;For over four decades I&amp;rsquo;ve worked with technical systems - not just how they work, but why they work. I&amp;rsquo;m less interested in individual technologies than in the rules by which systems emerge, cooperate, and remain reliable over many years.&lt;/p&gt;&#xA;&lt;h2 id=&#34;what-i-work-on&#34;&gt;What I work on&lt;/h2&gt;&#xA;&lt;p&gt;Today, dragons@work produces books, software, and open frameworks around technical systems and digital independence.&lt;/p&gt;&#xA;&lt;p&gt;This includes:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;technical books and documentation&lt;/li&gt;&#xA;&lt;li&gt;reference implementations in Lua and C&lt;/li&gt;&#xA;&lt;li&gt;open protocols and data formats&lt;/li&gt;&#xA;&lt;li&gt;tools for durable and traceable systems&lt;/li&gt;&#xA;&lt;li&gt;projects spanning technology, publishing, and philosophy&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;Much of this work interlocks. Books describe the concepts, frameworks create shared foundations, and software serves as a traceable reference implementation.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Die Erbin des Amuletts – Leseprobe</title>
				<link>https://dragons-at-work.de/en/publishing/books/die-erbin-des-amuletts/sample/</link>
				<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/publishing/books/die-erbin-des-amuletts/sample/</guid>
				<description>&lt;p&gt;Es regnete bereits seit zwei Tagen. Nicht, dass das ungewöhnlich gewesen wäre, doch gefühlt wurde es immer stärker und irgendwie auch immer nasser. Shyla stand fluchend vor dem Haus ihrer Mutter Elena, unter das Vordach der Eingangstür gedrückt. Sie zog den Schlüssel ihres Honda aus der Tasche und ärgerte sich, dass ihr Regenschirm, wie üblich, im Wagen lag. Die Straße erinnerte durch die Wassermassen mehr an einen Bach, doch die Alternative, wieder in das Haus ihrer Mutter zu gehen, war heute absolut ausgeschlossen. Seitdem Shylas dreißigster Geburtstag näher rückte, hatte Elena eine Art Torschlusspanik entwickelt. Sie war offensichtlich auf der Suche nach einem Bräutigam für ihre Tochter, denn sämtliche Informationen über die Junggesellen der kleinen Stadt wurden von ihr gesammelt, um dann, in hübsche Schwärmereien verpackt, an Shyla serviert zu werden. Elenas neueste Idee war, ihre Tochter mit Philip, dem Malermeister, zu verkuppeln. Shyla schauderte bei dem Gedanken an die vergangenen zwei Stunden, in denen ihre Mutter Philip wieder und wieder angepriesen hatte, gepaart mit einem großen Repertoire an Vorwürfen, was ihre Tochter ihrer Meinung nach so alles falsch machte. Shyla fluchte erneut. In ihrem Herz kam eine so lange schon bekannte Traurigkeit hoch. Eine Träne lief über ihre Wange, als sie daran dachte, dass ein Vater da bestimmt anders denken würde. Ein Vater würde keine Ambitionen zeigen, die eigene Tochter zu verschachern, da war sie sich sicher. Shyla kannte ihren Vater aber nicht. Er hatte die kleine Familie verlassen, als Shyla noch ein Baby war und ihre Mutter weigerte sich stur, über ihn zu sprechen. Nichts, wirklich gar nichts war aus Elena herauszubekommen.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Die Träumenden</title>
				<link>https://dragons-at-work.de/en/publishing/books/die-traeumenden/sample/</link>
				<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
				<guid>https://dragons-at-work.de/en/publishing/books/die-traeumenden/sample/</guid>
				<description>&lt;h2 id=&#34;mensch--seele&#34;&gt;Mensch &amp;amp; Seele&lt;/h2&gt;&#xA;&lt;p&gt;Das Bewusstsein,das sich erfährt,ist alles, was es erlebt.&lt;/p&gt;&#xA;&lt;h3 id=&#34;die-grundstruktur&#34;&gt;Die Grundstruktur:&lt;/h3&gt;&#xA;&lt;p&gt;Die Seele = das Bewusstsein, Beobachtende, das Erfahren-wollende.&lt;br&gt;&#xA;Der Mensch = das Instrument, durch das die Seele sich selbst fühlt. Der Ausdruck, der den Bewusstseinszustand perfekt spiegelt.&lt;br&gt;&#xA;Das bedeutet, die Seele hat einen Menschen, durch den sie eine menschliche Erfahrung macht. Und gleichzeitig, dass die Seele für diese Erfahrungen ein Mensch ist, so wie sie alles ist, das sie durch die menschlichen Augen wahrnimmt – getrennt von sich wahrnimmt. Temporär, absichtsvoll, um sich in allen Facetten fokussiert zu erfahren.&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
