Site update

Author: ferki

2013/03/28/unattended-ubuntu-install-in-a-vm/index.html

@@ -61,7 +61,7 @@ <h1><a href="/2013/03/28/unattended-ubuntu-install-in-a-vm/">Unattended Ubuntu i
 
     </section>
     <section id="section-2">
-        <h2 id="getanubuntuinstallationimage">Get an Ubuntu installation image</h2>
+        <h2 id="get-an-ubuntu-installation-image"><a href="#get-an-ubuntu-installation-image">Get an Ubuntu installation image</a></h2>
 
 <p>I’m using the latest 64-bit LTS server ISO which is marked 12.04.2 at the moment of writing this. I also recommend downloading it via torrent then keep it seeding.</p>
 
@@ -70,7 +70,7 @@ <h2 id="getanubuntuinstallationimage">Get an Ubuntu installation image</h2>
 <li><a href="http://www.ubuntu.com/download/desktop/alternative-downloads">alternative downloads</a></li>
 </ul>
 
-<h2 id="mountisoandcopyfiles">Mount ISO and copy files</h2>
+<h2 id="mount-iso-and-copy-files"><a href="#mount-iso-and-copy-files">Mount ISO and copy files</a></h2>
 
 <p>Mount the downloaded image then copy the contents to a directory where you can edit the files since the mounted filesystem will be read-only.</p>
 
@@ -80,11 +80,11 @@ <h2 id="mountisoandcopyfiles">Mount ISO and copy files</h2>
 <span class="synStatement">chmod</span> <span class="synSpecial">-R</span> u+w /copy/here/preseed
 </code></pre>
 
-<h2 id="modifyfiles">Modify files</h2>
+<h2 id="modify-files"><a href="#modify-files">Modify files</a></h2>
 
 <p>Adjust isolinux.cfg and preseed files to your needs. The options needed before the installer mounts the installation media should go into isolinux.cfg as part of the append statement. Every other preconfiguration for the installer could be set in the preseed file (list of preseed options). All path info in the below examples should be seen as if the root directory was the ISO image’s root.</p>
 
-<h2 id="isolinux.cfg">isolinux.cfg</h2>
+<h2 id="isolinux.cfg"><a href="#isolinux.cfg">isolinux.cfg</a></h2>
 
 <p>As I intend to use the new image for unattended installation I replaced the original file with the following:</p>
 
@@ -112,7 +112,7 @@ <h2 id="isolinux.cfg">isolinux.cfg</h2>
 
 <p>The installer mounts the installation media at this point so it could load the specified preseed file and use that from here on.</p>
 
-<h2 id="preseedfile">Preseed file</h2>
+<h2 id="preseed-file"><a href="#preseed-file">Preseed file</a></h2>
 
 <p>In order to don’t stop to wait for any user input I needed to specify the following minimal set of preconfiguration options: hostname, initial user’s full name, username and MD5 hashed password, home directory encryption, timezone, partition setup, mirror config, update policy, additional packages to be insalled, GRUB installation, and how to finish the installation.</p>
 
@@ -159,12 +159,12 @@ <h2 id="preseedfile">Preseed file</h2>
 
 <p><strong>Edit: install acpid by default as it is needed for proper VM shutdown. The initial username/password is ubuntu/ubuntu in this example.</strong></p>
 
-<h2 id="recreateiso">recreate ISO</h2>
+<h2 id="recreate-iso"><a href="#recreate-iso">recreate ISO</a></h2>
 
 <pre><code class="highlight">mkisofs <span class="synSpecial">-r</span> <span class="synSpecial">-V</span> <span class="synOperator">&quot;</span><span class="synString">auto-ubuntu-minimalvm</span><span class="synOperator">&quot;</span> <span class="synSpecial">-cache-inodes</span> <span class="synSpecial">-J</span> <span class="synSpecial">-l</span> <span class="synSpecial">-b</span> isolinux/isolinux.bin <span class="synSpecial">-c</span> isolinux/boot.cat <span class="synSpecial">-no-emul-boot</span> <span class="synSpecial">-boot-load-size</span> <span class="synNumber">4</span> <span class="synSpecial">-boot-info-table</span> <span class="synSpecial">-o</span> /path/to/new/iso /copy/here
 </code></pre>
 
