Beiträge von aRaphael

"...and I was asked to pay the invoice"

wtf They want money for their products??

...

Zitat von Bud

Also hab ich das Verzeichnis schnell über die Konsole erstellt. Dann habe ich versucht in den Ordner "netcup" mehrere Dateien mit FileZilla hochzuladen, was aufgrund von fehlenden Berechtigungen nicht funktioniert hat. Wie kann ich das Problem lösen?

Wenn du das Verzeichnis mit "sudo" erstellt hast, dann hat es ja den Besitzer "root"

Ändere den auf den Nutzer. mit dem du immer was hochladen willst.

Zitat von Bud

Das habe ich mal nicht gemacht, weil ich ja die IP verwende, und mir FQDN dann ja nichts bringt, oder?

Ich würde das trotzdem mal testen. Normalerweise überprüft munin, ob der Name zum fqdn passt.

Stimmt die ip-Adresse des Masters in der Konfig auf der node?

Auf der node mal service munin-node restart ausgeführt?

Ist Port 4949 offen, auf der node?

Mal im Master [Node] ersetzen durch [Node;FQDN]

wobei FQDN das ist was auf der node bei hostname -f ausgegeben wird.

Jede Änderung wird immer erst zu den nächsten vollen 5 min auf dem Master wirksam.

Zitat von Bud

Ich hab jetzt in der munin-node.conf auf meinem node die IP vom master zugelassen, sowie auf dem master in der munin.conf de IP des node eingetragen.

Ach ja, sorry. Das hatte ich vergessen zu erwähnen.

Zitat von Bud

ip/munin ist leider nicht erreichbar. bzw er findet das Verzeichnis nicht.

In /etc/munin/apache24.conf hast du überall "Require local" ersetzt durch "Require all granted" (und danach service apache2 restart) ?

Auf dem Master

apt install libwww-perl
apt install libcgi-fast-perl
apt install munin munin-node
a2enmod cgid

Auch auf dem Master In apache24.conf

Require local -> Require all granted

außerdem

a2enconf munin

und dann:

service apache2 reload

Auf den nodes:

apt install libwww-perl
apt install munin-node

dann sollten unter

masterdomain.tld/munin

die Graphen nach einem max. 5min delay (nein, nicht Jan) sichtbar sein.

Nachtrag:

Die ip des Masters muss noch auf den nodes erlaubt werden und die einzelnen nodes auf dem Master eingetragen werden. (Siehe dazu die doku von munin)

Zitat von CuzImBisonratte

....und ich kann ohne Probleme lvm sagen, dass dieses die volle größe nutzen soll, oder?

Ja, wenn du eh nur eine Partition nutzt (und sicher weißt, dass du auch in Zukunft keine zusätzlichen anlegen willst), dann kannst du das eine Volume auch auf das Maximum vergrößern. (Aber dann hättest du auf die Zwischenschicht lvm auch ganz verzichten können)

Zitat von CuzImBisonratte

Ist jetzt also doch alles richtig eingebunden und dh erkennt das einfach nicht?

Ja, 53 GB sind einfach noch keiner lvm-Partition zugeordnet. (df sieht diesen Speicherplatz nicht, aber dafür gibt es ja vgs)

Zitat von CuzImBisonratte

Ich kenne mich absolut nicht mit Partitionierung aus, deswegen die Frage: Was ist der Vorteil davon, die Partitionen klein zu lassen? Ich möchte ja nicht immer mal wieder in gparted rein um die zu vergrößern...

Ohne lvm legst du ja die Partitionsgrößen im Voraus fest und kannst sie dann nicht mehr (ohne größeren Aufwand) ändern. Evtl. merkst du später dass die Verteilung des Speicherplatzes nicht optimal war und eine Partition mehr benötigt und eine andere eigentlich zu viel hat.

Mit lvm kannst du die Partitionsgrößen auch nachträglich noch leicht ändern. (Ohne gparted o.ä., mit einem einzigen Befehl im laufenden Betrieb)

ABER: Während die Vergrößerung einer lvm-Partition (logical volume) völlig problemlos abläuft, ist das bei einer Verkleinerung leider nicht immer der Fall. (Ist mir selbst schon passiert)

Nettes Zitat dazu (Quelle habe ich gerade nicht präsent): "Everyone say its critical and may end up with disaster while we reduce the lvm. Reducing lvm is really interesting than any other part in Logical volume management."

Deshalb ist es "best practice" bei lvm, den zunächst nicht benötigten Speicherplatz erstmal unzugeordnet zu lassen, bis man weiß welche Partition ihn dann später evtl. benötigt.

Du kannst ja mal mit lvs schauen, wie groß deine Volumes sind und welches davon evtl. mehr Platz braucht.

Was gibt denn vgs aus?

Evtl. hast du ja nicht den ganzen Platz auf die lvm-Partitionen verteilt?

Was übrigens durchaus sinnvoll ist. Nur den Platz, den man momentan auch braucht in lvm-Partitionen stecken und den Rest unzugeordnet lassen. Erst wenn man in einer der Partitionen mehr Platz braucht, diese erweitern. Das ist ja gerade einer der Vorteile von lvm

Zitat von KB19

Im Zweifel einfach die GParted-ISO im SCP einlegen und booten, da kümmert sich GParted um alles.

Ja. ist am einfachsten, geht am schnellsten und man kann weniger Fehler machen.

(Allerdings habe ich gparted noch nie auf Servern genutzt, auf denen ich lvm installiert hatte)

Kannst du machen, musst du aber nicht. Zumindest nicht, wegen der Last. Die ist für den munin-master vernachlässigbar.

Die Daten werden ja auf den nodes erhoben. Der master holt die nur ab.

Aber natürlich ist es generell durchaus sinnvoll die Überwachung von den zu überwachenden Servern zu trennen.

Für einen munin-master langt der kleinste Server, den du kriegen kannst. (Ein Betriebssystem muss halt draufpassen. )

Zitat von Bud

Wenn ich das richtig verstehe, brauche ich bei Munin zwei Server? Also einen Master, und node dann auf dem, welchen ich überwachen möchte?

Nein, das ist nicht unbedingt nötig. Das kann auch beides auf dem gleichen Server laufen.

(Du hast dann aber halt keine Infos mehr, wenn der Webserver down geht)

Nein. Nur lokal jeweils auf dem Server..

Zitat von tom434

• Hohe Verbrauch von Systemressourcen (teilweise 20-30 % CPU Auslastung nur wegen Netdata + Hohe RAM Verbrauch)

Echt? Also diese Erfahrung habe ich nicht gemacht.

Ich bin Fan von munin. (Ist aber nicht "Echtzeit" im Sekundentakt, wie z.B. netdata, sondern nur alle 5 Minuten)

Zitat von eripek

Solche Verträge werden sicherlich auch auf Jahre im Voraus zum Fixpreis abgeschlossen

Das ist nicht der Fall. Mittelfristig durchaus. Aber nicht auf viele Jahre im Voraus.

Aber natürlich enthalten Energieverträge von größeren Energieversorgern mit größeren Unternehmen immer entsprechende absicherende Klauseln. (Beiderseitg)

Zitat von tab

Ja, wenn du DNSSEC aktivieren willst, dann wirst du mit den netcup Nameservern wahrscheinlich nicht glücklich werden

Ja.

Kurzfassung: Falls du auf DNSSEC verzichten kannst, sind die netcup-domains durchaus zu empfehlen, (weil preisgünstig und ohne dnssec durchaus zuverlässig)

Falls du DNSSEC zwingend benötigst, dann nicht.

Zitat von Antijurist

Das ist ja ernüchternd.

Naja. Das was wir hier geschrieben haben ist ja erstmal Spekulation.

Vielleicht geht der direkt Umzug ja auch völlig problemlos vonstatten.

Das kann nur jemand belastbar beantworten, der das auch schonmal ausprobiert hat.

Zitat von tab

Hinterher wirst du eh bald andere Nameserver nutzen wollen...

Ja. Viele hier gehen den umgekehrten Weg und ziehen ihre domains nach extern um.

Ah. OK,