Beiträge von Paul

Nachdem du den Dienst mit dem Systemd Service gestartet hast, konntest du dich immer noch nicht lokal (über 127.0.0.1) verbinden? Solang das nicht funktioniert, brauchst du den externen Zugriff gar nicht zu testen. Da müssen wir mal ansetzen. Du bist mir auch immer noch die Ausgabe von "ss -tulpn" schuldig

Sind das vielleicht die ganzen neuen Server von Bud ?

Poste bitte nochmal die Ausagabe des ersten Befehls. Es sieht nämlich eher so aus, als ob dein node server gar nicht mehr läuft. Wenn du den manuell über die Shell startest, musst du die Session natürlich offen lassen, sonst ist mit dem Beenden natürlich auch der node server wieder weg. Um ihn im Hintergrund laufen zu lassen, solltest du noch ein systemd service für wikijs anlegen: https://docs.requarks.io/install/linux (unter run as a service)

Was sagt denn

ss -tulpn

und

ufw status verbose

Geht es denn lokal?

telnet 127.0.0.1 3000

Achso, was natürlich auch noch sein könnte. Hört denn dein PostgreSQL überhaupt auf der IP? Schau mal in der postgresql.conf, was in

listen_addresses

eingetragen ist und passe das ggfs. an in

listen_addresses = '127.0.0.1'

Zitat von Bud

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            password

Zitat von Paule72

Das 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/c…ode/chown-invocation.html

Zitat

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 GNU
chown supports ‘.’ 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 ‘.’

Alles anzeigen

Zitat von aRaphael

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:

Code

mkdir -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.

Zitat von andreas.

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.

Zitat von andreas.

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/Angr…r-eskalieren-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.

Zitat von hoedlmoser

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.

Zitat

I see a server and i want it painted green

Zitat von aRaphael

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.

Zitat von Bud

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.