Han_Trio

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 (?)

Da war doch letztens schon was: In dem Beitrag steckt ne Menge drin, u.a. das hier: https://roadmap.sh/devops

Das ganze Thema Email wird scheiße komplex, je tiefer man reintaucht.. da spielen viele verschiedene Dinge eine Rolle, die miteinander verwoben sind. Also von der rein technischen Seite her. Für den Anfang ist es für ein grundsätzliches Verständnis hilfreich, wenn du dir bewusst bist: "Mails wandern nicht einfach nur von A nach B, da ist noch jede Menge zwischen". Damit weißt du schonmal mehr als gefühlte 98% der User Also was du hier rausziehen kannst, ist vielleicht erstmal der grobe Ablauf: - Anmeldung / Authentifizierung (SASL) - Absenden (SMTP) - Wegfindung (DNS) - Eingangskontrolle (reverse DNS) Und zum tieferen Verständnis kannst du dann ggf. an den einzelnen Punkten weiter ansetzen.

Moin, SMTP: https://datatracker.ietf.org/doc/html/rfc5321 SASL: https://datatracker.ietf.org/doc/html/rfc4954 Ohne allzu sehr in die Tiefe zu gehen: DNS und die Mail-Authentifizierung (SASL = Simple Authentication and Security Layer) sind zwei verschiedene Dinge SMTP ist das Protokoll, mit dem Mails versendet werden, und SASL ist eine Erweiterung davon. Das DNS gibt grundsätzlich das Ziel / die Route vor, wie du bereits richtig erkannt hast (und speziell bei Emails ist das sog. reverse DNS sehr wichtig, um den Sender zu verifizieren, siehe unten). Der erste Schritt: Die Authentifizierung (die beim Sender stattfindet), also das SASL, ist eine Authentifizierung des Users (!), also die credentials vom Postfach. Sobald diese Anmeldung / Authentifizierung passiert ist, kann die Mail verfasst und abgeschickt werden (streng genommen: verfassen kannst du die Mail auch schon vorher, nur der Versende-Vorgang erfordert eine Authentifizierung). Auf dem weiteren Weg, und auch beim Empfänger, spielt SASL keine Rolle mehr. Nun wird das DNS verwendet (Stichwort: MX record der Empfänger-MailDomain), damit die Mail den Weg zum Ziel finden kann. Beim Empfänger wird dann noch einmal geprüft, ob die Mail von einem Server aus verschickt wurde, der das auch darf - hier kommt das reverse DNS zum Einsatz: Die Mail kommt von einer bestimmten IP herein, und mittels reverse DNS wird geprüft, ob diese IP zur Absender-MailDomain passt. Das ist nicht zwingend notwendig, gehört aber SEHR verbreitet zum "guten Ton" beim Mailversand. Ich bin nicht ganz sicher, ob ich deine Frage richtig verstehe: das können sie - so gesehen - nicht der Prozess wird für jede Mail neu durchlaufen.

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)

Versuch mal diese beiden: sudo acpi -i sudo inxi -B Da sollte jew. der aktuelle Ladestand, aber auch die max. (verbleibende) Kapazität bei rauspurzeln. Bei mir zB so: sudo acpi -i Battery 0: Discharging, 66%, 01:40:06 remaining Battery 0: design capacity 7100 mAh, last full capacity 6830 mAh = 96% sudo inxi -B Battery: ID-1: BAT1 charge: 50.5 Wh condition: 75.8/78.8 Wh (96%) -> Mit 96% ist mein Akku noch recht tauglich - falls bei dir deutlich weniger bei rauskommen sollte, ist der nicht mehr ganz so fit € ok, dürfte wohl das gleiche sein wie bei dem von dir geposteten Bild, aber evtl kommt ja noch was nützliches an Info bei rum

