Han_Trio

UPDATE ! Nun funktioniert es endlich !
unter   /etc/default/ufw   musste der forwarding parameter auf "accept" gesetzt werden.
Grossen Dank an euch alle, mit euren Denkanstössen ans Ziel gekommen ❤️
 

So gesehen ist ufw auch "nur" ein Frontend für iptables
Ich denke auch, forwarding ist hier das Stichwort, mit dem man sich noch ein wenig näher befassen sollte.
Zum Thema PING: Das dürfte funktionieren, weil es bei ufw eine Sammlung von sog. "before rules" gibt. Die solltest du hier finden:
/etc/ufw/before.rules
Da steht u.a. drin:
# ok icmp codes for INPUT -A ufw-before-input -p icmp --icmp-type destination-unreachable -j ACCEPT -A ufw-before-input -p icmp --icmp-type time-exceeded -j ACCEPT -A ufw-before-input -p icmp --icmp-type parameter-problem -j ACCEPT -A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT # ok icmp code for FORWARD -A ufw-before-forward -p icmp --icmp-type destination-unreachable -j ACCEPT -A ufw-before-forward -p icmp --icmp-type time-exceeded -j ACCEPT -A ufw-before-forward -p icmp --icmp-type parameter-problem -j ACCEPT -A ufw-before-forward -p icmp --icmp-type echo-request -j ACCEPT (zumindest bei mir, aber Mint und Debian sind ja recht nah beieinander)
Diese rules (sofern vorhanden, wovon ich bei dir aber ausgehe) greifen vor sämtlichen manuell konfigurierten Einträgen.
Hier sollten übrigens auch schon die wichtigen "related / established"-Regeln drin stehen, die später für einen sauberen Rückweg von Paketen sorgen:
# quickly process packets for which we already have a connection -A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT  

Moin,
grundsätzlich erstmal: selber aktiv werden - schau den Leuten über die Schulter, frag Dinge, mach dir Notizen, geh ihnen (zumindest ein bisschen ) auf den Sack. Versuche Dinge zu verstehen und dann auch nachzumachen.
Meine Anfangszeit sah ungefähr so aus:
1   fragen / zeigen lassen + aufschreiben
2   verstehen
3   selber machen
4   "Huch kaputt" bzw. "hmm geht nicht"
5   1-3 wiederholen
Davon abgesehen: Weiterbildung - in Form von: erstmal Basis-Verständnis aufbauen - ist v.a. am Anfang ein wesentlicher Bestandteil des Ganzen. Irgendwo bzw. irgendwie muss man ja anfangen.
Ich kenne den aktuellen Lehrplan (neue Ausbildungsverordnung) nicht, aber ich würde ebenfalls vermuten, dass das Thema Netzwerk zeitlich erst später kommt (bei uns, alte Verordnung: 2. + 3. LJ).
Es KANN sinnvoll sein, sich da schon vorher mit zu beschäftigen, aber dann NICHT nach dem Motto "du hast noch keinen Plan von nix? Hier hast du nen Switch, beschäftige dich mal irgendwie damit." Das ist nicht zielführend.
Ich würde dann zumindest nachfragen, ob es vielleicht ein paar Stichworte gibt, mit denen man sich gezielt Wissen aneignen kann. Dann kommt man hoffentlich auch schnell zur Frage "Hm ok, auf welchem Stand bist du denn so?".
Und spätestens dann sollte klar sein, ob es sinnvoll ist, einen Switch zum Spielen hinzustellen, oder ob man nicht doch vorher noch ein wenig Netzwerk-Grundlagen benötigt.
TL;DR   Werde selber aktiv

Pfui bäh! Finger weg von der GUI!
Spätestens hier kommt der Punkt, an dem die dein Ausbilder erklären sollte, dass es zwar Switche geben mag die eine GUI mitliefern, das tun aber nicht alle. Und weil das schon zu einfach wäre gibt es bei unterschiedlichen Herstellern Switche mit und ohne GUI, und je nach Hersteller hat man in der GUI auch nicht alle Möglichkeiten die mal über CLI hätte. Im Regelfall ist die "Sprache" auf den Switchen des selben Herstellers gleich (zur Hölle mit dir, HPE Flexfabric). Somit kommt man da mit den Befehlen überall durch.
Und, auch wenn sich die Syntax der Befehle zwischen den Herstellern unterscheiden mag, über die CLI gibt es Mittel und /? Sachen zu finden.
Es mag auf den ersten Blick anstrengender sein, aber nach Möglichkeit immer einen großen Bogen um die GUI machen, die lügt und stinkt!

