Han_Trio

Ich hab mich damit scheiße schwer getan - ne Woche bestimmt, so insgesamt Aber das beinhaltet auch das zwischenzeitlich komplette "nochmal zurück ans Reißbrett", also sinnvolles Umformulieren etc., u.a. dank wertvoller Hilfe der Community hier. Das reine Erstellen würd ich dann auch auf ca. einen Tag schätzen.

Ja, du hast einen kleinen Denkfehler bzw. kennst die folgende Konvention noch nicht: Die erste Adresse in jedwedem Netz (und zwar UNabhängig von der Größe des Netzes) bezeichnet immer das Netz an sich - die Adresse ist also zwar vorhanden, kann aber nicht vergeben werden.

Mach dir nochmal klar, dass die beiden Dinger, also der Hex-Dump und das ARP-Datagramm, eigentlich genau das Gleiche darstellen, nur eben in unterschiedlicher Schreibweise -> das eine ist hexadezimal, das andere in Bits bzw. Byte. Hier zB nochmal ganz gut dargestellt: http://www.tcpipguide.com/free/t_ARPMessageFormat.htm -> die Graphik etwas weiter unten; hier ist ersichtlich dass die oberen Zahlen im deinem ARP-Datagramm (0-7, 8-15, 16-31) Bits sind. Es wird aber im Datagramm auch in Byte-Schritten gezählt, sodass man hier ein wenig aufpassen muss, dass man nicht durcheinander kommt. Die wichtigste Einsicht für den Vergleich der beiden Graphiken bekommst wohl, wenn du dir folgende Frage beantwortest: Wenn du eine Hex-Zahl bzw. ein Hex-Pärchen oben stehen hast, wieviel Bits entspricht das unten? -> Dann brauchst du im Prinzip "nur" noch abzählen PS

Es ist uns freigestellt, ins HomeOffice zu wechseln, aktuell zeitlich unbegrenzt. Durch unsere bereits vorher vorhandene Infrastruktur (und ein hervorragendes Netzwerk-Team) funktioniert das ziemlich reibungslos. Es gibt Auflagen für ständige Erreichbarkeit während der Arbeitszeit (telefonisch, oder zumindest per Chat) + Tagesprotokolle der durchgeführten Tätigkeiten. Ausnahmen sind wenige Mitarbeiter, für die eine vor-Ort-Präsenz unumgänglich ist bzw. für Arbeiten, die eben nur dort durchgeführt werden können. Es sind überall Hygiene-Spender vorhanden, v.a. "kritischen" an Durchlasspunkten. Es herrscht im gesamten Gebäude eine permanente Maskenpflicht (sowohl für Kunden als auch für Mitarbeiter), Ausnahmen nur direkt am Arbeitsplatz und am Mittagstisch (und hier wird auf Abstände geachtet). Es wird ebenfalls darauf geachtet, dass ca. alle halbe Stunde die Büroräume durchgelüftet werden. Es ist von Anfang an so gewesen, dass "von oben" alles transparent kommuniziert wurde, und die Einhaltung wurde und wird auch durchaus ernst genommen. Wobei ich diesen Punkt tatsächlich für den wichtigsten halte - Regeln sind schön und gut, aber die besten nützen nichts, wenn sie nicht eingehalten bzw. durchgesetzt werden. Böse Zungen werden behaupten, man könnte hier eine Parallele zur aktuellen gesamtdeutschen Situation erkennen..

Vielleicht noch ein paar praktische Hinweise zu cron: - es gibt auch noch anacron (zur zeitversetzten Durchführung, sollte die Maschine zum definierten Zeitpunkt off sein) - achte im Zweifelsfall darauf, absolute Dateipfade zu verwenden (auch innerhalb der Skripte) - zB "apt" -> "usr/local/bin/apt" o.ä. - Denk über irgendeine Art von Logging nach, und sei es auch nur, den Output der Commands (zb mit tee) irgendwohin zu schreiben Und speziell für apt: Schau dir mal die "-y" Option an wie bereits erwähnt, ist dies ein unbeaufsichtigtes Update / Upgrade. So vermeidest du zwar, auf Feedback reagieren zu müssen (continue y/n), aber kannst ggf ungewollte Dinge nicht verhindern bzw. bemerkst diese erst, wenns bereits geschehen ist.

Moin, ok, also Linux. Dann kurz vorweg: Wenn du dich mit quasi 0 Vorwissen in Linux fit machen willst, wirst du jede Menge weinen, fluchen und kotzen. Aber irgendwann wirst du auch Erfolge erzielen, verstehen und lachen können versprochen. Ich würde für den Anfang wie gesagt eine kleine lokale Maschine für die ersten Schritte empfehlen - RasPi oder eben virtualisiert, zB mit VirtualBox. Als Nächstes solltest du mit ein paar Grundlagen beginnen, die du auch an der Maschine testen kannst. So ganz simple Dinge, wie dich mit der Verzeichnis-Struktur (Spoiler: Es gibt kein C : Laufwerk) und dem Terminal vertraut zu machen. Es gibt hier zwei ganz gute Bücher, die offen verfügbar sind: http://openbook.rheinwerk-verlag.de/linux/ http://openbook.rheinwerk-verlag.de/it_handbuch/ (die Auflagen sind nicht mehr aktuell, aber dafür eben für lau einsehbar.) Allein mit den beiden Büchern (bzw. den entsprechenden Kapiteln über Linux) solltest du erstmal gut beschäftigt sein. Es gibt eine MENGE (auch recht guter) Youtube Tutorials, aber mir ging es so, dass ich - zumindest anfangs - dabei zwei Problemchen hatte: 1 Wie kann ich die Qualität bewerten, wenn ich selber noch keine Ahnung habe aka. "vielleicht labert der Typ auch gerade nur ganz viel Müll"? 2 Wie finde ich Tutorials für mein spezielles Anliegen, wenn ich selber nicht einmal die passenden Suchbegriffe kenne? Das kommt aber mit der Zeit wenn du gewisse Begriffe zumindest schonmal gehört hast. Persönlich kann ich diese Playlist hier empfehlen, der Typ ist super: https://www.youtube.com/watch?v=bju_FdCo42w&list=PLtK75qxsQaMLZSo7KL-PmiRarU7hrpnwK (englisch) Grundsätzlich wirst du bei Linux, speziell mit administrativen Tätigkeiten, mittel- bis langfristig nicht an der Konsole vorbei kommen. Man kann natürlich auch viel über "Klicki-Bunti" machen, aber das Terminal ist hier klassischerweise das Mittel der Wahl. Was das BS angeht.. nun, da scheiden sich die Geister Eine lokale kleine Test-Maschine würde ich aber mit einem Desktop aufsetzen, um den Einstieg zu erleichtern. Falls es kein RasPi wird: Ich persönlich kann Linux Mint mit "xfce" Desktop empfehlen - das ist recht ressoucenschonend, und von der Aufmachung her an Windows angelehnt, sodass man da nicht gleich völlig ins kalte Wasser geschmissen wird. Alternativ Ubuntu bzw. eine der entspr. Versionen mit unterschiedlichen Desktop Varianten (Lubuntu, Xubuntu, und wie sie alle heißen). Wenn du dich ein bisschen mit den Basics beschäftigt hast und "schwimmen kannst", dann könntest du dich mit Fernzugriff (Stichwort SSH, es gibt für Windows das Programm "Putty") beschäftigen und laaangsam Richtung (lokaler) Webserver bewegen. Ein Apache (der Name des Webserver Programms) ist vergleichsweise schnell eingerichtet, und das kann schon ein cooler Schlüssel-Moment sein, wenn er dann das allererste Mal läuft. Vielleicht baust du dann mal eine weitere Maschine, diesmal ohne GUI, remote per SSH erreichbar, und lässt die beiden miteinander "reden". Ubuntu / Debian / CentOS / whatever? Deine Wahl. Könnte die zweite Maschine vielleicht auch Webserver + Datenbank auf einmal laufen haben? Wie sieht es eigentlich mit Absicherung aus, wenn du für das Ganze später vielleicht einen Mietserver mit öffentlicher IP verwendest? Was sind diese "SSH keys", von denen immer geredet wird? Joah. So weit erstmal, das sollte für ne Weile reichen. gl hf

Hi, Wenn wir über Server reden, dann sind wir ja vermutlich (auch von dir aus, sozusagen) im Bereich Linux unterwegs (?) Der bereits erwähnte RaspberryPi ist hier ein guter Anfang, alternativ könntest du einen Blick auf das Thema Virtualisierung werfen (zB mit VirtualBox). Einen "richtigen" Server (also Mietserver mit öffentlicher IP etc.) würde ich persönlich, zumindest ganz am Anfang, eher nicht empfehlen, bevor nicht gewisse Basics vorhanden sind, zB eine rudimentäre Absicherung des Ganzen. Bzgl Linux kann ich dir durchaus ein paar Tips geben, aber wir sollten zuerst grob die Richtung klären

Ahh, da war mein Denkfehler. Ja dann ist es klar. Ich denke auch, das geht dann so in Ordnung

Öhm.. dann wäre es vielleicht am besten, du würdest kurz die ursprüngliche Aufgabe hier reinstellen. Ich würde mich im Zweifelsfall an die vorgegebene Syntax der Aufgabenstellung halten, aber gerade steh ich da irgendwie aufm Schlauch

Ist die Frage "theoretischer" Natur, also für Prüfungen etc., oder bezieht sich das auf ein bestimmtes Produkt? Ich gehe mal von theoretisch aus Ansonsten ist das von der Idee her erstmal grundsätzlich nicht falsch, hier allerdings ein paar Hinweise: Die Syntax ist folgendermaßen: "Regel | IP | Protokoll | Port" Das, was du beschreibst, ist eine sog. "restrictive" (beschränkende) Firewall - das bedeutet, dass ganz am Ende eine "unsichtbare" Regel steht, nämlich ein "Deny | Any | Any | Any". Oder anders formuliert: "Alles, was nicht durch irgendwelche Regeln vorher erfasst wird, ist verboten." Das Gegenteil wäre eine "permissive" (erlaubende) Firewall - hier ist alles erlaubt, was nicht explizit verboten ist - am Ende steht also ein "Allow | Any | Any | Any". (Permit und Allow sind gleichbedeutend.) Firewalls können grundsätzlich auf verschiedenen Ebenen filtern, klassischerweise auf IP- und Port-Ebene (Layer 3 + 4), jedoch durchaus auch auf MAC (Layer 2)- und Anwendungsebene (Layer 7). Die Firewallregeln prüfen NUR das, was du ihnen sagst - wenn du zB keine Regel für MAC-Adressen oder Ports geschaltet hast, wird das einfach ignoriert, bzw. es greift ggf. die letzte Regel. Wenn du also in einer restriktiven Umgebung den gesamten Datenverkehr einer Maschine erlauben möchtest, würdest du das so schreiben: Allow | 192.168.0.4 | Any | Any Möchtest du zB nur das http-Protokoll für einen Webserver freigeben, würde das so passieren: Allow | 192.168.0.4 | tcp | 80 (und ggf. zusätzlich noch das Gleiche für Port 443 / https). PS: Normalerweise arbeitet man bzgl. IPs auch noch mit source / Quell- und destination / Ziel-IPs.

Ich hab erst überlegt, ob das mit dem Header so eine Art "unnütze Zusatzinfo" sein soll, um den Leser zu verwiren Mein Ansatz würde dem von @treffnix folgen: Also mit der Info der Größe eines "Netto"-Pakets anfangen (was du ja bereits dargestellt hast) Daraus die Anzahl der Pakete errechnen (aufrunden!) Bei der Übertragung der Pakete kommt die "Brutto"-Größe zum tragen -> diese von Bytes auf Bits runterbrechen Und die Bruttogröße in Bits dann zum Schluss durch die Übertragungsrate (in Bits/s) teilen € komme ebenfalls auf 1393s

Was bekommst du angezeigt, wenn du "scan" eingibst? Anscheinend hat das aber mit der Art der Darstellung der Anzeige zu tun (hex vs. dec) Siehe zB hier https://www.3cx.de/forum/threads/undefined-video-mode-number-314.92711/ https://www.pclinuxos.com/forum/index.php?topic=110044.0 https://www.linuxquestions.org/questions/slackware-14/undefined-video-mode-number-891916/ "hex 314" entspricht dem dort erwähnten "dec 788", also versuchs mal mit "vga=788" bzw. vga=normal

Was ist so mit den "üblichen Verdächtigen"? - Web - FTP - Mail - Datenbank Also natürlich erstmal nix "wirklich" Produktives, aber einfach, um es mal gemacht zu haben Je nach Gusto dann später Dinge wie remote Zugriff + entspr. hardening, Backup Konzept, Monitoring, Update Automatismen, .. gibt ja ne Menge schöner Sachen, die man so machen kann.

Dann ist die interessante Frage: "Was hat sich geändert?" Zur Sache an sich: Hast du mal auf den fraglichen Servern geschaut, ob die Pakete / Anfragen dort WIRKLICH nicht ankommen? Evtl. liegt hier der Klassiker vor, dass der Rückweg nicht definiert ist. Also, für den Rechner stellt es sich so dar: Ich pinge den Server, bekomme aber keine Antwort. Was aber evtl. wirklich passiert: Ich pinge den Server, dieser empfängt, sendet auch etwas zurück, aber "irgendwo" dazwischen (auf dem Rückweg) bleibt es hängen, und ich bekomme "keine Antwort".

zum zweiten Punkt: Schau dir mal die /etc/fstab an Du mountest im Moment zwar vermeintlich korrekt, aber das ist (noch) nicht reboot-fest. Das o.a. file (file system table) wird beim Bootvorgang gelesen, und darin sollten alle "fixen" Filesysteme stehen.

"Berechnen" braucht du hier nichts - fang klein an Als Erstes solltest du mal aufbröseln, wieviele der Hex-Ziffern bzw. -Buchstaben oben im Trace für wieviele Teile des Headers unten stehen. Oder anders gefragt: Eine einzelne Hex-Stelle des Trace steht für wieviele Bit? Dann kannst du anfangen, den Trace mit dem Header zu vergleichen (Hinweis: deine "20" beim flow label ist nicht richtig). Wenn du das korrekt machst, solltest du auf die Stelle im Trace kommen, an der die source IP address anfängt, und dann brauchst du nur noch "abschreiben". Und das Gleiche nochmal mit der destination IP address (diese schließt sich direkt an die source an, wie im Header ja auch ersichtlich ist). Und als Bonus kannst du dann noch bei der Antwort die IPv6 in der gängigen Kurzschreibweise hinschreiben.

Ich hab mal ein paar hundert Postfächer unbeabsichtigt geleert, also die gesamte Korrespondenz ins Nirvana gepustet. Hintergrund: Es war eine (geplante) Löschaktion, die auch tatsächlich mehrere zig Postfächer treffen sollte. Dazu habe ich per Skript eine .txt mit den zu löschenden Postfächern eingelesen, wodurch für jeden Eintrag ein gewisses flag in einer DB auf einen "Lösch"-Wert gesetzt wurde. Ein separates Lösch-Skript schaut dann alle 10 Minuten, ob es etwas zu löschen gibt (alle Einträge, die entsprechend geflagt sind). Doof: in der DB waren die Postfächer teilweise mit einem beginnenden Leerzeichen hinterlegt (was zum Zeitpunkt der damaligen Erstellung nicht verhindert worden war). Aus dem Command "rm -rf /mail/kunde/ordner/postfach" des Lösch-Skripts wurde somit ein "rm -rf /mail/kunde/ordner/ postfach" - oder auch, wie die bash unter Linux es dann interpretiert, ein "rm -rf /mail/kunde/ordner/" Joah.. kompletter Ordner gelöscht, inkl. aller darin befindlichen Postfächer. Mehrfach, da per Skript ausgeführt. Es hat nicht lange gedauert, bis das aufgefallen ist.. geändert hat es natürlich nichts mehr, weg ist weg unter Linux. Backup (gewolltermaßen) nicht vorhanden. So blieb - naben der Ursachenforschung, die zum Glück recht schnell erledigt war - die Informierung des Kunden sowie die Sicherstellung, dass das nicht erneut auftritt. Tatsächlich haben wir noch weitere derartige Einträge gefunden, die also (theoretisch) auch noch weitere Kunden hätten betreffen können. Nachdem der akute Sturm sich dann gelegt hatte, ging es an die Aufarbeitung. Ich habe hier sogar Lob erhalten, für die sofortige Eskalation und auch für die zielorientierte Verhinderung zukünftiger Vorfälle. Ich fand es gut zu wissen, dass nicht erstmal nach dem Schuldigen gesucht und rumgemault wird, sondern sachliche Kommunikation, Analyse und Lösungsfindung im Vordergrund standen. Somit kann ich mich dem Rest hier anschließen, die bereits für einen offenen und ehrlichen Umgang plädiert haben. PS: Die Kommunikation mit dem betroffenen Kunden hat dann jemand anders übernommen

Also du hast schonmal richtig erkannt, dass es sich hier um ein /26 handelt. Es ist hier im Forum üblich, immer ein bisschen "Hilfe zur Selbsthilfe" zu geben, deswegen versuche ich mal, dich dahin zu schubsen, dass du es dir vielleicht auch selbst zusammenreimen kannst Stell dir sozusagen mal die "Vorgeschichte" eines /26 vor -> es war einmal ein Netz, das war ein 10.1.1.0/24 und hatte einen IP-Adressraum von: 10.1.1.0 (wobei die .0 die Bezeichnung des Netzes ist, also nicht für Hosts verwendbar) bis 10.1.1.255 (wobei die .255 die Broadcast-Adresse ist, also ebenfalls nicht für Hosts verwendbar) Jetzt kommt eines Tages der Netzwerk-Admin und teilt dieses in 4 gleichmäßig große /26er (Sub)netze auf. Frage 1: Wie lauten jeweils die IP-Adressen dieser /26er? Bzw. in welchem Bereich liegen sie? Frage 2: Ist darunter vielleicht eine IP-Adresse, die für standardmäßig für etwas Anderes als einen Host verwendet wird? So grob am Rand des Bereiches (s.o.)

SSH-Schlüssel sind nicht unbedingt per default vorhanden, sie können jedoch leicht generiert werden, z.B. mit dem command "ssh-keygen". Normalerweise wird dann das Schlüssel-Pärchen (private + public) abgelegt in $HOME/.ssh/ (beachte den Punkt), und der public key hat eine entspr. Endung, z.B. ".pub". Den public key kannst du dann auf dem Zielsystem hinterlegen, entweder dort direkt einfügen in $HOME/.ssh/authorized_keys oder mit "ssh-copy-id $USER@$Ziel-IP" vom Quellsystem aus.

Du hast dir aber auch gleich ein "spezial" Thema ausgesucht Fang erstmal ein wenig kleiner an. Ich habe selbst vor einigen (wenigen) Jahren erst "richtig" mit Linux angefangen. Wie ich andernorts schonmal geschrieben hatte, mein Lernkonzept sah in etwa so aus: - Ich will eigentlich nur Sache A machen. - Dazu gehören Dinge A1, A2 und A3. - Allein bei Ding A1 spielen Konzepte A1a, A1b und A1c eine Rolle.. Wenn man zuerst mit Sache A anfängt, dreht man mitunter schnell durch - deswegen mein Ratschlag: Fang mit Basics an. Das kompliziertere Zeugs baut darauf auf, aber wenn du später nicht für jeden Einzelschritt erstmal erarbeiten musst, wie das genau funktioniert, ist die Frustration am Ende deutlich geringer. (Dazu gehört auch, dass man - speziell bei Linux - von sich selber nicht erwarten darf, in kürzester Zeit alles zu wissen. Es ist einfach zu viel.) Eine virtuelle Umgebung hast du ja anscheinend schon. Richte vielleicht zwei kleine Testmaschinen ein, die sich untereinander sehen und erreichen können (mit SSH). Alleine bis hierher kannst du bereits viele Stunden investieren, um alles zu verstehen: Stichworte Einrichtung von statischen IPs, User anlegen / verwalten, Dienste starten + den Status kontrollieren, Konfig-Dateien editieren, optional Bedienung des Text-Editors vi.. um ein paar zu nennen. Anschließend kann man sich weiterführende Gedanken machen: - SSH absichern (Stichwort SSH keys, also eine Einwahl ohne Passwort) - einen Apache aufsetzen, um eine simple Webseite auf Server A zu bauen, die man sich von B aus ansehen kann. Dir werden auf dem Weg dahin automatisch noch genug andere Sachen begegnen Wie gesagt: Nicht gleich nach den Sternen greifen. Mach erstmal klein und in Ruhe.

Vielleicht ein wenig philosophisch aber hier wird der Unterschied recht gut dargestellt: https://petri.com/sql-server-string-data-types CHARs sind immer fix in der Länge (sie werden im Zweifelsfall mit blanks aufgefüllt), und sie belegen sie auch immer einen entsprechend fixen Speicherplatz, unabhängig von dem, was "wirklich" an Inhalt drin ist. VARCHARs hingegen sind flexibel (kosten zwar 2 extra Bytes, jedoch wird kein Speicherplatz "verschenkt", wenn die Eingabe kürzer ausfallen sollte). CHARs bieten in rel. wenigen Fällen einen nennenswerten Vorteil, nämlich zB dann, wenn man Eingaben von immer gleichbleibender Länge erwartet (siehe Link mit Beispielen). Zum eigentlichen Thema: Ich schließe mich an, das Ganze stellt lediglich einen Auszug dar. Wenn man sinnvoll etwas verwendet, was dort nur nicht als Beispiel aufgeführt ist, gibt es das ja trotzdem.

LibreOffice Impress Also das free / Open Source Äquivalent zu MS PowerPoint

Ich denke, es ist auch durchaus normal, dass hier ein derartiger "Brei" aus verschiedenen Meinungen bzw. Erfahrungen zusammen kommt Meiner persönlichen BBS-Erfahrung nach verhielt es sich so: - Mathe: Gab es nicht als eigenständiges Fach. Mit den bereits erwähnten Dingen wie Formelumstellung, Dreisatz, Prozentrechnung fuhr man grundsätzlich ziemlich ausreichend, quer durch alle relevanten Fächer. Verständnis von Potenzen (besonders der Unterschied von 10er und 2er) ist v.a. im Bereich Netzwerk zusätzlich hilfreich. - Englisch: Da gab es zum Anfang einen Einstufungstest, anschließend Eingruppierung in versch. "Gütegrade", also die bekannten B1, B2 sowie C1. Reichte dann entspr. von "fruits and vegetables" bis hin zu quasi business english, also mit weniger Fokus auf die Sprache an sich, als tatsächlich auf Inhalte + freies Sprechen. Thematisch war da jedoch nichts vorgegeben. Kann natürlich bei der nächsten BBS wieder komplett anders sein

Das ist vollkommen richtig, die TTL ist 8 Bit lang: https://tools.ietf.org/html/rfc791#page-11 bzw. https://tools.ietf.org/html/rfc791#page-14 Insofern ja, die Darstellung des Headers wäre hier nicht korrekt.

Gern Der eigentliche Sinn bzw. Unterschied ergibt sich übrigens, wenn man sich zusätzlich verdeutlicht, wie ein Restore aussehen würde: Diff. geht schneller (weil es eben nicht den "Umweg" über die einzelnen Tage gehen muss, sondern immer direkt das letzte full BU ansteuern kann) - dafür braucht es mehr Speicher. Inkr. verbraucht weniger Speicher, aber man muss - im schlimmsten Fall - sämtliche vorherigen inkrementellen einzeln durchgehen, bis man beim full BU angekommen ist, kann also nicht direkt aufs full BU zurückgreifen. Man muss mehrere "kleine" Restores durchführen, das braucht entspr. Zeit. Hier nochmal mit einer, wie ich finde, sehr übersichtlichen Graphik: https://kb.acronis.com/de/content/19639