Na die ersten 2 Zeilen sind ja komplett vorgegeben jeweils, mit den Erläuterungen unten, und sind für beide Pakete gleich. zB siehst du, dass ein "Hardwareadresstyp" 2 Byte lang ist, und sogar die Werte sind bereits genannt (0001hex - bei Verwendung von Ethernet, was hier der Fall ist). Das überträgst du auf die Tabelle, Zeile 1 / Byte 1 wäre also "00", Zeile 1 / Byte 2 wäre "01". -> 8 Bit = 1 Byte bzw. 2 Byte = 16 Bit. Die beiden Tabellen zeigen das Gleiche, der Unterschied ist nur, dass die obere Tabelle die Spalten in Bytes anzeigt, und die untere in Bits. Oder anders gesagt: 1 Hex-Zahlenpärchen entspricht 8 Bits / einem Byte. Etwas anspruchsvoller wird es ab Zeile 3, wobei die MAC-Adressen ebenfalls schon im Hex-Format oben vorliegen, und du sie auch einfach nur dorthin übertragen musst. IP-Adressen sind hier die Herausforderung: Sie müssen ins Hex-Format "übersetzt" werden.

Sagen wir mal so..: Wenn ein Mitarbeiter sich offiziell "auf Arbeit" befindet (also anwesend im HomeOffice, quasi eingestempelt), dann angerufen wird und es sich herausstellt, dass er gerade irgendwo SEHR betriebsfern unterwegs ist.. dann kann ich sogar nachvollziehen, dass anschließend diese Art von Nachweis verlangt wird. Das war nicht ganz von Anfang an so, aber nach dem Vorfall eben obligatorisch. Ich persönlich hätte dann zwar speziell diesen einen Mitarbeiter mal etwas genauer unter die Lupe genommen und nicht gleich alle, aber.. nunja, bin ja kein Manager ¯\_(ツ)_/¯ Stimmt teilweise. Es ist - falls vorhanden - eine Ticket-Referenz anzugeben, und wenn man sich die Mühe macht, ist es schon +/- nachvollziehbar. Nein, zum Glück nicht. Wäre das der Fall, wäre ich längst weg. Aber wie gesagt, aktuell strecke ich nichtsdestotrotz die Fühler nach was Anderem aus. Irgendwann is halt auch mal Schluss.

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?

@stefan.macke hat eine umfangreiche Sammlung zu diesem - und noch anderen - Themen zusammengetragen: https://it-berufe-podcast.de/vorbereitung-auf-die-ihk-abschlusspruefung-der-it-berufe/ (etwas weiter unten, Stichpunkt "Projektpräsentation") bzw speziell: https://it-berufe-podcast.de/inhalte-der-projektdokumentation/ https://it-berufe-podcast.de/inhalte-der-projektpraesentation-anwendungsentwickler-podcast-11/ Ich zitiere man ganz unverhohlen: Es geht also um "die Highlights" deines Projektes, nicht um jedes Detail. "Verkaufsgespräch" umschreibt das Ganze schon recht gut.

Hier ist zB eine entspr. Statistik: https://www.fachinformatiker.de/azubigehalt/ Allerdings ist das, wie von @maximemelian auch bereits angesprochen, nicht auf eine bestimmte Region beschränkt. Und natürlich hat auch nicht jeder FiSi an dieser Umfrage teilgenommen.. Statistisch gesehen ist es danach unterdurchschnittlich, ja, vor allem am Anfang. Allerdings ist das erfahrungegemäß für kleine(re) Betriebe auch eher üblich. Jedoch ein Firmenwagen wiederum ist eher unüblich für Azubis Wenn es nicht reicht, kannst du dich sonst noch über Hilfen in Form von Wohngeld und / oder BAB (BerufsAusbildungsBeihilfe) schlau machen.

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

Ein Alias ist eine Art zusätzlicher Name für das selbe Postfach - Mails, die an die verschiedenen Alias-Einträge gesendet werden, landen somit im selben Postfach. Diese Aliase gehören normalerweise zur selben Mail-Domain. Eine Weiterleitung hat üblicherweise kein eigenes Postfach, sondern leitet eben nur weiter - an verschiedene "normale" Postfächer, die völlig unabhängig von der ursprünglichen Mail-Domain sein können. Hier ganz gut zusammengefasst: https://community.keyhelp.de/viewtopic.php?t=8041

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.