Eine SNM (Subnetzmaske) besteht aus 32 Bits.
Hiervon sind 30 "sinnvoll" nutzbar, wenn man noch ein Netz daraus bauen können möchte (dann hat man, beim kleinstmöglichen, 4 IP-Adressen, von denen jedoch 2 nicht vergeben werden können -> Netzbezeichnung + Broadcast, wie üblich).
8 von den Bits sind bereits belegt (die ersten 8): eine andere Bezeichnung für "255.0.0.0" wäre "/8" (die sog. CIDR-Schreibweise).
Von den max 30 sinnvoll belegbaren Bits sind also 8 abzuziehen -> es bleiben 22 Bits übrig, mit denen erweitert werden kann.
Jede Erweiterung verdoppelt die Anzahl an Subnetzen, also 2^22.

Nunja, immerhin warst du nicht zu ängstlich oder stolz, um dir Hilfe zu suchen. Kann man auch nicht von jedem Azubi behaupten, das ist doch ein guter Anfang. Alles Andere kommt schon noch mit der Zeit
PS: relevant xkcd

Teil das Ganze in einzelne Schritte auf.

Was du erstmal brauchst, sind die Commands:
- tar
- date
um das Backup zu erstellen.
Mein Tip wäre, "spiel" erstmal ein wenig mit dem tar Command rum, bevor du da möglicherweise mit wertvollen Produktiv-Dateien rumhantierst
Also, erschaff zB drei einfache Text-Dateien mit irgendnem Inhalt, die packst du dann in ein Archiv zusammen.
Dann wieder entpacken (Bonus: hier kannst du dich nebenbei schonmal mit dem Begriff der "tar bomb" auseinander setzen :D)
Als nächsten Schritt kannst du dann nochmal dasselbe machen, diesmal allerdings zusätzlich mit einer Komprimierung (Bonus: es gibt mehrere Möglichkeiten bzw. Algorithmen)
Dann wieder entpacken.
Und dann kommt "date" ins Spiel - was gibt es hier für Möglichkeiten, um einzelne Komponenten der Ausgabe rauszufiltern (Datum + Uhrzeit)?
Wie wäre die gepackte Datei am besten zu benennen, mit dem Datum im Namen?
Oh ja, und irgendwann dann in ein Script packen. Aber das wird eine Weile dauern.
 
Abschließend darf ich ebenfalls, wie meine Vorredner, sagen: Wenn du schon "einigermaßen" fit in Linux / Bash bist, dann ist das machbar.
Aber - nicht böse gemeint! - den Eindruck habe ich ehrlich gesagt nicht. Vierter Tag in der Ausblidung spricht ja auch für diese Vermutung (?)

Ich entschuldige mich für meine sehr verspätete Antwort an euch.
Eure Tipps haben mir weitergeholfen.
Ich habe mit meinen Vorgesetzten gesprochen. Wir haben uns meine Berichtshefte angeschaut und uns mit dem betrieblichen Ausbildungsplan näher befasst.
Es kam (zu meiner Überraschung) sehr positiv an, dass ich meine Wahrnehmung und Infragestellung der Tätigkeiten bis jetzt angesprochen habe. Wir haben insgesamt ein sehr konstruktives Gespräch geführt und nun werde ich auch Bereich kennenlernen, die tatsächlich beide Seiten des Fachinformatikers kombinieren.
Meine Vorgesetzten haben es tatsächlich sehr wertgeschätzt, dass ich einfach mal alles angesprochen habe, was mir auf dem Herz liegt (ohne weinerlich zu wirken^^)

Naja Cert ließt sich eher so mau. Die Cloud/DevOps sind hauptsächlich Linux. Da würde ich ein Cert von Microsoft nicht mit der Kneifzange anfassen - auch wenn die Prinzipen natürlich auch mit Windows anwendbar sind.
Schau dir das hier mal an https://roadmap.sh/devops Klar das ganze ist überwältigend, aber zeigt Ausschnitte aus dem möglichen Techstack. 
Ich selber arbeite als DevOps
Linux: Generell brauchst du Linux Grundlagen (systemd/services, logs, Berechtigungen, Filesystem, DNS/Netzwerk, Container, SSH, Paketmanager, die ganzen Standardbefehle, ...). Container basieren nativ auf Linux und gefühlt mehr als das halbe Internet läuft auf Linux. Windows mit UIs benutzt fast niemand. Linux mit Terminal ist der Weg
Container: Man sollte auf jeden Fall Docker drauf haben. Mal ein Dockerfile schreiben, Container starten/stoppen, sich auf einen Container verbinden, .... . Für einfache Container Orchestrierung würde ich Docker Swarm/Docker Compose/Nomad/AWS ECS nehmen. K8s ist natürlich beste Container Orchestrierungstool, aber absolut komplex und für viele Use-cases einfach viel zu viel. Am Ende ist K8s Admin fast ein eigener Job... Klar der Skill ist überall gefragt, aber das eignet man sich nicht in 3 Tagen an. K8s ohne Linuxgrundlagen ist auch ein Witz. K8s ist nix für den Anfang einer DevOps Reise.
Netzwerk: Du brauchst die Netzwerk Grundlagen. MACs, IPs (Subnetting !), Ports, VPN, Routing, NAT. 
DNS/SSL: DNS Grundlagen braucht man und man sollte auch in der Lage sein Zertifikate mit AWS ACM/Let's Encrypt oder anderen Sachen zu beziehen
Infrastruktur als Code. Du baust alle Infrastruktur als Code mit z.B. Terraform oder Pulumi.
Configuration as Code: Du konfiguriest alle VMs mit Ansible, Chef, Puppet, etc. Generell gilt das Prinzip "Cattle, not pets" für Server. Man muss jederzeit einen Server löschen können und innerhalb kurzer Zeit mittels Terraform und Ansible wieder automatisiert frisch bereit haben. 
Cloud: Man sollte sich entweder in AWS, GCE oder Azure auskennen. AWS ist am weitesten entwickelt und auch die größte Cloud. Allein AWS ist ein Monster für sich und hier muss natürlich nicht alles kennen. Ein paar Kernservices braucht man aber: VPC, EC2, SSM, RDS, DynamoDB, Lambda, S3, ALB, ECS/ EKS, ECR, CloudWatch, ...
CI/CD pipelines: Hier Automatisiert man das Deployment von Apps, automatisches Ausführen von Tests, etc. Da gibt es viele Tools wie Jenkins, Azure DevOps und so weiter.
Monitoring/Logging: Server und Apps erzeugen Logs. Die möchte man irgendwo sammeln und analysieren. Gerne auch Alarme für bestimmte Logs oder Metriken. Mögliche Techstacks: AWS CloudWatch oder ELK-Stack oder Grafana+Prometheus+Loki oder ...
Git: Der eigene Code wird natürlich in Git verwaltet
Scripten: Oft muss man gerade in Pipelines viele Teile verbinden. Hier kommen gerne Bash und Python zum Einsatz. In der Cloud kann man auch gut mit AWS Lambda + Python viele Sachen automatisieren. 
Man muss natürlich nicht alles von Anfang ankennen und arbeitet sich langsam rein. 

Burnout tritt wesentlich häufiger auf als du denkst.
Genau das! Danke. Ich hab so einen Fall in der Familie gehabt, jemand vom "alten Schlag" ihr wisst schon, wird nie krank, wenn doch wird trotzdem gearbeitet, überstunden usw. Aber es geht einem ja gut und von heute auf morgen geing es von 100 auf 0 wie in dem Artikel, wenn ein Erwachsener Mann mit über 50 der eigentlich immer "stark" ist und eher nicht über seine Gefühle spricht wie ein kleines Kind anfängt zu weinen und zusammenbricht, anfängt zu zittern und wie ein häufchen Elend vor einem Sitzt dann merkt man erst mal so richtig wie hart und heftig ein Burnout sein kann und wie schnell es geht. 
Traurig aber wahr, ich leide unter Chronischer Migräne, sie ist zwar in den letzten Jahren besser geworden (meist lieg alle 1-2 Monate mal nen Tag flach), trotzdem musste ich mir immer wieder mal anhören "Sind doch nur Kopfschmerzen" oder "Du bist schon öfter mal Krank das fällt auf und für manche wirkt das dann einfach als hättest du keine Lust zu arbeiten". Und es macht mich jedes mal sauer...