-<h2 id="boot">boot</h2>
+<h2 id="boot"><a href="#boot">boot</a></h2>
 
 <ul>
 <li>createqemu image</li>

2023/04/24/host-gentoo-dependency-tarballs-as-github-releases/index.html

@@ -69,7 +69,7 @@ <h1><a href="/2023/04/24/host-gentoo-dependency-tarballs-as-github-releases/">Ho
 
     </section>
     <section id="section-2">
-        <h2 id="thechallenge">The challenge</h2>
+        <h2 id="the-challenge"><a href="#the-challenge">The challenge</a></h2>
 
 <p>Official Gentoo developers have a personal space on dev.gentoo.org, and
 mirroring provided by the Gentoo Infrastructure project. They may decide to
@@ -89,7 +89,7 @@ <h2 id="thechallenge">The challenge</h2>
 <li>has no cost or at least an affordable price</li>
 </ul>
 
-<h2 id="discardedalternatives">Discarded alternatives</h2>
+<h2 id="discarded-alternatives"><a href="#discarded-alternatives">Discarded alternatives</a></h2>
 
 <p>On my business domain it would cost extra money to host tarballs, and traffic
 limit might become a problem already around 350 downloads given the total
@@ -106,7 +106,7 @@ <h2 id="discardedalternatives">Discarded alternatives</h2>
 GitHub limits free storage to 1 GB, and traffic to 1 GB/month for the former,
 and the latter would require an external store to host blobs, though.</p>
 
-<h2 id="theidea">The idea</h2>
+<h2 id="the-idea"><a href="#the-idea">The idea</a></h2>
 
 <p>I’m always interested to find the simplest solution that could work for the
 given situation, and then iterate from there gradually.</p>
@@ -124,18 +124,18 @@ <h2 id="theidea">The idea</h2>
 <li>create a GitHub release in my fork which includes the tarball</li>
 </ul>
 
-<h2 id="anexample">An example</h2>
+<h2 id="an-example"><a href="#an-example">An example</a></h2>
 
 <p>I have <a href="https://cli.github.com">GitHub CLI</a> installed and configured, so I will use that as an example below along with the app-text/vale ebuild I worked on last time. Similar tools could work as well, like <a href="https://hub.github.com/">hub</a>, or even a mix of browser interactions and plain git commands.</p>
 
-<h3 id="preparetherepository">Prepare the repository</h3>
+<h3 id="prepare-the-repository"><a href="#prepare-the-repository">Prepare the repository</a></h3>
 
 <pre><code class="highlight">$ gh repo fork errata-ai/vale
 $ cd vale
 $ git checkout v2.24.4
 </code></pre>
 
-<h3 id="generatetarball">Generate tarball</h3>
+<h3 id="generate-tarball"><a href="#generate-tarball">Generate tarball</a></h3>
 
 <p>The <a href="https://devmanual.gentoo.org/eclass-reference/go-module.eclass/index.html">go-module eclass
 documentation</a>
@@ -158,7 +158,7 @@ <h3 id="generatetarball">Generate tarball</h3>
 Hoffstätte</a> via
 <a href="https://fosstodon.org/@asynchronaut/112809755664826257">Mastodon</a>.</p>
 
-<h3 id="creategithubrelease">Create GitHub release</h3>
+<h3 id="create-github-release"><a href="#create-github-release">Create GitHub release</a></h3>
 
 <p>First, mark the forked repository as default for this directory. Then create
 a GitHub release including our tarball, with clear references to Gentoo usage
@@ -172,15 +172,15 @@ <h3 id="creategithubrelease">Create GitHub release</h3>
 version and the purpose. The notes make the purpose of the release clear for
 humans to read.</p>
 
