mhu.dev

Extractig Generic Substates in Axum

2024-07-02T00:00:00+00:00

In this post I'll show you how to extract a generic substate in Axum handlers, without resorting to dynamic dispatch.

Developing NixOS (and Home Manager) Modules

2024-01-15T00:00:00+00:00

If you use NixOS or Home Manager, chances are that you have (unknowingly) created a NixOS module. In this post, I'll document my learnings around how they work, and how to easily test them in isolation.

NixOS on Hetzner Dedicated

2024-01-06T00:00:00+00:00

As it is currently fashionable for the Nerd interested in all things Nix(OS), I have set up my own NixOS Server on Hetzner Dedicated. I'll first go over the setup details, and then describe how I set everything up. Unfortunately, Documentation around the Nix ecosystem is pretty "meh" (being used the high quality of documentation in the Rust ecosystem), so maybe this helps someone else along the way.

Kubernetes resource management and you

2021-03-01T00:00:00+00:00

Scheduling and resource management is a topic many Kubernetes users seem to struggle with, even though it is vital to understand it and correctly configure your workload to ensure optimal resource usage and application availability. In this article, I'll explain what scheduling and resource management exactly is, how you configure and use them, and go into some best practices.

Continuously Deploying DNS records with DnsControl and CircleCI

2018-04-20T00:00:00+00:00

In the previous post</a>, I gave a quick introduction to DnsControl</a>, what it does and how it works. In this post, I'll show you how to continuously deploy your changes to Google Cloud DNS</a> using CircleCI</a>.

Managing DNS records the DevOps way

2018-04-19T00:00:00+00:00

Managing DNS records has always been a bit of a hassle for me. Most DNS providers have some sort of web gui where you have to manually fiddle in all records manually. Besides the fact that this is really tedious, this is quite error-prone. Humans are horrible at doing manual work! So let's automate this!

Working with Git submodules

2016-08-11T00:00:00+00:00

Here's a quick primer on how to work with Git submodules!

Java: Create self-signed TLS/SSL certificates for Tomcat

2016-02-09T00:00:00+00:00

To use an TLS certificate with Tomcat, you need to store it in a Java keystore File. You can generate both the keystore and the certificate using the Java command keytool</code>.

Step 0: Find your keytool</code></h2>
Make sure you have Java and keytool</code> command (ships with Java) installed. If you installed the JDK or JRE yourself it may not be in your $PATH</code>.</p>
For example, my keytool</code> is in ./jdk1.8/bin/</code>.</p>
If you do not know where to look, use the following commmand:</p>
find / -name keytool -type f 2>/dev/null
</span></code></pre>
Step 1: Generate the keystore and the certificate</h2>
Before we begin, a note about the "alias" and the "common name" of the certificate:</p>

The alias</strong> is simply a "label" used by Java to identify a specific certificate in the keystore (a keystore can hold multiple certificates). It has nothing to do with the server name, or the domain name of the Tomcat service.</li>
The common name</strong> (CN) is an attribute of the TLS certificate. Your browser will usually complain if the CN of the certificate and the domain in the URI do not match (but since you're using a self-signed certificate, your browser will probably complain anyway...). HOWEVER, when generating the certificate, the keytool will ask for "your first and last name" when asking for the CN, so keep that in mind. The rest of the attributes are not really that important</li>
</ul>
So let's generate a strong 4096-bit certificate that is valid for 2 years. Adjust ALIAS</code> and the path to the key store accordingly</p>
keytool -genkey -keystore</span> /srv/jakarta/.keystore</span> -alias</span> ALIAS \
</span>    -keyalg</span> RSA</span> -keysize</span> 4096</span> -validity</span> 720
</span># Enter keystore password = # well, enter something
</span># Re-enter new password = # same as above
</span># What is your first and last name?
</span>#   [Unknown]:  example.com # !!! IMPORTANT this is the domain name, NOT YOUR name
</span># What is the name of your organizational unit?
</span>#   [Unknown]:  # enter something or leave empty
</span># What is the name of your organization?
</span>#   [Unknown]:  # enter something or leave empty
</span># What is the name of your City or Locality?
</span>#   [Unknown]:  # enter something or leave empty
</span># What is the name of your State or Province?
</span>#   [Unknown]:  # enter something or leave empty
</span># What is the two-letter country code for this unit?
</span>#   [Unknown]:  # enter something or leave empty
</span># Is CN=example com, OU=Foo, O=Bar, L=City, ST=AA, C=FB correct?
</span>#   [no]:  yes
</span># Enter key password for <ALIAS>
</span>#     (RETURN if same as keystore password): # Press RETURN
</span></code></pre>
Great, now the keystore has been created (if it didn't exist already) and your self-signed certificate has been added to it.</p>
Step 2: Configure Tomcat</h2>
To use the new certificate, configure your Tomcat accordingly:</p>
Activate the HTTPS-Connector in your conf/server.xml</code>. Adjust keyAlias</code>, keystoreFile</code> and keystorePass</code> accordingly:</p>
<</span>Connector </span>port</span>="</span>8443</span>" </span>protocol</span>="</span>org.apache.coyote.http11.Http11NioProtocol</span>"
</span>           </span>maxThreads</span>="</span>150</span>" </span>SSLEnabled</span>="</span>true</span>" </span>scheme</span>="</span>https</span>" </span>secure</span>="</span>true</span>"
</span>           </span>clientAuth</span>="</span>false</span>" </span>sslProtocol</span>="</span>TLS</span>"
</span>           </span>keyAlias</span>="</span>ALIAS</span>" </span>keystoreFile</span>="</span>/srv/jakarta/.keystore</span>"
</span>           </span>keystorePass</span>="</span>PW from step 1</span>" />
</span></code></pre>
And that's it! Restart Tomcat and you're ready!</p>

Make all *.local domains resolve to localhost 2016-02-02T00:00:00+00:00 It's time for my yearly blog post, so let's get started! Some development environments use *.local</code>-domains which point to localhost. Creating a hosts-entry for every single domain is not an elegant solution, so let's do something easier: let's use dnsmasq to resolve ALL .local-domains to localhost! Tested on CentOS 7, but should work similarly for other Linuxes. All commands assume you have root privileges. If you are not logged in as root</code>, prepend sudo</code> to all commands. First, make sure dnsmasq is installed: yum install dnsmasq </code></pre> Ok, now we have to tell dnsmasq to listen for queries. Add the following line to /etc/dnsmasq.conf</code>: listen-address=127.0.0.1 </code></pre> Next, create a "zone file" for .local</code>. Create a file /etc/dnsmasq.d/local</code> and add the following: address=/local/127.0.0.1 </code></pre> This tells dnsmasq to resolve queries to *.local</code> to 127.0.0.1</code>. Now, start up dnsmasq. Also enable "autostart": systemctl restart dnsmasq systemctl enable dnsmasq </code></pre> Ok, now that we set up a local DNS server, let's tell our DHCP client to actually use it. Add the following line to /etc/dhcp/dhclient.conf</code>: prepend domain-name-servers=127.0.0.1; </code></pre> Last step: let the DHCP client apply the new settings: dhclient </code></pre> And that's it! Let's make a quick test: $ ping foo.local PING foo.local (127.0.0.1) 56(84) bytes of data. 64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.017 ms 64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.068 ms # ... </code></pre> Success! Heredoc in Javascript 2015-03-16T00:00:00+00:00 Update 2023: JavaScript now has "native" multiline strings for quite some time: const monty = `It's only a model. Who's that then? On second thoughts, let's not go there. It is a silly place.`; console.log(monty); // It's only a model. // Who's that then? // On second thoughts, let's not go there. // It is a silly place. </code></pre> Original post for context below. Most programming languages have a syntax for defining multiline string literals. Here's an example for Ruby: monty = <<END It's only a model. Who's that then? On second thoughts, let's not go there. It is a silly place. END puts monty.inspect #=> "It's only a model.\nWho's that then?\nOn second thoughts, let's not go there.\nIt is a silly place.\n" </code></pre> Javascript, however, does not have such a syntax. You can just insert newline characters yourself (\n</code>), but then you have to escape the actual newline aswell... It's quite messy! var monty = "It's only a model.\n\ Who's that then?\n\ On second thoughts, let's not go there.\n\ It is a silly place."; </code></pre> There is, however, a funny hack :) var monty = (function() {/*Well, we did do the nose. What do you mean? She looks like one. You don't vote for kings. */}).toString().match(/[^]*\/\*([^]*)\*\/\}$/)[1]; console.log(monty); //=> Well, we did do the nose. //=> What do you mean? //=> She looks like one. //=> You don't vote for kings. </code></pre> And that's how you do Heredocs in Javascript!


Continuous Deployment with Github Pages
2013-12-12T00:00:00+00:00
Or how to let Travis-CI merge into master if the build is successful</strong>.</p>
It is way easier than I thought.</p>
Prerequisites</h2>

The travis</code> gem</li>
Travis-CI integration up and running (ie .travis.yml</code> is set up).</li>
</ul>
Step 1: Acquire Github Access Token</h2>
This is required because we don't want to write our Github username and password anywhere.
Go to your Github Application Settings</a> and create a new Token.</p>
Step 2: Encrypt the token</h2>
Even the Token is not something to post on your Twitter.</p>
travis</span> encrypt</span> -a</span> - GITHUB_TOKEN=your_generated_token
</span></code></pre>
Your token will be encrypted and automatically added to your .travis.yml</code> file.</p>
Step 3: Add some magic to your Travis config</h2>
'nuff said. Add these lines to .travis.yml (note this are only two lines):</p>
after_success</span>:
</span>- '</span>[ "${TRAVIS_BRANCH}" = "stable" ] && git push https://${GITHUB_TOKEN}:x-oauth-basic@github.com/${TRAVIS_REPO_SLUG}.git HEAD:master</span>'
</span></code></pre>
Now for some explanation:
The first part, [ "${TRAVIS_BRANCH}" = "stable" ] &&</code> only runs the following command if the current branch name is "stable". You can omit this if you want to merge from ANY branch, or change it to use another branch.</p>
The second part, git push https://${GITHUB_TOKEN}:x-oauth-basic@github.com/${TRAVIS_REPO_SLUG}.git HEAD:master'</code> actually pushes the currently checked out state into master.</p>

$GITHUB_TOKEN</code> holds our Token from above</li>
$TRAVIS_REPO_SLUG</code> holds github_username/github_repo_name</code> (in my case this is mhutter/mhutte.github.io</code>).</li>
</ul>

Back story</h2>
To ensure new pages don't break Jekyll (as I managed earlier this month), I use Travis-CI</a>.</p>
I started working on a development branch and only merging into master after the Travis build succeeded. However, being the lazy guy I am I asked myself: "Wouldn't it be nice to let Travis automatically merge into master if the build succeeds?"</p>


Install own CA-Certificate in Linux
2012-03-27T00:00:00+00:00
Overview</strong></p>

Ubuntu, SLES, Debian</a></li>
CentOS, RHEL</a></li>
</ul>
Ubuntu, SLES, Debian</h2>
Tested under Ubuntu</strong> and SLES 11</strong> so far.</em></p>
Required Packages</h3>
install with apt-get install ...</code> or similar</p>

openssl</code></li>
</ul>
Steps</h3>
# Step 0: Convert the Certificate to PEM format
</span>openssl</span> x509</span> -inform</span> der</span> -in</span> certificate.cer</span> -out</span> certificate.pem
</span>
</span># Step 0.5: Make sure there is only 1 Certificate in the File
</span>grep </span>'</span>BEGIN.* CERTIFICATE</span>' certificate.pem | </span>wc -l </span># should output `1`
</span>
</span># Step 1: Verify it's the correct Certificate
</span>openssl</span> x509</span> -noout -fingerprint -in</span> certificate.pem
</span>
</span># Step 2: Copy the File to /etc/ssl/certs
</span># Do I really have to explain that? If you can't do that on your own you
</span># probably shouldn't be installing CA-Certificates anyway...
</span>
</span># Step 3: Find out the Hash of your Cert
</span>openssl</span> x509</span> -noout -hash -in</span> certificate.pem
</span>
</span># Step 4: Inside /etc/ssl/certs, link your certificate to "hash.0"
</span>ln -s</span> certificate.pem `</span>openssl</span> x509</span> -hash -noout -in</span> certificate.pem`.0
</span></code></pre>
CentOS</h2>
Required Packages</h3>
install with yum install ...</code> or similar</p>

ca-certificates</code></li>
</ul>
Steps</h3>
# Enable the CA configuration feature
</span>update-ca-trust</span> enable
</span>
</span># Add the new certificate to `/etc/pki/ca-trust/source/anchors`
</span>cp</span> certificate.cer /etc/pki/ca-trust/source/anchors/
</span>
</span># update the CA certs
</span>update-ca-trust</span> extract
</span></code></pre>
And that's it!</p>


Apache: Redirect if domain name does not match
2011-12-14T00:00:00+00:00
Note: This post is mostly kept for nostalgic reasons :-)</em></p>
Redirect everything to dratir.ch:</p>
RewriteEngine </span>On
</span>Rewritecond </span>%{HTTP_HOST} </span>!^dratir\.com
</span>RewriteRule </span>(.*) </span>http://dratir.com/$1</span> [QSA,R=</span>301</span>,L]
</span></code></pre>

mhu.dev

Extractig Generic Substates in Axum

Developing NixOS (and Home Manager) Modules

NixOS on Hetzner Dedicated

Kubernetes resource management and you

Continuously Deploying DNS records with DnsControl and CircleCI

Managing DNS records the DevOps way

Working with Git submodules

Java: Create self-signed TLS/SSL certificates for Tomcat

Make all *.local domains resolve to localhost

Heredoc in Javascript

Continuous Deployment with Github Pages

Prerequisites</h2> The travis</code> gem</li>

Step 1: Acquire Github Access Token</h2> This is required because we don't want to write our Github username and password anywhere. Go to your Github Application Settings</a> and create a new Token.</p>

Install own CA-Certificate in Linux

Ubuntu, SLES, Debian</h2> Tested under Ubuntu</strong> and SLES 11</strong> so far.</em></p>

CentOS</h2>

Apache: Redirect if domain name does not match

Step 1: Acquire Github Access Token</h2>
This is required because we don't want to write our Github username and password anywhere. Go to your Github Application Settings</a> and create a new Token.</p>

Ubuntu, SLES, Debian</h2>
Tested under Ubuntu</strong> and SLES 11</strong> so far.</em></p>