Posts by m_ueberall

    Da ihr offenbar noch nicht sicher seid was darauf alles laufen muss, würde ich an eurer Stelle zunächst auf einen VPS setzen ohne Mindestlaufzeit. Ist zwar teurer als 12 Monate Mindestlaufzeit, aber eben auch flexibler.

    cw_pn : Die Möglichkeit, die Mindestvertragslaufzeit bei einem RS (Root-Server) gegen Aufpreis auf bis zu einen Monat zu reduzieren, gibt es natürlich auch; in Verbindung mit einem RS ist ferner das Buchen des "Root-Server Service Level A+" möglich, was – selbstverständlich nur neben dem eigenverantwortlichen Betreiben mehrerer Server – Ausfallzeiten verkürzen kann.

    Weiter oben steht aber auch der Hinweis, dass die Minimalwerte nur erreichbar sind, wenn Swap konfiguriert wurde. Hast du das in deiner Testinstallation getan?

    Ja, die Test-VM verfügt über eine 2GB-Swap-Partition–Aber wie gesagt, es ist sowieso keine Minimalinstallation. (Die Swap-Partition ist analog zum ZFS-"rpool"-Pool verschlüsselt, und bereits das könnte hier ein zugrundeliegendes Problem sein bei 256MB RAM.)

    Schlägt die Installation (von einer LiveCD) fehl oder bootet das dadurch installierte Minimalsystem danach nicht? Es gab hier vor einigen Wochen einmal eine ähnliche Diskussion, die ich nicht mehr weiterverfolgt habe, aber bei derart geringen Systemressourcen sollte es doch möglich sein, das in einer heimischen (K)VM auszutesten, indem man eine derartige, ggf. debootstrap-basierte Minimalinstallation unter temporärer Verwendung von 256MB/512MB RAM vornimmt und den verfügbaren Speicher danach sukzessiv vor jedem Reboot reduziert, bis man bei 128MB angekommen ist? Das resultierende Festplattenabbild kann man im Erfolgsfall danach ja übertragen.

    Nachtrag: Ich habe einmal der selbst verwendete "Ubuntu-20.04-Standardinstallation" für Server – welche jedoch keine absolute Minimalkonfiguration darstellt – in einer KVM sukzessiv das RAM entzogen und festgestellt, dass 256MB nicht zum Booten ausreichte (mit 512MB RAM geht's). Wenn man nach Minimalanforderungen sucht, welche sich leider nicht mehr explizit im Ubuntu 20.04 LTS (Focal Fossa) Server Guide finden – letzterer empfiehlt 1GB RAM –, stößt man auf Aussagen, die ebenfalls mindestens 512MB voraussetzen.

    R60 : Wo findet sich denn die Angabe mit den 128MB RAM? Habe die Angaben bei Debian gefunden, welche bei Stretch noch von 128MB RAM sprachen, bei Buster jedoch auf 256MB RAM korrigiert wurden. Den dortigen Satz "Die absoluten Minimalanforderungen an den Arbeitsspeicher sind um einiges geringer als in der Tabelle angegeben." müsste man ggf. wirklich einmal einer genaueren Prüfung unterziehen.

    Hatte da schon mal den Support angeschrieben. Leider gehen Ubuntu und Debian nicht, auch wenn hier die Minimalanforderungen sagen das 128MB RAM reichen.

    Schlägt die Installation (von einer LiveCD) fehl oder bootet das dadurch installierte Minimalsystem danach nicht? Es gab hier vor einigen Wochen einmal eine ähnliche Diskussion, die ich nicht mehr weiterverfolgt habe, aber bei derart geringen Systemressourcen sollte es doch möglich sein, das in einer heimischen (K)VM auszutesten, indem man eine derartige, ggf. debootstrap-basierte Minimalinstallation unter temporärer Verwendung von 256MB/512MB RAM vornimmt und den verfügbaren Speicher danach sukzessiv vor jedem Reboot reduziert, bis man bei 128MB angekommen ist? Das resultierende Festplattenabbild kann man im Erfolgsfall danach ja übertragen.

    [Ü]ber Mobilfunk funktioniert es wunderbar und ohne Probleme. Dies IP "192.168.0.1" ist von meinem Vodafone-Kabel Router.

    Der Vodafone-Kabelrouter verwendet standardmäßig eben Vodafone-DNS-Server. Da ist manchmal der Wurm 'drin; selbst schon einmal damit konfrontiert gewesen.

    Da die Domäne/Unterdomäne via https://www.whatsmydns.net/ problemlos von verschiedenen Orten abgerufen werden kann (ein paar Fehler in der Übersicht gibt es immer 'mal), liegt das Problem eindeutig daran, dass hier die "falschen" (Vodafone-)DNS-Server verwendet werden. Die lassen sich in Datei /etc/resolv.conf problemlos ersetzen[*]—entweder durch die üblichen Verdächtigen (1.1.1.1, 8.8.8.8, 9.9.9.9) oder besser noch durch dnscrypt-proxy ...


    [*] diese Datei wird i.d.R. dynamisch überschrieben und ist ggf. ein symbolischer Link, aber das lässt sich durch manuelle Löschung, Neuerstellung und "Überschreibungsschutz" (chattr +i /etc/resolv.conf) verhindern.

    Gibt es eigentlich einen etwas komfortablen Ersatz oder Aufsatz für cron?

    Mit ein paar mehr Möglichkeiten, z.B. eine Liste von bestimmte Zeiten/Daten anzugeben (z.B. Werktags 9:30/11:05/17:25 ...) ohne gleich mehrere cronjobs einrichten zu müssen.

    Klar könnte ich mir was skripten, aber falls es da schon was kleines, feines gibt... :)

    Da gibt es (natürlich) auch etwas von Ratiop… systemd! Nennt sich [Timer] ...

    Ich meine nicht das Sonderangebot, sondern Expert Special 2018.

    Ah. Die Produktbeschreibung findet sich natürlich im lokalen tagesaktuellen Archiv der "netcupproduktexml": :D

    wobei doof gefragt, kann [der KVM-Hypervisor] eigentlich, z.B. ein VPS hat 4 GByte RAM, und weil da was läuft was nur 1 GB braucht, dass er die nicht gebrauchten 3 GByte am Host anderweitig zur Verfügung hat und der Guest wieder bekommt bis er diese auch tatsächlich allokiert?

    Ja, genau so läuft das (es wird standardmäßig immer nur vom Hostsystem allokiert, was benötigt wird). Das Hostsystem/der Hypervisor kann KVMs "auf dem Papier" sogar erlauben, mehr Speicher zu allokieren, als in der Summe zur Verfügung steht ("Overcommitting", analog zu vCPUs) – ggf. knallt es dann, wenn dieser tatsächlich allokiert werden soll und die Anfrage nicht bedient werden kann.

    Zudem glaube ich nicht, dass die Root-Passwort-Funktion auf diese Weise funktioniert.

    Wie genau Netcup diese Funktion derzeit oder zukünftig umsetzt, ist aber nicht der Punkt, sondern es geht hierbei darum, wie man unautorisierte Zugriffe verhindert oder er­schwert.


    Der qemu-guest-agent ("QGA") erlaubt standardmäßig tatsächlich das Ändern des Passworts über die entsprechende Funktion guest-set-user-password, und sofern das Hostsystem diese Methode ausführen kann, ist es unumgänglich, diese auch im laufenden Betrieb als potentiellen Angriffsvektor zu berücksichtigen (wie man mit einer lokalen KVM austesten kann):

    qemu-guest-agent_test01.png

    (Wer obiges selbst nachstellen will, kann die erforderlichen Schritte/Beispiele hier, hier und hier nachlesen – bei Verwendung des Virtual Machine Managers musste ich die VM-Definition manuell ergänzen.)


    Durch Deaktivierung der o.g. QGA-Funktion und Verschlüsselung der Festplatte sperrt man effektiv die Möglichkeit einer nicht erwünschten Passwort­änderung über das SCP/den QGA-Kontrollkanal und somit ist es deutlich schwerer für Unbefugte, an die Inhalte der eigenen virtuellen Maschine gelangen. Dies erfordert dann mindestens einen voll­stän­di­gen Speicher- und Plattenabzug und entsprechende Kenntnisse, diese auszuwerten. Zum Vergleich: Gelingt es einem Angreifer (nicht notwendigerweise ein Netcup-Mitarbeiter), ein Passwort zu ändern, ist ein Login über den Hostrechner relativ einfach.

    (Brute-Force-Login-Versuche über die virtuelle Konsole sollten übrigens ebenfalls überwacht, protokolliert, und unterbunden werden – bspw. durch erzwungenes Herunterfahren der virtuellen Maschine derart, dass ein "normales" Neustarten nicht mehr funktioniert. Damit greift dann die "Encryption at Rest".)

    Mit ein wenig Geduld und über ein paar Hinweise kann man der/den genauen Ursache(n) via Google auf die Schliche kommen, welche hardware- und/oder kernel­spezifi­scher Natur sein können (Optane ist "so eine Art Cache-SSD", also kann man hier die Angaben/Kommentare bzgl. SSDs zugrundelegen). Food for thought:

    Im Endeffekt sind die Werte eh' nicht (mehr) aussagekräftig.

    Afaik nur, wenn Du sie mit einem VPS (z.B. 200) überträgst. ;)

    Dafür muss sie dem VPS zugewiesen sein, dann sollte das klappen.

    Den VPS kann der Empfänger dann ja wieder kündigen…

    Oder er weist die Failover-IP-Adresse(n) einem anderen Produkt zu und gibt den ursprünglich damit verknüpften VPS/RS wieder zurück… 8o

    Öhm, ja ... "Wir können dazu keine Aussage treffen, sind nur Mieter", so könnte man sich freilich auch disqualifizieren.

    Die Formulierung klingt eben besser als "Aus vertraglichen Gründen dürfen wir hierzu keine Aussage treffen". Aber genau so ist sie zu lesen.

    oldoldstable wirft aber noch immer keinen Fehler, da es im Hauptarchiv nach wie vor verfügbar ist. Merkt man also leider nicht direkt, außer dass keine Updates mehr rein kommen. :D

    Hm… Unterscheidet sich die Repository-Definition bei der Netcup-Installation denn von derjenigen, welche man in Minimalausführung in einem Container sieht?

    Da schaut's so aus:

    debian_jessie.png

    (Ist IMHO doch eine deutliche Warnung…)