Beiträge von Paul

Zitat von mustafa

Danke für die Tipps - und willkommen in der Realität könnte man sagen:-). An die Möglichkeit, den Server per VPN zu verwalten, hatte ich noch gar nicht gedacht. Guter Hinweis.Danke dafür...

Wobei der VPN Zugriff ebenfalls ein Angriffspunkt darstellt. Im Grunde verlagerst du die Angriffe nur auf einen anderen Dienst (ok, vermutlich gehen die Botnetze eher auf SSH als auf VPN, aber die Grundproblematik bleibt ja die gleiche). Du vertraust dann einfach nur einer anderen Software. Wobei ein aktuelles OpenSSH schon relativ robust und stabil läuft. Wenn da nicht zufällig die Zugangsdaten in falsche Hände geraten ist das aus meiner Sicht nicht unsicherer als ein VPN. Fail2Ban ist da schon sehr hilfreich. Man konzentriert sich manchmal so sehr auf die eigentlich schon stabilen und zuverlässigen Punkte, dass man meist das Offensichtliche außer Acht lässt wie z.B. veraltete PHP Applikationen, Ruby on Rails, Java, ... Je nachdem, was der Server macht, ist SSH in der Regel dein kleinstes Problem Das nur nochmal so als Hinweis in den Raum geworfen.

Zitat von H6G

Ich tippe eher auf G9 Server mit AMD Epyc CPUs oder dem neuen Abrechnungssystem.

Wobei es natürlich zu dem Start einer neuen Generation oft auch interessante Aktionsangebote gibt. Das eine schließt das andere ja nicht aus

Zitat von Kraeutergarten

Welchen Linux Desktop verwendet ihr aktuell so? Hab mir einen NUC gekauft, überlege aktuell was da drauf soll.

Fedora 30 + Gnome-Shell

Wäre es nicht sinnvoller eine Software zu nehmen, mit der man sich auch auskennt? Muss es denn Joomla sein? Wenn ja ->

https://docs.joomla.org/Tutorials:Beginners/de

Habe heute erst einen Server mit einem OpenSuse Leap 15.1 Image installiert. Gecrashed ist da nichts. Läuft alles einwandfrei. Wenn dann ist es wohl ein spezielles Problem mit Ubuntu. Schau doch mal in die Logs, was du da so findest.

Das ist schon korrekt so. Im Grunde sind es SAS Festplatten mit einem Optane Cache. Das führt zu einer gefühlten "SSD Performance". Ist halt viel Marketing in der Beschreibung. Aber grundsätzlich falsch ist es nicht :-).

Zitat von Ecki

fällt mir leider gerade echt schwer den zu brauchen.

So ein Mist

Geht mir aber gerade genauso Irgendwie will mir kein vernünftiger Anwendungszweck einfallen. Als Storage Server ist er zu klein. Als "normaler" Server zu überdimensioniert. Da sind die normalen SSDs vorteilhafter.

Zitat von LuMaXx

Wieso denn nicht? Hatte noch nie Probleme gehabt mit.

Bis jetzt

Achtung, ein E-Mail Provider per se fällt nicht unter das Telekommunikationsgesetz. Siehe dazu auch das kürzlich gefällte Urteil zu Gmail: https://www.heise.de/newsticke…gle-vor-EuGH-4445723.html

Zitat von v.homic

Hier ein Screenshot meiner derzeitigen Konfiguration, die aber nicht funktioniert (habe schon einen Tag gewartet):

Hatte den letzten Teil beim ersten Durchlesen wohl übersehen. Kannst du mal im Whois nachschauen, welche Nameserver dort erscheinen (du kannst die Domain ansonsten auch gerne mal per PN mitteilen, dann schaue ich gerne selbst nach). Ich hatte bei Netcup auch schon ein paar Mal das Problem, dass Nameserver Änderungen zwar im CCP gespeichert, aber nie wirklich geändert wurden. In der Regel hilft es, wenn man dann nochmal auf "Nameserver speichern" klickt. Vielleicht hängt da im Hintergrund nur irgendwo ein Skript. Wenn das nach 24h dann weiterhin nicht funktionieren sollte, würde ich mal den Support kontaktieren. Denn dann stimmt da irgendwas nicht.

Es reichen die FQDNs. Die Felder für die IP Adressen kannst du einfach leer lassen. Das ist gar kein Problem.

Enpass + Webdav nutze ich sehr gerne. An Bitwarden stört mich persönlich der "Cloud-Zwang". Man kann den Password Manager nicht nutzen, wenn man ihn nicht an einen Webservice anbindet. Selbst wenn es ein eigener Server sein sollte. Password Manager sollten meiner Meinung nach für den Offline Gebrauch konzipiert werden und nur optional eine Synchronisation anbieten.

Schau dir vorher unbedingt mal deine "/etc/fstab" und vielleicht auch die "/etc/default/grub" an, wie dort die Block Devices angesprochen werden. Wenn du dort etwas wie "/dev/vdaX" siehst, müsstest du das in /dev/sdaX ändern, sonst wird dein System nach dem Neustart nicht mehr booten (Im Falle der grub config bitte nicht vergessen, die grub.cfg neu erstellen zu lassen). Das dürfte wohl der größte Stolperstein werden.

Ansonsten viel Erfolg beim Upgrade! Der Wechsel von upstart auf systemd wird sicherlich auch nicht ganz trivial sein. Daher könnte man durchaus überlegen, ob man nicht zunächst das Upgrade auf 16.04 durchführt und dann erst auf 18.04 wechselt. Aber das musst du entscheiden.

Achja, stelle den Festplattentreiber am besten vor(!) dem Upgrade um und überprüfe, dass das System wieder sauber startet

Zitat von killerbees19

Mehr Aufwand als mit Stable hat man natürlich schon. Aber dafür vermeidet man eventuell, dass schwere Bugs in Stable landen. Wenn man nur lauter Testinstallationen hat, bemerkt man echte Fehler oftmals erst viel zu spät.

Meinst du das vielleicht genau umgekehrt? Gerade wenn man "up to date" bleibt, merkt man Fehler ja meist recht früh. Bei einem größeren "stable" Upgrade übersieht man diese doch aufgrund der vielen Änderungen meist eher.

Zitat von fisi

Hat von euch jemand Erfahrungen mit OpenShift gesammelt? Ich bin auf der Suche nach einer Verwaltung für Docker mit Kubernetes.

Ja. OpenShift ist aber ein RedHat Alleingang. Das nutzt niemand außerhalb einer gewachsenen RedHat Umgebung. Die kommerzielle Version ist extem teuer, selbst im Unternehmens-Umfeld (ab $50.000). Es gibt zwar auch die Community Edition "okd", die ist aber recht unangenehm in der Installation und der Wartung.

Die deutlich bessere Alternative: Rancher.

Zitat von Gunah

Bei mir musste ich so vorgehen.

