Beiträge von indigo

Als die Version 8.1.1 raus kam, hatte ich mal auf einem Testserver das Upgrade probiert und dabei kam auch der cURL Fehler, ein paar Tage später lief das Upgrade dann problemlos durch. Es scheint 3 Versionen von OC 8.1.1 zu geben, die neueste 8.1.1.3 hat einige Probleme behoben. Eventuell wird ja bei der Installation übers Webhostingpanel die erste Version 8.1.1.1 installiert, während bei einem Upgrade von 8.1.0 automatisch auf 8.1.1.3 aktualisiert wird. Am einfachsten findet man das raus indem man im Owncloudverzeichnis in die Datei version.php schaut. Da steht genau drin, welche Version gerade installiert ist...

Als Update zu diesem Thread: Das heute Nacht von Ubuntu verteilte Kernelupdate (3.13.0-46.76 auf 3.13.0-46.77) sollte man nicht einspielen. IPv6 funktioniert nach dem Update zunächst nicht, wodurch dann z.B. der nginx Webserver nicht auf die fest konfigurierte IPv6 Adresse binden kann und nicht mal mehr unter IPv4 erreichbar ist. Nach einigem Minuten erholt sich IPv6 zwar dann aber falls man kein monit oder ähnliches installiert hat, muss man den Webserver danach manuell neu starten, um das Problem zu beheben.

Außerdem gibt es vorher nicht dagewesene Fehler im kern.log die nicht sehr vertrauenserweckend sind. Zumindest in anderen Threads zu der auftretenden Fehlermeldung wurde berichtet, dass danach das System ganz eingefroren sei, was bei mir noch nicht passiert ist. Die fast täglichen Kernelupdates für Ubuntu 14.04 im Moment sprechen nicht wirklich dafür, dass die Kernels ausreichend getestet werden und das bei einem LTS Release das eigentlich stabil sein sollte...

Hallo,

gestern wurde von Qualys auf die GHOST Schwachstelle hingewiesen, die es angeblich ermöglicht über einen Bug in der glibc den Server von außen zu übernehmen, selbst wenn der Angreifer über keine Zugangsdaten verfügt (Laut Qualys reicht es aus eine Email mit speziellem Inhalt an den Server zu schicken, um darüber Shellzugang zu erhalten und Schadsoftware auszuführen). Betroffen sind:

* Ubuntu 10.04/12.04
* Debian 7
* CentOS 6 and 7 (potentially 5 as well)
* SLES 11

Für alle genannten Distributionen wurden heute Nacht Security Updates verteilt, die man dringend installieren sollte. Worüber ich mich dabei aber etwas wundere ist, dass angeblich danach ein Serverneustart notwendig sein soll...

Weitere Infos gibt es hier:

The Laws of Vulnerabilities: The GHOST Vulnerab... | Qualys Community

Mit diesem Code kann man überprüfen ob der eigene Server schon gepatcht ist:

http://i.yt.gl/get/44ecc/pseet.zip

Allerdings halte ich diese Überprüfung nicht für erforderlich, wenn man die verteilten Patches installiert. Mein Debian 7 wird zumindest auch ohne Neustart nach eingespieltem Patch als "not vulerable" angezeigt, von daher die Frage:

Weiß jemand irgendwas genaueres dazu, wieso unbedingt ein Serverneustart erforderlich ist?

Hallo,

ich verwende auf einem meiner Server das Ubuntu 14.04 64bit Image. Für ein paar Monate lief es auch zuverlässig aber mit dem Kernelupdate auf 3.13.0-37 im Oktober kamen dann einige Probleme. Das Syslog war mit Kernel-Fehlermeldungen zugespamt und ich bin auch in anderen Foren dazu fündig geworden, dass dieser Kernel in Kombination mit KVM-Virtualisierung Probleme macht. Deshalb bin ich dann auf den 3.13.0-36 Kernel zurückgegangen und da bin ich bis heute noch, denn selbst im 3.13.0-40 Kernel waren die Probleme noch vorhanden. Inzwischen ist der 3.13.0-43 Kernel seit einem Monat draußen und bevor ich wieder mit dem Experimentieren anfange, wollte ich nur mal hören, ob jemand den aktuellen Ubuntu 3.13.0-43 Kernel installiert hat und ob er zuverlässig läuft.

Danke für ein kurzes Feedback

Nach einem Reboot sind beide Server aus dem Internet aus über IPv6 erreichbar und ich kann auch beliebige IPv6 Systeme im Internet anpingen. Wenn dann der Ausfall Eintritt, sind sie weder von außen erreichbar, noch kann ich von inner her mit ping6 irgendwelche Server im Internet erreichen. Bei einem Ausfall sind auch die beiden Netcup Systeme untereinander nicht anpingbar.

Sowohl meine Ipv4 als auch meine ipv6 config stehen auf static aber wie gesagt, das Problem ist ja nicht, dass Ipv6 gar nicht geht, es geht ja, nur eben stets nur für unbestimmte Zeit und dann gehts eben nicht mehr und das ist unbefriedigend, gerade weil einer der beiden Server als Nameserver läuft und der muss zuverlässig erreichbar sein aber das ist er leider nur über IPv4...

Hallo,

ich habe Dein Posting zu IPv6 gelesen und da es keine weiteren Updates dazu gab, würde mich interessieren, ob es eine Lösung für das Problem gibt. Ich stehe nämlich vor dem gleichen Problem: Ebenfalls Netcup Server mit Ubuntu 14.04 allerdings auch einen mit Debian Wheezy. Bei beiden geht IPv6 erst mal problemlos nach einem Reboot, manchmal ein paar Stunden, manchmal ein paar Tage aber dann geht ohne identifizierbaren Grund auf einmal keine IPv6 Verbindung mehr. Ein Reboot schafft dann zwar Abhilfe, aber ich kann nicht alle paar Tage oder Stunden die Server neu booten.

Konfigurationsdateien sehen genauso aus wie im Netcup-Wiki beschrieben und da die Verbindung ja erst mal ne Weile lang geht, sollte da eigentlich alles stimmen...Ip6tables habe ich für meine Tests mal alle auf ALLOW gesetzt, um sicher zu sein, dass das Problem nicht daher kommt, aber die Ursache muss wo anders liegen...nur wo?

Ich habe mir für diese Installationskombination vor ner Weile ein Installationskript geschrieben, das auch gleich noch mysql, alle für postfixadmin notwendigen Datenbanken und einen ersten Nutzer anlegt, damit man sich direkt in Roundcube einloggen kann, um die Installation zu testen.

Du kannst mit den Skript auch gleichzeitig alle üblichen Server-Absicherungen durchführen, wie die Verschiebung des ssh ports oder die Konfiguration einer iptables Firewall. Weitere damit installierbare Komponenten sind OpenVPN, Munin, Monit oder auch neben Apache2 alternativ ein Lighttpd oder ein Nginx Webserver. Nachdem Du die relativ einfache Konfigurationsdatei des Skripts angepasst hast, hast Du knapp 15 Minuten später einen komplett lauffähigen und abgesicherten Wheezy Server...

Falls Du das Skript nehmen möchtest, schreib einfach ne kurze PM, dann schicke ich Dir einen Link wo Du es downloaden kannst. Ich hab es selbst entwickelt, aber will es nicht so direkt irgendwo posten. Ist eben nur ein kleines privates Bastelprojekt, das aber soweit sehr zuverlässig funktioniert hat.

Gruß
Oliver

Hi Moritz,

falls Du kein System wie Froxlor verwenden willst und Du nach einem Snapshot sowieso den alten Stand gesichert hast, kann ich Dir gerne mal mein selbst geschriebenes Installationsskript zukommen lassen. Es kann Dir nicht nur nginx, php, mysql und postfix installieren sondern es konfiguriert Dir auch alles so, dass alles problemlos zusammenspielt.

Zusätzlich übernimmt das Skript alle üblichen Absicherungen wie die Verschiebung des ssh ports, Einrichten eines non-root Nutzers, die Änderung der Passwörter oder die Konfiguration einer iptables Firewall und es kann außerdem noch Vsftpd, OpenVPN, Munin, Monit und eine Reihe anderer sinnvoller Sachen installieren und konfigurieren, so dass Du nach der Anpassung der Konfigurationsdatei des Skripts in etwa 15 Minuten einen voll lauffähigen Server hast.

Kannst das Skript gerne ausprobieren, wenn Du willst. Ich habe das nur für mich selbst geschrieben aber bisher noch nicht ins Internet gestellt, da ich davor noch einige Sachen optimieren müsste, aber dafür hab ich im Moment nicht die Zeit...

Wenn Du es damit ausprobieren willst, schreib einfach nur kurze PM, dann schicke ich Dir einen Link wo Du es downloaden kannst.

Gruß
Oliver

An dieser Stelle noch ein kurzes Feedback um das Thema zum Abschluss zu bringen. Der Support hatte das Hostsystem auf dem mein Vserver läuft nach meiner Frage zu den Latenzzeiten am 30.12. abends kurzfristig für ein paar Minuten runtergefahren, um etwas umzukonfigurieren. Daraufhin waren zumindest die Lesezugriffe auf einen Mittelwert von 1ms gesunken, die Schreibzugriffe blieben aber bei einem Mittelwert von 100ms. So konnte man auf jeden Fall aber erst mal sinnvoll arbeiten.

Heute wurde dann eine weitere Optimierung durchgeführt und seit dem liegt die Verzögerung sowohl für Lese- als auch Schreibzugriffe unter 1ms.

Das Problem ist somit gelöst

Hallo,

