Han_Trio

Mails werden in aller Regel nicht einfach nur von A nach B transportiert, da liegen meist div. Stationen "dazwischen". Wie @Chief Wiggum schon schrieb, der Mail-Header auf Empfänger-Seite sollte diese Stationen alle beinhalten, auch mit den entspr. Zeitstempeln. Auch steht dort ggf. die Zeitzone mit drin, in der der Server arbeitet - evtl. lässt sich so der (vermeintliche) Zeitunterschied erklären, v.a. wenn es exakt zwei Stunden sind (?) In Deutschland befinden wir uns zB gerade in GMT+1 bzw UTC+1.

Win + L (Bildschirmsperre) Ich denke, das Hauptproblem ist, dass hier - wie meiner Erfahrung nach v.a. im medizinischen Bereich üblich - einfach kein Bewusstsein dafür herrscht, was alles "passieren könnte". Die Leute in Arztpraxen sind idR. eher IT-Laien, sprich sie sind ggf. recht fit in der Bedienung ihrer alltäglichen Programme / Software, aber das war's dann auch. Dinge wie Passwort-Richtlinien, oder auch IT-Sicherheit im Allgemeinen, sieht man dort eher selten. (Und das ist gar nicht böse gemeint, die haben tatsächlich meist schon genug damit zu tun, den Praxis-Alltag zu organisieren.) Vermutlich könnte man hier mit einer Basis-IT-Sicherheitsschulung schon recht viel erreichen. Halt so Dinge wie Bildschirm sperren, keine Passwörter auf Post-Its unter die Tastatur (oder gleich an den Bildschirm ) kleben, keine Links in "komischen" Emails anklicken, etc. Oder zielte deine Frage speziell auf FIDO ab?

Hallo Dreisatz, Äquivalenzumformungen (also Umstellung von Gleichungen), Umrechnen von Binär-, Dezimal- und Hexadezimalwerten (v.a. wichtig im Bereich Netzwerk). Das wären so die "Highlights", die mir einfallen - viel komplizierter wird es aber nicht

Hast du es mal mit einem repo, speziell für diese Version, versucht? Siehe zB: https://computingforgeeks.com/how-to-install-mariadb-11-on-ubuntu/ Kernstück wäre dann: curl -LsS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version=11.0

Mal ein Update zum Anfang des Jahres + nun bestandener Probezeit Alter 39 42 Wohnort Niedersachsen letzter Ausbildungsabschluss (als was und wann) FISI Sommer 2019 Berufserfahrung keine in diesem Bereich 4 Jahre Vorbildung Abitur, abgebrochenes Studium, ca. 4 Jahre vorher in derselben Firma 1st-Level-Support Arbeitsort Niedersachsen (bzw. 100% remote / "home based") Grösse der Firma KMU, ca. 20 MA knapp 400 Tarif nein Branche der Firma Cloud Provider Arbeitsstunden pro Woche laut Vertrag 40 Arbeitsstunden pro Woche real 24-56 (variabel, da Schichtarbeit, im Schnitt jedoch 40) + Bereitschaft Gesamtjahresbrutto 32.400 € 40.000 € + Schichtzuschläge Anzahl der Monatsgehälter 12 Anzahl der Urlaubstage 28 30 + 4 Sonder- / Sozialleistungen 100% Homeoffice, MA-cloud, business udemy + bezahlte Weiterbildungen Variabler Anteil am Gehalt Überstunden durch Bereitschaften; Abbau möglich und erwünscht Schichtzuschläge Verantwortung weder personell noch Budgets Tätigkeiten (Aufgaben/Aufgabenbereich) Linux-Systemadministrator / 2nd Level support; Planung, Einrichtung, Überwachung und Pflege von diversen Systemen: Web- / DB- / Mailserver, Loadbalancing, Backups, Patches, Automatisierung, etc.. AWS, Kubernetes, VMWare, Openstack, Ansible Insgesamt lässt sich festhalten: Sowohl der techstack als auch der organisatorische Gesamtaufwand hat sich für mich sprunghaft immens vergrößert, dafür aber auch das Gehalt + die Lernkurve. Mehr geht immer, aber für den Moment bin ich recht zufrieden

Ansonsten ist es bestimmt auch hilfreich, sich über sog Positionsparameter zu informieren zB: https://bash.cyberciti.biz/guide/$1 $0 is the name of the script itself (script.sh) $1 is the first argument $2 is the second argument $9 is the ninth argument ${10} is the tenth argument and must be enclosed in brackets after $9. ${11} is the eleventh argument. -> Wenn du das in die entspr. "$"-Ausdrücke (Variablen) innerhalb des Skriptes einsetzt, sollte sich auch erschließen, was da genau passiert.

Ansible / Terraform sollte (nach einer ordentlichen Evaluation, die einen Teil des Abschlussprojekts darstellt) lediglich das Mittel sein, mit dem du ein bestimmtes Problem löst. Die Reihenfolge ist nicht "Ich mag Ansible, also würde ich gern irgendwas damit machen und schaue mal, was ich so finde", sondern: - Es gibt ein Problem / eine Aufgabe -> bereits an dieser Stelle (mit IST- + SOLL-Zustand, etc.) kommt der Projektantrag zustande - "Wie könnte man das lösen?" (mit welchen verschiedenen Mitteln / Herangehensweisen -> Evaluation) -> hier kommt man "möglicherweise" auf Ansible - Implementierung / Durchführung Oder anders gesagt: Du hast evtl. bereits die Lösung, dir fehlt aber noch das konkrete Problem