-<h3 id="useitinanebuild">Use it in an ebuild</h3>
+<h3 id="use-it-in-an-ebuild"><a href="#use-it-in-an-ebuild">Use it in an ebuild</a></h3>
 
 <p>With the GitHub release in place in the fork, add the tarball as an extra
 distfile to the <code>SRC_URI</code> in the ebuild:</p>
 
 <pre><code class="highlight">SRC_URI<span class="synOperator">+=&quot;</span><span class="synString"> https://github.com/ferki/vale/releases/download/v</span><span class="synPreProc">${PV}</span><span class="synString">-gentoo-deps/</span><span class="synPreProc">${P}</span><span class="synString">-gentoo-deps.tar.xz</span><span class="synOperator">&quot;</span>
 </code></pre>
 
-<h2 id="conclusion">Conclusion</h2>
+<h2 id="conclusion"><a href="#conclusion">Conclusion</a></h2>
 
 <p>GitHub releases can host dependency tarballs when packaging Go software for Gentoo as an external contributor.</p>
 

2023/04/25/packaging-vale-2-24-4-for-gentoo/index.html

@@ -60,7 +60,7 @@ <h1><a href="/2023/04/25/packaging-vale-2-24-4-for-gentoo/">Packaging vale-2.24.
 
     </section>
     <section id="section-2">
-        <h2 id="changes">Changes</h2>
+        <h2 id="changes"><a href="#changes">Changes</a></h2>
 
 <ul>
 <li><p>drop EGO_SUM in favor of dependency tarballs</p>

2023/04/26/gentoo-has-xsel-1-2-1-among-the-firsts/index.html

@@ -63,7 +63,7 @@ <h1><a href="/2023/04/26/gentoo-has-xsel-1-2-1-among-the-firsts/">Gentoo has xse
 
     </section>
     <section id="section-2">
-        <h2 id="whydoesitmatter">Why does it matter?</h2>
+        <h2 id="why-does-it-matter"><a href="#why-does-it-matter">Why does it matter?</a></h2>
 
 <p>The xsel-1.2.1 release has accumulated several changes over time, including
 fixes for segfaults and memory leaks. As a personal highlight, the

2023/08/05/releasing-rex-1-14-3/index.html

@@ -60,7 +60,7 @@ <h1><a href="/2023/08/05/releasing-rex-1-14-3/">Releasing Rex-1.14.3</a></h1>
 
     </section>
     <section id="section-2">
-        <h2 id="fixlocalpackageinstallation">Fix local package installation</h2>
+        <h2 id="fix-local-package-installation"><a href="#fix-local-package-installation">Fix local package installation</a></h2>
 
 <p>An older contribution aimed at improving OpenBSD management capabilities had
 unintended side effects, and – depending on other circumstances – caused
@@ -74,7 +74,7 @@ <h2 id="fixlocalpackageinstallation">Fix local package installation</h2>
 
 <p>I added relevant tests and fixed the default value.</p>
 
-<h2 id="fixcheckingcommandexistence">Fix checking command existence</h2>
+<h2 id="fix-checking-command-existence"><a href="#fix-checking-command-existence">Fix checking command existence</a></h2>
 
 <p>In rare cases, command existence checks return an exit code indicating success,
 while actually reporting an error in their output.</p>
@@ -92,7 +92,7 @@ <h2 id="fixcheckingcommandexistence">Fix checking command existence</h2>
 <p>Instead, Rex now double-checks whether the command candidate actually exists in
 the file system or not.</p>
 
-<h2 id="fixtestsrelatedtogitfunctionality">Fix tests related to Git functionality</h2>
+<h2 id="fix-tests-related-to-git-functionality"><a href="#fix-tests-related-to-git-functionality">Fix tests related to Git functionality</a></h2>
 
 <p>The previous Rex-1.14.2 came with a new set of tests for Git functionality, and
 it all looked fine in our GitHub Actions workflows exercising the test suite on

2023/08/11/local-management-with-rex/index.html