Ich kann nichts dafür das ich Migräne hab und such mir das nicht aus, ich wäre froh wenn ich keine mehr hätte und nicht jedesmal wenn ich eine Attacke habe das gefühl hab mein Kopf würde explodieren und das ich wenn die Attacke richtig kommt nunmal absolut flach liege, ich hab zwar Medikamente aber einen Tag lieg ich meisten trotzdem flach und schlaf halt den ganzen Tag im Dunklen Zimmer da super Licht und Lärmempfindlich. Das Problem Leute die keine Migräne haben (und das wünsche ich niemanden) verstehen nicht das Migräne nicht nur "etwas" Kopfschmerzen sind, sonder wirklich höllische Schmerzen, wenn sogar das Denken weh tut.

Das Gleiche Prinzip ist halt dann eben auch bei Depressionen etc. man sieht es nicht, man hat oder hatte es selbst nicht und damit ist es ja garnet so schlimm. Häufig sind aber auch gerade die älteren Kollegen da leider ziemlich verständnislos muss ich sagen weil die eben diese "alte Hase" Einstellung haben, das man doch immer mit 110 % arbeiten sollte, nie krank wird und bei ner Erkältung etc. geht man ja trotzdem arbeiten, selbst wenn man eigentlich krank im Bett liegen sollte. 
Wobei ich da sagen muss dann war der Burnout wohl noch nicht komplett ausgeprägt und er hat ihn frühzeitig bemerkt und die Bremse rechtzeitig eingelegt, wenn der Burnout richtig zuschlägt dann ist man im absoluten Großteil der Fälle nicht nach 4 Wochen wieder im Büro, sprech da durch mehrere Fälle in Familie und Freundeskreis aus Erfahrung, die meisten waren minimum ein halbes Jahr krankgeschrieben.
Auch das ist leider Traurig und wahr. Es wird einfach nicht ernst genommen, oft fehlt das Mitgefühl komplett und das sollte es eigentlich wenn schon alleine aus dem "Egoismus Gedanken" heraus nicht sein, denn "wenn der Kollege jetzt ein Halbes Jahr mit Burnout ausfällt dann muss ich die Arbeit von ihm machen" sollte den Leuten dann vielleicht in den Kopf kommen und zeigen, dummer Spruch und drüber lustig machen und damit den Stressfaktor noch erhöhen sind vielleicht nicht die beste Wahl weder für den Betroffenen noch für einen selbst.

Für Python ist der The Hitchhiker’s Guide to Python eine gute Anlaufstelle.

Da du die beiden explizit erwähnt hast:
- Falls du dich im Thema Netzwerk ein bisschen weiter umschauen willst (und englisch kein Problem ist), kann ich dies hier empfehlen:
"Networking for System Administrators"
-> https://www.amazon.de/Networking-Systems-Administrators-Mastery-Band/dp/1642350338
Persönliche Meinung: Seltene Mischung aus unterhaltsam + informativ, nix für blutige Anfänger, jedoch holt es einen schon noch an der Basis ab.
- Ansonsten noch spielerisch SQL entdecken: https://sql-island.informatik.uni-kl.de/
(weiß nicht, ob dir das ggf. ein wenig zu lasch ist ich fands lehrreich + unterhaltsam)

Vor Corona:
Grundsätzlich Präsenzpflicht im Büro, HomeOffice in Einzelfällen möglich nach Vorankündigung + angemessener Begründung (dazu zählte u.a.auch "hab die Handwerker im Haus", jedoch keine regelmäßigen Dinge wie "mittwochs kommt mein Kind immer früher aus der Schule, da muss ich da sein").
"während Corona" (bis 30.06.21):
Bis auf wenige Mitarbeiter (unentbehrlich vor Ort) war es anfangs der gesamten Belegschaft freigestellt, ins HomeOffice zu wechseln.
Später, als es verpflichtend wurde, ist dies umgehend durchgesetzt worden.
Es wurde klar kommuniziert, dass bei Notwendigkeit der Präsenz vor Ort (Um- / Einbauarbeiten, etc) dies zu erfolgen hat, dies war "ab und zu" nötig. So weit, so normal.
Ab 01.07.21
reset to default 😕 (siehe "vor Corona").
Anfragen über eine Anpassung (hin zu möglichen Regelmäßigkeiten, und sei es auch nur 1 Tag / Woche) sind quasi im Keim erstickt worden.
##########
pers. Fazit: Ich bin mittelschwer enttäuscht, dass einfach wieder der vorherige Zustand herrscht, ohne zumindest mal Resumé zu ziehen.
Die technischen Vorgaben fürs HomeOffice (VPN, Dienst-Lappys + -handys, zusätzliche Monitore) waren bereits vorher vorhanden und funktionieren super  -> keine Probleme
Organisatorisch wurde sich auch ziemlich schnell drauf eingeschossen: tgl. kurzes (!) Jitsi-Meeting mit allen Mitarbeitern, ständige tel. Erreichbarkeit durch Diensthandys, Transparenz der durchgeführten Tätigkeiten durch Tagesprotokolle an Vorgesetzte -> nur kleine / wenige Probleme
Tatsächlich sehe ich persönlich sowohl Vor- als auch Nachteile, sodass für mich eine Mischform optimal wäre (zB 1-2 Tage / Woche). So könnte ich den (von mir durchaus gewünschten) persönlichen Kontakt zu Kollegen pflegen, aber eben auch die Annehmlichkeiten wie den teilweisen Wegfall des Arbeitsweges genießen.
Aber anscheinend ist dies nicht gewünscht, zumindest wird es nicht von oben kommuniziert, Anfragen in diese Richtung werden abgeschmettert.
Neu = gefährlich, anscheinend.. Aktuell mit ein Grund für mich (neben ein, zwei anderen), sich mal nach etwas Neuem umzusehen.

Mir wurde im Voraus (u.a. hier im Forum) gesagt, dass sich die Fragen des PA ca. zu jew. 1/3 aus folgenden Bereichen zusammensetzen:
- spezifische Fragen zum Projekt (genauere Erläuterungen von ggf. vorhandenen Unklarheiten + Abklopfen des tatsächlich vorhandenen Verständnisses, also ob man wirklich weiß, was man da überhaupt gemacht hatte)
- allgemeine Fragen aus dem "groben" Bereich des Projekts (zB Alternativen zur Vorgehensweise)
- allgemeine Fragen (bunt gemixt)
Tatsächlich ist das auch genau so eingetreten. Da die ersten beiden Punkte projektbezogen waren, interessiert dich vermutlich v.a. Punkt 3. Darum ging es bei mir:
- Wie "funktioniert" Email? (Nicht total im Detail; es genügte zu sagen, dass eine Email eben nicht nur von Sender zu Empfänger wandert, sondern dass div. Zwischenstationen durchlaufen werden; Stichworte MUA, MTA, Mail Header mit "Received" Zeilen der einzelnen Stationen, etc)
In diesem Zusammenhang auch: Wofür steht MX record?
- Daraus folgend, Thema DNS: Welche Arten von records gibt es, was ist ein reverse DNS Eintrag, und warum ist er beim Versand von Emails besonders wichtig?

Mir wurde im Voraus (u.a. hier im Forum) gesagt, dass sich die Fragen des PA ca. zu jew. 1/3 aus folgenden Bereichen zusammensetzen:
- spezifische Fragen zum Projekt (genauere Erläuterungen von ggf. vorhandenen Unklarheiten + Abklopfen des tatsächlich vorhandenen Verständnisses, also ob man wirklich weiß, was man da überhaupt gemacht hatte)
- allgemeine Fragen aus dem "groben" Bereich des Projekts (zB Alternativen zur Vorgehensweise)
- allgemeine Fragen (bunt gemixt)
Tatsächlich ist das auch genau so eingetreten. Da die ersten beiden Punkte projektbezogen waren, interessiert dich vermutlich v.a. Punkt 3. Darum ging es bei mir:
- Wie "funktioniert" Email? (Nicht total im Detail; es genügte zu sagen, dass eine Email eben nicht nur von Sender zu Empfänger wandert, sondern dass div. Zwischenstationen durchlaufen werden; Stichworte MUA, MTA, Mail Header mit "Received" Zeilen der einzelnen Stationen, etc)
In diesem Zusammenhang auch: Wofür steht MX record?
- Daraus folgend, Thema DNS: Welche Arten von records gibt es, was ist ein reverse DNS Eintrag, und warum ist er beim Versand von Emails besonders wichtig?

Mir wurde im Voraus (u.a. hier im Forum) gesagt, dass sich die Fragen des PA ca. zu jew. 1/3 aus folgenden Bereichen zusammensetzen:
- spezifische Fragen zum Projekt (genauere Erläuterungen von ggf. vorhandenen Unklarheiten + Abklopfen des tatsächlich vorhandenen Verständnisses, also ob man wirklich weiß, was man da überhaupt gemacht hatte)
- allgemeine Fragen aus dem "groben" Bereich des Projekts (zB Alternativen zur Vorgehensweise)
- allgemeine Fragen (bunt gemixt)
Tatsächlich ist das auch genau so eingetreten. Da die ersten beiden Punkte projektbezogen waren, interessiert dich vermutlich v.a. Punkt 3. Darum ging es bei mir:
- Wie "funktioniert" Email? (Nicht total im Detail; es genügte zu sagen, dass eine Email eben nicht nur von Sender zu Empfänger wandert, sondern dass div. Zwischenstationen durchlaufen werden; Stichworte MUA, MTA, Mail Header mit "Received" Zeilen der einzelnen Stationen, etc)
In diesem Zusammenhang auch: Wofür steht MX record?
- Daraus folgend, Thema DNS: Welche Arten von records gibt es, was ist ein reverse DNS Eintrag, und warum ist er beim Versand von Emails besonders wichtig?

Ahoi Community, 
der alte Notenrechner dreht, inzwischen in seinem 22. Jahr, seine letzten Runden. Demnächst kommen die ersten Prüfungen nach der Reform der IT-Berufe. Die damit verbundene neue Prüfungsordnung ist nicht gerade einfacher geworden und macht in jedem Fall eine Überarbeitung des Notenrechners erforderlich. Ich stricke derzeit an einer neuen Fassung, Vorabversion hier: 
  http://caesborn.de/pruefungspage/notenrechner_reformiert.html
Wer Anregungen hat oder Fehler findet (es würde mich wundern, wenn er schon perfekt wäre), bitte gern und ausführlich hier melden. 
VG, Uli

Klar, das sind alles sozial gestörte Nerds mit nem BMI >40, die sich neben der Auswahl des zu verzehrenden Fast Foods kaum entscheiden können, welchen User sie denn heute BOFH-style verarschen.
Wahlweise auch das blasse Strichmännchen, welches im zarten Alter von 50 bei Mutti wohnt, noch nie das schöne Geschlecht gedatet, geschweige denn überhaupt angesprochen hat und nie, NIEMALS in die Sonne darf, denn dann erblindet oder gar verbrennt es augenblicklich. Aka. das Ding aus dem Keller.
Im Ernst: "alle" ist natürlich viel zu pauschalisiert. Meiner persönlichen Erfahrung nach kommen die Klischees zwar nicht völlig von ungefähr, es gibt immer vereinzelte Leute, die das bestätigen.
Aber im Überdurchschnitt kann man wohl durchaus von "normalen Menschen" sprechen

Klar, das sind alles sozial gestörte Nerds mit nem BMI >40, die sich neben der Auswahl des zu verzehrenden Fast Foods kaum entscheiden können, welchen User sie denn heute BOFH-style verarschen.
Wahlweise auch das blasse Strichmännchen, welches im zarten Alter von 50 bei Mutti wohnt, noch nie das schöne Geschlecht gedatet, geschweige denn überhaupt angesprochen hat und nie, NIEMALS in die Sonne darf, denn dann erblindet oder gar verbrennt es augenblicklich. Aka. das Ding aus dem Keller.
Im Ernst: "alle" ist natürlich viel zu pauschalisiert. Meiner persönlichen Erfahrung nach kommen die Klischees zwar nicht völlig von ungefähr, es gibt immer vereinzelte Leute, die das bestätigen.
Aber im Überdurchschnitt kann man wohl durchaus von "normalen Menschen" sprechen

Klar, das sind alles sozial gestörte Nerds mit nem BMI >40, die sich neben der Auswahl des zu verzehrenden Fast Foods kaum entscheiden können, welchen User sie denn heute BOFH-style verarschen.
Wahlweise auch das blasse Strichmännchen, welches im zarten Alter von 50 bei Mutti wohnt, noch nie das schöne Geschlecht gedatet, geschweige denn überhaupt angesprochen hat und nie, NIEMALS in die Sonne darf, denn dann erblindet oder gar verbrennt es augenblicklich. Aka. das Ding aus dem Keller.
Im Ernst: "alle" ist natürlich viel zu pauschalisiert. Meiner persönlichen Erfahrung nach kommen die Klischees zwar nicht völlig von ungefähr, es gibt immer vereinzelte Leute, die das bestätigen.
Aber im Überdurchschnitt kann man wohl durchaus von "normalen Menschen" sprechen

In aller Kürze und rein individuell:
- Theorie / lernen / vorbereiten
- (Versuch der) Anwendung
- Bestenfalls: Irgendwas vergessen / nicht vollständig durchgeführt
- Schlimmstenfalls: Voll auf die Fresse fliegen (von "funktioniert nicht, und ich weiß nicht, warum" bis hin zu "huch kaputt")
- Leute fragen und nerven (wichtig!)
- mehr / besser verstehen
- neu machen
- irgendwann klappt's
- von vorne
Für mich war (und ist) es völlig normal, dass es gute und schlechte Tage gibt. Ich versuche, die schlechten zumindest als lehrreich mitzunehmen ("den Fehler mache ich sicherlich kein zweites Mal"), und die guten zu genießen.
Tatsächlich verschiebt sich natürlich auch die Empfindung dessen, was man selbst als Routine empfindet:
Was ich teilweise heute im Schlaf beherrsche und in 10 Minuten durchziehen kann, dafür habe ich vor.. was weiß ich, 2 Jahren, noch 4h gebraucht. Und schön war es danach trotzdem nicht
Aber es war damals halt einfach noch neu für mich, und ich hatte keine Ahnung von den ganzen "Nebenkriegsschauplätzen", die damit einhergehen. Das kommt mit der Zeit und Erfahrung.
Nichtsdestotrotz begegnen mir immer wieder völlig neue Dinge, und ich muss immer wieder mal quasi bei Null anfangen (naja, zumindest teilweise). Ich habe hier zwei Faktoren für mich herausgefiltert, die mir sehr wichtig erscheinen:
- Keine Angst vor Fehlern
- Keine Angst vor Fragen
Das ist im Zweifelsfall sicher auch abhängig von der jew. Unternehmenskultur und den entspr. Leuten vor Ort, aber so sollte es idealerweise sein.

Sei und bleib neugierig, lernwillig und engagiert, dann sollte sehr Vieles machbar sein. Und wenn du dein Schiff auch mal durch einen Sturm steuern musst: Irgendwo dahinter scheint auch wieder die Sonne.

In aller Kürze und rein individuell:
- Theorie / lernen / vorbereiten
- (Versuch der) Anwendung
- Bestenfalls: Irgendwas vergessen / nicht vollständig durchgeführt
- Schlimmstenfalls: Voll auf die Fresse fliegen (von "funktioniert nicht, und ich weiß nicht, warum" bis hin zu "huch kaputt")
- Leute fragen und nerven (wichtig!)
- mehr / besser verstehen
- neu machen
- irgendwann klappt's
- von vorne
Für mich war (und ist) es völlig normal, dass es gute und schlechte Tage gibt. Ich versuche, die schlechten zumindest als lehrreich mitzunehmen ("den Fehler mache ich sicherlich kein zweites Mal"), und die guten zu genießen.
Tatsächlich verschiebt sich natürlich auch die Empfindung dessen, was man selbst als Routine empfindet:
Was ich teilweise heute im Schlaf beherrsche und in 10 Minuten durchziehen kann, dafür habe ich vor.. was weiß ich, 2 Jahren, noch 4h gebraucht. Und schön war es danach trotzdem nicht
Aber es war damals halt einfach noch neu für mich, und ich hatte keine Ahnung von den ganzen "Nebenkriegsschauplätzen", die damit einhergehen. Das kommt mit der Zeit und Erfahrung.
Nichtsdestotrotz begegnen mir immer wieder völlig neue Dinge, und ich muss immer wieder mal quasi bei Null anfangen (naja, zumindest teilweise). Ich habe hier zwei Faktoren für mich herausgefiltert, die mir sehr wichtig erscheinen:
- Keine Angst vor Fehlern
- Keine Angst vor Fragen
Das ist im Zweifelsfall sicher auch abhängig von der jew. Unternehmenskultur und den entspr. Leuten vor Ort, aber so sollte es idealerweise sein.

Sei und bleib neugierig, lernwillig und engagiert, dann sollte sehr Vieles machbar sein. Und wenn du dein Schiff auch mal durch einen Sturm steuern musst: Irgendwo dahinter scheint auch wieder die Sonne.

Kannst ja mal die "üblichen Verdächtigen" durchsuchen, wo Aliase normalerweise drinstehen, zB:
grep -r "alias ls" ~/.bash* ~/.profile /etc/profile.d/ /etc/profile /etc/bash.bashrc Tatsächlich sollte exakt dein Output, nämlich
ein default Eintrag in deiner /home/$USER/.bashrc sein, wenn sie unmodifiziert ist.
Und die wird später eingelesen als die /etc/bash.bashrc, somit wird dein Alias überschrieben Siehe auch:
https://askubuntu.com/questions/815066/whats-the-difference-between-bashrc-and-etc-bash-bashrc

Ich kenne jetzt nicht die einzelnen Inhalte vom Sommer 2020, aber insgesamt würde ich das als "statistischen Ausrutscher" betrachten
Du tust eigentlich schon genau das, was hier dazu empfohlen wird:
- alte Prüfungen durchgehen
- eigene Schwachstellen erkennen + gezielt dran arbeiten
Ich würde zusätzlich empfehlen, vielleicht nochmal in die Lehrpläne / BBS-Inhalte reinzuschauen, ob noch irgendetwas "total Neues" dazu kam, was bisher in den vorherigen Prüfungen nicht standard Thema war.
Ansonsten, noch als Tips für die Prüfung selbst:
- suche dir möglichst früh aus, welchen Schritt du streichen möchtest
- bearbeite zuerst die Aufgaben, die du sicher kannst, lass die dicken Brocken eher für den Schluss übrig
Viel Erfolg!

Hier werden tatsächlich die letzten 5 Jahre empfohlen.
-> Hat den Hintergrund, dass es reicht, um einen guten Überblick der Themen zu haben und sich an die Art der Fragestellung zu gewöhnen.
Andererseits ist Manches thematisch auch derartig "im Fluss", dass es irgendwann veraltet ist bzw. nicht mehr dran kommt, sodass 10 Jahre schon fast zu viel sein könnten. Aber schlimmstenfalls hat man halt zu viel gelernt, wirklich "schaden" kann es nicht
Ich persönlich würde tatsächlich ziemlich ähnlich vorgehen wie Du: Kurz vorher nur noch lernen, was wirklich Bock macht, und nicht mehr auf Biegen und Brechen reinprügeln. Ganz ehrlich, nach deiner Beschreibung tust du wesentlich mehr als der Durchschnitt, und a) ist ein wenig Unsicherheit völlig normal (war bei mir auch der Fall), und b) ist das IMMER besser als die Sorte, die dann nachher sagt "joah hab nur ne 4, aber ich hab ja auch nicht gelernt".
Trink am Abend vorher ein (!) Bier, leg dich zeitig schlafen, dann passt das schon