Wenn man allen Usern etwas "aufzwingen" möchte, also nicht nur in den systemweiten Konfigs, sondern tatsächlich (per default) auf User-Level, dann könnte man hier mal reinschauen: /etc/skel/.bashrc /etc/skel/ ist das "Grundgerüst" für ein /home/$USER Verzeichnis, und wenn man da etwas ändert, sollte es in diesem (neuen) Zustand für alle neu angelegten User übernommen werden.

Das grep command heißt erstmal nur, dass es in irgendeiner Datei drin steht. Nicht zwangsläufig, dass die Inhalte auch angewendet werden. Hast du die Shell anschließend frisch aufgemacht? Erst dann werden die Inhalte beim Start mit geladen. Alternativ, im laufenden Betrieb: source /home/$USER/.bashrc

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

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

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!

Ich kann mich hier den Vorrednern anschließen: Dein Vorgehen ist bereits so ziemlich "best practice", also das, was man hier gemeinhin im Forum auch empfiehlt: nämlich die ~ letzten 5 Jahre an Prüfungen durchzugehen + dann an evtl. noch vorhandenen Defiziten zu arbeiten. Es vereint mehrere Vorteile: - du gewöhnst dich an die Art der Fragestellungen, musst also nicht wertvolle Zeit opfern, um in der Prüfung überhaupt erstmal zu verstehen, um was es eigentlich geht - du verschaffst dir einen breit aufgestellten Überblick in den potentiellen Themengebieten - du kannst gezielt an deinen Schwachstellen arbeiten Vielleicht noch ein paar generelle Tips (dann für die tatsächliche Prüfung): - Mach zuerst das, was du sicher kannst. Soll heißen, lasse die Fragen, bei denen du absehbar mehr Zeit brauchst, vorerst aus und bearbeite sie später. Du hast einfach mehr Ruhe, wenn du dann nachher im Hinterkopf hast "Ja cool, ich hab ja bereits das andere Kleinzeugs gemacht, da kann ich mir hier jetzt angemessen Zeit für nehmen". - Entscheide möglichst früh, welchen Handlungsschritt du auslassen willst. Das war für mich auch so eine Kopfsache: Gleich am Anfang gesagt "Nö, das hier mache ich nicht." Ich hab die gesamte restliche Prüfung nicht einen Gedanken mehr daran verschwenden müssen -> Konzentration auf das Wesentliche. Ich wünsche viel Erfolg

ifconfig ist dein Freund Da sollten dann alle Arten von Netzwerk-Interfaces auftauchen - sowohl LAN als auch WLAN. Suche nach dem Stichwort "ether", das bezeichnet die MAC Adresse.

Ein "sinnvolles" Subnetz ist eines, in dem sich mindestens 4 IPs befinden (also ein /30er). -> auch bei diesen sind ja auch noch zwei IPs reserviert, nämlich die erste + letzte, für Netzbezeichnung respektive broadcast. Tatsächlich ist es meines Wissens üblich, solche Mini-Netze (/30er) zwischen zB zwei Netzwerkgeräten aufzuspannen, damit eben genau diese beiden Geräte die zwei verfügbaren IPs bekommen. Zumindest haben wir das seinerzeit in der BBS im PacketTracer so gemacht Was /31 Netze angeht, bin ich mir in diesem Zusammenhang nicht sicher, ob es die überhaupt in freier Wildbahn gibt - /32 hingegen ist üblicherweise die Bezeichnung für exakt eine einzige IP-Adresse. Joah. TL;DR Ein /30er Netz lässt sich nicht mehr sinnvoll in weitere Subnetze unterteilen, deswegen sind /31 und /32 hier raus.

Zum Stichwort Massenbetankung: Es geht nicht nur darum, dass damit viele Systeme gleichzeitig "befüllt" werden können, sondern auch darum, dass es automatisiert geschieht Darüber hinaus, was auch @cortez schon meinte: Es kann durchaus lohnenswert sein, bereits etablierte Lösungen auf Aktualität zu überprüfen bzw. ggf. zu verbessern.