@@ -56,7 +56,7 @@ <h1><a href="/2023/08/11/local-management-with-rex/">Local management with Rex</
 combination of local and remote execution. This post summarizes the main
 orientation points about local management.</p>
 
-<h2 id="tldr">TL;DR</h2>
+<h2 id="tldr"><a href="#tldr">TL;DR</a></h2>
 
 <p>Rex provides several options for local management to choose from, allowing
 authors to express their intent explicitly according to their use case at hand:</p>
@@ -73,7 +73,7 @@ <h2 id="tldr">TL;DR</h2>
 
     </section>
     <section id="section-2">
-        <h2 id="basicanatomyofrextaskdefinitions">Basic anatomy of Rex task definitions</h2>
+        <h2 id="basic-anatomy-of-rex-task-definitions"><a href="#basic-anatomy-of-rex-task-definitions">Basic anatomy of Rex task definitions</a></h2>
 
 <p>For the majority of use cases, I find it best to think about the most important
 parts of task definitions like this:</p>
@@ -97,7 +97,7 @@ <h2 id="basicanatomyofrextaskdefinitions">Basic anatomy of Rex task definitions<
 <p>I’ll not go into all details here to allow us staying aware of further
 internals while focusing on the general approach.</p>
 
-<h2 id="taskswithoutanexplicittarget">Tasks without an explicit target</h2>
+<h2 id="tasks-without-an-explicit-target"><a href="#tasks-without-an-explicit-target">Tasks without an explicit target</a></h2>
 
 <p>Tasks without any explicit target get executed on the local machine directly:</p>
 
@@ -125,7 +125,7 @@ <h2 id="taskswithoutanexplicittarget">Tasks without an explicit target</h2>
 task)</a>
 section in the documentation.</p>
 
-<h2 id="taskstargetinglocalexplicitly">Tasks targeting <code>&lt;local&gt;</code> explicitly</h2>
+<h2 id="tasks-targeting-local-explicitly"><a href="#tasks-targeting-local-explicitly">Tasks targeting <code>&lt;local&gt;</code> explicitly</a></h2>
 
 <p>One may intentionally design a task to manage the local machine by using the
 special <code>&lt;local&gt;</code> hostname recognized by Rex:</p>
@@ -142,7 +142,7 @@ <h2 id="taskstargetinglocalexplicitly">Tasks targeting <code>&lt;local&gt;</code
 <code>-H</code> or <code>-G</code> options, or with the <code>on</code> option of
 <a href="https://metacpan.org/pod/Rex::Commands#run_task"><code>run_task</code></a> from code.</p>
 
-<h2 id="overridethetaskstargettolocal">Override the task’s target to <code>&lt;local&gt;</code></h2>
+<h2 id="override-the-tasks-target-to-local"><a href="#override-the-tasks-target-to-local">Override the task’s target to <code>&lt;local&gt;</code></a></h2>
 
 <p>The <code>-H</code> command line option supports the same special <code>&lt;local&gt;</code> hostname:</p>
 
@@ -166,7 +166,7 @@ <h2 id="overridethetaskstargettolocal">Override the task’s target to <code>&lt
 <p>This approach allows users to intentionally choose local execution, regardless
 of a task having an explicit target or not.</p>
 
-<h2 id="disablesshpertaskwithno_sshtask">Disable SSH per task with <code>no_ssh task</code></h2>
+<h2 id="disable-ssh-per-task-with-no_ssh-task"><a href="#disable-ssh-per-task-with-no_ssh-task">Disable SSH per task with <code>no_ssh task</code></a></h2>
 
 <p>The <code>no_ssh</code> command hints individual tasks to not use SSH:</p>
 
@@ -190,7 +190,7 @@ <h2 id="disablesshpertaskwithno_sshtask">Disable SSH per task with <code>no_ssh
 <p>See also the <a href="https://metacpan.org/pod/Rex::Commands#no_ssh">no_ssh</a>
 documentation.</p>
 
-<h2 id="disablesshgloballywithno_ssh">Disable SSH globally with <code>no_ssh</code></h2>
+<h2 id="disable-ssh-globally-with-no_ssh"><a href="#disable-ssh-globally-with-no_ssh">Disable SSH globally with <code>no_ssh</code></a></h2>
 
 <p>In case none of the tasks need SSH to connect to their targets, the <code>no_ssh</code>
 command can disable it globally:</p>
@@ -212,7 +212,7 @@ <h2 id="disablesshgloballywithno_ssh">Disable SSH globally with <code>no_ssh</co
 <p>See also the <a href="https://metacpan.org/pod/Rex::Commands#no_ssh">no_ssh</a>
 documentation.</p>
 
-<h2 id="runningpartsofataskwithinlocalblocks">Running parts of a task within <code>LOCAL{}</code> blocks</h2>
+<h2 id="running-parts-of-a-task-within-local-blocks"><a href="#running-parts-of-a-task-within-local-blocks">Running parts of a task within <code>LOCAL{}</code> blocks</a></h2>
 
 <p>Wrapping parts of the task steps in a <code>LOCAL{}</code> block forces these to run on
 the local machine instead of on the target in effect otherwise:</p>
@@ -233,7 +233,7 @@ <h2 id="runningpartsofataskwithinlocalblocks">Running parts of a task within <co
 <p>See also the <a href="https://metacpan.org/pod/Rex::Commands#LOCAL">LOCAL</a>
 documentation.</p>
 
-<h2 id="connecttolocalhostoverssh">Connect to local host over SSH</h2>
+<h2 id="connect-to-local-host-over-ssh"><a href="#connect-to-local-host-over-ssh">Connect to local host over SSH</a></h2>
 
 <p>Using the identity of the local machine as target makes it possible to treat it
 the same way as remotes, including connecting to it using SSH like to any

2024/07/25/packaging-go-dependencies-for-gentoo/index.html

@@ -62,7 +62,7 @@ <h1><a href="/2024/07/25/packaging-go-dependencies-for-gentoo/">Packaging Go dep
 
     </section>
     <section id="section-2">
-        <h2 id="introductiontogentoopackaging">Introduction to Gentoo packaging</h2>
+        <h2 id="introduction-to-gentoo-packaging"><a href="#introduction-to-gentoo-packaging">Introduction to Gentoo packaging</a></h2>
 
 <p>While I won’t go into great detail about Gentoo packaging here, one aspect
 stands out as relevant: requiring all the source packages already available
@@ -102,13 +102,13 @@ <h2 id="introductiontogentoopackaging">Introduction to Gentoo packaging</h2>
 Instead, the ebuild must list any supplementary sources, allowing the package
 manager to download and verify these in advance as usual.</p>
 
-<h2 id="threewaystoapproachgodependencies">Three ways to approach Go dependencies</h2>
+<h2 id="three-ways-to-approach-go-dependencies"><a href="#three-ways-to-approach-go-dependencies">Three ways to approach Go dependencies</a></h2>
 
 <p>Go projects have different ways available to them to describe and manage their
 dependencies. This also affects downstream packaging when distributing the
 software towards end users. Let’s take a closer look at these methods.</p>
 
-<h3 id="vendordirectory">Vendor directory</h3>
+<h3 id="vendor-directory"><a href="#vendor-directory">Vendor directory</a></h3>
 
 <p>Some projects include their dependencies in a <code>vendor</code> directory in their
 repository. This feels great from a reproducibility perspective, since the
@@ -126,7 +126,7 @@ <h3 id="vendordirectory">Vendor directory</h3>
 <p>Because of the above, projects often won’t or can’t have a <code>vendor</code> directory,
 since they may consider it inefficient or even ineffective.</p>
 
-<h3 id="gomodules">Go modules</h3>
+<h3 id="go-modules"><a href="#go-modules">Go modules</a></h3>
 
 <p>Go modules describe their dependencies in a <code>go.mod</code> file, accompanied by their
 checksums in a <code>go.sum</code> file.</p>
@@ -155,7 +155,7 @@ <h3 id="gomodules">Go modules</h3>
 <p>As a result, Gentoo decided to deprecate this approach in favor of dependency
 tarballs, and using <code>EGO_SUM</code> in ebuilds leads to QA warnings.</p>
 
-<h3 id="prepackageddependencies">Prepackaged dependencies</h3>
+<h3 id="prepackaged-dependencies"><a href="#prepackaged-dependencies">Prepackaged dependencies</a></h3>
 
 <p>What if we could download all dependencies, create a (compressed) tarball
 archive out of them, and use it as an auxiliary source for the project getting
@@ -213,7 +213,7 @@ <h3 id="prepackageddependencies">Prepackaged dependencies</h3>
 external maintainers and their chosen hosting solution. Sounds risky in any
 security-conscious environment.</p>
 
-<h2 id="howcanwedobetter">How can we do better?</h2>
+<h2 id="how-can-we-do-better"><a href="#how-can-we-do-better">How can we do better?</a></h2>
 
 <p>At this point I have two approach in mind which would potentially solve the
 security and hosting challenges I encountered while packaging.</p>

pages/about.html

@@ -31,19 +31,19 @@ <h1><a href="/">🧑‍💻 agile sysadmin</a></h1>
         </nav>
 
         <main>
-            <h2 id="comments">Comments</h2>
+            <h2 id="comments"><a href="#comments">Comments</a></h2>
 
 <p>I intentionally omit a commenting function on this site. If you want to
 discuss something, please share the link or a quote on your favorite
 platform, and let your network know what you think. If you would like to
 involve me, please tag me directly on one of the platforms I use.</p>
 
-<h2 id="mistakes">Mistakes</h2>
+<h2 id="mistakes"><a href="#mistakes">Mistakes</a></h2>
 
 <p>In case you find something factually wrong, I would appreciate if you contact
 me on one of my channels, so I can fix it.</p>
 
-<h2 id="techstack">Tech stack</h2>
+<h2 id="tech-stack"><a href="#tech-stack">Tech stack</a></h2>
 
 <ul>
 <li>Built with <a href="http://preaction.me/statocles">Statocles</a></li>
@@ -52,7 +52,7 @@ <h2 id="techstack">Tech stack</h2>
 <li>Hosted on <a href="https://pages.github.com">GitHub Pages</a></li>
 </ul>
 
-<h2 id="history">History</h2>
+<h2 id="history"><a href="#history">History</a></h2>
 
 <p>Initial content comes from my previous <a href="https://agilesysadmin.wordpress.com/">Agile
 sysadmin</a> blog.</p>

pages/impressum.html

@@ -32,21 +32,21 @@ <h1><a href="/">🧑‍💻 agile sysadmin</a></h1>
         </nav>
 
         <main>
-            <h1 id="impressum">Impressum</h1>
+            <h1 id="impressum"><a href="#impressum">Impressum</a></h1>
 
-<h2 id="angabengem5tmg">Angaben gemäß 5 TMG</h2>
+<h2 id="angaben-gem-5-tmg"><a href="#angaben-gem-5-tmg">Angaben gemäß 5 TMG</a></h2>
 
 <p>Ferenc Erki <br>
 IT consulting <br>
 Naugarder Str. 47 <br>
 10409 Berlin</p>
 
-<h2 id="kontakt">Kontakt</h2>
+<h2 id="kontakt"><a href="#kontakt">Kontakt</a></h2>
 
 <p>Telefon: +4917686096002 <br>
 E-Mail: ferki@ferki.it</p>
 
-<h2 id="umsatzsteuer-id">Umsatzsteuer-ID</h2>
+<h2 id="umsatzsteuer-id"><a href="#umsatzsteuer-id">Umsatzsteuer-ID</a></h2>
 
 <p>Umsatzsteuer-Identifikationsnummer gemäß 27 a Umsatzsteuergesetz: <br>
 DE328787869</p>