Erste Frage bei solchen Dingen: Was sagt denn das Log? also von nginx, in dem Fall. Ist es überhaupt aktiviert? -> sollte auch in der config mit drin stehen und üblicherweise nach /var/log/ bzw. /var/log/nginx/ zeigen. Und dann ggf. noch unterteilt in access.log + error.log

traceroute "in schön" (unter Linux): sudo mtr -w -c 10 $URL >> report_wide.$URL -> wide format (vollständige Namen der Stationen), 10x am Stück pro Ausführung, inkl durschnittlichem package loss (für jede einzelne Station), Output wird immer hinten dran gehängt im file. Geht natürlich auch mit IPs, und der timestamp ist bei jeder Messung auch gleich dabei Und dann zB minütlich per cronjob ausführen, eben zu den kritischen Stoßzeiten.

Die Frage zielt (auch) in die Richtung ab, ob du dir überhaupt schonmal Gedanken darüber gemacht hast, bzw. ob du Interesse zeigst -> das tust du ja allein schon, indem du dich zB in diesem Forum genau danach erkundigst Es spricht (meiner persönlichen Ansicht nach) nichts dagegen, die Frage zB erstmal so zu beantworten: "Das weiß ich noch nicht ganz genau, denn ich bin ja noch in der Ausbildung / gerade aus der Ausbildung raus." Dann kannst du aber auch Folgendes gleich noch hinterher schieben: "Ich habe schon von A, B sowie C gehört und konnte in X und Y ein wenig reinschnuppern. Ich bin da drin sicher (noch) kein Profi, bin aber sehr gern bereit, da Zeit + Mühe zu investieren, sofern mir diese Möglichkeit gegeben wird."

Du hast also mehrere Accounts derselben Mail-Domain, aber nur einer der Accounts soll nicht mehr senden können (?) Tauchen in dem o.a. Punkt "Outgoing Server (SMTP)" diese Accounts dann auch separat auf (mit entspr. unterschiedlichem Login), oder gibt es nur einen Eintrag für die gesamte Domain? Falls Ersteres (mehrere Einträge): Man könnte vielleicht einfach einen absichtlich falschen / fehlerhaften Eintrag nur für den einzelnen Account setzen, dann gibts zwar ggf Fehlermeldungen, aber zumindest würde nicht mehr gesendet.

Stichwort "best hacker practice" Hier ist es zB ganz gut (wenn auch nicht allzu tief) beschrieben: https://www.cisco.com/c/de_de/support/docs/smb/routers/cisco-rv-series-small-business-routers/1778-tz-VLAN-Best-Practices-and-Security-Tips-for-Cisco-Business-Routers.html#best-practice-2---default-vlan-1-and-unused-ports bzw. https://www.cisco.com/c/de_de/support/docs/smb/routers/cisco-rv-series-small-business-routers/1778-tz-VLAN-Best-Practices-and-Security-Tips-for-Cisco-Business-Routers.html#frequently-asked-questions-1 "Ein bewährtes Sicherheitsverfahren besteht darin, den Management- und Benutzerdatenverkehr zu trennen. Daher wird empfohlen, VLAN 1 beim Konfigurieren von VLANs nur für Managementzwecke zu verwenden." "Warum wird VLAN 1 als Standard-VLAN nicht für die virtuelle Segmentierung des Netzwerks empfohlen? Der Hauptgrund dafür ist, dass Hacker wissen, dass VLAN 1 der Standard ist und häufig verwendet wird. Sie können sich damit per „VLAN-Hopping“ Zugriff auf andere VLANs verschaffen. Wie der Name schon sagt, können Hacker gefälschten Datenverkehr senden, der sich als VLAN 1 ausgibt, was den Zugriff auf Trunk-Ports und damit andere VLANs ermöglicht." Sonst auch hier noch ein wenig mehr: https://networkengineering.stackexchange.com/questions/32737/why-should-the-native-vlan-never-be-used/32740 "The advice is always to not use VLAN 1, so if an attacker or unwanted client connects and ends up on VLAN 1 and there is nothing configured on this VLAN, such as a useable gateway, they are pretty much stuck and can't go anywhere"

Schau mal hier rein: /home/$USER/.steam/debian-installation/logs/bootstrap_log.txt Da stehen bei mir (nutze auch Linux Mint) zumindest immer die startup + shutdown Meldungen von Steam drin, evtl. sind da auch Fehlermeldungen zu sehen bei dir. Ansonsten ggf auch noch in anderen (Log)dateien in dem Verzeichnis. Oder aber, wenn das alles zu nichts führt, Steam de- und nochmal reinstallieren. Interessehalber, was war das für ein Spiel, bzw. hat es einen nativen Linux-Client? Falls nicht: Steam hat mit Proton zwar eine mittlerweile ziemlich gute Kompatibilität geschaffen, aber v.a. neuere TripleA-Titel machen da gern mal Probleme. Im Zweifelsfall mal hier den Titel prüfen: https://www.protondb.com/

Steht doch da recht eindeutig schon in der entspr. location. Also, entweder gibt es diese DB / Tabelle gar nicht (könnte ggf ein Schreibfehler sein?). Oder aber, der filepath ist falsch.

Ganz genau Router 1 muss hier etwas zu 10.0.0.0/22 (zurück)schicken, hat dafür aber keinen Eintrag. Er nimmt also seine default route (0.0.0.0) als standard Eintrag für etwas, von dem er nicht weiß, wohin damit. Diese default route führt ihn nach 210.20.20.5 als next hop - das wäre aber zurück Richtung Internet.