mbw
Ich kann bzw. werde nur zu dem zweiten Punkt etwas sagen. Hier wurde ja keine kryptografische Verschlüsselung “gebrochen”, sondern es wurde eine Umleitung (der “Man in the middle”) eingeführt, eingehende Daten vom Client (Nutzer) mitgeschnitten und an den Server weitergeleitet.
Das können sowohl Nutzer als auch Serveradmins merken, theoretisch. Nutzerseitig geht man im Moment eben noch davon aus, dass nur solche CAs vom Browser als Vertrauenswürdig eingestuft werden, die bestimmte Mindestkriterien erfüllen. Das ist heute bereits nicht perfekt, wie etwa hier dazu angemerkt wurde.
Aber zumindest ist es nach heutigem Stand für diese CAs verpflichtend, dass sie sich an den “Certificate Transparency Log”-Standard halten. Ungewöhnliche Logeinträge haben die Server-Admins in dem verlinkten Artikel auch bemerkt und auf crt.sh verwiesen, sie hatten aber kein automatisches Monitoring dafür.
Wenn man eine Domain verwaltet, kann man nach unauthorisiert ausgestellten Zertifikaten Ausschau halten. Das kann man entweder selbst irgendwie implementieren. Oder man nutzt halt vorhandene Dienste wie hier beschrieben, bei welchen man automatisch alarmiert wird.
Ich schnappe immer wieder mal was auf von https://news.ycombinator.com/ oder https://lobste.rs.
Eine weitere interessante Quelle von kleinen, unbekannten Blogs könnte https://blogs.hn sein, insb. mit Shuffle
.
Ich hab mir über die Jahre eine kleine Auswahl angesammelt mit meinem RSS-Reader. Über die Jahre sammelt sich da echt was an und man kann die Feeds auch durchsuchen, falls man sich nur noch dunkel an einen Titel erinnert den man vor Jahren gelesen hat z.B.
Um noch einen konkreten Blog hierzulassen: https://brr.fyi/ ist von einem Mitarbeiter von McMurdo Station, Antarktis. Ist ausnahmsweise mal nicht technischer Natur sondern hat auch etwas Slice of Life - Charakter.
Just so that you have an additional data point, here’s how I do it.
I run a backup first, using borg-backup
. I used rsync
in the past, then rsnapshot
and now borg since it allows for compressed incremental backups, diffing on the “chunk” level, meaning I won’t backup the entirety of a modified file again and safe a lot of space.
I used yay
before, but like you I didn’t want to go into it blindly and do some modicum of sanity-checking the PKGBUILD for changes beforehand. Since it wasn’t obvious on what would be the best way of using yay
for doing this, I asked around on the ArchLinux Forum, and ultimately decided to try one of the simpler tools suggested in the Arch Wiki, aurutils
.
After setting it up (the author helped me migrate), I now use it as follows:
aur repo --upgrades
: Searches for new versions of aur packages and displays themaur sync --upgrades --no-build
: Performs a git-pull under~/.cache/aurutils/sync
and opensvifm
so that I can look at a diff of the PKGBUILD and all the other changes in the affected directory.aur sync --upgrades --no-view
: Builds the package. It is now available as part of the custom (local) repository used only for aur packages, but hasn’t been upgraded yet. That is, apackage.tar.gz
or whatever has been created and put into~/.cache/aurutils/sync/
, where thePKGBUILD
resides as wellsudo pacman -Syu
: Upgrades all packages from all repositories, including the ones from the custom repository
I won’t argue pro or against one aur helper or the other, but I feel like I have a little more insight about what happens under the hood since I made the switch. That being said, in the very beginning, I managed aur packages manually. This works also, but at some point became too tedious for my taste. I am happy with the semi-automatic approach I am using now.
I used tmsu (“tag my shit up”) for a while, but it required too much discipline and then I dropped it.
In addition, tools like fzf
for fuzzy file-search (comes with shell integration to e.g. replace the default history search in bash) and ripgrep-all
made this kind of organization unnecessary for me. It now suffices to have a vague idea where a thing is located and I can do a brute-force search in a few seconds.
The next-level filesystem argument is brought forward every few months, but I’m not buying it.
Mir hat ein Dozent sich aus dem Grund mal verweigert, das Kurspasswort für die Vorlesungsmaterialien mitzuteilen. Ich war an dem Termin als das mitgeteilt wurde nicht in der Vorlesung weil ich eben arbeiten musste, was von dem Dozenten mit dem Kommentar “ja das ist dann eben sehr schlecht” versehen wurde.
Es kommt aber auch sicher auf Studiengang und Hochschulort an wie (un-)gern das gesehen ist.
Then again, I’m not sure if for servers, Debian is still as important as it used to be. I’m probably overly generalizing, but often all you need is a few daemons installed natively (SSH, Docker, firewall), and your reverse proxy and any services are then managed e.g. via docker compose.
There are variations on this, but with the fraction of packages installed via the distro’s package manager having become smaller like that, what distro you use for a server should not impact your QoL as severely as it used to I think.
Your point about desktop usage still holds of course.
Auch ich nutze klassische Foren nur noch selten. Eigentlich nur noch ab und zu das Arch Linux Forum und auch nur wenn ich nicht mehr weiterweiß und fragen muss.
Bei einem klassischen Forum tendiert man dazu, seine Fragen/Beiträge länger zu formulieren oder ist sogar dazu angehalten. Dann macht man sich eben mehr Gedanken vorher und manchmal erledigt sich die Frage im Rahmen weiterer Nachforschungen von selbst.
So oder so ist die Hemmschwelle für mich größer, extra einen neuen Thread aufzumachen. Das war früher anders, aber wenn man halt einmal dieses “Was ist denn das für eine dumme Frage!!1” entgegengeknallt bekommen hat, gewöhnt man sich die Selbstzensur leider an.
Auf Discord hat man natürlich auch mehr Funktionen (Reactions, File Uploads, Voice Chat) und das Tempo ist höher. Ist Geschmackssache, aber ist halt der neue Standard. Bereuen werden wir es sicher irgendwann mal, wenn Walled Gardens wie Discord/Reddit mal irgendwann das Licht ausmachen und die Internetgeschichte an deren Stelle einen großen schwarzen Fleck aufweist.
I don’t know if this will be terribly useful for helping with your problem. I had this problem very seldomly and I believe it was related to some X.org problem which was fixed after an update, but it could of course be something entirely different for you.
As a very first step, I would maybe look if there is anything suspicious going on in the output of sudo journalctl -S
. Possible invocations are sudo journalctl -S 2023-08-14
, or -S today
or -S yesterday
, or just sudo journalctl
but then there may be a lot of output.
Oorrr, your distro doesn’t use systemd and this command doesn’t work (in which case you could try dmesg
or looking under var/log
manually, probably one of the most recently modified logfiles in there.
Depending on your distro there may be of course dedicated forums where the problem may already be known. The usual advice about updating packages etc. I will assume you have already followed^^