Moving all posts to a single location.

2 files changed, 202 insertions, 0 deletions

diff --git a/content/blog/publishing-with-pelican.md b/content/blog/publishing-with-pelican.md
new file mode 100644
index 0000000..d49a420
--- /dev/null
+++ b/content/blog/publishing-with-pelican.md
@@ -0,0 +1,24 @@
+Title: Publishing with Pelican
+Date: 2015-01-27 06:00
+Modified: 2015-01-26 21:30
+Tags: pelican, nginx, networksec, frqrec, social media, vim
+Slug: publishing-with-pelican
+Authors: David Runge
+Summary: Some links and information on publishing with Pelican
+
+I haven't done serious web development work in quite some time. There are reasons for that.  
+Mostly because I have been busy being a [sys admin](http://www.math.tu-berlin.de/iuk/lehrrechnerbereich) instead...  
+
+A reason for now doing this kind of work for myself again, is my departure from a lot of social media websites like Facebook (no, no link here). The reasons for that are quite obvious, apart from the general evilness of large companies, agencies and governments alike (especially when looking at the developments in European and US-American politics in the past few months, or rather years).  
+
+After some changes in my hosting plans (moving away from [Hosteurope](https://www.hosteurope.de/) to [NetworkSEC](http://networksec.de), but more on that soon), 
+this also involved dividing private content from that of the association ([Freakquenzy Records e.V.](http://frqrec.de)) I am working with.  
+
+Ultimately this led me to the decision to find a publishing tool that was not depending on a database setup (like [Wordpress](http://wordpress.org) is), but rather something text file based (also because I am a daily [Vim](http://www.vim.org/) user).  
+Say hello to [Pelican](http://blog.getpelican.com/), a Python based static website generator!  
+With Pelican one can write content in [Markdown](http://daringfireball.net/projects/markdown/) and have simple [themes](http://pelican-themes-gallery.place.org/) and the site generator take care of the rest. Pretty awesome! A separate [Makefile](https://en.wikipedia.org/wiki/Makefile) (besides the easy possibility of local testing) makes it possible to push a new website version directly to the webserver or other destinations.
+Currently I've started work on some static pages and my own theme, cloned from the [notmyidea-cms theme](https://github.com/getpelican/pelican-themes/tree/master/notmyidea-cms). Now my whole website can be conveniently developed in my own [git repository](https://git.sleepmap.de/sleepmap/).  
+
+Although for newbie users a login backend for administering a website (like the one Wordpress offers) is a very easy solution, it also introduces security issues (bad passwords, hacked computers & malware, PHP bugs, bad content, bad plugins, etc.).  
+I'm glad I've found a very lightweight and fast solution in Pelican, that works well with [nginx](http://nginx.org/).
+
diff --git a/content/blog/ssh-tunnel-and-postfix.md b/content/blog/ssh-tunnel-and-postfix.md
new file mode 100644
index 0000000..30e8ab6
--- /dev/null
+++ b/content/blog/ssh-tunnel-and-postfix.md
@@ -0,0 +1,178 @@
+Title: SSH tunnel with single hop, using systemd network and autossh
+Date: 2015-02-01 20:00
+Modified: 2015-02-01 20:00
+Tags: archlinux, autossh, ssh, tunnel, systemd, systemd.network, postfix, TUN
+Slug: ssh-tunnel-with-single-hop-using-systemd-network-and-autossh
+Authors: David Runge
+Summary: Howto on setting up a SSH tunnel with the help of a systemd .network file between two machines, with no direct access to each other and modifying Postfix to use that tunnel.
+
+Recently I had the pleasure of setting up a SSH tunnel between two virtual machines that share no route and are located in two different subnets.  
+They can however reach each other via SSH, hopping their host.
+Let's assume the following setup:  
+
+* **client1** (Arch Linux) has *10.0.5.2/24*
+* **client2** (Arch Linux) has *10.0.6.2/24*
+* **host** (Debian) is *10.0.5.1/24* to **client1** and *10.0.6.1/24* to **client2**
+
+As I needed the two clients to be able to send mail to each other and reach each others' services, I did some digging and opted for a SSH connection using TUN devices (aka. *"poor man's VPN"*).
+The following is needed to set this up:  
+
+* root access on both virtual machines (**client1** & **client2**)
+* a user account on the **host** system
+* SSH ([OpenSSH](http://www.openssh.com/) assumed) installed on all three machines
+
+# Connect the clients
+
+## Change sshd_config
+The following two settings have to be made in each clients */etc/ssh/sshd_config* (to allow root login and the creation of TUN devices):  
+
+    #!aconf
+    PermitRootLogin yes  
+    PermitTunnel yes  
+
+I hope it is needless to say, that permitting root access via SSH has its caveats. You should make sure to set a very secure password, or only allow SSH keys for login.
+
+## Generate and exchange keys
+Generate SSH keys on **client1** (you can of course use other key types, if your OpenSSH installation allows and supports it):  
+
+    :::bash
+    ssh-keygen -t rsa -b 4096 -C "$(whoami)@$(hostname)-$(date -I)"  
+
+Here you can choose between setting a password for the key (to unlock the key with *ssh-add* yourself) or not setting one (to be able to use the key on system boot with an automated service).  
+Add them to your user at **host** like this:  
+
+    :::bash
+    ssh-copy-id -i .ssh/id_rsa user@host  
+
+Also add it to */root/.ssh/authorized_keys* on **client2**.
+
+## Use ProxyCommand to connect
+To make a first connection between the clients, one can use the following settings in */root/.ssh/config* of **client1** to hop **host** and connect to **client2**:  
+
+    #!aconf
+    Host client2
+      ProxyCommand ssh user@10.0.5.1 -W 10.0.6.2:%p
+      ForwardAgent yes
+      User root
+      ServerAliveInterval 120
+      Compression yes
+      ControlMaster auto
+      ControlPath ~/.ssh/socket-%r@%h:%p
+
+The *ForwardAgent yes* setting here is especially interesting, as it forwards the SSH key of **client1** to **client2**.  
+On **client1** a simple  
+
+    :::bash
+    ssh client2 -v
+should now directly connect to **client2** by hopping **host**.
+
+# Tunneling
+## Start the tunnel
+Now to the fun part: Creating the tunnel.  
+OpenSSH supports a VPN-like feature, that creates a TUN device on both ends of the connection. As the "direct" (hopping **host**) connection between **client1** and **client2** has been setup already, let's try the tunnel:  
+
+    :::bash
+    ssh -w5:5 client2 -v
+
+The *-w* switch will create a TUN device (*tun5* to be exact) on each client.  
+Now, to start the tunnel without executing a remote command (*-N*), compression of the data (*-C*) and disabling pseudo-tty allocation (*-T*), one can use the following:  
+
+    :::bash
+    ssh -NCTv -w5:5 client2
+
+## Setting up the TUN devices
+A short  
+
+    :::bash
+    ip a s
+
+on **client1** and **client2** shows, that the *tun5* devices have been created on both clients. However they don't feature a link yet.  
+This can be achieved by setting up a [systemd.network](http://www.freedesktop.org/software/systemd/man/systemd.network.html) with the help of [systemd-networkd](http://www.freedesktop.org/software/systemd/man/systemd-networkd.service.html). By placing a *.network* file in */etc/systemd/network/*, the TUN device will be configured as soon as it shows up.  
+Here I chose the *10.0.10.0/24* subnet, but you could use any other private subnet (that's still available in your setup).  
+On **client1** (*/etc/systemd/network/client1-tun.network*):  
+
+    #!ini
+    [Match]
+    Name=tun5
+    Host=client1
+    
+    [Network]
+    Address=10.0.10.1/24
+    
+    [Address]
+    Address=10.0.10.1/24
+    Peer=10.0.10.2/24
+
+On **client2** (*/etc/systemd/network/client2-tun.network*):  
+
+    #!ini
+    [Match]
+    Name=tun5
+    Host=client2
+    
+    [Network]
+    Address=10.0.10.2/24
+    
+    [Address]
+    Address=10.0.10.2/24
+    Peer=10.0.10.1/24
+
+After adding the files a restart of the **systemd-networkd** service on both machines is necessary.  
+
+    :::bash
+    systemctl restart systemd-networkd
+
+Now starting the tunnel again should give a fully working point-to-point TCP connection between the two (virtual) machines using the TUN devices.  
+If you need a more complex setup (i.e. to access the other clients' subnet), you will have to apply some routes (either using [Netfilter](http://www.netfilter.org/) or [systemd.network](http://www.freedesktop.org/software/systemd/man/systemd.network.html)), depending on your individual setup.
+
+# Hosts
+To make both hosts know about each other by hostname (and domain, if any), too, those can be added to the clients' */etc/hosts* files.  
+On **client1** (*/etc/hosts*):  
+
+    10.0.10.2 client2.org client2
+On **client2** (*/etc/hosts*):  
+
+    10.0.10.1 client1.org client1
+
+# Postfix
+If using [postfix](http://www.postfix.org/) as MTA, the service has to be configured to use */etc/hosts* before resolving to your networks DNS resolving.  
+On **client1** and **client2** (*/etc/postfix/main.cf*):  
+
+    #!ini
+    lmtp_host_lookup = native
+    smtp_host_lookup = native
+    ignore_mx_lookup_error = yes
+
+# Autossh and system boot
+Wrapping it all up, it's usually intended to have a tunnel service be started on system boot. SSH tunnels are supposedly known for their poor connectivity. One way to get around this issue is to manage them with [autossh](http://www.harding.motd.ca/autossh/).
+A simple [systemd service](http://www.freedesktop.org/software/systemd/man/systemd.service.html) file can then be used to manage this behavior.  
+On **client1** (*/etc/systemd/system/tunnel@.service*):  
+
+    #!ini
+    [Unit]
+    Description=AutoSSH tunnel to a host
+    After=network.target
+    
+    [Service]
+    Environment="AUTOSSH_GATETIME=0"
+    ExecStart=/usr/bin/autossh -M 0 -NCTv -o ServerAliveInterval=45 -o ServerAliveCountMax=2 -o TCPKeepAlive=yes -w 5:5 %I
+    
+    [Install]
+    WantedBy=multi-user.target
+
+Enable the service with  
+
+    :::bash
+    systemctl enable tunnel@client2
+
+Start the service with  
+
+    :::bash
+    systemctl start tunnel@client2
+
+
+*[SSH]: Secure Shell
+*[MTA]: Message Transfer Agent
+*[TCP]: Transmission Control Protocol
+*[TUN]: network TUNnel (virtual-network kernel devices)
+*[VPN]: Virtual Private Network