Server stoppen - (per ~# shutdown -h now).

Optimierung gestartet - Server wurde wieder gestartet danach.

und gleiche spiel nochmal, danach war es weg.

Beim ersten Server bin ich auch so vorgegangen. Bei den weiteren habe ich dann bewusst den Server offline gelassen, die Medien Seite so oft aktualisiert bis die Meldung bzgl. der Speicheroptimierung wieder erschien und erst dann den Server wieder gestartet (da ich ja dann wusste, dass das zwei mal gemacht werden musste). So konnte ich z.B. vermeiden, dass meine k8s Nodes unnötig Stress im Cluster verursachen, weil sie wieder "joinen" und anschließend doch wieder heruntergefahren werden mussten.

Für was wird der Server denn eingesetzt? GNU/Linux ist keine Option? Erspart einem eine Menge Ärger, wenn ich mir die Erfahrungen mit Windows Servern hier im Forum so durchlese

Zitat von douzer

Ich hab die Optimierung am WE durchgeführt, die Meldung blieb jedoch im SCP.

Vermutlich musst du das zwei mal durchführen. Das war zumindest bei mir der Fall. Erst war eine "normale" Speicheroptimierung nötig und dann nochmal eine intensive Speicheroptimierung (wie vom TO erwähnt). Das war sehr verwirrend, weil der Server zwischenzeitlich wieder lief und dann nochmal heruntergefahren werden musste. Hier hätte ich wirklich ein paar Informationen mehr gewünscht, was da technisch genau passiert.

Zitat von Julian137

Leider nennt Microsoft keine genaueren Gründe. Somit weiss ich nicht, gegen welche Richtlinien von Microsoft verstoßen wird.

Habt Ihr mir einen Tipp?

Es ist halt leider so wie es ist. Dieses Problem hatten wir hier wohl alle schon mal oder teilweise auch immer noch. Den einzigen Tipp, den ich vielleicht noch geben kann: Hartnäckig bleiben und es immer wieder mal versuchen. Irgendwann hat man vielleicht mal Glück und die Sperre wird aufgehoben.

Das eigentlich Frustrierende an der Sache ist ja, dass man selbst meist gar nichts dafür kann. In den meisten Fällen war es vielleicht einfach ein anderer Kunde im gleichen Netcup Subnetzwerk, der Spam versendet hat. Dann wird man selbst direkt mitgesperrt.

Man könnte jetzt natürlich den Server wechseln und hoffen, dass die neue IP (noch) nicht gesperrt wurde. Aber auch die neue IP könnte irgendwann gesperrt werden. Vielleicht früher, vielleicht später. Es bleibt ein Glücksspiel.

Hast du dich schon im SNDS angemeldet?

Zitat von A:H

Bitte vergesst nicht, dass obwohl php7.0 out of service ist seitens Debian noch immer Sicherheits-Updates ausgeliefert werden sollten solange die Distribution bzw. Version supported wird.

lg.

Also zumindest in der Theorie. Wie das in der Praxis aussieht, ist eine andere Geschichte. Security Bugs müssen in der alten Version erst einmal erkannt werden und dann muss ein funktionierender(!) Backport erstellt werden. Bei kommerziellen Distributionen wie SUSE oder RHEL kann ich mir das noch einigermaßen vorstellen. Da sitzen Leute, die werden genau dafür bezahlt. Aber gerade bei einer Community Distribution wie Debian habe ich da ein paar Bedenken. Nichts gegen die Entwickler. Die machen einen tollen Job. Aber diese Backport Geschichte von Bugs aus neueren Versionen, die evtl. auch in alten Versionen vorhanden sein können und das entsprechenden selbst zu patchen, ist wahrlich kein schöner Job.

Wenn die Entwickler einer Software sagen, diese Version ist EOL, sollte man das lieber auch so hinnehmen, unabhängig davon, was einem die Distribution verspricht. Mit einer Firma wie RedHat hat man zumindest noch einen Vertrag. Da könnte man zur Not noch jemanden vor Gericht zerren, wenn doch mal was passieren würde. Aber bei Debian ist das etwas anderes.

Generell besser keine Software einsetzen, die EOL ist. Außer man hat einen Vertrag mit einer Firma, die einem Backports/Sicherheitsupgrades garantiert. Man wiegt sich nur in einer falschen Sicherheit.

Zumindest eine Meldung auf https://www.netcup-status.de/ wäre ganz nett. Betrifft ja doch einige wie es scheint. Bei mir sind es zum Glück nur Testsysteme, aber auch die sind mittlerweile über 15 Stunden down. Da scheint das Problem wohl doch etwas größer zu sein oder man hat Schwierigkeiten die eigentliche Fehlerursache zu finden.

Aber die Netcup Mitarbeiter sind da sicherlich dran. Das wird schon