Reformat using prettier
This commit is contained in:
parent
eeac83e132
commit
210dc82ee9
SSH key fingerprint:
SHA256:bFAjFH3hR8zRBaJjzQDjc3o4jqoq5EZ87l+KXEjxIz0
6 changed files with 395 additions and 215 deletions
|
|
@ -1,11 +1,23 @@
|
|||
<!DOCTYPE html>
|
||||
<html lang="en-us">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta charset="utf-8" />
|
||||
<title>dadada's web log</title>
|
||||
<link rel="alternate" type="application/atom+xml" href="https://dadada.li/feed.xml" title="dadada">
|
||||
<link
|
||||
rel="alternate"
|
||||
type="application/atom+xml"
|
||||
href="https://dadada.li/feed.xml"
|
||||
title="dadada"
|
||||
/>
|
||||
</head>
|
||||
<body style="min-width:30em; max-width:60em; margin-left:auto; margin-right:auto">
|
||||
<body
|
||||
style="
|
||||
min-width: 30em;
|
||||
max-width: 60em;
|
||||
margin-left: auto;
|
||||
margin-right: auto;
|
||||
"
|
||||
>
|
||||
<header>
|
||||
<nav>
|
||||
<a href="https://dadada.li/">dadada</a>
|
||||
|
|
@ -33,22 +45,32 @@ decrypts +----------------+ +----------+ +-----------+
|
|||
+->| SEA (master) |
|
||||
| remote on paper |
|
||||
+-----------------+
|
||||
</pre>
|
||||
</pre>
|
||||
<p>
|
||||
See <a href="https://www.void.gr/kargig/blog/2013/12/02/creating-a-new-gpg-key-with-subkeys/">here</a> on how to strip the master key (sec) from your keyring and create secret subkeys (ssb) for daily active use.
|
||||
The master key can sign (S) new subkeys, create certificates (C) and provide authentication (A).
|
||||
The master key lives forever, while the ssb that is used for signing is created with an expiration date.
|
||||
All encryption keys may remain valid indefinitely until revoked.
|
||||
The master key can be used to revoke the subkeys.
|
||||
See
|
||||
<a
|
||||
href="https://www.void.gr/kargig/blog/2013/12/02/creating-a-new-gpg-key-with-subkeys/"
|
||||
>here</a
|
||||
>
|
||||
on how to strip the master key (sec) from your keyring and create secret
|
||||
subkeys (ssb) for daily active use. The master key can sign (S) new
|
||||
subkeys, create certificates (C) and provide authentication (A). The
|
||||
master key lives forever, while the ssb that is used for signing is
|
||||
created with an expiration date. All encryption keys may remain valid
|
||||
indefinitely until revoked. The master key can be used to revoke the
|
||||
subkeys.
|
||||
</p>
|
||||
<p>
|
||||
A few considerations
|
||||
<p>A few considerations</p>
|
||||
|
||||
<ul>
|
||||
<li>use a separate PIN on the trusted system / for the master key (sec) in case a key-logger reads the PIN on a semi-trusted machine (e.g. laptop or android) when decrypting a secret subkey (ssb)</li>
|
||||
<li>
|
||||
use a separate PIN on the trusted system / for the master key (sec) in
|
||||
case a key-logger reads the PIN on a semi-trusted machine (e.g. laptop
|
||||
or android) when decrypting a secret subkey (ssb)
|
||||
</li>
|
||||
<li>use subkey (A) for authenticating ssh</li>
|
||||
<li>keep master key offline / air-gapped</li>
|
||||
</ul
|
||||
</p>
|
||||
</ul>
|
||||
</main>
|
||||
<footer>Released: 2017-12-03</footer>
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -1,11 +1,23 @@
|
|||
<!DOCTYPE html>
|
||||
<html lang="en-us">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta charset="utf-8" />
|
||||
<title>dadada's web log</title>
|
||||
<link rel="alternate" type="application/atom+xml" href="https://dadada.li/feed.xml" title="dadada">
|
||||
<link
|
||||
rel="alternate"
|
||||
type="application/atom+xml"
|
||||
href="https://dadada.li/feed.xml"
|
||||
title="dadada"
|
||||
/>
|
||||
</head>
|
||||
<body style="min-width:30em; max-width:60em; margin-left:auto; margin-right:auto">
|
||||
<body
|
||||
style="
|
||||
min-width: 30em;
|
||||
max-width: 60em;
|
||||
margin-left: auto;
|
||||
margin-right: auto;
|
||||
"
|
||||
>
|
||||
<header>
|
||||
<nav>
|
||||
<a href="https://dadada.li/">dadada</a>
|
||||
|
|
@ -13,17 +25,41 @@
|
|||
</header>
|
||||
<main>
|
||||
<h1>My $HOME</h1>
|
||||
<p>Recently, I came across a blog posting titled <a href="https://morr.cc/home-sweet-home/">$HOME, sweet $HOME</a>, where <a href="https://morr.cc/"">@blinry</a> advocates for structuring your <code>HOME</code> directory based on projects and their activity. After reading this I felt inspired to finally have a look at the mess I made of my $HOME in the last years.</p>
|
||||
<p>A few things about my old <code>$HOME</code>:
|
||||
<ul>
|
||||
<li><code>Documents</code> contained basically everything I had accumulated during the last years besides music, videos, pictures and source code.</li>
|
||||
<li><code>projects</code> just contained one gigantic folder of all projects that I ever worked on. - the rest was based on the default <a href="https://freedesktop.org/wiki/Software/xdg-user-dirs/">xdg-user-dirs</a></li>
|
||||
</ul>
|
||||
<p>
|
||||
Recently, I came across a blog posting titled
|
||||
<a href="https://morr.cc/home-sweet-home/">$HOME, sweet $HOME</a>, where
|
||||
<a href="https://morr.cc/">@blinry</a> advocates for structuring your
|
||||
<code>HOME</code> directory based on projects and their activity. After
|
||||
reading this I felt inspired to finally have a look at the mess I made
|
||||
of my $HOME in the last years.
|
||||
</p>
|
||||
<p>If you sorted the files by file type like the default XDG directories
|
||||
<p>A few things about my old <code>$HOME</code>:</p>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
<code>Documents</code> contained basically everything I had
|
||||
accumulated during the last years besides music, videos, pictures and
|
||||
source code.
|
||||
</li>
|
||||
<li>
|
||||
<code>projects</code> just contained one gigantic folder of all
|
||||
projects that I ever worked on. - the rest was based on the default
|
||||
<a href="https://freedesktop.org/wiki/Software/xdg-user-dirs/"
|
||||
>xdg-user-dirs</a
|
||||
>
|
||||
</li>
|
||||
</ul>
|
||||
<p>
|
||||
If you sorted the files by file type like the default XDG directories
|
||||
suggest, files from one project may be scattered across many different
|
||||
directories.</p>
|
||||
<p>So my goal for the new <code>$HOME</code> was to have a clean directory structure where: - it is obvious where to place new files - paths do not become too long to type out - the directory structure relates to how I work</p>
|
||||
directories.
|
||||
</p>
|
||||
<p>
|
||||
So my goal for the new <code>$HOME</code> was to have a clean directory
|
||||
structure where: - it is obvious where to place new files - paths do not
|
||||
become too long to type out - the directory structure relates to how I
|
||||
work
|
||||
</p>
|
||||
<p>A quick tour of my new <code>$HOME</code>:</p>
|
||||
<ul>
|
||||
<li><code>lib</code> for immutable files</li>
|
||||
|
|
@ -32,10 +68,21 @@
|
|||
<li><code>tmp</code> for unsorted files and downloads</li>
|
||||
</ul>
|
||||
<h2 id="the-project-directory">The project directory</h2>
|
||||
<p>All of my projects are stored in <code>src</code>. I use a flat directory structure, where every project has its own subdirectory based on its name. Projects can become part of one or more larger contexts through the use of tags.</p>
|
||||
<p>
|
||||
All of my projects are stored in <code>src</code>. I use a flat
|
||||
directory structure, where every project has its own subdirectory based
|
||||
on its name. Projects can become part of one or more larger contexts
|
||||
through the use of tags.
|
||||
</p>
|
||||
<h2 id="tags">Tags</h2>
|
||||
<p>Tag directories are stored in <code>tag</code>. Each directory stores symbolic links to parts of a project that can be distributed around <code>lib</code> and <code>src</code>. One possible use for the tag directories is creating workbenches. If I use some directories in <code>lib</code> or <code>src</code> in different contexts,
|
||||
<code>tag</code> can be used to include them in multiple workbenches.</p>
|
||||
<p>
|
||||
Tag directories are stored in <code>tag</code>. Each directory stores
|
||||
symbolic links to parts of a project that can be distributed around
|
||||
<code>lib</code> and <code>src</code>. One possible use for the tag
|
||||
directories is creating workbenches. If I use some directories in
|
||||
<code>lib</code> or <code>src</code> in different contexts,
|
||||
<code>tag</code> can be used to include them in multiple workbenches.
|
||||
</p>
|
||||
<p>An example workflow</p>
|
||||
<pre>
|
||||
$ cd tag
|
||||
|
|
@ -43,8 +90,13 @@ $ mkdir -p course1/examples
|
|||
$ ln -s ~/src/example1 course1/examples/
|
||||
$ ln -s ~/lib/courses/course1 course1/material
|
||||
$ rm -r course1
|
||||
</pre>
|
||||
<p>I create new tags for various reasons, but mostly one for each larger context (e.g. work, hobbies, admin foo, thesis, courseXY) and some more for tracking project activity. There are four different tags in <code>tag</code> directory right now for tracking project activity:</p>
|
||||
</pre>
|
||||
<p>
|
||||
I create new tags for various reasons, but mostly one for each larger
|
||||
context (e.g. work, hobbies, admin foo, thesis, courseXY) and some more
|
||||
for tracking project activity. There are four different tags in
|
||||
<code>tag</code> directory right now for tracking project activity:
|
||||
</p>
|
||||
<ul>
|
||||
<li>permanent</li>
|
||||
<li>active</li>
|
||||
|
|
|
|||
|
|
@ -1,11 +1,23 @@
|
|||
<!DOCTYPE html>
|
||||
<html lang="en-us">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta charset="utf-8" />
|
||||
<title>dadada's web log</title>
|
||||
<link rel="alternate" type="application/atom+xml" href="https://dadada.li/feed.xml" title="dadada">
|
||||
<link
|
||||
rel="alternate"
|
||||
type="application/atom+xml"
|
||||
href="https://dadada.li/feed.xml"
|
||||
title="dadada"
|
||||
/>
|
||||
</head>
|
||||
<body style="min-width:30em; max-width:60em; margin-left:auto; margin-right:auto">
|
||||
<body
|
||||
style="
|
||||
min-width: 30em;
|
||||
max-width: 60em;
|
||||
margin-left: auto;
|
||||
margin-right: auto;
|
||||
"
|
||||
>
|
||||
<header>
|
||||
<nav>
|
||||
<a href="https://dadada.li/">dadada</a>
|
||||
|
|
|
|||
48
index.html
48
index.html
|
|
@ -1,11 +1,23 @@
|
|||
<!DOCTYPE html>
|
||||
<html lang="en-us">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta charset="utf-8" />
|
||||
<title>dadada</title>
|
||||
<link rel="alternate" type="application/atom+xml" href="https://dadada.li/feed.xml" title="dadada">
|
||||
<link
|
||||
rel="alternate"
|
||||
type="application/atom+xml"
|
||||
href="https://dadada.li/feed.xml"
|
||||
title="dadada"
|
||||
/>
|
||||
</head>
|
||||
<body style="min-width:30em; max-width:60em; margin-left:auto; margin-right:auto">
|
||||
<body
|
||||
style="
|
||||
min-width: 30em;
|
||||
max-width: 60em;
|
||||
margin-left: auto;
|
||||
margin-right: auto;
|
||||
"
|
||||
>
|
||||
<header>
|
||||
<nav>
|
||||
<a href="https://dadada.li/">dadada</a>
|
||||
|
|
@ -13,8 +25,14 @@
|
|||
</header>
|
||||
<main>
|
||||
<h1>dadada's web page</h1>
|
||||
<p>Things I enjoy: learning things and skills, making and eating food, weird music, biking, trains</p>
|
||||
<p>Tech stuff: Rust, Nix, networking, aircrafts, and a sprinkle of science, recovering from PHP, iOS, Android, explorer of legacy codebases</p>
|
||||
<p>
|
||||
Things I enjoy: learning things and skills, making and eating food,
|
||||
weird music, biking, trains
|
||||
</p>
|
||||
<p>
|
||||
Tech stuff: Rust, Nix, networking, aircrafts, and a sprinkle of science,
|
||||
recovering from PHP, iOS, Android, explorer of legacy codebases
|
||||
</p>
|
||||
<h2>Socials</h2>
|
||||
<ul>
|
||||
<li><a href="https://chaos.social/@dadada">Fediverse</a></li>
|
||||
|
|
@ -24,9 +42,23 @@
|
|||
</ul>
|
||||
<h2>Talks</h2>
|
||||
<ul>
|
||||
<li><a href="https://gitli.stratum0.org/dadada/lazy-admin-talk">NixOS for Lazy Admins (2023-09-14)</a>, <a href="https://bbb.stratum0.org/playback/presentation/2.3/b3f9875e5e8180697cd3d3029085a7ef441d513d-1694710080145">Recording</a></li>
|
||||
<li><a href="talks/pad-archiver">Gitlab als Archivar (2022-06-14)</a></li>
|
||||
<li><a href="talks/systemd-generator">systemd-generator(7) (2019-03-14)</a></li>
|
||||
<li>
|
||||
<a href="https://gitli.stratum0.org/dadada/lazy-admin-talk"
|
||||
>NixOS for Lazy Admins (2023-09-14)</a
|
||||
>,
|
||||
<a
|
||||
href="https://bbb.stratum0.org/playback/presentation/2.3/b3f9875e5e8180697cd3d3029085a7ef441d513d-1694710080145"
|
||||
>Recording</a
|
||||
>
|
||||
</li>
|
||||
<li>
|
||||
<a href="talks/pad-archiver">Gitlab als Archivar (2022-06-14)</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="talks/systemd-generator"
|
||||
>systemd-generator(7) (2019-03-14)</a
|
||||
>
|
||||
</li>
|
||||
</ul>
|
||||
<h2>Blog</h2>
|
||||
<ul>
|
||||
|
|
|
|||
|
|
@ -1,30 +1,48 @@
|
|||
<!DOCTYPE html>
|
||||
<html lang="en-us">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta charset="utf-8" />
|
||||
<title>dadada</title>
|
||||
<link rel="alternate" type="application/atom+xml" href="https://dadada.li/feed.xml" title="dadada">
|
||||
<link
|
||||
rel="alternate"
|
||||
type="application/atom+xml"
|
||||
href="https://dadada.li/feed.xml"
|
||||
title="dadada"
|
||||
/>
|
||||
</head>
|
||||
<body style="min-width:30em; max-width:60em; margin-left:auto; margin-right:auto">
|
||||
<body
|
||||
style="
|
||||
min-width: 30em;
|
||||
max-width: 60em;
|
||||
margin-left: auto;
|
||||
margin-right: auto;
|
||||
"
|
||||
>
|
||||
<header>
|
||||
<nav>
|
||||
<a href="https://dadada.li/">dadada</a>
|
||||
</nav>
|
||||
</header>
|
||||
<main>
|
||||
<h1 id="gitlab-als-archivar">📚 Gitlab als Archivar 📔</h1>
|
||||
<p>Eine kleine Spielerei zur Datensicherung.</p>
|
||||
<p>🦣 <span class="citation" data-cites="dadada">@dadada</span><span
|
||||
class="citation" data-cites="chaos.social">@chaos.social</span></p>
|
||||
<hr />
|
||||
<h2 id="ausgangslage">Ausgangslage</h2>
|
||||
<p>Hochschulpolitik produziert viele Pads - Notizen - Protokolle -
|
||||
Todolisten</p>
|
||||
<p>Pads verschwinden unerwartet - Server tot - Niemand erinnert sich
|
||||
mehr an den Link - Etherpad kann Löschfristen 🙈</p>
|
||||
<p>Konsequenz:</p>
|
||||
<hr />
|
||||
<pre><code>🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥
|
||||
<main>
|
||||
<h1 id="gitlab-als-archivar">📚 Gitlab als Archivar 📔</h1>
|
||||
<p>Eine kleine Spielerei zur Datensicherung.</p>
|
||||
<p>
|
||||
🦣 <span class="citation" data-cites="dadada">@dadada</span
|
||||
><span class="citation" data-cites="chaos.social">@chaos.social</span>
|
||||
</p>
|
||||
<hr />
|
||||
<h2 id="ausgangslage">Ausgangslage</h2>
|
||||
<p>
|
||||
Hochschulpolitik produziert viele Pads - Notizen - Protokolle -
|
||||
Todolisten
|
||||
</p>
|
||||
<p>
|
||||
Pads verschwinden unerwartet - Server tot - Niemand erinnert sich mehr
|
||||
an den Link - Etherpad kann Löschfristen 🙈
|
||||
</p>
|
||||
<p>Konsequenz:</p>
|
||||
<hr />
|
||||
<pre><code>🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥
|
||||
🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥
|
||||
🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥
|
||||
🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥
|
||||
|
|
@ -45,13 +63,13 @@ mehr an den Link - Etherpad kann Löschfristen 🙈</p>
|
|||
🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥
|
||||
🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥
|
||||
🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥</code></pre>
|
||||
<hr />
|
||||
<h2 id="lösung-1-copy-paste">Lösung 1: Copy-Paste</h2>
|
||||
<ul>
|
||||
<li>$Person kopiert ab und zu das Pad irgendwo hin</li>
|
||||
<li>$Person braucht muss dran denken, ist aber etwas verplant</li>
|
||||
</ul>
|
||||
<pre><code>Pad Wiki
|
||||
<hr />
|
||||
<h2 id="lösung-1-copy-paste">Lösung 1: Copy-Paste</h2>
|
||||
<ul>
|
||||
<li>$Person kopiert ab und zu das Pad irgendwo hin</li>
|
||||
<li>$Person braucht muss dran denken, ist aber etwas verplant</li>
|
||||
</ul>
|
||||
<pre><code>Pad Wiki
|
||||
+-------+ +-------+
|
||||
|- Info | |- Info |
|
||||
| ... | | ... |
|
||||
|
|
@ -60,28 +78,33 @@ mehr an den Link - Etherpad kann Löschfristen 🙈</p>
|
|||
|- Ideen| |- Ideen|
|
||||
| ... | | ... |
|
||||
+-------+ +-------+</code></pre>
|
||||
<hr />
|
||||
<h2 id="lösung-2-git-und-update-script">Lösung 2: Git und
|
||||
Update-Script</h2>
|
||||
<ul>
|
||||
<li>Pad-URLs in Datei</li>
|
||||
<li>Pads als Plaintext exportieren</li>
|
||||
<li>In Git einchecken</li>
|
||||
</ul>
|
||||
<pre><code>+------------------------+ +------+
|
||||
<hr />
|
||||
<h2 id="lösung-2-git-und-update-script">
|
||||
Lösung 2: Git und Update-Script
|
||||
</h2>
|
||||
<ul>
|
||||
<li>Pad-URLs in Datei</li>
|
||||
<li>Pads als Plaintext exportieren</li>
|
||||
<li>In Git einchecken</li>
|
||||
</ul>
|
||||
<pre><code>+------------------------+ +------+
|
||||
|- http://pad.url/p/pad | | git |
|
||||
|- http://pad.url/p/pad1 |---->| \pad |
|
||||
| ... | | \pad1|
|
||||
| ... |</code></pre>
|
||||
<p><a
|
||||
href="https://git.fginfo.tu-bs.de/fginfo/pad-archiver/-/blob/eac632d0cc68c7a9383a334088beadf00b930284/update">Update-Script</a></p>
|
||||
<hr />
|
||||
<h2 id="lösung-3-ci">Lösung 3: CI</h2>
|
||||
<ul>
|
||||
<li>Scheduled Task führt Update-Script aus</li>
|
||||
<li>Gitlab committet Änderungen automatisch</li>
|
||||
</ul>
|
||||
<pre><code>+--------------+ +-----------+
|
||||
<p>
|
||||
<a
|
||||
href="https://git.fginfo.tu-bs.de/fginfo/pad-archiver/-/blob/eac632d0cc68c7a9383a334088beadf00b930284/update"
|
||||
>Update-Script</a
|
||||
>
|
||||
</p>
|
||||
<hr />
|
||||
<h2 id="lösung-3-ci">Lösung 3: CI</h2>
|
||||
<ul>
|
||||
<li>Scheduled Task führt Update-Script aus</li>
|
||||
<li>Gitlab committet Änderungen automatisch</li>
|
||||
</ul>
|
||||
<pre><code>+--------------+ +-----------+
|
||||
| pad-archiver |-----CI---->| Container |
|
||||
+--------------+ +-----------+
|
||||
| |
|
||||
|
|
@ -91,20 +114,26 @@ href="https://git.fginfo.tu-bs.de/fginfo/pad-archiver/-/blob/eac632d0cc68c7a9383
|
|||
| pads-repo |--Scheduled->| Docker-Runner |
|
||||
| |<--Commits---| |
|
||||
+-----------+ +---------------+</code></pre>
|
||||
<p><a
|
||||
href="https://git.fginfo.tu-bs.de/fginfo/pad-archiver/-/tree/eac632d0cc68c7a9383a334088beadf00b930284">CI-Config</a>
|
||||
<!-- Frage: andere unkonventionelle Spielereien mit Gitlab --></p>
|
||||
<hr />
|
||||
<h2 id="lösung-4-rewrite-in-go">Lösung 4: Rewrite in Go</h2>
|
||||
<ul>
|
||||
<li>Empfehlung: go-git - Git nativ in Go
|
||||
<ul>
|
||||
<li>versucht kompatibel zu Git’s Plumbing und Porcelain zu sein</li>
|
||||
<li>wird unter Anderem von Keybase und Gitea benutzt</li>
|
||||
</ul></li>
|
||||
<li>LOC ist jetzt ein bisschen sehr viel mehr …</li>
|
||||
</ul>
|
||||
<pre><code> ,_---~~~~~----._ +--------------+
|
||||
<p>
|
||||
<a
|
||||
href="https://git.fginfo.tu-bs.de/fginfo/pad-archiver/-/tree/eac632d0cc68c7a9383a334088beadf00b930284"
|
||||
>CI-Config</a
|
||||
>
|
||||
<!-- Frage: andere unkonventionelle Spielereien mit Gitlab -->
|
||||
</p>
|
||||
<hr />
|
||||
<h2 id="lösung-4-rewrite-in-go">Lösung 4: Rewrite in Go</h2>
|
||||
<ul>
|
||||
<li>
|
||||
Empfehlung: go-git - Git nativ in Go
|
||||
<ul>
|
||||
<li>versucht kompatibel zu Git’s Plumbing und Porcelain zu sein</li>
|
||||
<li>wird unter Anderem von Keybase und Gitea benutzt</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>LOC ist jetzt ein bisschen sehr viel mehr …</li>
|
||||
</ul>
|
||||
<pre><code> ,_---~~~~~----._ +--------------+
|
||||
_,,_,*^____ _____``*g*\"*, | THIS IS FINE |
|
||||
/ __/ /' ^. / \ ^@q f +--------------+
|
||||
[ @f | @)) | | @)) l 0 _/ //
|
||||
|
|
@ -115,9 +144,10 @@ href="https://git.fginfo.tu-bs.de/fginfo/pad-archiver/-/tree/eac632d0cc68c7a9383
|
|||
] ~ ~ |
|
||||
| |
|
||||
| | </code></pre>
|
||||
<p><a
|
||||
href="https://git.fginfo.tu-bs.de/fginfo/pad-archiver">Rewritten</a></p>
|
||||
</main>
|
||||
<footer>Released: 2022-12-03</footer>
|
||||
</body>
|
||||
<p>
|
||||
<a href="https://git.fginfo.tu-bs.de/fginfo/pad-archiver">Rewritten</a>
|
||||
</p>
|
||||
</main>
|
||||
<footer>Released: 2022-12-03</footer>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -1,100 +1,132 @@
|
|||
<!DOCTYPE html>
|
||||
<html lang="en-us">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta charset="utf-8" />
|
||||
<title>systemd.generator(7)</title>
|
||||
<link rel="alternate" type="application/atom+xml" href="https://dadada.li/feed.xml" title="dadada">
|
||||
<link
|
||||
rel="alternate"
|
||||
type="application/atom+xml"
|
||||
href="https://dadada.li/feed.xml"
|
||||
title="dadada"
|
||||
/>
|
||||
</head>
|
||||
<body style="min-width:30em; max-width:60em; margin-left:auto; margin-right:auto">
|
||||
<body
|
||||
style="
|
||||
min-width: 30em;
|
||||
max-width: 60em;
|
||||
margin-left: auto;
|
||||
margin-right: auto;
|
||||
"
|
||||
>
|
||||
<header>
|
||||
<nav>
|
||||
<a href="https://dadada.li/">dadada</a>
|
||||
</nav>
|
||||
</header>
|
||||
<main>
|
||||
<h1 id="systemd.generator7">systemd.generator(7)</h1>
|
||||
<p><a
|
||||
href="https://www.youtube.com/watch?v=X88zHJjodFw">Recording</a></p>
|
||||
<h1 id="dynamische-systeme-sind-schwierig">Dynamische Systeme sind
|
||||
schwierig</h1>
|
||||
<ul>
|
||||
<li>➤ Devices, Mountpoints, Services, Timer möglichst als Unit</li>
|
||||
<li>Transitionstechnologie für <code>/etc/fstab</code> und SysV
|
||||
init-Skripte</li>
|
||||
<li>Hooks für den Bootprozess (System-Update, Resume, Debug …)</li>
|
||||
<li>Umgebungsvariablen setzen</li>
|
||||
<li>➤ Generatoren generieren beim Boot dynamisch Units</li>
|
||||
</ul>
|
||||
<h1 id="calling-convention">Calling convention</h1>
|
||||
<p><code># /path/to/generator normal-dir early-dir late-dir</code></p>
|
||||
<ul>
|
||||
<li>Generatoren sind in
|
||||
<ul>
|
||||
<li><code>/run/systemd/{system,user}-generators/*</code></li>
|
||||
<li><code>/etc/systemd/{system,user}-generators/*</code></li>
|
||||
<li><code>/usr/lib/systemd/{system,user}-generators/*</code></li>
|
||||
<li><code>/usr/local/lib/systemd/{system,user}-generators/*</code></li>
|
||||
</ul></li>
|
||||
</ul>
|
||||
<h1 id="generierte-units">Generierte Units</h1>
|
||||
<ul>
|
||||
<li>neu generieren mit <code>systemctl daemon-reload</code></li>
|
||||
<li>generierte Units landen in
|
||||
<ul>
|
||||
<li><code>normal-dir</code> ➤ <code>/run/systemd/generator</code></li>
|
||||
<li><code>early-dir</code> ➤
|
||||
<code>/run/systemd/generator.early</code></li>
|
||||
<li><code>late-dir</code> ➤
|
||||
<code>/run/systemd/generator.late</code></li>
|
||||
</ul></li>
|
||||
</ul>
|
||||
<h1 id="templating">Templating</h1>
|
||||
<ul>
|
||||
<li>generierte Units dürfen auch sein
|
||||
<ul>
|
||||
<li>Templates</li>
|
||||
<li>Instanzen von Templates (<code>getty@tty1.service</code>)</li>
|
||||
</ul></li>
|
||||
<li>Generatoren können auch Symlinks in <code>.wants/</code>,
|
||||
<code>.target</code> und <code>.requires/</code> erstellen</li>
|
||||
</ul>
|
||||
<h1 id="abhängigkeiten-vermeiden">Abhängigkeiten vermeiden</h1>
|
||||
<ul>
|
||||
<li>kein syslog oder journal benutzen</li>
|
||||
<li>keine Units starten</li>
|
||||
<li>keine nicht essentiellen Dateisysteme verwenden (aber /proc, /usr,
|
||||
/sys und /dev)</li>
|
||||
<li>Generatoren werden parallel ausgeführt</li>
|
||||
</ul>
|
||||
<h1 id="performance">Performance</h1>
|
||||
<p>kann Boot verlangsamen ➤ Nicht mit bash implementieren, lieber C</p>
|
||||
<h1 id="debugging">Debugging</h1>
|
||||
<pre><code>dir=$(mktemp -d)
|
||||
<main>
|
||||
<h1 id="systemd.generator7">systemd.generator(7)</h1>
|
||||
<p><a href="https://www.youtube.com/watch?v=X88zHJjodFw">Recording</a></p>
|
||||
<h1 id="dynamische-systeme-sind-schwierig">
|
||||
Dynamische Systeme sind schwierig
|
||||
</h1>
|
||||
<ul>
|
||||
<li>➤ Devices, Mountpoints, Services, Timer möglichst als Unit</li>
|
||||
<li>
|
||||
Transitionstechnologie für <code>/etc/fstab</code> und SysV
|
||||
init-Skripte
|
||||
</li>
|
||||
<li>Hooks für den Bootprozess (System-Update, Resume, Debug …)</li>
|
||||
<li>Umgebungsvariablen setzen</li>
|
||||
<li>➤ Generatoren generieren beim Boot dynamisch Units</li>
|
||||
</ul>
|
||||
<h1 id="calling-convention">Calling convention</h1>
|
||||
<p><code># /path/to/generator normal-dir early-dir late-dir</code></p>
|
||||
<ul>
|
||||
<li>
|
||||
Generatoren sind in
|
||||
<ul>
|
||||
<li><code>/run/systemd/{system,user}-generators/*</code></li>
|
||||
<li><code>/etc/systemd/{system,user}-generators/*</code></li>
|
||||
<li><code>/usr/lib/systemd/{system,user}-generators/*</code></li>
|
||||
<li>
|
||||
<code>/usr/local/lib/systemd/{system,user}-generators/*</code>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<h1 id="generierte-units">Generierte Units</h1>
|
||||
<ul>
|
||||
<li>neu generieren mit <code>systemctl daemon-reload</code></li>
|
||||
<li>
|
||||
generierte Units landen in
|
||||
<ul>
|
||||
<li>
|
||||
<code>normal-dir</code> ➤ <code>/run/systemd/generator</code>
|
||||
</li>
|
||||
<li>
|
||||
<code>early-dir</code> ➤ <code>/run/systemd/generator.early</code>
|
||||
</li>
|
||||
<li>
|
||||
<code>late-dir</code> ➤ <code>/run/systemd/generator.late</code>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<h1 id="templating">Templating</h1>
|
||||
<ul>
|
||||
<li>
|
||||
generierte Units dürfen auch sein
|
||||
<ul>
|
||||
<li>Templates</li>
|
||||
<li>Instanzen von Templates (<code>getty@tty1.service</code>)</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
Generatoren können auch Symlinks in <code>.wants/</code>,
|
||||
<code>.target</code> und <code>.requires/</code> erstellen
|
||||
</li>
|
||||
</ul>
|
||||
<h1 id="abhängigkeiten-vermeiden">Abhängigkeiten vermeiden</h1>
|
||||
<ul>
|
||||
<li>kein syslog oder journal benutzen</li>
|
||||
<li>keine Units starten</li>
|
||||
<li>
|
||||
keine nicht essentiellen Dateisysteme verwenden (aber /proc, /usr,
|
||||
/sys und /dev)
|
||||
</li>
|
||||
<li>Generatoren werden parallel ausgeführt</li>
|
||||
</ul>
|
||||
<h1 id="performance">Performance</h1>
|
||||
<p>kann Boot verlangsamen ➤ Nicht mit bash implementieren, lieber C</p>
|
||||
<h1 id="debugging">Debugging</h1>
|
||||
<pre><code>dir=$(mktemp -d)
|
||||
SYSTEMD_LOG_LEVEL=debug /usr/lib/systemd/system-generators/systemd-fstab-generator "$dir" "$dir" "$dir"
|
||||
find $dir</code></pre>
|
||||
<ul>
|
||||
<li>syslog(3) ist nicht vefügbar</li>
|
||||
<li>keine Magie versuchen</li>
|
||||
</ul>
|
||||
<h1 id="nicht-geeignet-für">Nicht geeignet für</h1>
|
||||
<ul>
|
||||
<li>Ersatz von init-Skripten ➤ systemd-sysv-generator(8)</li>
|
||||
<li>dynamische Konfigurationsdateien ➤ <code>ExecStartPre=</code> oder
|
||||
Service mit <code>Before=</code></li>
|
||||
</ul>
|
||||
<h1 id="beispiele">Beispiele</h1>
|
||||
<ul>
|
||||
<li><p>systemd-fstab-generator(8)</p></li>
|
||||
<li><p>systemd-debug-generator(8)</p></li>
|
||||
<li><p>systemd-getty-generator(8)</p></li>
|
||||
<li><p>systemd-sysv-generator(8)</p></li>
|
||||
<li><p>systemd.environment-generator(7)</p></li>
|
||||
</ul>
|
||||
<h1 id="source">Source</h1>
|
||||
<ul>
|
||||
<li><code>man 7 systemd.generator</code></li>
|
||||
</ul>
|
||||
</main>
|
||||
<footer>Released: 2019-03-14</footer>
|
||||
</body>
|
||||
<ul>
|
||||
<li>syslog(3) ist nicht vefügbar</li>
|
||||
<li>keine Magie versuchen</li>
|
||||
</ul>
|
||||
<h1 id="nicht-geeignet-für">Nicht geeignet für</h1>
|
||||
<ul>
|
||||
<li>Ersatz von init-Skripten ➤ systemd-sysv-generator(8)</li>
|
||||
<li>
|
||||
dynamische Konfigurationsdateien ➤ <code>ExecStartPre=</code> oder
|
||||
Service mit <code>Before=</code>
|
||||
</li>
|
||||
</ul>
|
||||
<h1 id="beispiele">Beispiele</h1>
|
||||
<ul>
|
||||
<li><p>systemd-fstab-generator(8)</p></li>
|
||||
<li><p>systemd-debug-generator(8)</p></li>
|
||||
<li><p>systemd-getty-generator(8)</p></li>
|
||||
<li><p>systemd-sysv-generator(8)</p></li>
|
||||
<li><p>systemd.environment-generator(7)</p></li>
|
||||
</ul>
|
||||
<h1 id="source">Source</h1>
|
||||
<ul>
|
||||
<li><code>man 7 systemd.generator</code></li>
|
||||
</ul>
|
||||
</main>
|
||||
<footer>Released: 2019-03-14</footer>
|
||||
</body>
|
||||
</html>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue