Beiträge von tab

Muss ich mir mal genauer anschauen im Sourcecode. Ich vermute aber, dass sich dadurch hinter den Kulissen nicht viel verändert hat. Außer, dass mit Werten über 100 es jetzt auch möglich ist das Auslagern von Pages aus dem RAM in den Swapspace gegenüber dem manchmal notwendigen Schreiben von gecacheten Dateien zurück auf die Platte/SSD sogar zu bevorzugen, was mit Werten bis 100 davor nicht möglich war. Man ist also lediglich flexibler geworden durch die Änderung. Der Defaultwert von 60 (und alle anderen Werte <=100) bewirkt nach dieser Änderung also das selbe wie davor. Also 60 bleibt 60 und 10 bleibt 10 .

Zitat von Olivetti

krasse anleitung.

btw. swappiness geht ja mittlerweile sogar bis 11 äh 200.

Ja, habe ich da auch gelesen und jetzt mal an einem Server verifiziert. Auf 190 konnte ich es setzen (mittels sudo sysctl vm.swappiness=190), bei 210 hat er gemeckert. Wie lange ist das schon so? Die allermeisten, auch relativ neue Anleitungen im Netz gehen vom Maximalwert 100 aus.

Da der Server (4C,8GB, Debian 11) eh ziemlich gelangweilt ist derzeit, obwohl ich ihm zum Test noch eine meiner Nextclouds zusätzlich "aufgebürdet" habe, haben Werte von 10,60 und 190 (natürlich) absolut gar keinen Unterschied gemacht. Im Swapfile finden sich irgendwelche 227 MB und die sind schon Tagen da drin ohne Änderung. Auch der Wert von 10 hat nicht dazu geführt, dass die wieder ins RAM geladen wurden. Ebensowenig wurde mehr ausgelagert mit dem Wert 190. Es gab eben keine Veranlassung, irgendwas auszulagern und offenbar wurden die irgendwann ausgelagerten Pages seit Tagen nicht gebraucht. Um dem Ding mal etwas zusätzliche Auslastung zu geben, habe ich dann noch YABS laufen lassen, mit dem (erwartungsgemäßen) Ergebnis, dass der Swap auch hier unverändert blieb und der Geekbench 6 Test (etwas überraschend) sogar nochmal etwas besser ausfiel als im Auslieferzustand vom 25.06., damals 1248/3935, heute 1457/4665.

Insgesamt also: Wenn nichts geswappt werden muss, dann wird auch nichts geswappt, offenbar egal welcher Wert von vm.swappiness eingestellt ist. Insofern, wenn genug RAM vorhanden ist, dann ist es völlig egal, was da eingestellt ist. Was ja auch genau so sein sollte und deshalb keine große Überraschung ist. Und wenn nicht genug RAM vorhanden ist, dann wird man mit dem Swap auf Dauer nichts retten können, höchstens ein paar kurzzeitige Spitzen etwas abfedern. Hier mag dann das System, je nach eingestelltem Wert und Art der Überlastung, besser oder schlechter auf die Überlastung reagieren.

Zitat von aRaphael

Es gab Aktionsserver mit 48 GB

Ja, ich hatte mal einen. Der war gedacht als Web- und Mailserver, als Angebot für Kunden, deren aktuelle Webspaces nicht für ihre Websites geeignet waren. Davon bin ich aber bald wieder abgekommen und deswegen habe ich mich von dem Ding auch getrennt. Hat immerhin jenseits von 30€ gelegen vom monatlichen Preis her und war für alle meine anderen Zwecke hoffnungslos überdimensioniert. War aber auch noch die Vorgängergeneration und so hatte er "nur" 8 Cores. War damals aber ein sehr interessantes Angebot. Seit damals habe ich auch kein vergleichbares Angebot mehr gesehen.

Wie hast du es denn beim ersten Versuch gemacht? Hat es überhaupt schon mal funktioniert`?

Zitat von erik

Vielen Dank für die Tipps, konnte nun die Swapfile deaktivieren. Hat jemand nen Tipp/Link, wie ich die Swapfile dann richtig anlegen kann, dass so ein Fehler nicht nochmal auftritt?

Z.B. hier: Swap space anlegen. Ich weiss nicht, welche Distribution und Version du installiert hast, aber dort gibt es Anleitungen für verschiedene Distributionen. Und die Swappiness-Einstellung wird auch konform mit gängiger Meinung einfach mal vorsichtshalber auf 10 gesetzt .

Zitat von H6G

Raumpatrouille Orion bitte

Das waren doch die mit dem Bügeleisen und den tollen Tänzen.

Zitat von iKameo

Da wird mir ganz übel wenn ich mir nur die Stromkosten vorstelle

Das düfte bei den Borg ja nicht das große Problem sein. Wer so einen Borg-Kubus betreiben kann, der kann da auch nebenher noch den Strom für so einen Unikomplex oder auch für die Weihnachtsbeleuchtung eines mittleren deutschen Landkreises abzweigen.

Zitat von aRaphael

Hattest du da auch die swappiness runtergeschraubt, oder bei 60% belassen? (s.o.)

Für ein Desktop-Linux mag dieser Standardwert ja noch OK sein, aber für einen Server ist er m.E. viel zu hoch. 10-20% langen da völlig.

Ein Server muss eigentlich nur dann auslagern, wenn es unumgänglich ist.

Die Swappiness beeinflusst nicht, wann der Server auslagert, sondern nur was er bevorzugt auslagert. Also "anonymous" pages vs filecache pages. Anonymous sind z.B. Daten, die von Programmen erzeugt und im RAM gespeichert werden.

Und da gibt es - je nach Verwendungsart eines Servers - durchaus auch Fälle, wo du mit einem Wert von 100 eventuell besser fährst als mit 10. Wenn z.B. viele IO-lastige Anwendungen laufen oder wenn irgendwelche Hintergrundprozesse laufen, die eigentlich gerade gar nicht gebraucht werden.

Hier ist es ganz gut erklärt.

Apropos 1GB RAM. Bei einem OS/2 Warp PC, der eine Fertigungsanlage steuern und nebenbei Messdaten per TCP/IP empfangen, auswerten, anzeigen, speichern und an einen Oracle-Datenbankserver übertragen musste, habe ich den Swap deaktiviert, nachdem der Kunde mir für eine weitere Linie einen PC mit 128MB RAM hingestellt hat. Die Teile haben schon mit 32 MB RAM nicht mehr geswappt. Naja, sonst wäre er für die Aufgabe auch nicht tauglich gewesen. Und selbst diese, aus heutiger Sicht lahme, alte Kiste, hätte sich mit der Erfassung von so ein paar Daten alle 5 Minuten sicher zu Tode gelangweilt.

Zitat von olg

Die anderen SSL Zertifikate kosten leider zu viel Geld. Daher wäre auch ein Tausch alle 90 Tage in Ordnung, wenn es denn möglich wäre..(?)

Es gibt auch LE-Zertifikate, die nur für die Domain oder Subdomain selbst und eventuell die www Subdomain gelten. Da funktioniert die automatische Erneuerung und die kosten ebenfalls nichts. Der einzige Nachteil, so ein Zertifikat muss für jede Subdomain einzeln eingerichtet werden. Beim Wildcard-Zertifikat (Domain und alle Subdomains) funktioniert die automatische Erneuerung nicht.

Falls du doch lieber das Wildcard-Zertifikat pro Domain nutzen willst, musst du eben den DNS-Eintrag bei der Domain zur Erneuerung jedes Mal manuell erstellen/ändern. Die DNS-Einträge einer Domain bearbeiten kannst du direkt im CCP unter "Domains" im Tab "DNS".

Zitat von RAD750

Peinlich für die. Cron ist doch standardmäßig mit Debian dabei, oder nicht?

Zumal andere Pakete installiert sind, die cron als Abhängigkeit haben.

Der Service-Weltmeister braucht halt auch Supportanfragen, damit er glänzen kann

Lasse auch gerade Debian 12 installieren, schaun mer mal.

Edit: So, ich schaue mir gerade mal das installierte Debian 12 Image an. Das ist schon ziemlich unterschiedlich zum Debian 11 von den installierten Paketen her. Bei 11 war chrony installiert, bei 12 nicht. Bei 11 war auch kein systemd-resolved, bei 12 schon. Würfeln die das aus, was ins Image mit reinkommt?

Zitat von Bud

Ich habe meinen VC1-1 nun nochmal platt gemacht, und es unter Debian 11 probiert und es hat auf Anhieb geklappt.

Es liegt tatsächlich am Debian 12 Image von Strota. Mich würde nur brennend interessieren, warum.

Denn an und für sich würde ich schon sehr gerne Debian 12 verwenden.

Hmm, geht mir genauso. Man weiss natürlich bei solchen Images nie, welche Änderungen gegenüber älteren Versionen da vom Hoster eingebaut wurden. Macht eigentlich die Defaulteinstellung Sinn, dass die Kiste alle paar Minuten mit dem DHCP-Server telefoniert? Muss da die IP irgendwie reserviert werden oder was soll das. Dass der DHCP-Server plötzlich eine andere IP zuweist wird ja wohl hoffentlich nicht passieren Sonst hat mein Mailserver ein Problem . Insofern sollte man die doch auch einfach statisch eintragen können wie hier bei netcup!? Oder bietet das DHCP sonst noch irgendwelche Vorteile, außer dass unnötig Traffic erzeugt und CPU-Zeit abgezwackt wird?

Hmm, das muss dann aber ein Munin-Ding sein und ist ggf bestimmt irgendwie konfigurierbar. Viele Server haben kein (öffentliches) IPv6, auch heute noch. Mein Mailserver ist ja auch vom gleichen Anbieter. Und da sieht Apache2 auch so aus:

root@mail:~# netstat -tulpen | grep apache2
tcp6       0      0 :::80                   :::*                    LISTEN      0          17447      779/apache2
tcp6       0      0 :::443                  :::*                    LISTEN      0          17451      779/apache2

Und das, obwohl er keine öffentliche IPv6-Adresse hat und somit von aussen nur per IPv4 zugegriffen werden kann. Und er funktioniert trotzdem. Address mapping?

Edit: Scheint ja schon gelöst zu sein, wie vermutet durch Konfiguration von Munin.

Liesse sich ja recht einfach testen, indem man eine index.html da reinlegt mit den passenden Rechten. Eine andere Möglichkeit wäre natürlich, dass Munin die Dateien wohl schreiben will, aber wegen fehlenden Rechten nicht kann. Das sollte sich dann aber auch in einer Logdatei finden lassen. Seh schon, die (funktionierende!) Keyhelp-Installation wird den heutigen Tag vermutlich nicht überleben. Wollte eigentlich auch Plesk noch ausprobieren, wenn man schon eine Lizenz dazubekommt. Die hat wohl mehr Beschränkungen als Keyhelp, aber auch Vorteile.

Zitat von aRaphael

Jetzt bin ich neugierig geworden. Ich probiere das jetzt auch mal aus.

Ich wollte so einen Mini-vserver bei denen sowieso schon immer mal antesteten. Da ist das eine gute Gelegenheit.

Ja, mach mal. Das Serverchen habe ich schon eine ganze Weile, aber erst mal andere Anwendungen damit getestet. Geholt habe ich es mir aber auch für einen Munin-Server oder, falls mir Munin nicht gefallen sollte, eben für ein anderes Monitoring.

Im Prinzip müssen da halt die selben Records rein wie jetzt bei deinem Noch-Hoster. Dann sollte auch alles weiterhin funktionieren. Das mit MX, SPF und DKIM ist eh klar.

Zitat von Borgqueen

Dann habe ich aktuell einen Denkfehler. Aktueller Stand bei mir zwecks Munin:

• Auf meinem Server sind munin-node & munin munin-node installiert (Port ist freigeschaltet) und läuft.
• Auf einem weiteren Server ist nur munin-node installiert (Port ist freigeschaltet)
  

Der Web-Output wird aber nur vom Server erzeugt, die Clients werden anhand IP und Port abgefragt und brauchen keinen vHost.

Die Probleme sind ja hier im Forum seit langem bekannt, auch netcup kennt sie natürlich und arbeitet daran, wie [netcup] Lars S. ja beim letzten Community Event mitgeteilt hat. Da das Problem nun doch schon eine ganze Weile besteht und immer noch aktuell ist, stellt sich mir die Frage, ob man da in irgendeiner Form zur Ursachenfindung beitragen kann. Sollen wir alle gefundenen Domains mit "kaputtem" DNSSEC an den Support melden, damit ihr euch die Details anschauen könnt? Dann aktiviere ich das mal auf allen unbenutzten und unwichtigen Domains. Oder habt ihr selbst schon genügend Datenmaterial?

Auf Dauer ist das jedenfalls ein unhaltbarer Zustand, ein vorhandenes Feature, was man aber mit den netcup Nameservern besser nicht benutzen sollte, wenn einem die Auflösbarkeit seiner Domains wichtig ist. Ok, das Problem mag erst ab einer gewissen Größenordnung registrierter und verwalteter Domains auftreten und bei vielen anderen Domainhostern ist DNSSEC gar nicht erst verfügbar. Aber das macht es ja für Kunden, die sich des Problems nicht bewusst sind - und das dürften die meisten sein, um keinen Deut besser.

Edit: So, habe jetzt bei einer de-Inklusivdomain mit Defaulteinstellungen fü das Webhosting DNSSEC aktiviert und Verisign ist erst mal zufrieden. Schaun mer mal wie lang ... DNSViz bringt den üblichen "Fehler" mit der zu langen TTL des RRSets NSEC3PARAM (86400 länger als die TTL des RRSIG-RR (0)). Das scheint aber mittlerweile so gehandhabt zu werden entgegen den Empfehlungen des RFC und auch Sinn zu machen. Unbound stört sich daran auch nicht.

Also die Netcup DNS-Server für Kundendomains sind das schon mal nicht. Das wären normalerweise

third-dns.netcup.net.
second-dns.netcup.net.
root-dns.netcup.net.

Ob es eine Möglichkeit gibt, schon vor dem Umzug DNS-Einträge für eine Domain zu machen - die ja dann noch gar nicht be netcup registriert ist - weiss ich nicht. Habe ich noch nicht probiert. Eventuell wenn man den AUTH-Code nicht gleich beim Umzug eingibt, sondern erst später. Wo liegen denn die Postfächer für die Domain? Sollen die auch vom dänischen Provider zu netcup umziehen oder liegen die ganz woanders und sollen auch da bleiben? Werden sich die MX Einträge im DNS also ändern beim Umzug oder bleiben sie gleich?

Für alles, was nicht megakritisch ist, würde ich einfach die Domain umziehen. Falls das erfolgreich ist, gleich die Postfächer einrichten. Dann sind die neuen Postfächer möglicherweise ein paar Stunden nicht erreichbar, aber ein normaler Mailserver wird noch eine ganze Weile versuchen, die Mail zuzustellen, die während dieser Zeit gesendet wurden. Es gehen also in der Regel keine "normalen" eingehenden Mails verloren, sie werden nur erst später zugestellt. Wenn das eine Inklusivdomain eines Webhostings wird, dann werdendie für netcup passenden DNS-Einträge beim Umzug automatisch gesetzt. Ebenso, wenn es eine zusätzliche Domain wird. Dann werden die Einträge bei der Zuordnung zu einem Webhosting passend gesetzt.

Zitat von CUPPY1089

Habe eine bessere Idee: Ich ändere kurz die MX Einträge zu Netcup, werfe die E-Mail ins Netz und dann können wieder beide Autoresponder Ping-Pong spielen - dann hast du mehr als ich davon, wenn ich wieder zu Apple gewechselt habe!

Ich hab davon rein gar nichts, weder positiv noch negativ. Meine Mail ist woanders zuhause. Mit Ausnahme von einigen Testaccounts. Tu, was du nicht lassen kannst. Am Ende sitzt netcup sowieso am deutlich längeren Hebel. Wenn so ein Ping Pong öfter vorkommt, dann werden sie schon entsprechend reagieren und das Pong stoppen .