…and this is how it’s done, the simplest way possible. I initially heard about this technique from Jan-Piet Mens, a large-scale fiddler unlike me, and have fully committed to it.
Write a Markdown file with a manpage structure and a tiny bit of syntactic legalese at the top. I’ll call mine demo.7.md, but I’ve also gone with having it double as a README.md in the past.
% demo(7) | A demo manual page
# Name
**demo** - A demo manual page
# Synopsis
`demo` (No arguments are supported)
# History
Introduced as an example on a random blog post
# See also
* pandoc(1)
Convert to a manual page markup using pandoc(1) and view the manpage:
pandoc --standalone --to man demo.7.md -o demo.7
man -l demo.7
That’s your quick-and-dirty WYSIWYG manual page.
(Update Sep. 29, 2023: Fixed missing “.7” in final man -l invocation.)
Disable the dynamic motd on Ubuntu and everywhere else
This is without messing around in /etc/pam.dor doing things that may be reverted by future updates. Remember to systemctl enable disable-dynamic-motd.timer.
# /etc/systemd/system/disable-dynamic-motd.timer
[Unit]
Description=Disable all the dynamic-motd scriptlets (timer)
[Timer]
OnBootSec=10
OnActiveSec=3600
[Install]
WantedBy=timers.target
# /etc/systemd/system/disable-dynamic-motd.service
[Unit]
Description=Disable all the dynamic-motd scriptlets (service)
[Service]
Type=oneshot
ExecStart=sh -c 'chmod -v -x /etc/update-motd.d/*'
Disable verbose logging on realmd.service
Problem on AD-member Linux client, realmd logs thousands of redundant messages:
Feb 01 11:11:34 kvm-28ca realmd[22302]: client using service: :1.1042
Feb 01 11:11:34 kvm-28ca realmd[22302]: holding daemon: :1.1042
Feb 01 11:11:34 kvm-28ca realmd[22302]: client gone away: :1.1042
Feb 01 11:11:34 kvm-28ca realmd[22302]: released daemon: :1.1042
Solution, disable debug logging in the systemd unit by introducing this drop-in:
dpkg –compare-versions is not exactly a secret, but I’ve wrapped a script around it to visualize and better wrap my head around non-straightforward naming schemes:
Ich bin wirklich dazu übergangen, mich komplett auf systemd-Timer statt Crontab-Einträge einzulassen, lediglich die Zeitangaben für kalendergebundene Events machen mir dauerhaft zu schaffen. Mir ist ein Rätsel, dass die allwissenden systemd-Entwickler darauf verzichtet haben, eine zusätzliche Konfigurationsmöglichkeit über die bekannten, selbsterklärenden und intuitiv verständlichen Crontab-Spezifikationen zu akzeptieren. Hier also eine Handvoll Beispiele:
Wann
Crontab
OnCalendar
Täglich um Uhr
45 13 * * *
13:45:00
Alle 5 Minuten
*/5 * * * *
*:00/5:00
Montags, Mittwoch, Donnerstag um Uhr
14 9 * * 1,3,5
Mon,Wed,Fri 09:14:00
Montag bis Freitag um Uhr
0 4 * * 1-5
Mon..Fri 04:00:00
Jeden Monatsersten um Uhr
0 6 1 * *
*-*-1 06:00:00
Alle 5 Minuten von 06:00 – 17:55
*/5 6-17 * * *
06..17:00/5:00
⚠️ Achtung: In der Tabelle sind non-breakable Spaces enthalten. ⚠️ Die Werte sind somit nicht für copy&paste geeignet.
Zum Testen mit systemd-analyze wird die jeweilige Definition mit Anführungszeichen übergeben:
Alternativ, insbesondere bei hoher Ausführungsfrequenz oder bei Überschneidungsgefahr, benutze ich, wenn ich schon in systemd unterwegs bin, heute gern monotone Timer.
Versuche, hybride Timer mit Elementen aus beiden Timer-Typen zu konfigurieren, haben bei mir keine Fehlermeldungen produziert, aber der OnCalendar-Teil der Konfiguration wurde ignoriert. Das genaue Verhalten scheint nicht definiert zu sein.
WantedBy sollte bei Timern im Systemkontext auf timers.target lauten, da damit die NTP-Synchronisation vorm Start des Timer sichergestellt ist. Im Userkontext (Wallpaperchanger, Zeiterfassung, dies das) steht nur default.target zur Verfügung.
Inb4, warum überhaupt auf systemd-Timer statt crontab einlassen? Ganz einfach, weil systemd-Timer absolut narrensicher zu managen sind:
Du willst einen systemd-Timer verteilen/managen/paketieren? Kein Problem. Zwei Dateien nach /etc/systemd/system packen, systemctl daemon-reload, systemctl enable, fertig. Anders als in der Crontab musst du dir keine Meta-Syntax ausdenken, um zu identifizieren, ob der Eintrag schon da ist, und um ihn punktgenau löschen zu können.
Du willst einen vorinstallierten Timer anpassen? Ebenfalls kein Problem. Du legst ein Drop-In daneben, in dem du deine neue Timer-Spezifikation hinterlegst, etwa /etc/systemd/system/apt-daily.timer.d/local.conf als Drop-In für /lib/systemd/system/apt-daily.timer.
AUI-TransceiverTypenschildGehäuselogoDiskettenlaufwerk und HauptschalterGerät auf KüchentischBedienpanel
Von den Leuten, die uns “STRG”, “ENTF” und “EINFG” gebracht haben, ein Highlight, das sich leider nie durchgesetzt hat: Die GRDST-Taste.
Diese RS/6000 hat den Weg zu mir so um 2000 gefunden, als mein erster Vollzeit-Linuxjob noch ein paar Jahre entfernt war.
Damals kuschelte IBM etwas widerwillig mit Linux und hatte auf AIX 4.3.3 parallel zur Einführung von AIX 5L (das L sollte für die Nähe zu Linux stehen) RPM als additiven Paketmanager eingeführt. Die Liste der damals verfügbaren Pakete kann bei bullfreeware.com bewundert werden (hier ein lokaler Mirror). Ich habe zuletzt noch einige davon installiert, um das Tool zum Benchmarking übersetzen zu können.
Zur 7012 besitze ich auch noch das passende SCSI-CDROM mit der passenden obskuren Blockgröße. Installationsmedien sind aber keine mehr vorhanden. Die Demo-Installation mit User root und Password root muss also für immer halten. Außer AIX ist mir kein Betriebssystem bekannt, das auf dem System nutzbar wäre.
SSH fehlt, aber per Telnet über den wackeligen AUI-Transceiver mit 10 Megabit/s macht das System einen sehr guten und responsiven Eindruck, fast besser als heute manche VMware-Instanz. 😉
Die Towers of Hanoi aus dem BYTE Unix Benchmark führt die RS/6000 mit ca. 1050 Loops pro Sekunde aus. Ein halbwegs aktuelles Vergleichssystem mit Intel-CPU und 3,6 GHz kommt auf ca. 3200000 Loops pro Sekunde.
Divisionen in der folgenden Schleife macht die RS/6000 mit 16500/s (Perl 5.5 vorinstalliert) bzw. 14500/s (Perl 5.8 aus dem RPM); mein moderneres Vergleichssystem kommt auf knapp 7 Millionen/s.
Softwaretechnisch größtes Highlight dürfte das installierte Java 1.1.8 sein. IPv6 wird zur Konfiguration angeboten, funktioniert aber in dieser aus dem Jahr 1999 stammenden Implementation nicht wirklich zufriedenstellend.
Technische Daten: POWER1-Prozessor mit 50 MHz, 128 MB Arbeitsspeicher, 2 GB Festplatte. Produktionszeitraum 1993-1994. (Mirror vom Datenblatt)
(Dieser Beitrag stand 2014 schon mal an anderer Stelle. Die Benchmarks auf heutigen Systemen wurden aktualisiert und ein lokaler Mirror der Bullfreeware-Liste und des Datenblatts gesichert.)
Ich weiß jetzt wieder, wie ich Letsencrypt auf DNS Round-Robin mit zwei Servern aufgesetzt hatte und finde es auch mit einigen Jahren Abstand gar nicht mal so schrecklich.
Die Server kennen sich auf Port 80 unter ihrem Namen im Round-Robin und unter einem eigenen Rollennamen:
Was jetzt noch übrig bleibt, wird daraufhin geprüft, ob a) die angeforderte Challenge im Dateisystem nicht vorhanden ist und b) der Request an den Namen aus dem Round-Robin gestellt wurde (um endlose Proxy-Rekursionen zu verhindern). Falls die Challenge lokal nicht existiert, wird der Request per Reverse Proxy an einen nachgelagerten Server gestellt:
Mit 2 Servern ist klar, wo die Challenge zu holen ist. Bei 3 und mehr Servern würde ich eher nicht riskieren, in multiple Proxy-Weiterleitungen zu gehen, sondern mod_rewrite über RewriteMap aktiv ermitteln lassen, auf welchem der anderen Server die Challenge denn tatsächlich liegt.
When systemd makes you suffer because “run job every 10 minutes” is infinitely harder to specify than in crontab, remember there are monotonic timers in systemd that aren’t derived from wallclock time, or “Calendar Events” as they call it.
Run timer once 60 seconds after system startup, then every 10 minutes after the job finished:
# /etc/systemd/system/demo.timer
[Unit]
Description=demo monotonic timer
[Timer]
OnStartupSec=60
OnUnitInactiveSec=600
[Install]
WantedBy=timers.target # When in a system session
# WantedBy=default.target # When in a user session (~/.config/systemd, systemctl --user etc.)
See also TGT0006, this is just as useful for downgrading privileges on the fly.
“When was the last time apt-get on that Debian/Ubuntu machine installed package upgrades?”
Reliably answering this is a lot harder than it looks, subject of countless discussions and really does need to parse /var/log/apt/history.log, which is painful.
The script below maintains a file /var/log/apt/lastupgrade with the last upgrade’s time stamp, for further processing.
Does NOT track invocations of apt-get upgrade that did not lead to package upgrades.
Does NOT look behind logfile rotations, which should not be a problem because it’s closely hooked to dpkg.
/usr/sbin/apt-lastupgrade:
#!/bin/bash
while IFS=: read -r key value
do
if [[ "${key}" == 'Start-Date' ]]
then
upgraded=0
elif [[ "${key}" == 'Upgrade' ]]
then
upgraded=1
elif [[ "${key}" == 'End-Date' ]]
then
if [[ ${upgraded} -eq 1 ]]
then
printf -v lastupgrade "%s" "${value}"
fi
upgraded=0
fi
done < /var/log/apt/history.log
if [[ -v lastupgrade ]]
then
tee /var/log/apt/lastupgrade <<-Here
# Timestamp of last upgrade: ${lastupgrade}
Here
touch -d "${lastupgrade}" /var/log/apt/lastupgrade
fi
cookiecount– Load a page and show the cookies it sets
$ ./cookiecount https://example.com
0 cookies received.
ps1_anon.bash – anonymize bash prompt, for screenshots and pastes
# Anonymize bash prompt for screenshots and pastes
# Source from or add to ~/.bashrc
function ps1_anon (){
if [[ -v SAVED_PS1 ]]
then
PS1="${SAVED_PS1}"
unset SAVED_PS1
else
SAVED_PS1="${PS1}"
PS1='\$ '
fi
}