Manchmal muss man dem Webserver einen Tritt verpassen z.B. mehrere laufende Worker-Prozesse, von denen einer warum auch immer noch das alte Zertifikat ausliefert. Einfach mal alles ordentlich neu durchladen und mit etwas Glück ...
Beiträge von frostschutz
-
-
nicht ausgeschaltet aber direkt ins rescue-system wäre schick
den ssh-publickey dafür schon beim bestellvorgang reinpasten... und ab gehts
würde einen ordentlichen ersteindruck machen, aber na ja, bislang wars auch kein problem das von hand
-
Mit Linux wär das nicht passiert...
-
Es geht ja erstmal darum, überhaupt ein Backup zu haben. Wie man das dann hochlädt, das ist ein lösbares Problem. Wenn man es gar nicht hat, dann unlösbar.
Kommt auch auf die Datenmenge an, wer eine 100TB Mediathek betreibt, der kommt nicht umhin, als das auf dem Postweg "hochzuladen" oder selber ins RZ zu fahren.
Und ansonsten kann man sich klar einfach noch eine andere Kiste irgendwo mieten zum spiegeln, aber bei 10GB ist das jetzt noch nicht so angesagt...
-
Nebenbei, das "nach Hause runterladen" soll dich nicht davon abhalten, auf dem Server selber auch den Zustand der letzten 7 Tage / Wochen vorzuhalten. (Solang du den Speicherplatz nicht anderweitig nutzt.)
Streng genommen ist das kein Backup weil auf der gleichen Maschine, auf dem gleichen Speichermedium, und wenn das eingeht ist ja alles auf einmal weg.
Aber manchmal muss man ja einfach so z.B. "auf den Stand von gestern" zurückgreifen können. Ohne dafür erst was hoch- oder runterladen zu müssen.
-
10GB? rsync nach Hause...
-
wenn du die tabelle nicht löschen kannst, vielleicht geht umbenennen noch?
-
Zitat
Dann aber festgestellt, dass scheinbar nicht mit UTF-8-Zeichensatz importiert wurde - die Umlaute wurden falsch dargestellt.
Im Dump selbst sind die Zeichen aber richtig?
Ich hatte mal den "Spaß" bei einem anderen Webhoster. Die hatten eine alte MySQL Installation (ohne utf8mb4, also ohne emoji und pipapoh) aber zu dem Zweck auch eine MariaDB. Leider stammte das 'mysqldump' Tool vom veralteten MySQL und das hat brav aus der MariaDB-utf8mb4 Datenbank einen Dump erzeugt und völlig fehlerlos alles in Ascii-?-Fragezeichen verwandelt. Der Dump war unbrauchbar und es war mein Glück, daß ich es beim Umzug bemerkt habe...
Solang die Zeichen im Dump richtig sind, manchmal reicht es dann aus, das Charset im Dump selbst anzugeben ( wenn nicht eh schon der Fall )
Wenn die DB selber gar nicht mehr reagiert wirst wohl bei Netcup nachhaken müssen
Viel Erfolg
-
es wird dir nicht viel anderes übrig bleiben
php 5 wird seit bald 2 jahren nicht mehr aktiv unterstützt und es gibt jetzt auch keine patches für kritische sicherheitslücken mehr
und das problem mit froxlor und php5 soll gelöst sein ... https://github.com/Froxlor/Froxlor/issues/559
umgekehrt würd ich da eher erwarten, daß froxlor probleme mit php5 hat oder haben wird, weil - das eben "keiner mehr benutzt"...? (benutzen sollte)
-
Fakt ist, da dass System ja 24/7 läuft, werde ich mir primär eine WD Red 3TB Platte kaufen und verbauen.
Nach Adam Ries bezahle ich aber, wenn ich mir eine zweite WD Red kaufe, statt nur 100€ schnell mal 200€ für meine Platten
Für mein Zuhause-RAID bin ich dieses Jahr von uralten 2TB- auf 8TB-Platten umgestiegen, WD80EZAZ aus WD MyBooks, gabs dieses Jahr mehrmals zu einem TB-Preis deutlich unter 20€. Gehäuse und Netzteil noch gratis obendrauf.
100€ für eine 3TB-Platte (30€+/TB) ist doch der helle Wahnsinn. Die teuren Festplatten gehen auch kaputt, davon kann man sich nicht freikaufen.
Das 0815-RAID zuhause ist auch kein 24/7 Betrieb sondern 24/7 idle.
Spiegelung ist okay solange diese auf Dateibasis erfolgt (rsync, borgbackup o.ä.)
-
Mit entsprechender TTL ist auch das kein großes Problem... (und du musst die alte IP ja nicht sofort abdrehen)
Aber wie auch immer. Sorry fürs abdriften.
-
Wie die Datei formatiert sein muss, darum gehts ja gar nicht. Aber man sollte mehrere IP-Adressen eben einfach so angeben können, ohne dafür irgenwelche komischen Verrenkungen machen zu müssen, wie bei Debian der Fall. Aber ist halt so.
Bei Debian hat sich die Variante mit den vielen up/down Befehlen für mich als die praktikabelste erwiesen. Schaut halt komisch aus. ymmv
Und Bugs hat das Debian System auch zur Genüge. Im laufenden System die IP-Konfiguration ändern hat da nicht so gut geklappt. Im Zweifel Reboot notwendig, oder von Hand machen.
Den zweiten Teil mit dem Programm, das nach jeder Neuinstallation eine neue IP braucht, hab ich nicht so recht verstanden. In Zeiten von IPv4 Knappheit klingt das eigentlich kontraproduktiv, IPv4s auf sowas zu verschwenden. Bei IPv6 wärs ja kein Problem, da kannst du dir jeden Tag eine neue IP würfeln wenns sein muss.
-
*blinzel* 10 Jahre alte Anleitung? Steht so auch im Wiki? Hrmmm.
Was EIGENTLICH funktionieren sollte ist "address ersteip zweiteip dritteip" aber bei Debian kann das nochmal 10 Jahre dauern.
Bei Ubuntu scheinbar schon passiert.Evtl. auch noch interessant:
https://wiki.debian.org/Networ…ddresses_on_one_Interface
Ich bin da ganz unten beim Manual Approach nur ohne das Alias/Label-Zeug. Also für jede IP ein up/down ip addr add/del 1.2.3.4/32 dev dings
Aliase haben oft für Missverständnisse gesorgt (sieht aus wie ein eigenes Netzwerkinterface, ist aber keins) und sind offiziell obsolet. Steht so auch in linux/Documentation/networking/alias.txt """ IP-aliases are an obsolete way to manage multiple IP-addresses/masks per interface.
Aber es funktioniert ja und das ist dann wohl die Hauptsache...
-
utf8 ist utf8, aber bei (mysql) Datenbanken gibts den Sonderfall, daß dort utf8 historisch nur bis 3 bytes geht, aber neue Zeichen 4 bytes brauchen. und dafür hat die Datenbank dann einen neuen Zeichensatz erfunden, utf8mb4. Was effektiv bedeutet, daß du eigentlich alle Datenbanken auf utf8mb4 umstellen musst, weil utf8 nicht mehr reicht und dann komische Sachen passieren, wenn die Leute mit ihren neumodischen Emojis ankommen.
Wenn du statt einem Umlaut zwei komische Zeichen siehst, dann hat irgendwas anderes in der Kette utf8 nicht unterstützt sondern z.B. latin1 gesehen und somit den utf8-Umlaut (ein Zeichen zwei Bytes) als zwei Zeichen verstanden. Da muss man dann einfach suchen. Manchmal ist es schon der mysql-Dump selber, der zwar richtig in UTF-8 kodiert ist aber dann trotzdem nicht UTF-8 (als Zeichensatz für die Übertragung) setzt.
Wenn man mysqldump o.ä. Tools verwendet um die Datenbank zu sichern, müssen das auch neue Versionen sein die utf8mb4 unterstützen, sonst werden alle utf8mb4 Zeichen stillschweigend zu Fragezeichen. Ganz ohne Fehlermeldung, merkt man erst wenns zu spät ist. Das kann passieren wenn man mit altem Debian, CentOS unterwegs ist, für utf8mb4 sich ein MariaDB irgendwo her organisiert hat, aber mysqldump noch das Tool vom alten mysql ist das von utf8mb4 nie was gehört hat...
-
wollte ich mal Fragen inwieweit es bei Netcup möglich ist hier Preise anpassen zu lassen.
Zu Weihnachten oder Ostern einen Aktionsserver nehmen und zufrieden sein...
-
Server: früher Debian, heute ArchLinux. Hat sich bei der Systemd-Umstellung so ergeben, es war bei Debian eine Zeit lang nicht klar ob das reibungslos klappt, ArchLinux ausprobiert die das schon länger verwenden und dabei geblieben.
Für Familie, Laptop, ohne große Anforderungen, Hauptsache mal eben schnell ein Linux installiert: Ubuntu.
Eigener Desktop: seit Ewigkeiten Gentoo. Versuche, hier auch auf ArchLinux zu wechseln, sind bislang gescheitert.
Auf der einen Seite brauche ich das, was Gentoo bietet, eigentlich schon lange nicht mehr (Compilerflags und Useflags, geh bitte) und mir gefällt das Paketmanagement bei ArchLinux viel besser (auch Rolling Release aber nicht Ewigkeiten warten bis der ganze Schlamassel compiliert ist).
Auf der anderen Seite renne ich bei ArchLinux als Desktop immer in mysteriöse Probleme. Wenn ich bei einer frischen ArchLinux Installation im Xorg mit xterm/urxvt als allererstes mit vollkommen unlesbar verpixelten Schriften begrüßt werde, habe ich schon fast keine Lust mehr. ArchLinux ist eben mehr so eine Debian debootstrap Minimal-Installation, prädestiniert für Serveranwendungen. Wenn man das auf einen vollen Desktop hochziehen will, hat man was zu tun.
Das hängt natürlich auch damit zusammen, daß ich im GUI-Bereich eklatante Wissenslücken habe. Ich arbeite sehr viel mit dem Terminal und habe mir nie sonderlich die Mühe gemacht, GUI-spezifische Sachen wie fontconfig & Co zu durchschauen. Wenn ich dann auf der grafischen Oberfläche ein Problem mit Schriftdarstellung habe, weiß ich schlichtweg nicht, wo ich da anfangen soll nach der Ursache zu suchen.
Und solange man wieder mit 1 Klick ins alte Gentoo gebootet hat wo der Hase einfach läuft, dann ist die Motivation auch gering, sich damit auseinanderzusetzen.
Wenn man lange eine Distro eingesetzt hat, dann ist man davon abhängiger, als man denkt. Ich bin immer wieder überrascht wenn in anderen Distros irgendein Konzept ein anderes ist (Initramfs, cron, ...). Und Tricks die man in einer Distro kennt, sind eben auf andere nicht so unbedingt übertragbar. Und manche Programme verhalten sich im Detail anders, ohne daß man jetzt unmittelbar weiß, woher das kommt, weil da irgendeine Default-Konfiguration je nach Distro abweicht. Und dann geht die Sucherei eben los...
-
Zitat
Du vermittelst den Eindruck, fail2ban zu benutzen wäre was für "Anfänger"
Zunächst einmal ist das nicht der Eindruck den ich vermitteln möchte. Ich sag gar nichts gegen fail2ban. Ich sag auch nix gegen Portänderungen. Mach ich ja eh selber. Ich sag nur daß das im Prinzip beides in die gleiche Richtung geht, das eine wird verteufelt, das andere auf ein Podest gehoben. Das eine ist eben angesehener/akzpetierter als das andere. Viele Leute installieren Linux, haben ganz schräge Firewall-Sachen am Start und "ohne Firewall wirst du sofort gehackt" und... das ist eben nur sehr oberflächlich betrachtet so.
Und da sind wir beim Punkt: 100% Sicherheit gibt es nie, was gerade die jüngste Vergangenheit gezeigt hat, sei es Spectre, Meltdown, Heartbleed oder sonst was. Und dann ist es doch besser, wenn man potentielle Angreifer frühzeitig aussperrt, anstatt sie "unendlich lange" probieren zu lassen.
Ja, ist ja auch ein Argument für Portänderungen. Für den Fall daß mal eine unbekannte Sicherheitslücke alle SSHDs der Welt angreifbar macht, ist es doch besser, der SSHD läuft nicht auf dem Standardport sondern woanders, wo du dann vielleicht nicht so schnell gefunden wirst. Kann so passieren. Ändert nichts daran, daß das alles als Security by Obscurity anzusehen ist.
Bei Sicherheitsmaßnahmen geht man immer von einem theoretischen Angreifer aus, dem maximale Resourcen zur Verfügung stehen. Bei Festplattenverschlüsselung investiert man X-hunderttausend Iterationen (und bald massenhaft RAM) in die Schlüsselableitung, um es rein rechnerisch und technisch unmöglich zu machen, das in sinnvoller Zeit zu knacken, auch mit 100-Millionen-Dollar Hardware. Bei SSH & Co analog mit Keys die soviel Entropie-Zufallsbits haben daß es schlichtweg völlig unmöglich ist, da durchzukommen. Bei IPv4 gibt es 4294967296 IPs, 1 davon gehört dir, der Rest dem Gegner. Dein Sicherheitskonzept muss dieses Szenario überleben und deswegen heißt es überall: mach SSH nicht mit Passwörtern sondern mit 4096-BIt-Keys. Auch wenn ein ausreichend langes Passwort (z.B. 12 Zufallswörter) genauso wenig zu knacken und praktisch kein Unterschied machen würde, man tut das einfach nicht weil es eine bessere Lösung gibt.
fail2ban kann soll darf man ruhig machen. Aber man braucht sich nicht einbilden, daß es eine starke Sicherheitsmaßnahme ist. Wer das umgehen möchte der kann das einfach tun. Wer 100'000 geleakte Keys hat und weiß, einer davon gehört dir, dann wird der sich ein Botnetz mieten und von 100'000 IPs je eine Anfrage zu dir schicken, kein Ding. Wenn es jemand wirklich auf dich abgesehen hat und was in der Hand hat gegen dich, dann bringt das mit fail2ban gar nichts.
-
Das ist eine echte Sicherheitsmaßnahme, die effektiv Brute-Force Attacken verhindert.
Das System muss sicher sein, egal ob dein SSH auf Port 22 oder 222 läuft, egal ob du fail2ban benutzt oder nicht. Ist das so, dann hast du Security. Der ganze Rest ist Obscurity.
Wenn du ausschließlich mit Key-Auth arbeitest und nicht mit "passwort123", und du deine Keys nicht vor X Jahren mit Debian erzeugt hast die da so einen lustigen Bug hatten in ihrem Zufallsgenerator mit nur 32768 möglichen Ergebnissen, dann ist Bruteforce von vorneherein ausgeschlossen.
Umgekehrt kann man sich nicht darauf verlassen, daß mit fail2ban schwache Passwörter nicht trotzdem erraten werden können. Du musst immer davon ausgehen, daß ein Angreifer auf einen entsprechend großen IP-Pool zurückgreifen kann, mit dem ein Brute-Force dann keineswegs verhindert wird. Detailfragen kommen dann noch hinzu, wie gehst du mit IPv6 um, sperrst du da gleich ganze Subnetze, wenn ja in welcher Größe?
Die einzige praktische Auswirkung von fail2ban ist eigentlich, daß man sich gelegentlich selbst aussperrt. Bei allen anderen ist es egal ob du sie sperrst oder nicht, solange dein System sicher ist, kommen die eh nicht rein. Das ist dann nur Schönung von Traffic/Logs/... aber keine echte Sicherheitsmaßnahme mehr.
Das heißt nicht daß du auf fail2ban verzichten sollst. Im Gegenteil, kann jeder gerne machen. Ditto bei Portänderungen, jeder wie er will. Auf "Sicherheit" als solches hat das aber nur sehr begrenzt Auswirkung.
Gefährlich wird es dann wenn man sich auf unwirksame Maßnahmen verlässt. Ein offener SSHD wird nicht sicher wenn er auf einem anderen Port läuft oder wenn fail2ban ins Log schaut. Der SSHD muss zuerst sicher sein und dann kannst du das andere Zeug machen wie dir beliebt.
Es ist auch ein Unterschied ob du alleine am Server bist oder beliebige User darauf ihr Unwesen treiben. Wenn du "aus Gründen" unsichere Passwortlogins für Hinz und Kunz erlaubst, dann ist fail2ban natürlich der verzweifelte Versuch, Sicherheit herzustellen wo keine Sicherheit möglich ist.
-
Ich ändere meinen SSH-Port auch, solange ich der einzige SSH-Nutzer bin. Nicht als Sicherheitsmaßnahme sondern einfach für die Übersicht.
Ich würde gerne wissen, wenns jemand speziell auf meinen Server abgesehen hat, ich schaue also durchaus mal das sshd und andere Logs an, wer da so klingelt.
Der Standardport wird sowas von sinnlos zugespammt, und das Logfile dementsprechend vollgemüllt. Mit geändertem Port ist das deutlich übersichtlicher.
Andere sorgen mit fail2ban o.ä. Geschichten für diese Übersicht. Dabei ist fail2ban im Prinzip auch nur reine Obscurity. Wenn du eine Sicherheitslücke hast, dann kommen die beim ersten Versuch rein bzw. holen sich einfach eine neue IP, das ist ja kein Problem. Aber das ist halt "kulturell akzeptierte" Obscurity wogegen die Leute Hautausschlag bekommen wenn du nur anfängst, was von geändertem SSH-Port zu faseln.
-
Bodenhaltung: Auch mal ganz rausgegangen aus dem SCP? Bei mir war das zuerst auch so, neu eingeloggt und siehe da, Server war seit zig Minuten on aber hat den Bootvorgang einfach aus anderen Gründen nicht geschafft (verhauenes Kernelupdate).
Auf meinem vServer funktioniert Spectre dann immer noch (gibts keinen Patch für) und Meltdown funktioniert, wenn vServer mit altem Kernel läuft bzw. der Kernel mit nopti gestartet wurde. Ich hatte ja gehofft, es würde reichen, wenn der Host das erledigt, aber scheinbar reicht das nicht (bei vServer mit dediziertem Core) und der Bug ist dann - zumindest innerhalb der VM - noch aktiv? Blickt da noch jemand durch...
iLion: journalctl --since="1 day ago" ?
