Ich habe nun...
Code# PostgreSQL / Wiki.js host all all 127.0.0.1/32 password...an das Ende meiner /etc/postgresql/15/main/pg_hba.conf hinzugefügt, und mit sudo systemctl restart postgresql neu gestartet. Leider bleibt die Fehlermeldung dieselbe.
Kannst du dich denn "manuell" einloggen über die Console (mit User + Password). Also ein psql -U netcup und anschließender Eingabe des Passworts? Wenn nicht, schau mal in das PostgreSQL Log.
Stichwort: pg_hba.conf
https://www.postgresql.org/docs/current/auth-pg-hba-conf.html
Standardmäßig erlaubt Postgres den Zugriff nur lokal über den Socket und dann auch für jeden lokalen User auf dem System. Du kannst daher folgenden Eintrag in der /etc/postgresql/15/main/pg_hba.conf setzen
host all all 127.0.0.1/32 passwordDas chown hier (chown (GNU coreutils) 8.32 auf opensuse leap 15.4) nimmt den "." klaglos anstelle des ":". Also chown user.group file funktioniert. Ich habe das jahrelang mit "." gemacht, bis mir mal jemand gesagt hat, das sei falsch. Laut manpage ist es auch falsch.
Interessant. Hier auf meinem Fedora funktioniert es, aber ebenfalls nur mit Warnung.
/tmp $ chown paul. test
chown: warning: '.' should be ':': „paul.“Könnte evtl. an der coreutils version liegen. Hier wird auch noch so etwas erwähnt, dass das wohl durchaus mal möglich war: https://www.gnu.org/software/coreu…invocation.html
Some older scripts may still use ‘.’ in place of the ‘:’ separator.
POSIX 1003.1-2001 (see Standards conformance) does not
require support for that, but for backward compatibility GNUchownsupports ‘.’ so long as no ambiguity results,
although it issues a warning and support may be removed in future versions.
New scripts should avoid the use of ‘.’ because it is not
portable, and because it has undesirable results if the entire
owner‘.’group happens to identify a user whose name
contains ‘.’
Auf meinen anderen Muninserver mit Ubuntu 20.04 ist der Fehler aber auch drin.
Die entsprechende Zeile in /etc/init.d/munin sieht so aus:
Codemkdir -p /var/cache/munin/www && chown munin. /var/cache/munin/www && chmod 755 /var/cache/munin/www
Da Ubuntu ja auf Debian basiert und die einfach viele Pakete übernehmen, war das jetzt quasi fast zu erwarten 
Aber erschreckend finde ich, dass das vorher noch niemandem aufgefallen ist. Hat es dafür echt das Netcup Forum gebraucht? "chown munin:" wäre jetzt eine gültige Anweisung gewesen. Gut möglich, dass hier einfach jemand das Shift vergessen hat. Aber fällt sowas nicht auf? Über Jahre nicht? Ehrlich gesagt zweifel ich gerade so ein wenig an der Qualitätssicherung in Debian...
Oder gibt es irgendeine dubiose Funktion in chown, die einen "." erlaubt? Wäre mir zumindest jetzt neu.
Das Problem liegt am Paket in dem Debian Repository: https://packages.debian.org/bookworm/all/munin/download Dort ist es schon so.
Da hat wohl der Maintainer schlampig gearbeitet. Es ist generell etwas unsauber, dass hier immer noch die das alte Init Skript zum Einsatz kommt und man das in Bookworm nicht geschafft hat, ein vernünftiges Systemd Service File mitzuliefern. Man hätte ja z.B. einfach mal bei Fedora nachschauen können wie die das machen. Die bringen sogar einen systemd.timer mit anstelle von Cron.
Da müsste man mal einen Bugreport bei Debian aufmachen und das melden.
Man könnte das auch lokal bei sich temporär anpassen. Allerdings ist die Gefahr groß, dass das beim nächsten Update wieder überschrieben wird.
Und wie sieht es aus, wenn ein Hardware-RAID-Controller zwischen der SSD und dem OS ist?
Die Idee eines Hardware RAIDs ist ja, dass man das im OS so gar nicht direkt an der Disk sieht, sondern dass man sie wie eine ganz normale Disk verwenden kann. Man sollte es aber auf dem Host System mittels "lspci" sehen können, zumindest ob da ein Hardware Controller aktiv ist. In einer VM hingegen wird man das wohl nicht sehen können.
Ob da auch tatsächlich ein Platten- oder SSD-Array durchgereicht wird, kann man z.B. mit dem Befehl hdparm (hdparm -I Laufwerk) abfragen.
Das zeigt aber eher den Unterschied zwischen virtio-scsi vs. virtio-blk (sprich sda vs vda). Wenn du den Disk Treiber bei Netcup auf scsi umstellst, solltest du eigentlich den gleichen Output bekommen wie bei dem Mitbewerber. Bei einer echten Disk würde im hdparm Output noch viel mehr auftauchen.
Heise veröffentlicht in letzter Zeit auch nur noch KI basierte Übersetzungen, die sich absolut schrecklich lesen. Beispiel (https://www.heise.de/news/Angreifer…en-9273706.html). Da hätte man lieber die englischen Begriffe beibehalten. So klingt das einfach nur noch peinlich.
Geht das nur mir so oder ist die Qualität der deutschen IT News in letzter Zeit ganz schön unter die Räder gekommen? Golem ist ja auch nicht viel besser. Die bringen gefühlt auch nur noch zu 90% Amazon Werbung.
Der Flaschenhals dürfte in den meisten Fällen (wie leider auch hier manchmal) Shared IO sein. Das macht aus meiner Sicht die meisten dieser VDS Produkte unattraktiv, weil man zwar deutlich mehr bezahlt, aber am Ende nur begrenzt mehr dafür bekommt. VDS mit dedicated Storage wäre wirklich mal was. Denn was nützen mir die dedizierten Kerne, wenn die Load durch iowait entsprechend hoch schiesst und die Kerne sich langweilen, weil sie auf die Disk warten müssen. Das sollte man auch berücksichtigen, wenn man solche Produkte bucht.
Du könntest in der /etc/fstab mal nachschauen und das swapfile dort deaktivieren. Dann sollte zumindest der Server wieder booten und du kannst in Ruhe nach dem Problem suchen.
warum sollte ich mir einen 64 GB RS zulegen wenns auch ein 32 GB RS mit ein wenig swap zur sicherheit tut?
Der Sprung von 32GB auf 64GB ist natürlich groß und da ist sicherlich ein kleines Swap File die bessere Wahl. Primär geht es mir darum, dass man nicht direkt mit Swap planen sollte. Ich habe schon so viele Server gesehen, die dann am Ende nur 16 GB RAM, dafür aber ein 20GB großes Swapfile hatten. Daher meine eher allgemeine Abneigung gegenüber Swap und warum ich lieber einen Server mit genügend RAM wähle.
I see a server and i want it painted green
Wobei man sich das alles ja sparen kann, wenn man gleich einen Server nimmt, der genügend RAM für seine Aufgaben hat.
(Bis auf diesen kleinen 1GB-Server habe ich swap auch überall abgeschaltet)
Genau das 
Swap kommt ja noch aus einer Zeit, in der RAM so richtig teuer war und nur ein Bruchteil von der Größe hatte, die man heute so für ein Appel und ein Ei bekommt. Mittlerweile kann man wirklich sämtliche Server mit so viel RAM betreiben, dass man wirklich keinen Swap mehr benötigt. Das braucht man vielleicht höchstens noch auf Desktop Systemen mit irgendwelchen Hibernate Funktionen, aber auch da ist ja der Standby mittlerweile gängiger.
Hm. Ich überlege gerade ob ich doch noch auf meinen VPS 200 G8 umziehe, wenn ich meinen munin Master und UptimeKuma auf einem Server laufen lassen will. Der hat auch nur 1 CPU, aber halt 2 GB RAM... Aber eigentlich wollte ich da am Samstag Wiki.js rauf schmeißen.
Mach das. Installiere aber nicht zuviele Dinge auf einem einzigen Server. Verteil das lieber. Unterschätze nie die menschlichen Fehler. Dann ist nämlich nicht immer direkt alles down
Uptime Kuma ist halt eine NodeJS Applikation. Diese sind generell sehr RAM lastig. Da würde ich schon eher mit 2 GB rechnen. Läuft z.B. auf einem VPS 200 wunderbar. Zumal, wenn man auf dem Server auch noch andere Dinge laufen hat (wie z.B. Munin). 1 GB ist dann doch etwas wenig, wenn dann tatsächlich etwas produktiv darauf laufen soll. Das frisst jetzt auch kein Loch in den Geldbeutel, sorgt aber dafür, dass man etwas ruhiger schlafen kann, weil man noch etwas Puffer hat.
Ich selbst achte bei der Server Auswahl eigentlich immer darauf, dass der RAM Bedarf im Durschnitt nicht höher als 60% ist. Das ist erfahrungsgemäß ein recht guter Wert.
Ist es eigentlich verboten fremde Seiten zu pingen oder ähnliches? Muss ich damit rechnen das die IP meines Servers bei solchen "Aktionen" gebannt werden kann?
Solange du es nicht übertreibst, sollte es eigentlich ok sein. Alle 60 Sekunden einen HEAD Request dürfte niemanden schaden. Könnte höchstens sein, dass sie nur bestimmte User Agents zulassen und dich daher aussperren. Aber sonst ist es ja eigentlich egal, ob du die Seite jetzt über einen Browser aufrufst oder über dein Monitoring Tool, wenn sie sowieso öffentlich erreichbar ist.
Das mit dem
/var/cache/munin/www/Verzeichnis ist ja eine Änderung von dir. Ich würde das erst einmal sein lassen, rückgängig machen und beim Standard Verzeichnis von Munin bleiben. Du hast davon erst einmal keinen Mehrheit und ggfs. nur Probleme (wie aktuell). Solche Umbiegungen kann man später irgendwann mal machen, wenn man sich tief genug eingearbeitet hat und bewusst machen möchte. Solche Änderungen sind später eine nette Hausaufgabe, die man ohne Hilfe machen kann. Sobald man dafür Hilfe braucht, sollte man das lieber nicht machen und sich lieber auf das wesentliche konzentrieren.
Dann fangen wir doch mal mit Apache an. Das bekommen wir auch alles ohne Provider Wechsel schon hin
Schau mal bitte folgendes nach:
1. Apache Logs. Siehst du deine Zugriffe? Was steht da evtl. noch zusätzlich?
2. Apache Konfiguration. Wie sieht denn deine aktuelle Konfiguration aus? Ich habe hier mehrmals /etc/munin/apache24.conf gelesen. Das ist ja aber eigentlich gar nicht im regulären Apache Konfigurationsordner. Schau mal, ob der Symlink in /etc/apache/conf-enabled entsprechend aktiviert ist.
3. Munin Files. Wo liegen denn die docroot Dateien von Munin im Filesystem? Stimmt der Ordner mit dem in der Konfiguration überein? Wie sehen die File Permissions aus? Kann der Webserver darauf zugreifen?
Ich kenne die Debian Images von Strat0 ebenfalls. Das ist wirklich ein ganz normales Debian ohne irgendwelche Änderungen. Nur die Netzwerk Konfiguration ist leicht anders und Netcup setzt (in der Image Installation) gewisse Kernel Settings per sysctl. Aber sämtliche Pakete (Munin, Apache), die man installiert, kommen am Ende sowieso aus den Debian Repositories. Weder Netcup noch Strat0 bauen hier eigene Pakete und schmuggeln die hier irgendwie unter
Bud Kannst du vielleicht nochmal kurz zusammenfassen, was aktuell nicht funktioniert? Hast du Probleme mit Munin? Oder mit Apache? Oder mit der Firewall? Aufgrund der Länge dieses Threads (das längste Thema sollte sich langsam mal warm anziehen), ist das mittlwereile doch etwas unübersichtlich geworden. Gerade Apache und Munin sind ja 2 verschiedene Baustellen, die man unabhängig voneinander mal anschauen muss. Und da es ja bisher sowieso eher Test Umgebungen sind, können wir da zur Not auch gerne mal zusammen drauf schauen.
Und vielleicht noch eine kleine Randbemerkung: Strat0 gehört zu I0n0s. bzw. die gehören beide zum selben Mutterkonzern. Man muss nur mal einen kurzen whois auf eine Strat0 IP machen, dann sieht man das sofort. Und da dürfte nicht nur die Produktpalette sehr ähnlich sein. Auch die Images werden sich mit Sicherheit kaum unterscheiden.
Die Software ist ja am Ende sowieso die gleiche. Ob jetzt Image oder ISO - spielt letztendlich keine Rolle. Für alles andere hat man seine Automatisierungstools (z.B. Ansible), welche man drüber jagt und dann sieht es letztendlich eh so aus wie man es gerne möchte! Sich auf vorgefertigte Installationen oder Konfiguration zu verlassen, ist generell sehr fahrlässig. Man muss die Software verstehen lernen. Dann kann man die Config einfach lesen und anpassen. Sich einfach nur Befehle zu merken in der Hoffnung, dass die vordefinierte Konfiguration schon irgendwie greift, führt früher oder später immer zu Problemen. Ich kann hier an dieser Stelle nur appellieren, sich mit der ganzen Thematik etwas intensiver auseinanderzusetzen und zu verstehen was Apache vHosts und Module sind, wie diese funktionieren, was ein DocumentRoot ist, etc. Das ist teilweise ganz schön haarsträubend, was man hier lesen muss kann (nicht böse gemeint - jeder hat mal angefangen - aber man wechselt doch nicht den Provider, weil sich die vorinstallierten Pakete unterscheiden).