Beiträge von gunnarh

  • VM - Failed to start VM {name}, nach OS-Disk Vergrößerung

    Danke [netcup eos] Thorsten L.... habe mir euren Hinweis in https://docs.eoscloud.io/products/volum…rage-user-guide jetzt durchgelesen. Zitat:

    Zitat

    The default behavior when growing a root Volume is to automatically extend the size of the root disk. If you want to disable this behavior, ensure that incus-growpart.service is disabled and also check that a potential cloud-init.cfg does now grow the root disk.

    Das beschreibt das aktuelle Verhalten, dass die Partitionen automatisch vergrößert und auch die Filesysteme automatisch vergrößert werden meinem Verständnis nach nicht deutlich genug. Da steht, wenn man das Volume vergrößert, vergrößert sich die Root-Disk (wollte man vielleicht Root-Partition schreiben und hat sich geirrt?).

    Ich denke da sollte geschrieben stehen (Vorschlag):

    When growing a root volume, the default behavior is that the root disk expands and the primary partition and filesystem are automatically extended. This happens on next startup and is performed either by incus-growpart.service and/or by the growpart and resizefs modules of cloud-init Service, configured in /etc/cloud/cloud.cfg, depending on the operating system of the VM.

    To prevent the root partition and filesystem from growing automatically, check for and disable these mechanisms before growing the volume.

    If you need additional separate partitions and filesystems for specific mount points, consider attaching a separate new volume that can be grown independently.

  • [eos] Stop und Restart via ACPI

    Ja, kann ich bestätigen:

    Code
    root@myVM1:~# journalctl --since "1 hour ago" --grep="power"
Sep 03 11:32:58 myVM1 systemd-logind[792]: Power key pressed short.
Sep 03 11:32:58 myVM1 systemd-logind[792]: Powering off...
Sep 03 11:32:58 myVM1 systemd-logind[792]: System is powering down.
Sep 03 11:32:59 myVM1 systemd[1]: systemd-poweroff.service: Deactivated successfully.
Sep 03 11:32:59 myVM1 systemd[1]: Finished systemd-poweroff.service - System Power Off.
Sep 03 11:32:59 myVM1 systemd[1]: Reached target poweroff.target - System Power Off.

  • VM - Failed to start VM {name}, nach OS-Disk Vergrößerung

    Danke [netcup eos] Thorsten L. für die ausführlicher Erläuterung.

    Dass das beim StartUp automatisch vergrößert wird kommt wie gesagt für mich unerwartet. Vielleicht möchte man das zumindest im Web-GUI Dialogfeld erwähnen und einen Link zu einer Erläuterung in der Doku setzen.

    Was die Information das incus-growpart.service zu deaktivieren betrifft: Das existiert auf meiner Ubuntu 26.04 Cloud VM nicht.

    Code
    root@myVM1:~# systemctl list-units | egrep -i "incus|grow" 
  run-incus_agent.mount          loaded active     mounted   /run/incus_agent
  incus-agent.service            loaded active     running   Incus - agent

    Das wird denke ich nicht mit incus sondern mit cloud-init hiermit erledigt: Module "growpart" und "resizefs" in der /etc/cloud/cloud.cfg

    Code
    # The modules that run in the 'init' stage
cloud_init_modules:
  - seed_random
  - bootcmd
  - write_files
  - growpart
  - resizefs
  - disk_setup
  - mounts
...

  • VM - Failed to start VM {name}, nach OS-Disk Vergrößerung

    Das Vergrößern von root Volumes scheint nun möglich zu sein und funktioniert auch.

    Allerdings tut euer Mechanismus da meines Erachtens ungefragt "zu viel des guten". Ihr vergrößert auch gleich die sda2 Partition und erweitert das Filesystem. Das ist zwar sicherlich sehr komfortabel für jemanden, der das genau so gewollt hat. Aber wenn ich die Disk eigentlich vergrößern wollte um im Freespace eine neue Partition anzulegen habe ich nun ein Problem, denn es gibt keinen Freespace.

    Vor der Vergrößerung des Volumes:

    Code
    root@myVM1:~# fdisk --list /dev/sda
Disk /dev/sda: 55.88 GiB, 60000000000 bytes, 117187500 sectors
...
Device      Start       End   Sectors  Size Type
/dev/sda1    2048    206847    204800  100M EFI System
/dev/sda2  206848 117187466 116980619 55.8G Linux filesystem

    Nach der Vergrößerung des Volumes über die EOS-Console:

    Code
    root@myVM1:~# fdisk --list /dev/sda
Disk /dev/sda: 74.51 GiB, 80000000000 bytes, 156250000 sectors
...
Device      Start       End   Sectors  Size Type
/dev/sda1    2048    206847    204800  100M EFI System
/dev/sda2  206848 156249966 156043119 74.4G Linux filesystem

    Ich denke, dass dieser Komfort optional sein sollte bzw. beim Vergrößern parametrierbar / abwählbar sein sollte.

  • Ab sofort: Firewall für netcup vServer verfügbar

    Zitat von randomsushi

    Dachte ich hätte mich klar ausgedrückt... wie auch immer: Port 25 wird nicht erreicht ...

    Deine Fragen zeigen mir aber, dass Du meinen Anfrage nicht gründlich gelesen oder verstanden hast:

    Na dann schalt ihn frei. Nimm die Default drop Regel von Netcup raus und trage eine allow Regel für 25/TCP ein. Es gibt kein Problem mit dem Betrieb von Postfix als SMTP Server bei aktivierter Netcup Firewall. Der Spickzettel unter RE: Ab sofort: Firewall für netcup vServer verfügbar deckt auch den Mailserver betrieb getesteter Weise ab.

  • Ab sofort: Firewall für netcup vServer verfügbar

    Zitat von randomsushi

    Dummerweise stellt der Mailserver (nginx, postgresql, postfix, dovecot) keine Mails mehr zu, wenn ich die netcup-FW zusätzlich aktiviere.

    Was bedeutet "stellt nicht zu"?
    Port 25 SMTP Incoming kann nicht mehr erreicht werden? => Wäre trivial den freizuschalten. Hast du vermutlich selbst bereits gecheckt
    Mail wird rejected? => Dann vermutlich weil Dinge wie DNS-Reverse-Lookup-Check, Abfrage von konfigurierten BlackLists etc... fehlschlagen? Das sollte dann aber das Postfix Log zeigen.

  • Das längste Thema

    Zitat von ASS

    Mietrecht

    Da Wohnraum und damit verbunden das Mietrecht ein dringendes menschliches Grundbedürfnis ist, gelten da in den meisten Ländern spezielle Schutzbestimmungen. Auf Server trifft das glücklicherweise ja nicht zu, auch wenn es hier Leute gibt die Server-Hoarding in der Maslowschen Bedürfnispyramide vermutlich auf Stufe 1 oder 2 ansiedeln würden 8o

  • Das längste Thema

    Als Österreicher habe ich zum Deutschen Recht freilich keinen intimen Bezug, aber aus meiner Sicht hat hier ohnehin niemand einen Rechtsanspruch von einer Privatperson etwas geschenkt bzw. gegen eine Ablöse überlassen zu bekommen. Und Diskriminierung liegt ja ohnehin keine vor, wenn man sachliche Regeln wie "ich kommuniziere nur in deutscher Sprache, ich nehme Zahlungen nur von Euro Konten aus dem EU-Sepa-Raum mittels Sofortüberweisung entgegen" anwendet. Und wie gesagt, es gibt keinen Kontrahierungszwang. Ich kann Anfragen auch ohne Angabe von Gründen ablehnen oder unbeantwortet lassen.

  • Das längste Thema

    Zitat von Bud

    Vor einem ähnlichen Problem stehe ich derzeit auch. Allerdings kündige ich die Server lieber, als dass sie in die falschen Hände geraten... Die Tauschbörse ist meines Erachtens nicht mehr das, was sie einmal war.

    Hier im längsten Thema anbieten wäre aber auch eine Option. Oder öffentlich anbieten aber das Angebot transparent auf einen Personenkreis einschränken der deutsch spricht und/oder eine akzeptable Forums-Reputation aufweist. Sagt ja niemand, dass man jeden der sich meldet nehmen "muss". Ich finde auch diese "Verlosungen" ehrlich gesagt etwas befremdlich. Wenn ich mehrere Interessenten habe würde ich einfach einen nach Bauchgefühl auswählen, per Direktnachricht kontaktieren und den Thread dann als vergeben schließen. Muss sich ja niemand rechtfertigen oder transparent machen wer nun zum Zug gekommen ist.

  • Das längste Thema

    Zitat von mainziman

    mehr als einen 403 Fehler will er mir nicht geben

    Einfach 1:1 alle Header die dein Browser schickt auch mit wget abbilden. Da ist kein JavaScript oder andere Tricks im Spiel.

    Hier etwas übersichtlicher, ich habe nun alle Header die mein Edge sendet hier rein dupliziert: