-
Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr
Der "Was hast du heute gelernt?" Thread
- Themenstarter Binfort
- Beginndatum
Jo, krass. Danke [kannte ich noch nicht], aaaaber USB ist mir noch etwas "gewoehnungsbedurftig", da ich mich von der Komplexitaet von USB erschlagen fuehlte, als ich mich etwas mit USB beschaeftigte [was definitiv dem "Groessenwahn" etwas Einhalt gebot, dem ich beinahe verfallen bin oder waere, wobei ich mir noch nicht ganz sicher bin].
Mir schwebt fuer den Anfang etwas "leichteres", wie bspw. ein PCI-Adaper, vor dem geistigen Auge vor, weil das etwas "einfacher" zu portieren oder besser zu "verstehen" ist.
Vielleicht sollte ich noch etwas "aufraeumen" bevor ich mich an einem Controller "abarbeite", wobei MAC / LLC laut ISO 11898-1anscheinend kein Hexewerk ist [habe schon ISO 11898-1 grob "ueberflogen" und Inhalte mit Quellcode vom Adapter mit SJA1000 Controller verglichen oder wie man so eine "Netzwerkkarte" in der "CAN Welt" nennt].
Jetzt wird das etwas off-topic. *duck* :>
Mir schwebt fuer den Anfang etwas "leichteres", wie bspw. ein PCI-Adaper, vor dem geistigen Auge vor, weil das etwas "einfacher" zu portieren oder besser zu "verstehen" ist.
Vielleicht sollte ich noch etwas "aufraeumen" bevor ich mich an einem Controller "abarbeite", wobei MAC / LLC laut ISO 11898-1anscheinend kein Hexewerk ist [habe schon ISO 11898-1 grob "ueberflogen" und Inhalte mit Quellcode vom Adapter mit SJA1000 Controller verglichen oder wie man so eine "Netzwerkkarte" in der "CAN Welt" nennt].
Jetzt wird das etwas off-topic. *duck* :>
Zuletzt bearbeitet:
Seit Tagen rede ich in der Firma mir den Mundel fusselig dass MemoryMappedFiles schneller sind ist als gewöhnliche Memorystreams.
Ich bekomme dann solch Argumente wie aber "in der Implementation von Delphi wird auch nur am Stück eingelesen, wie soll das schneller sein'?!
Nun habe ich endlich mir die Zeit genommen mich durch die Windows Dokumentation zu wühlen und habe ein Vergleichstest gebaut und siehe da 45% schneller. Dazu durfte ich mich in Boyer-Moore-Algorithmus einlesen und den zurecht hacken um zeilenweise die Treffer anzuzeigen.
Ich bekomme dann solch Argumente wie aber "in der Implementation von Delphi wird auch nur am Stück eingelesen, wie soll das schneller sein'?!
Nun habe ich endlich mir die Zeit genommen mich durch die Windows Dokumentation zu wühlen und habe ein Vergleichstest gebaut und siehe da 45% schneller. Dazu durfte ich mich in Boyer-Moore-Algorithmus einlesen und den zurecht hacken um zeilenweise die Treffer anzuzeigen.
Vorübergehend zurück geworfen auf meinen fast 14 Jahre alten PC mit 2 GB RAM habe ich gelernt, wie unterschiedlich OS und Desktops sich verhalten bei gleicher Hardware Architektur, was die Resourcenauslastung und CPU Last betrifft. So belegt unter CentOS 7 Linux der aktuelle Mate Desktop nach dem Start lt. Systemmonitor nur 12 % RAM, bei Debian und FreeBSD viel mehr als das doppelte, so um die ca 32 %. Womit das erklärt werden könnte, kann ich nicht beurteilen. Das es graduelle Unterschiede gibt, ist mir schon klar, aber solche signifikanten Unterschiede dürften meineserachtens nicht sein. Bei aktueller Hardware spielt das natürlich alles keine Rolle. Fazit, Vergleiche bringen immer unterschiedliche Ergebnisse. Das einzuordnen, bedingt einen hohen Grad an technischer Kompetenz. Aber eine wirkliche realistische Antwort erwarte ich auch nicht.
Habe gestern gelernt, dass das OpenBSD-Basissystem die perfekte Lösung ist wenn man jemanden im klassischen Stil statische Dateien auf einem Server hosten lassen will.
OpenSSH mit SFTP Chroot, OpenBSD httpd und acme-client sind schnell konfiguriert und eine perfekte Kombination.
Dazu noch das Learning, dass echt viele Leute mit Filezilla umgehen können, selbst wenn sie so gar keine Ahnung von irgendwas technischem haben. Das habe ich unterschätzt. Dürften doch die meisten Leute schon einmal für irgendwas verwendet haben.
Hintergrund: Mir ging es nicht darum unbedingt auf einem BSD aufzubauen oder gar selbst eine Lösung bereitzustellen, aber am Ende war es dann das einfachste, weil jemand HTML-Dateien, die von wo kamen online stellen wollte. Hatte zunächst nach klassischen Webhostern gesucht oder irgendsowas wie "CDN mit statischem Hosting", aber das war alles irgendwie kompliziert, komisch oder wenig Vertrauen erweckend. Vor allem kam das mit Unmengen an Zeug (MySQL, PHP, Email, etc.), das nicht gebraucht wurde. Einige Lösungen die auch preislich einigermaßen okay waren klangen danach, dass wenn das jetzt ein paar Aufrufe hätte gleich mal an irgendwelchen Limits wäre. Das wollte ich auch nicht riskieren.
OpenSSH mit SFTP Chroot, OpenBSD httpd und acme-client sind schnell konfiguriert und eine perfekte Kombination.
Dazu noch das Learning, dass echt viele Leute mit Filezilla umgehen können, selbst wenn sie so gar keine Ahnung von irgendwas technischem haben. Das habe ich unterschätzt. Dürften doch die meisten Leute schon einmal für irgendwas verwendet haben.
Hintergrund: Mir ging es nicht darum unbedingt auf einem BSD aufzubauen oder gar selbst eine Lösung bereitzustellen, aber am Ende war es dann das einfachste, weil jemand HTML-Dateien, die von wo kamen online stellen wollte. Hatte zunächst nach klassischen Webhostern gesucht oder irgendsowas wie "CDN mit statischem Hosting", aber das war alles irgendwie kompliziert, komisch oder wenig Vertrauen erweckend. Vor allem kam das mit Unmengen an Zeug (MySQL, PHP, Email, etc.), das nicht gebraucht wurde. Einige Lösungen die auch preislich einigermaßen okay waren klangen danach, dass wenn das jetzt ein paar Aufrufe hätte gleich mal an irgendwelchen Limits wäre. Das wollte ich auch nicht riskieren.
Ich habe heute gelernt, dass unter FreeBSD 12 ein "pfctl -t pfbadhost -T replace -f /etc/pf-badhost.txt" fehl schlägt, wenn die Datei mehr als 2^15 IP-Adressen hat. Unter FreeBSD 11 war das kein Problem. Ein "-add" zeigte bei mir ebenfalls kein Problem - nur ein "-replace".
Lösung bringt das Hochsetzen der neuen sysctl net.pf.request_maxcount. Dabei ist zu beachten, dass ein "-replace" offenbar für jede IP Adresse den zweifachen Wert benötigt. In meinem Fall hat die Datei mit den Badhosts gut 50.000 Einträge. Daher reichte mir ein Wert von 2^16-1 in der /boot/loader.conf (bei o.g. sysctl handelt es sich um ein Tunable Value, das nur beim Booten gesetzt werden kann):
Wofür das ganze? Ich verfahre (ungefähr) nach diesem Howto, um täglich eine Liste bekannter Badhosts zu aktualisieren, die dann per PF vom Server weggehalten werden: https://www.geoghegan.ca/pfbadhost.html
Der Vollständigkeit halber, hier mein Bug-Report mit der Antwort von Kristof Provost.
Lösung bringt das Hochsetzen der neuen sysctl net.pf.request_maxcount. Dabei ist zu beachten, dass ein "-replace" offenbar für jede IP Adresse den zweifachen Wert benötigt. In meinem Fall hat die Datei mit den Badhosts gut 50.000 Einträge. Daher reichte mir ein Wert von 2^16-1 in der /boot/loader.conf (bei o.g. sysctl handelt es sich um ein Tunable Value, das nur beim Booten gesetzt werden kann):
Code:
# Einfügen in /boot/loader.conf
net.pf.request_maxcount=131071Der Vollständigkeit halber, hier mein Bug-Report mit der Antwort von Kristof Provost.
was ich Sonntag gelernt habe:
wende dein erworbenes Wissen an und zwar bedächtig!
Oder anders gesagt: bau keinen Riesenmist mit der Hoffnung, es wird schon gut gehen, weil du so ein Gefühl hast, gerade eben dran zu sein mit "Glück haben".
Was hatte ich verbockt?
Ich wollte meinen ziemlich alten RaidZ1 größere Platten geben (nach einiger Überlegung entschied ich mich hierfür).
Die erste getauschte Platte war die älteste im Verbund mit fünf Platten, über 100.000h und aus purer Kuriosität noch im Pool. Beim Resilver gab es einen ersten Fehler, eine Datei wurde an gemeckert. Nicht weiter wichtig. Bei der Gelegenheit erinnerte ich mich dann aber daran, dass ich gar keinen aktuellen Backup hatte!!!
Natürlich hatte ich Backups der "wichtigen Dinge", aber es waren nun mal im Laufe der Zeit auch unwichtige Dinge, die aber nett zu haben sind, hinzugekommen. Als Beispiel: noch ungesehene Filme. Außerdem fiel mir gerade ein, dass ich den Fileserver nicht alleine nutze und auch die Backups der wichtigen Dinge veraltet sein können (nein, sicher veraltet sind), weil eben Leute aus meiner Familie Daten abgelegt haben könnten.
Jeder weiß, dass ohne Backup nichts geht.
Ich weiß nicht, wie oft ich das schon gepredigt habe.
Man kann natürlich mal Gottvertrauen beweisen und schlampig damit umgehen, aber nicht vor einem geplanten Umbau!!!
Auch ich weiß das, natürlich, eigentlich...
Schon genug Mist gebaut?
Weit gefehlt.
Mir schwante, dass ich nun doch einen Backup haben wollte, bevor ich weiter umbaute. Wie das zu machen ist, war meine nächste Sorge, denn ich hatte kein externes Medium mehr herumliegen, das ausreichend Speicherplatz gehabt hätte. Wegen des Resilverings mit einer defekten Datei (die auch schon ersetzt worden war), hatte ich nebenbei einen scrub angeworfen. Nach einem Plattentausch ja grundsätzlich keine dumme Idee. Doch die nächste Idee war dafür umso dümmer. Ich hatte nämlich eine interne HD mit ausreichend Kapazität frei und wollte die zunächst in ein externes Gehäuse friemeln und dann über Netzwerk und USB3 meinen Backup machen, als mir so in den Sinn kam, dass direkt im Fileserver ja noch ein SATA-Port frei ist und dass es viel schneller und auch einfacher ist, die Platte im Server provisorisch zu verkabeln und das Backup direkt über SATA zu fahren. Die Idee gefiel mir gut, ich schnappte ein SATA-Kabel und verlegte es, stöpselte es ins Motherboard, pulte ein Spannungskabel hervor und legte es zur Platte, schloss mein SATA-Kabel an der Platte an und betrachtete das Spannungskabel und dachte bei mir selbst: "och, da wird ja schon nichts passieren, wenn ich die Platte nun im laufenden Betrieb (bei laufendem Scrub!) einfach mal anschließe"...
Und ja, ihr könnt euch eure Kommentare auch an der Stelle sparen: ich kenne sie alle! Ich habe es schon hunderttausendmal mit Kopfschütteln und Unverständnis Anderen erklärt und nie verstanden, wie man denn sooo dooof sein kann.
Und dann schnappte der Stecker auf den Anschluss und alle Festplatten stellten ihre Aktivität spontan ein, das System war nicht mehr erreichbar, die ssh-Konsolen hingen, nichts mehr, nur drehende Lüfter.
Auch nach einem Neustart keinen Kontakt mehr zum System.
Scheiße.
Oder?
Man kann da gar nicht sagen oder denken: Pech gehabt.
Das ist kein Pech, das ist Dummheit! Nein, dass ist Dummheit in beliebiger Potenz.
Nehmt das alle zum Anlass, nicht selbst dumm zu sein UND wider besseres Wissen zu handeln!
Ich möchte die Geschichte noch ein wenig weiter erzählen.
Der Fileserver ist ein altes FreeBSD, das niemals upgedatet wurde. Das ZFS darauf eines der ersten in FreeBSD benutzten. Ich sollte den vielleicht neu machen, bin aber zu faul. Jedenfalls gab es damals Probleme mit root on ZFS und ich entschied mich, auch aus anderen Gründen, das System auf einem Stick mit UFS zu betreiben. Von diesem Stick halte ich eine Kopie im Fileserver parat, für den Fall der Fälle. Den hatte ich nun ja. Also, Neustart mit alternativem Stick und ein Blick auf den zpool zeigte: drei Platten faulty, pool faulty, alles im Eimer, alles Hin.
Das war Sonntag.
Heute früh betrachtete ich mir den Bootvorgang mit dem ersten Stick (ich musste dazu eine GraKa einbauen) und sah, dass er ein defektes Dateisystem hatte. Stick in den PC, fsck, neuer Start vom Stick, Blick auf den Pool: ein neuer Scrub beginnt und der Pool ist nur ein wenig Degraded.
Inzwischen ist der Scrub durch und mein Pool meldet sich heil wieder.
Ich fasse nichts an! Derzeit läuft ein Backup, auf ein neu gekauftes, externes Medium. Lass es laufen, so lange es dauert!
Vielleicht ist das gerade so nochmal gut gegangen. Vielleicht werde ich weiteres Lehrgeld bezahlen müssen.
Glück gehört zum Leben, aber man kann sich nicht darauf verlassen und sollte es einfach nicht in Anspruch nehmen.
Wenn das nochmal gut geht und man daraus eine Lehre ziehen will: trust in ZFS
Allerdings gibt es vielleicht auch eine rein technische Lehre, denn offenbar schreibt ein Scrub nicht nur etwas auf die benutzten Datenplatten, sondern auch ins System (bei mir einen USB-Stick). Deshalb kann man nicht "in laufendem Betrieb" innerhalb eines Scrubs das System wechseln. Zumindest nicht so einfach, wie ich das machte.
Und noch was nebenbei, was dieser Aktion aber nicht bedurft hätte: mein nächster Pool hat >= zwei Platten Redundanz. Alles Andere ist Pfusch. Es wird ein Raidz2 werden, wenn irgendwie möglich.
wende dein erworbenes Wissen an und zwar bedächtig!
Oder anders gesagt: bau keinen Riesenmist mit der Hoffnung, es wird schon gut gehen, weil du so ein Gefühl hast, gerade eben dran zu sein mit "Glück haben".
Was hatte ich verbockt?
Ich wollte meinen ziemlich alten RaidZ1 größere Platten geben (nach einiger Überlegung entschied ich mich hierfür).
Die erste getauschte Platte war die älteste im Verbund mit fünf Platten, über 100.000h und aus purer Kuriosität noch im Pool. Beim Resilver gab es einen ersten Fehler, eine Datei wurde an gemeckert. Nicht weiter wichtig. Bei der Gelegenheit erinnerte ich mich dann aber daran, dass ich gar keinen aktuellen Backup hatte!!!
Natürlich hatte ich Backups der "wichtigen Dinge", aber es waren nun mal im Laufe der Zeit auch unwichtige Dinge, die aber nett zu haben sind, hinzugekommen. Als Beispiel: noch ungesehene Filme. Außerdem fiel mir gerade ein, dass ich den Fileserver nicht alleine nutze und auch die Backups der wichtigen Dinge veraltet sein können (nein, sicher veraltet sind), weil eben Leute aus meiner Familie Daten abgelegt haben könnten.
Jeder weiß, dass ohne Backup nichts geht.
Ich weiß nicht, wie oft ich das schon gepredigt habe.
Man kann natürlich mal Gottvertrauen beweisen und schlampig damit umgehen, aber nicht vor einem geplanten Umbau!!!
Auch ich weiß das, natürlich, eigentlich...
Schon genug Mist gebaut?
Weit gefehlt.
Mir schwante, dass ich nun doch einen Backup haben wollte, bevor ich weiter umbaute. Wie das zu machen ist, war meine nächste Sorge, denn ich hatte kein externes Medium mehr herumliegen, das ausreichend Speicherplatz gehabt hätte. Wegen des Resilverings mit einer defekten Datei (die auch schon ersetzt worden war), hatte ich nebenbei einen scrub angeworfen. Nach einem Plattentausch ja grundsätzlich keine dumme Idee. Doch die nächste Idee war dafür umso dümmer. Ich hatte nämlich eine interne HD mit ausreichend Kapazität frei und wollte die zunächst in ein externes Gehäuse friemeln und dann über Netzwerk und USB3 meinen Backup machen, als mir so in den Sinn kam, dass direkt im Fileserver ja noch ein SATA-Port frei ist und dass es viel schneller und auch einfacher ist, die Platte im Server provisorisch zu verkabeln und das Backup direkt über SATA zu fahren. Die Idee gefiel mir gut, ich schnappte ein SATA-Kabel und verlegte es, stöpselte es ins Motherboard, pulte ein Spannungskabel hervor und legte es zur Platte, schloss mein SATA-Kabel an der Platte an und betrachtete das Spannungskabel und dachte bei mir selbst: "och, da wird ja schon nichts passieren, wenn ich die Platte nun im laufenden Betrieb (bei laufendem Scrub!) einfach mal anschließe"...
Und ja, ihr könnt euch eure Kommentare auch an der Stelle sparen: ich kenne sie alle! Ich habe es schon hunderttausendmal mit Kopfschütteln und Unverständnis Anderen erklärt und nie verstanden, wie man denn sooo dooof sein kann.
Und dann schnappte der Stecker auf den Anschluss und alle Festplatten stellten ihre Aktivität spontan ein, das System war nicht mehr erreichbar, die ssh-Konsolen hingen, nichts mehr, nur drehende Lüfter.
Auch nach einem Neustart keinen Kontakt mehr zum System.
Scheiße.
Oder?
Man kann da gar nicht sagen oder denken: Pech gehabt.
Das ist kein Pech, das ist Dummheit! Nein, dass ist Dummheit in beliebiger Potenz.
Nehmt das alle zum Anlass, nicht selbst dumm zu sein UND wider besseres Wissen zu handeln!
Ich möchte die Geschichte noch ein wenig weiter erzählen.
Der Fileserver ist ein altes FreeBSD, das niemals upgedatet wurde. Das ZFS darauf eines der ersten in FreeBSD benutzten. Ich sollte den vielleicht neu machen, bin aber zu faul. Jedenfalls gab es damals Probleme mit root on ZFS und ich entschied mich, auch aus anderen Gründen, das System auf einem Stick mit UFS zu betreiben. Von diesem Stick halte ich eine Kopie im Fileserver parat, für den Fall der Fälle. Den hatte ich nun ja. Also, Neustart mit alternativem Stick und ein Blick auf den zpool zeigte: drei Platten faulty, pool faulty, alles im Eimer, alles Hin.
Das war Sonntag.
Heute früh betrachtete ich mir den Bootvorgang mit dem ersten Stick (ich musste dazu eine GraKa einbauen) und sah, dass er ein defektes Dateisystem hatte. Stick in den PC, fsck, neuer Start vom Stick, Blick auf den Pool: ein neuer Scrub beginnt und der Pool ist nur ein wenig Degraded.
Inzwischen ist der Scrub durch und mein Pool meldet sich heil wieder.
Ich fasse nichts an! Derzeit läuft ein Backup, auf ein neu gekauftes, externes Medium. Lass es laufen, so lange es dauert!
Vielleicht ist das gerade so nochmal gut gegangen. Vielleicht werde ich weiteres Lehrgeld bezahlen müssen.
Glück gehört zum Leben, aber man kann sich nicht darauf verlassen und sollte es einfach nicht in Anspruch nehmen.
Wenn das nochmal gut geht und man daraus eine Lehre ziehen will: trust in ZFS
Allerdings gibt es vielleicht auch eine rein technische Lehre, denn offenbar schreibt ein Scrub nicht nur etwas auf die benutzten Datenplatten, sondern auch ins System (bei mir einen USB-Stick). Deshalb kann man nicht "in laufendem Betrieb" innerhalb eines Scrubs das System wechseln. Zumindest nicht so einfach, wie ich das machte.
Und noch was nebenbei, was dieser Aktion aber nicht bedurft hätte: mein nächster Pool hat >= zwei Platten Redundanz. Alles Andere ist Pfusch. Es wird ein Raidz2 werden, wenn irgendwie möglich.
ich habe heute gelernt, dass der Inhalt eines int Arrays Elements in C, von dem man ziemlich sicher ist,
dass der Wert entweder 0 oder 70000 betragen muss - man aber immer wieder 18801652560 zu sehen bekommt,
keineswegs ein Fehler in Form einer Adresse o.ä. sein muss - sondern total korrrekt ist, wenn man bedenkt dass der Wert
von einer Mototorola BIG_ENDIAN Maschine kommt und hier in der LITTLE_ENDIAN Welt natürlich byte-vertauscht
interpretiert wird.
Klar, dafür haben kluge Köpfe <byteswap.h> erdacht ... aber bis ich da 'mal drauf gekommen bin?! -- OMG!
dass der Wert entweder 0 oder 70000 betragen muss - man aber immer wieder 18801652560 zu sehen bekommt,
keineswegs ein Fehler in Form einer Adresse o.ä. sein muss - sondern total korrrekt ist, wenn man bedenkt dass der Wert
von einer Mototorola BIG_ENDIAN Maschine kommt und hier in der LITTLE_ENDIAN Welt natürlich byte-vertauscht
interpretiert wird.
Klar, dafür haben kluge Köpfe <byteswap.h> erdacht ... aber bis ich da 'mal drauf gekommen bin?! -- OMG!
Little <-> Big Endian <-> Mixed <->...
Menschenlesbare ASCII "Header" Files, die den Datensatz beschreiben (vorgeschlagen z.B. auch in der ISO 21289) und dann ein simpel aufgebauter Binary Datensatz, werden leider viel zu selten genutzt. Dann könnte man ja Datensätze selber auswerten, anstatt irgendeine proprietäre Meßgeräte SW zu verwenden. Die andere Fraktion ist die "Ich werte es in Excel aus" Fraktion; wenn's einer wollte, habe ich auch einen ASCII Export von 20GB Integer Matrizen zukommen lassen...
Für Fehlereinbautest bei ARM Prozessoren - einfach mal dezent den Prozessor im Startup im Endian Format umstellen...
Menschenlesbare ASCII "Header" Files, die den Datensatz beschreiben (vorgeschlagen z.B. auch in der ISO 21289) und dann ein simpel aufgebauter Binary Datensatz, werden leider viel zu selten genutzt. Dann könnte man ja Datensätze selber auswerten, anstatt irgendeine proprietäre Meßgeräte SW zu verwenden. Die andere Fraktion ist die "Ich werte es in Excel aus" Fraktion; wenn's einer wollte, habe ich auch einen ASCII Export von 20GB Integer Matrizen zukommen lassen...
Für Fehlereinbautest bei ARM Prozessoren - einfach mal dezent den Prozessor im Startup im Endian Format umstellen...
Wenn's beim Ports testen in poudriere nicht läuft kann es sehr sinnvoll sein, erstmal wieder zurück zum manuellen "make install" zu gehen .... zumindest in "exotischen" Situationen wie dieser:
Mein neuer MakeMKV Port baut im pre-configure eine größere Menge statischer Libs in ein temporäres Verzeichnis, das dauert hier gute 15 Minuten -- da habe ich bestimmt 10, 20 mal dabei zugesehen bis ich auf die Idee gekommen bin, lieber mal im Port diese ganze Vorbereitung auszukommentieren, stattdessen das temporäre Verzeichnis zu sichern und wiederzuverwenden, um direkt ohne Wartezeit den eigentlichen Build testen zu können
-- hätte VIEL Zeit sparen können, wenn ich eher auf diese Idee gekommen wäre 
Mein neuer MakeMKV Port baut im pre-configure eine größere Menge statischer Libs in ein temporäres Verzeichnis, das dauert hier gute 15 Minuten -- da habe ich bestimmt 10, 20 mal dabei zugesehen bis ich auf die Idee gekommen bin, lieber mal im Port diese ganze Vorbereitung auszukommentieren, stattdessen das temporäre Verzeichnis zu sichern und wiederzuverwenden, um direkt ohne Wartezeit den eigentlichen Build testen zu können
-- hätte VIEL Zeit sparen können, wenn ich eher auf diese Idee gekommen wäre 
Das der vmm von OpenBSD wirklich klasse und unklompliziert ist um im kleinen Umfang ein paar VMs für ein paar bastelleien zu basteln ...
... das das aber alles nichts hilft wenn man versehentlich (Zahlendreher!) der VM die gleiche IP wie dem Host gibt und sich 10 Minuten über diverse wunderlichkeiten im Netzwerk wundert
... das das aber alles nichts hilft wenn man versehentlich (Zahlendreher!) der VM die gleiche IP wie dem Host gibt und sich 10 Minuten über diverse wunderlichkeiten im Netzwerk wundert
Dass eine gesicherte Verbindung zum remoten MySQL-/MariaDB-Server trivial einfach geht (hier bei Linode gefunden):
Falls lokal schon ein solcher Server läuft, kann man natürlich auch den Port ändern, damit es da keine Konflikte gibt.
Use Case bei uns: Mein Kollege will regelmäßig Kundendaten aus der MariaDB auf dem (Web-)Server in unser Buchhaltungssystem (MonkeyOffice mit CubeSQL) rüberholen. Erstens sollte der Verkehr natürlich verschlüsselt stattfinden und zweitens wollte ich den Datenbankserver nicht offen ins Internet stellen (nur weil er vielleicht 1x am Tag für ein paar Minuten über das Internet erreichbar sein muss).
Daher dachte ich erst daran, den MariaDB-Server mit Letsencrypt-Zertifikat auszustatten, somit den Verkehr über TLS abzusichern und zusätzlich den Port per AUTHPF(8) nur zeitweilig vom Kollegen öffnen zu lassen. Aber dann suchte ich mal nach "mysql ssh tunnel" und wurde schnell fündig. Super einfach, alles mit Bordmitteln... genau das, was wir brauchen!
ssh user@example.com -L 3306:127.0.0.1:3306 -NFalls lokal schon ein solcher Server läuft, kann man natürlich auch den Port ändern, damit es da keine Konflikte gibt.
Use Case bei uns: Mein Kollege will regelmäßig Kundendaten aus der MariaDB auf dem (Web-)Server in unser Buchhaltungssystem (MonkeyOffice mit CubeSQL) rüberholen. Erstens sollte der Verkehr natürlich verschlüsselt stattfinden und zweitens wollte ich den Datenbankserver nicht offen ins Internet stellen (nur weil er vielleicht 1x am Tag für ein paar Minuten über das Internet erreichbar sein muss).
Daher dachte ich erst daran, den MariaDB-Server mit Letsencrypt-Zertifikat auszustatten, somit den Verkehr über TLS abzusichern und zusätzlich den Port per AUTHPF(8) nur zeitweilig vom Kollegen öffnen zu lassen. Aber dann suchte ich mal nach "mysql ssh tunnel" und wurde schnell fündig. Super einfach, alles mit Bordmitteln... genau das, was wir brauchen!
Und bei uns haben sie (mal) wieder gelernt, daß wenn der Kunde verspricht die SW nur für Versuche auf dem Prüfstand und nur für diese eine Funktion in der SW zu verwenden und man deutlich mitteilt, daß das ungetestet ist nach kurzer Zeit eine Riesenbeschwerde kommt, daß die Produktivumgebung / Maschinen stehen.
Und nachdem ich jetzt chrome Testuser in der Fa. bin (endlich mal was neues nach IE) habe ich gelernt daß diese Software "_S_agenhafte _A_benteuer (eines) _P_rogrammierers" immer noch auf den D*** IE angewiesen ist und mit so neumodischen Zeug nicht umgehen kann. Seit wann hat eigentlich MS den auf depricated gesetzt - ist doch schon etwas her?