danke fürs Antworten, also ich habe gerade nochmal auf die Verlaufskurve im Munin geschaut und die disk latency ist dauerhaft auf hohem Niveau, wenn auch etwas niedriger als in den ersten 2 Stunden, wo ich viel Installationsarbeit durchgeführt habe. Im Mittel über die letzten 36 Stunden liegt der Wert bei 789ms, das ist also fast eine Sekunde und kann so nicht normal sein. Gerade wenn ich z.B. ein Programm wie den GNU Midnight Commander aufrufe, passiert manchmal 4 Sekunden lang überhaupt nichts, nachdem ich mc eingegeben habe. Er muss halt sowohl für das Programm als auch dann nochmal für die Verzeichnislistings auf die Festplatte zugreifen und solange beides nicht erledigt ist, hängt er im IO Wait und macht gar nix. Wie lange es dauert ist verschieden, aber man sieht im Muninplot das der Wert schon häufig über der 1sec Linie liegt mit einigen Peaks bei 4 und 5 Sekunden.

Es geht mir aber weniger um Peaks als um den Langzeitmittelwert, dass es mal länger dauert, weil viele parallel auf die Festplatte zugreifen ist unvermeidlich, aber dass es immer so lange dauert, da kann was nicht stimmen. Ich hab mir nochmal die Plots meines anderen KVM Servers angeschaut, und da liegt der Mittelwert über die letzten 30 Tage bei 2.72ms mit einem einzelnen Peak bei 1.69 sonst sind die Peaks bei 100-400ms

Hast Du Deine Latenzzeiten mal konkret gemessen, speziell was den Mittelwert angeht ?

Naja ich werde am Montag mal beim Support nachfragen, da ich den Vserer ja erst am Freitag abend aufgesetzt habe, wollte ich so lange mal hier im Forum nachhören, ob das anderen schon mal aufgefallen ist...

Dass Defragmentieren etwas bringt, glaube ich kaum, die Partition wurde ja erst vor 2 Tagen angelegt...

Alles Gute
Oliver

Hallo Stefan,

nein ein Problem ist es nicht, aber einfacher ist es sich ein bash Script zu schreiben, das einem die iptables anlegt und sie dann mit dem erwähnten iptables-save in die rules.v4 zu schreiben. Wenn man die iptables ändern, editiert man das bash Skript, führt es aus und wenn alle Einträge stimmen speichert mans in rules.v4

Die [0:0] hat wohl keine tiefere Bedeutung, bei mir stehen da bunt gemischte Zahlen drin, die nicht zu Ports oder anderen Dingen passen

[11:719]
[1:140]
[0:0]
[143:9012]
[12:1216]

Habe leider keine Ahnung, wozu die gut sind.

Alles Gute
Oliver

Hi Stefan,

die Datei rules.v4 editiert man grundsätzlich nicht per Hand sondern sie wird automatisch erstellt.

Du stellst erst mal nur per iptables Kommando alle Filter ein, die Du haben willst, wenn Du Dir sicher bist, dass alles gut ist gibst Du

iptables-save > /etc/iptables/rules.v4

ein, dann werden die gegenwärtigen iptables in die Datei rules.v4 übernommen, wodurch sie dann beim neu booten so eingestellt bleiben.

Das vorherige Einstellen übers iptables Kommando hat auch den große Vorteil, dass falls Du Dich beim Rumspielen selber aussperrst, kannst Du den Vserver immer noch neu starten und dann sind die fehlerhaften iptables wieder gelöscht. Wenn sie erstmal in der rules.v4 drin stehen und da Müll drin steht, weil du es per Hand editiert hast, ist das nicht so spaßig...

Alles Gute
Oliver

Hallo,

ich hätte mal eine Frage bezüglich Festplattenlatenzzeiten. Ich habe mir heute einen Root-Server M zugelegt und beim Einrichten ist mir bereits aufgefallen, dass beim Installieren von Paketen der Download sehr schnell abläuft, aber die Einrichtung der Pakete im Vergleich zu anderen Vservern ungewöhnlich langsam war. Ausgelastet war die CPU in diesen Momenten aber auch nicht.

Nachdem ich jetzt mal munin installiert habe, hat munin von sich aus bereits eine hohe disk latency bemängelt. In den letzten 2 Stunden lag laut munin die IO Wait time im Mittel bei 1.21 mit einem Spitzenwert von 13.25 (Das sind Werte in Sekunden nicht Millisekunden) Wenn ich mir diesen Wert bei einem anderen KVM Server anschaue, den ich habe, dann liegt der Wert Mittelwert da bei 2.36ms mit einem Spitzenwert von 194ms, auf einem Xen Server liegt sie im Mittel bei 22.91ms mit einem Spitzenwert von 41.58ms. Ich habe eigentlich nur das Wheezy-Image mit ohne alles aufgespielt und danach nichts ungewöhnliches installiert nur Mailserver, Webserver, etc und die CPU ist trotz der ganzen Installationsaktivitäten bei 82% idle, 8% io/wait und 10% system+user

Mir ist gerade nicht so ganz klar, woran es klemmt, ob es etwas Spezifisches bei meinem Vserver ist oder etwas Generelles. Zumindest ist es schon relativ nervig, wenn man eine kleine 1kb große Datei von einem Verzeichnis der Festplatte in ein anderes kopiert und dabei erstmal 2 Sekunden warten muss, bis die Aktion über die Bühne ist.

Hat jemand etwas ähnliches erlebt und die Ursache dafür gefunden?

Danke für ne kurz Antwort
Oliver