Tech Blog

Centralized Logging with journald and Standard Linux Tools

Fri, 19 Dec 2025 02:00:00 +0000

Every modern Linux distribution ships with journald as its logging system. It captures logs from system services, the kernel, and applications in a structured, indexed format. Rather than fighting this or replacing it with something else, I decided to embrace journald as the foundation of my centralized logging architecture.

The goal is simple: collect logs from all my systems into a central location, store them in a stable format that will be readable for years, and be able to load them into tools like Elasticsearch whenever I need to analyze them. No vendor lock-in, no proprietary formats, just plain JSON files on disk.

The architecture has three parts: getting data into journald, shipping it to a central server, and storing it durably.

Getting Data Into journald

Most applications already write to journald by default when running as systemd services. The interesting cases are containers and network devices.

Docker and Container Orchestrators

Docker provides a journald logging driver that sends container logs directly to the host's journal. Both HashiCorp Nomad and Kubernetes can use this driver. The key benefit is that container logs gain all the structured metadata that journald provides, plus you can add your own.

Here's how I configure a Nomad task to use the journald logging driver:

task "hello-world" {
  driver = "docker"

  config {
    image = "akroh/hello-world:v3"

    labels {
      owner = "website@example.com"
    }

    logging {
      type = "journald"
      config {
        tag    = "${NOMAD_JOB_NAME}"
        labels = "owner"
        env    = "NOMAD_ALLOC_ID,NOMAD_JOB_NAME,NOMAD_TASK_NAME,NOMAD_GROUP_NAME,NOMAD_NAMESPACE,NOMAD_DC,NOMAD_REGION,NOMAD_ALLOC_INDEX,NOMAD_ALLOC_NAME"
      }
    }
  }
}

The tag option sets the SYSLOG_IDENTIFIER field, making it easy to filter logs by job name. The labels option includes Docker labels as journal fields, and env includes the specified environment variables. This metadata becomes invaluable when you need to correlate logs across services.

When a container writes a log line, it appears in the journal with all this context:

{
  "CONTAINER_ID": "0f07251e631e",
  "CONTAINER_NAME": "server-c10085f7-a59f-4132-3f01-c9050a0303bd",
  "CONTAINER_TAG": "phone-notifier",
  "OWNER": "website@example.com",
  "IMAGE_NAME": "docker.example.com/phone-notifier:v12",
  "MESSAGE": "10.100.8.98 - - [18/Dec/2025:22:35:06 +0000] \"POST /v1/notify HTTP/1.1\" 200 598",
  "NOMAD_ALLOC_ID": "c10085f7-a59f-4132-3f01-c9050a0303bd",
  "NOMAD_DC": "va",
  "NOMAD_JOB_NAME": "phone-notifier",
  "NOMAD_TASK_NAME": "server",
  "PRIORITY": "6",
  "SYSLOG_IDENTIFIER": "phone-notifier",
  "_HOSTNAME": "compute01.va.local.example.com",
  "_TRANSPORT": "journal"
}

Network Devices via rsyslog

Network devices like switches, routers, and IP phones typically send logs via syslog over UDP. You can configure rsyslog to receive these and forward them into journald, preserving the original message and adding metadata.

Create /etc/rsyslog.d/10-syslog.conf:

module(load="omjournal")
module(load="imudp")

input(type="imudp" port="514" ruleset="syslog-to-journald")

template(name="journal" type="list") {
  constant(value="udp_514" outname="TAGS")
  property(name="rawmsg" outname="MESSAGE")
  property(name="fromhost-ip" outname="LOG_SOURCE_IP")
}

ruleset(name="syslog-to-journald"){
    action(type="omjournal" template="journal")
}

This configuration listens on UDP port 514, preserves the raw syslog message without parsing it, and adds the source IP address as metadata. The TAGS field helps identify the log path when you have other rsyslog configuration.

Getting Data Out of journald

The systemd-journal-upload service is a built-in tool that ships journal entries to a remote server over HTTP. It runs as a daemon, watches for new entries, and pushes them as they arrive.

The service maintains a cursor that tracks the last successfully uploaded entry. This cursor is persisted to disk, so if the service restarts or loses connectivity, it resumes from where it left off without duplicating or losing entries.

Install systemd-journal-remote (it provides systemd-journal-upload) using your distro's package manager, then configure the upload target.

Create or edit /etc/systemd/journal-upload.conf:

[Upload]
URL=http://logs.example.com:19532

Enable and start the service:

sudo systemctl enable --now systemd-journal-upload.service

The HTTP Protocol

The upload service sends journal entries using a straightforward HTTP protocol:

Endpoint: POST /upload
Content-Type: application/vnd.fdo.journal
Transfer-Encoding: chunked

The body contains entries in the journal export format. Each entry is a series of field-value pairs separated by newlines, with entries separated by blank lines. Text fields use the format FIELD_NAME=value\n, while binary fields use a length-prefixed format.

The chunked transfer encoding allows the client to stream entries continuously. When there are no more entries to send, the client completes the request and waits for acknowledgment before updating its cursor.

Receiving and Storing Logs

The systemd project provides systemd-journal-remote as a companion to the upload service. It receives uploads and writes them into local journal files. This works well if you want to query logs using journalctl on the central server.

I use a custom receiver that takes a different approach. Instead of storing logs in the journal export format, it writes them as NDJSON (newline-delimited JSON) files. The receiver:

Accepts HTTP uploads from journal-upload clients
Parses the journal export format and converts entries to JSON
Appends to a write-ahead log (WAL) and fsyncs for durability
Periodically flushes the WAL to compressed NDJSON files partitioned by date and hour

The output is zstd-compressed NDJSON files organized by region and time:

logs/
  region=va/
    source=journald/
      dt=2025-12-18/
        hour=14/
          events-019438a2-7b3c-7def-8123-456789abcdef.ndjson.zst

Filenames use UUIDv7 identifiers, which embed a timestamp and random component. This allows multiple receiver instances to write files concurrently without coordination, enabling horizontal scaling when needed.

Each line in these files is a complete JSON object with the original journal fields plus metadata like the source region and timestamp. This forms what's sometimes called the "bronze layer" in a data lake architecture.

Why NDJSON?

The archival format matters for long-term retention. NDJSON has several properties that make it ideal:

Readable with standard tools: zstdcat file.ndjson.zst | jq . works today and will work in 20 years.
No schema migrations: JSON is self-describing. Fields can be added without breaking anything.
Open compression: zstd is open-source, well-documented, and widely supported.
Easy to rehydrate: Decompress, parse JSON, bulk-load into Elasticsearch or any other tool.
Extensible to cloud storage: The same file layout works on local disk, NFS, or S3.

This approach decouples collection and archival from analysis. You can bulk-load historical data into Elasticsearch whenever you need it, write custom scripts to process the JSON directly, or reprocess the archive with updated parsing logic years later. The data remains accessible regardless of how your tooling evolves.

References

Designing wall mounts for the Odroid HC2

Fri, 25 Dec 2020 12:00:00 +0000

When I purchased Hard Kernel's Odroid HC2, I assumed I would find a tidy way to mount the device along side my other computer and network gear. I considered building a mount or shelf from wood; I also considered drilling holes in the heatsink to hang the device from a screw-in hook, but none of these solutions were low profile or sleek. This led me down the path of designing and printing my first 3D part.

The Odroid HC2 is a small computer attached to a heatsink that accepts a single 3.5" hard disk. It's a low cost (~$50), low power (~10W) way to attach storage to your network. I am using three of them together to provide redundancy.

I'd never used a CAD program nor did I have access to a 3D printer when I decided I wanted to make my own mount. And thanks to the pandemic of 2020, the "maker space" at the public library was closed, so I couldn't try 3D printing before investing in my own equipment.

Before purchasing a printer, I wanted to be sure I could learn to use a CAD program. I watched a few YouTube tutorials on the subject and then gave design a try with Autodesk Fusion 360. Below is the haphazardly designed first attempt. It was enough to convince me that with more time I could produce a better design. So I ordered a Prusa Mini printer.

The printer kit arrived in December after an 8 week lead time. I dusted off the earlier design and prepared it for printing. I exported the 3D design to an STL file and ran that through Prusa Slicer to create a g-code file (the raw instructions to the printer for creating the part). I loaded the g-code file to a USB stick and commenced printing with PLA filament. It was rewarding to have something I designed come to reality in just 25 minutes (even if it's an ugly mess).

While this first prototype did actually fit the HC2's heatsink, it had several problems. It wasn't symmetrical, so two different parts would be needed for the the top and bottom. There wasn't enough clearance for screw heads. And the fit around the HC2 was too tight.

I designed a second version in about 4 hours (I had to relearn all the things I had forgotten after the 8 week wait). I took into account the things I learned from the first version.

The second version fit perfectly. So I loaded the ASA filament and began batch printing the production parts. ASA filament was used because of its high heat tolerance. The heatsink temperature is routinely 43°C so PLA filament would have likely deformed over time.

And finally after many months of sitting on my workbench, each Odroid HC2 is wall-mounted using four M3 screws.

This project reaffirmed my opinion that the Metric system is far superior to the Imperial system. And I learned that Vernier calipers and a good metal ruler are really useful tools to have around.

The project files can be downloaded from github.com/andrewkroh/3d-designs.

Testing Github Pull Requests Using git Patches

Wed, 17 Jan 2018 12:00:00 +0000

Did you know that Github can provide a patch file for any pull request (PR)? Appending .patch to any pull request URL will get you a patch file for the PR.

If you want to locally test the changes provided in the PR then applying the patch to your local repository can be a fast way to get the changes. You simply need to download the patch with curl then apply it using git.

curl -L -O https://github.com/elastic/go-libaudit/pull/18.patch
git am 18.patch

After running those command the PR will be applied to your branch. You can see the changes by checking the git log.

git log -1

Parsing User Agent strings from Packetbeat

Sun, 24 Jan 2016 21:10:00 +0000

Packetbeat is a open source tool from Elastic (the makers of Elasticsearch) that analyzes network traffic in real-time and stores the data in Elasticsearch. You can collect some interesting data if you install Packetbeat in a location where it can see all the traffic between your network and the Internet. I use a SPAN port on a Cisco switch to mirror my network's traffic into Packetbeat.

To get an overview of the various operating systems and browsers being used on a network you can configure Packetbeat to collect all HTTP traffic including the User-Agent request header. Packetbeat collects the raw user agent string which needs to be parsed and normalized in order to analyze which OSes and browsers are being used. Parsing of the user agent strings can be performed by Logstash (another product by Elastic).

Once you are collecting data you can easily visualize and explore it using Kibana.

The data flow through my setup is Packetbeat -> Logstash -> Elasticsearch. Below I will show example configurations that can be used for this task.

Packetbeat Configuration

interfaces:
  device: eth1
  with_vlans: true

protocols:
  http:
    ports: [80, 8080, 8000, 000, 8002]
    send_headers: ["User-Agent"]

output:
  logstash:
    hosts: ["localhost:5044"]

logging:
  to_files: true
  files:
    path: /var/log/packetbeat
    name: packetbeat.log
  level: info

Logstash Configuration

input {
  beats {
    port => 5044
  }
}

filter {
  if [type] == "http" {
    useragent {
      # Read the user-agent field from the JSON sent by Packetbeat
      source => "[http][request_headers][user-agent]"
      # Remove the raw request_headers since we don't need them after reading
      # the user-agent string.
      remove_field => "[http][request_headers]"
      # Put all the of parsed user-agent data under the "ua" key.
      target => "ua"
    }
  }
}

output {
  # I am using 'Found' which is Elastic's hosted Elasticsearch offering.
  elasticsearch {
    hosts => "xyz.us-west-1.aws.found.io:9243"
    ssl => true
    user => "readwrite"
    password => "password"
    manage_template => false
    index => "%{[@metadata][beat]}-%{+YYYY.MM.dd}"
    document_type => "%{[@metadata][type]}"
  }
}

Example Output

The document that is indexed in Elasticsearch now includes a ua field that holds all of the parsed user-agent data.

{
  "@timestamp": "2016-01-24T20:08:37.193Z",
  "beat": {
    "hostname": "beats",
    "name": "beats"
  },
  "bytes_in": 185,
  "bytes_out": 367,
  "client_ip": "10.10.0.18",
  "client_port": 36801,
  "client_proc": "",
  "client_server": "",
  "count": 1,
  "direction": "out",
  "http": {
    "code": 301,
    "content_length": 148,
    "phrase": "Permanently",
    "response_headers": {}
  },
  "ip": "23.7.122.8",
  "method": "GET",
  "params": "",
  "path": "/",
  "port": 80,
  "proc": "",
  "query": "GET /",
  "responsetime": 45,
  "server": "",
  "status": "OK",
  "type": "http",
  "@version": "1",
  "host": "beats",
  "tags": [
    "beats_input_raw_event"
  ],
  "ua": {
    "name": "Chrome",
    "os": "Mac OS X 10.6.8",
    "os_name": "Mac OS X",
    "os_major": "10",
    "os_minor": "6",
    "device": "Other",
    "major": "12",
    "minor": "0",
    "patch": "742"
  }
}

Managing a Firewall with Puppet when using Docker

Sun, 08 Mar 2015 22:30:01 +0000

The problem with using Docker and managing your firewall with Puppet is that you have two competing tools trying to manage the rules in the firewall. The puppetlabs-firewall module allows you purge all unmanaged firewall chains and rules, and if configured to do so, puppet will purge the rules added by Docker.

This is how you purge all unmanaged rules:

resources { 'firewall':
  purge => true,
}

A feature added in puppetlabs-firewall 1.3 provides a method for allowing Puppet to selectively purge unmanaged firewall rules within a particular chain. A firewallchain parameter named ignore accepts regular expressions that are to be matched against firewall rules within that chain that are to be ignored when purging.

When the docker service is started it add iptables rules like this:

-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT

To configure puppetlabs-firewall to ignore the docker rules when purging you can configure your firewallchain to ignore rules containing "-o docker0" and "-i docker0". It is important to note that you cannot purge all firewall resources as shown above and make use of the ignore parameter; the implications of this are that you lose the ability to purge unmanaged firewallchains and you must define a firewallchain for each chain from which you wish to have puppet purge rules.

firewallchain { 'FORWARD:filter:IPv4':
  ensure => present,
  purge  => true,
  ignore => [
    '-o docker0',
    '-i docker0',
  ],
}

For my projects I have created wrapper module around puppetlabs-firewall that creates a firewallchain for INPUT, OUTPUT, and FORWARD and configures each of them to purge all rules except for those containing docker0. I am not creating any NAT rules outside of docker so I have chosen to not manage any of the chains within the NAT table using Puppet.

Vulnerability Assessment and Compliance Verification

Sun, 08 Mar 2015 18:55:21 +0000

OpenSCAP is an open source tool for performing automated vulnerability assessment and policy compliance verification on linux. SCAP, pronounced “ess-cap”, is the Security Content Automation Protocol which pulls together open standards for describing vulnerabilities like CVE, CVSS, OVAL, and XCCDF. The OpenSCAP tool, which is NIST certified, ingests the SCAP content and outputs a report of which checks passed and failed.

Let's walkthrough an example of how to audit a RedHat 6 machine against SCAP content provided by DISA known as the Redhat 6 STIG Benchmark.

First, you need to install OpenSCAP and its dependencies (and I'm installing wget and unzip so that I can download the STIG and unzip it).

$ yum install openscap-utils wget unzip
================================================================================
 Package               Arch   Version                Repository            Size
================================================================================
Installing:
 openscap-utils        x86_64 1.0.8-1.el6_5.1        rhel-x86_64-server-6  52 k
 unzip                 x86_64 6.0-1.el6              rhel-x86_64-server-6 149 k
 wget                  x86_64 1.12-5.el6_6.1         rhel-x86_64-server-6 483 k
Installing for dependencies:
 bzip2                 x86_64 1.0.5-7.el6_0          rhel-x86_64-server-6  49 k
 elfutils              x86_64 0.158-3.2.el6          rhel-x86_64-server-6 233 k
 elfutils-libs         x86_64 0.158-3.2.el6          rhel-x86_64-server-6 211 k
 fakeroot              x86_64 1.12.2-22.2.el6        rhel-x86_64-server-6  73 k
 fakeroot-libs         x86_64 1.12.2-22.2.el6        rhel-x86_64-server-6  23 k
 file                  x86_64 5.04-21.el6            rhel-x86_64-server-6  47 k
 gdb                   x86_64 7.2-75.el6             rhel-x86_64-server-6 2.3 M
 libxslt               x86_64 1.1.26-2.el6_3.1       rhel-x86_64-server-6 452 k
 man                   x86_64 1.6f-32.el6            rhel-x86_64-server-6 263 k
 openscap              x86_64 1.0.8-1.el6_5.1        rhel-x86_64-server-6 2.9 M
 patch                 x86_64 2.6-6.el6              rhel-x86_64-server-6  91 k
 perl                  x86_64 4:5.10.1-136.el6_6.1   rhel-x86_64-server-6  10 M
 perl-Module-Pluggable x86_64 1:3.90-136.el6_6.1     rhel-x86_64-server-6  40 k
 perl-Pod-Escapes      x86_64 1:1.04-136.el6_6.1     rhel-x86_64-server-6  32 k
 perl-Pod-Simple       x86_64 1:3.13-136.el6_6.1     rhel-x86_64-server-6 212 k
 perl-libs             x86_64 4:5.10.1-136.el6_6.1   rhel-x86_64-server-6 578 k
 perl-version          x86_64 3:0.77-136.el6_6.1     rhel-x86_64-server-6  51 k
 rpm-build             x86_64 4.8.0-38.el6_6         rhel-x86_64-server-6 127 k
 rpmdevtools           noarch 7.5-2.el6              rhel-x86_64-server-6 109 k
 xz                    x86_64 4.999.9-0.5.beta.20091007git.el6
                                                     rhel-x86_64-server-6 137 k
 xz-lzma-compat        x86_64 4.999.9-0.5.beta.20091007git.el6
                                                     rhel-x86_64-server-6  16 k
Updating for dependencies:
 elfutils-libelf       x86_64 0.158-3.2.el6          rhel-x86_64-server-6 182 k
 file-libs             x86_64 5.04-21.el6            rhel-x86_64-server-6 313 k
 rpm                   x86_64 4.8.0-38.el6_6         rhel-x86_64-server-6 902 k
 rpm-libs              x86_64 4.8.0-38.el6_6         rhel-x86_64-server-6 313 k
 rpm-python            x86_64 4.8.0-38.el6_6         rhel-x86_64-server-6  57 k
 xz-libs               x86_64 4.999.9-0.5.beta.20091007git.el6
                                                     rhel-x86_64-server-6  89 k

Transaction Summary
================================================================================
Install      24 Package(s)
Upgrade       6 Package(s)

Total download size: 21 M

Now with the tool installed we can audit our server against the DISA STIG. The DISA STIG can be downloaded from DISA’s web site.

$ wget http://iase.disa.mil/stigs/Documents/U_RedHat_6_V1R6_STIG_SCAP_1-1_Benchmark.zip
$ unzip U_RedHat_6_V1R6_STIG_SCAP_1-1_Benchmark.zip
$ oscap info U_RedHat_6_V1R6_STIG_SCAP_1-1_Benchmark-xccdf.xml
$ oscap xccdf eval \
  --report `hostname`-redhat_6_v1r6_stig.html \
  --cpe U_RedHat_6_V1R6_STIG_SCAP_1-1_Benchmark-cpe-dictionary.xml \
  U_RedHat_6_V1R6_STIG_SCAP_1-1_Benchmark-xccdf.xml

The HTML report that is generated can be viewed in the browser. It summarizes each rule with a simple pass/fail result. There are details for each rule and remediation instructions.

Another useful test for RedHat systems is to verify that all of the required patches have been installed to address the RedHat security advisories, RHSA (you can subscribe for announcements here.

$ wget http://www.redhat.com/security/data/oval/com.redhat.rhsa-all.xml
$ oscap oval eval \  
  --results rhsa-results-oval.xml \  
  --report `hostname`-rhsa-report.html \  
  com.redhat.rhsa-all.xml

Again, you can view the report in the browser to see what patches have been applied and what patches need to be applied.

Configuring Cisco ASA SSL Ciphers

Fri, 06 Mar 2015 16:49:28 +0000

To protect against SSL vulnerabilities it is important to disable SSLv3 and weak ciphers on your cisco ASA device.

To enumerate the ciphers supported by the device I use an openssl wrapper script called cipherscan that is available on github. On a default Cisco ASA setup here is what ciphers are available.

bash-4.3$ ./cipherscan sslvpn.example.com
.......
Target: sslvpn.example.com:443

prio  ciphersuite         protocols    pfs_keysize
1     RC4-SHA             SSLv3,TLSv1
2     DHE-RSA-AES128-SHA  TLSv1        DH,1024bits
3     DHE-RSA-AES256-SHA  TLSv1        DH,1024bits
4     AES128-SHA          SSLv3,TLSv1
5     AES256-SHA          SSLv3,TLSv1
6     DES-CBC3-SHA        SSLv3,TLSv1

Certificate: UNTRUSTED, 2048 bit, sha256WithRSAEncryption signature
TLS ticket lifetime hint: None
OCSP stapling: not supported
Server side cipher ordering

To change the supported protocols and ciphers, login to the Cisco ASA via SSH. You can list the current SSL configuration with show ssl and then make the required changes.

You should disable SSLv3 due to the POODLE vulnerability. And you should verify that you are using strong ciphers. I prefer to use ciphers that support PFS, but the Cisco AnyConnect IOS app for the SSL VPN does not support the PFS ciphers so I had to include aes256-sha1 and aes128-sha1.

asa5505(config)# ssl client-version tlsv1-only  
asa5505(config)# ssl server-version tlsv1  
asa5505(config)# ssl encryption dhe-aes256-sha1 dhe-aes128-sha1 aes256-sha1 aes128-sha1
asa5505# show ssl  
Accept connections using SSLv2 or greater and negotiate to TLSv1  
Start connections using TLSv1 only and negotiate to TLSv1 only  
Enabled cipher order: dhe-aes256-sha1 dhe-aes128-sha1 aes256-sha1 aes128-sha1

And finally verify the changes using cipherscan.

bash-4.3$ ./cipherscan sslvpn.example.com  
...  
Target: sslvpn.example.com:443

prio  ciphersuite         protocols  pfs_keysize  
1     DHE-RSA-AES256-SHA  TLSv1      DH,1024bits  
2     DHE-RSA-AES128-SHA  TLSv1      DH,1024bits  
3     AES256-SHA          TLSv1  
4     AES128-SHA          TLSv1

Certificate: UNTRUSTED, 2048 bit, sha256WithRSAEncryption signature  
TLS ticket lifetime hint: None  
OCSP stapling: not supported  
Server side cipher ordering

Creating a Site-to-Site VPN with Solaris 11

Sun, 01 Feb 2015 17:27:29 +0000

I documented the process I used to create a site-to-site VPN between two sites using Solaris 11 as the router. I did this because the documentation provided by Oracle has several critical flaws.

Here's the direct link to the document that's embedded below:

Creating a Site-to-Site VPN with Solaris 11

Migrating a CVS Repository to Git

Thu, 26 Dec 2013 17:08:51 +0000

So you want to take those old CVS repositories and migrate them to Git?

You can use cvs2git to migrate your CVS repository with history to Git. It requires direct filesystem access the CVS repository that you wish to convert.

Fist download cvs2git, compile, and install.

  
svn co --username=guest --password="" http://cvs2svn.tigris.org/svn/cvs2svn/trunk cvs2svn-trunk  
cd cvs2svn-trunk  
make install

Now you are ready to convert a repository's history into git fast-forward format.

  
mkdir -p /tmp/convert/cvs2git-tmp  
cd /tmp/convert  
cvs2git --blobfile=cvs2git-tmp/git-blob.dat --dumpfile=cvs2git-tmp/git-dump.dat --username=cvs2git /path/to/cvs/repo/component

cvs2git only migrates history so you need to add all the files to Git yourself.

  
cvs co component  
cd component  
find . -type d -name 'CVS' -exec rm -rf {} \;  
git init  
git add --all

Now import the history and push it all to the origin.

  
cat ../cvs2git-tmp/git-blob.dat ../cvs2git-tmp/git-dump.dat | git fast-import  
git remote add origin https://github.com/name/component.git  
git push origin master

DDNS Updater for DNS Made Easy

Sat, 09 Jul 2011 16:00:03 +0000

The problem with hosting a domain on a dynamic IP is that when your IP address changes your domain becomes inaccessible until you update the DNS record with your new IP. Hosting a domain on a dynamic IP address can be done easily if you use DDNS (Dynamic Domain Name Service) and can afford a few minutes of downtime. DNS records can be automatically updated via DDNS when the server's IP address changes.

DNS Made Easy has been handling DNS for my domains since 2004. I have written a tool in Java for performing secure DDNS updates to their servers when your IP address changes. It works by making a HTTP request to a server on the public internet that echos back the requester's IP address as seen by the server; this is what allows the tool to work behind NAT. Then it compares this IP address to the address returned during the last call, and only if they are different will it make a secure request to update the DDNS record.

This tool was written to be run periodically by some form of scheduler: crontab or Windows scheduled tasks.

For all the details head on over to GitHub and see dns-made-easy-updater.

Tech Blog

Centralized Logging with journald and Standard Linux Tools

Getting Data Into journald

Docker and Container Orchestrators

Network Devices via rsyslog

Getting Data Out of journald

The HTTP Protocol

Receiving and Storing Logs

Why NDJSON?

References

Designing wall mounts for the Odroid HC2

Testing Github Pull Requests Using git Patches

Parsing User Agent strings from Packetbeat

Packetbeat Configuration

Logstash Configuration

Example Output

Managing a Firewall with Puppet when using Docker

Related Links

Vulnerability Assessment and Compliance Verification

Configuring Cisco ASA SSL Ciphers

Creating a Site-to-Site VPN with Solaris 11

Migrating a CVS Repository to Git

DDNS Updater for DNS Made Easy