Beiträge von m_ueberall

Zitat von KB19

Fällt aber irgendwann auf, wenn die VM zu wenig RAM zum cachen verwendet, oder?

Bösartigerweise würde ich behaupten, dass dies primär irgendwann dann auffällt, wenn lang-laufende Prozesse ohne lokal nachverfolgbarem Grund plötzlich und unerwartet sterben/gestorben werden (vgl. OOM-Killer).

Zitat von condor

Bei einem vServer-Wechsel innerhalb von netcup, kann ich da eine IP kostenlos mitnehmen, sobald ich die Konfiguration meines neuen Servers abgeschlossen habe und ggf. auf die neue IP verzichten oder diese nur temporär zugewiesen bekommen?

Kostenlos umstellen lassen sich nur FailOver-IPs, welche separat zu buchen/bezahlen sind. Umstellen gegen Gebühr lassen sich zusätzlich gebuchte IP-Adressen. Diejenige IPv4-Adresse, welche derzeit als zwingender Bestandteil in einem VPS-/RS-Angebot enthalten ist, lässt sich meines Wissens gar nicht mitnehmen, auch nicht gegen Gebühr. (Dasselbe gilt für IPv6-Subnets.)

Huuhuu, mag einer die frisch provisionierten Sondermodelle einmal einem I/O-Benchmark unterziehen?

Zitat von Virinum

Wie würde man DNSSEC eigentlich korrekt wieder "zurückbauen"?

Wer würde das überhaupt wollen?

Zitat von perryflynn

Es kann auch helfen Delays einzuprogrammieren. Ansonsten kann der Anfang des Passworts verloren gehen, wenn KVM/VNC beim Wechsel vom einem zum anderen mal 100ms länger braucht.

Richtig. Bei Keepass2 ginge das beispielsweise mittels "{USERNAME}{ENTER}{DELAY 2000}{PASSWORD}{ENTER}" (Verzögerung in ms).

Zitat von Interessent

Keepass hat eben gestern nicht funktioniert. Nur beim User Name. Nicht beim Passwort

Wenn man Keepass2 anweist, statt {USERNAME}{ENTER}{PASSWORD}{ENTER} einfach nur {PASSWORD} zu senden, sieht man am Bild­schirm, ob das ge­sen­de­te Pass­wort dem er­war­te­ten entspricht. Das kann man ggf. korrigieren und die erstgenannte Sequenz wiederherstellen.

Zitat von mainziman

ja bei den Temperaturen wo des gelagert werden muss, auf jeden Fall;

Bitcoin-(od sonstwas)-mining wär evtl. effektiver in Relation zur Stromrechnung

Es ist nicht zwingend notwendig, einen Whisky (insbesondere abgefüllt ab Werk) bei konstant 20 Grad Celsius und gleichbleibender Luftfeuchtigkeit zu lagern, wenn es sich nicht um "höchstpreisige" Sammlerflaschen/-fässer handelt. Kein Sonnenlicht, keine wiederholten/anhaltenden Hitze- und Kältespitzen, keine dauerhafte Feuchtigkeit sind völlig ausreichende Lagerbedingungen für mehrere(!) Jahre.

Zitat von Interessent

Hallo,

gibt es eine Möglichkeit Usernamen und Passwort beim VNC Login reinzukopieren, so wie es bei Putty auch möglich ist?

Natürlich, beispielsweise mit KeePass2. Wenngleich ich das selbst bislang nicht für Nutzernamen/Passwort verwende, habe ich es spontan einmal damit getestet:

autotype01.png autotype02.png autotype03.png

Zitat von aRaphael

Evtl. mal was, das gar nix mit IT/Technik/usw. zu tun hat?

Whisky. Ungeöffnet eine Geldanlage, geöffnet ein Genuss (wenn die Auswahl stimmt).

Zitat von michaeleifel

Danke. Den Parameter hab ich gesucht, der kommt mit in die bereits existierende Liste:

Code

ExecStart=-/usr/sbin/qemu-ga --blacklist==guest-file-open,guest-file-close,guest-file-read,guest-file-write,guest-file-seek,guest-file-flush,guest-exec,guest-exec-status

SSH-Keys kommen nicht zum Einsatz? (Und Nutzer- und Betriebssysteminformationen teile ich auch nicht gern…)

ExecStart=-/usr/sbin/qemu-ga --blacklist=guest-exec,guest-exec-status,guest-set-user-password,guest-file-close,guest-file-flush,guest-file-open,guest-file-read,guest-file-seek,guest-file-write,guest-get-users,guest-get-osinfo,guest-ssh-get-authorized-keys,guest-ssh-add-authorized-keys,guest-ssh-remove-authorized-keys

Zitat von joas

Da haben nur die Leute mit nclabs Berechtigung Zugriff. Daher konnte er via Suche auch nichts finden.

Oh, das hatte ich übersehen.

Ich zitiere hier einmal, da die Antwort generell von Interesse sein dürfte und sich m.W. nicht speziell auf die nclabs-Umgebung bezieht:

Zitat von [netcup] Lars S.

[…]

wie bereits erläutert, stellen wir auf alten Tarifen keine neuen PHP-Versionen mehr bereit, da dies technisch nicht oder nur eingeschränkt möglich ist. Die bestehenden Versionen werden bei Bedarf mit backported Security-Updates versehen.

Die Hard-Migration verfolgen wir nicht mehr weiter, da der technische Aufwand aufgrund der vielfältigen Konfigurationen schlicht zu hoch ist. Unsere Kunden haben die Möglichkeit, per Soft-Migration auf einen neuen Tarif zu wechseln.

Zitat von MartinN

In meinem Webhostingpaket "Expert XL de" kann ich nur die PHP-Versionen 5.3.3, 5.4, 5.5, 5.6, 7.0, 7.1, 7.2 einstellen. Für Nextcloud 21 wird aber eine neuere PHP-Version benötigt. Wann erfolgt die Aktualisierung?

Diese Frage wurde doch vor zwei Wochen seitens Netcup hier beantwortet? Hat die Suche keine Fundstelle des Diskussionsfadens ausgeworfen?

Bitte nur keinesfalls die Blacksmith-Performanz als (Teil-)Benchmark zurande ziehen, sofern die KVM hier auf einem Intel-Host mit cpuid level 13, 15, 22 (und model name Xeon Gold 6140/E5-2660 v3) läuft (vgl. /proc/cpuinfo). Danke!

Bezüglich der Geschwindigkeitsangaben würde ich mir bei Netcup wünschen, dass fairerweise auch der Basistakt in den Angeboten erwähnt wird, wenngleich man diesen bei den Herstellern online nachschlagen kann. (Unabhängig davon, ob es Mitbewerber machen oder nicht.)

Zitat von m_ueberall

Ich habe derzeit Probleme, die ausgegebenen sha256-Prüfsummen unten einzuordnen (und mittlerweile leichte Kopfschmerzen, was nicht hilfreich ist).

Hintergrund: Die Metadaten/Label der Abbilder sollen unter anderem org.opencontainers.image.base.digest erhalten; diese Prüsumme ist in den beiden Abschnitten hier und hier erläutert.

Wenn man nur lange genug darüber brütet, fällt der Groschen. Die ausgegebenen Prüfsummen im Log sind abhängig vom ver­wen­de­ten Aus­ga­be­for­mat der Schich­ten (im Ma­ni­fest fin­den sich Angaben mit/ohne Kompression), und zu org.opencontainers.image.base.digest findet sich hier die zielführende Anmerkung.

Nutzt hier jemand Docker, um mittels docker buildx build Abbilder für eine oder mehrere Architekturen zu erstellen?

Ich habe derzeit Probleme, die ausgegebenen sha256-Prüfsummen unten einzuordnen (und mittlerweile leichte Kopfschmerzen, was nicht hilfreich ist).

Hintergrund: Die Metadaten/Label der Abbilder sollen unter anderem org.opencontainers.image.base.digest erhalten; diese Prüsumme ist in den beiden Abschnitten hier und hier erläutert. Ich würde erwarten, dass die Prüfsumme für alpine:latest diejenige ist, welche man oben auf dieser Seite findet (ändert man die Architektur, ändert sich die Prüfsumme – siehe Abbildungen unten).

In der nachfolgenden Ausgabe wird jedoch dieselbe Prüfsumme für das Basisabbild unabhängig von der Architektur angegeben. Auch die Prüfsummen für manifest/config ändern sich nicht, finden sich aber bei docker inspect <image> auch nicht wieder (schade, aber kein zwingender Beinbruch, wenn ich das richtig verstehe) – allerdings findet sich dort in der Ausgabe erst recht nicht die auf den Docker-Hub-Seiten genannten architekturabhängigen Prüfsummen.

Findet sich irgendwo ein Referenzbeispiel aus der Praxis oder hat das schon einmal jemand durchexerziert?

% #### Unten sieht man das Äquivalent von zwei Aufrufen ähnlich "docker buildx build --platform=linux/{amd64,arm64} ."
% ./ci_build.sh
[+] Building 28.8s (7/7) FINISHED                                                                                                    
 => [internal] load build definition from Dockerfile                                                                             => => transferring dockerfile: 2.14kB                                                                                           => [internal] load .dockerignore                                                                                                => => transferring context: 2B                                                                                                  => [internal] load metadata for docker.io/library/alpine:latest                                                                 => [1/2] FROM docker.io/library/alpine:latest@sha256:00abeca57ca04b7672955453580fd51ab9ad1b4c5571b1e7643becaadb81b749           => => resolve docker.io/library/alpine:latest@sha256:00abeca57ca04b7672955453580fd51ab9ad1b4c5571b1e7643becaadb81b749           => CACHED [2/2] RUN  apk update   && apk upgrade   && apk add openjdk11-jre-headless zip   && cd /tmp   && wget -O signal-lib   => exporting to oci image format                                                                                              2 => => exporting layers                                                                                                        1 => => exporting manifest sha256:5f5dac468572f0942a06d7d5b4aeb292ed22393528d95d2d1135ab6f7f6d7069                                => => exporting config sha256:19b9ba5fb32685b530c3b4949dd2c87072f2e690c7c7c6350982b3a7626f0039                                  => => sending tarball                                                                                                           => importing to docker                                                                                                         [+] Building 3.5s (7/7) FINISHED                                                                                                     
 => [internal] load build definition from Dockerfile                                                                             => => transferring dockerfile: 2.14kB                                                                                           => [internal] load .dockerignore                                                                                                => => transferring context: 2B                                                                                                  => [internal] load metadata for docker.io/library/alpine:latest                                                                 => [1/2] FROM docker.io/library/alpine:latest@sha256:00abeca57ca04b7672955453580fd51ab9ad1b4c5571b1e7643becaadb81b749           => => resolve docker.io/library/alpine:latest@sha256:00abeca57ca04b7672955453580fd51ab9ad1b4c5571b1e7643becaadb81b749           => CACHED [2/2] RUN  apk update   && apk upgrade   && apk add openjdk11-jre-headless zip   && cd /tmp   && wget -O signal-lib   => exporting to oci image format                                                                                                => => exporting layers                                                                                                          => => exporting manifest sha256:5f5dac468572f0942a06d7d5b4aeb292ed22393528d95d2d1135ab6f7f6d7069                                => => exporting config sha256:19b9ba5fb32685b530c3b4949dd2c87072f2e690c7c7c6350982b3a7626f0039                                  => => sending tarball                                                                                                           => importing to docker                                                                                                         
%
% #### Erstellungszeitpunkt beider Abbilder liegt hinter Zeitpunkt der letzten Docker-Hub-Basisabbildaktualisierung von heute:
% docker inspect 8b2d99c62ff9 | grep -E "Architecture|sha256:" | tail -3
        "Architecture": "arm64",
                "sha256:62170e181a92ced0deb88df006382d43977c9fc1ee8463603224492435f72735",
                "sha256:a10d7118744d985ceeabc952831db10beaa025937f25f966db8eb2946a57fcc4"
% docker inspect 72723e12459d | grep -E "Architecture|sha256:" | tail -3
        "Architecture": "amd64",
                "sha256:1a058d5342cc722ad5439cacae4b2b4eedde51d8fe8800fcf28444302355c16d",
                "sha256:c2920354e93234a3397b64758f016f7680245eea69ac3db21c4a174517dbac19"
% 

arm64.png amd64.png

Gnah.

Zitat von frank_m

Die Frage ist nun: Kann ich die Image Referenz der Container aktualisieren, so dass sie auf das neue Image zeigen und nicht mehr auf das alte? Dann könnte man das alte löschen. Mir ist klar, dass das nicht trivial ist, da der Inhalt der Images nicht 100% identisch ist. Eine Online Recherche hat nichts ergeben. Es gibt offensichtlich nur wenige Leute, die das Problem haben.

Ich würde nicht sagen, dass nur wenige Leute das Problem haben, aber es gibt keine "schöne" Lösung dafür.

Standardmäßig hat man es hier nicht mit einem "Overlay" der Containerinstanz "über" dem Basisabbild zu tun, welches einen Austausch "einfacher" machen würde, son­dern es wird der Umstand ausgenutzt, dass beim ZFS-Backend im Moment der Instantiierung lediglich Verweise auf die bereits existierenden Dateien im Pool dupliziert werden, anstatt die Dateien selbst zu duplizieren (copy-on-write, cow). [*]

Möchte man das "Basisabbild" erneuern, sind im Wesentlichen neue Containerinstanzen zu erzeugen, in welchen dieselben Änderungen vorgenommen werden, wie sie bei den alten Containerinstanzen im Rahmen von Anwendungsinstallationen/Konfigurationsanpassungen abgespeichert wurden. Auf Anwenderebene geht das grund­sätz­lich wie folgt:

• Seien BI1 das veraltete Basisabbild, COn (n=1..N) die darauf basierenden Container(instanz(en)) und BI2 ein neues Basisabbild

• Generiere CO0 aus BI1, um den "Originalzustand" der COn vor Anpassung als Vergleich im Zugriff zu haben

• Für alle COm (m=1..n):
  • Erstelle die Liste aller modifizierter Dateien/Verzeichnisse, welche sich gegenüber CO0 geändert haben (rsync kann das im "dry-run-Modus", wenn man sich beispielsweise zwischen CO0 und COm via ssh verbindet); ggf. auch zwischenzeitlich gelöschte Dateien berücksichtigen!
  • Generiere COm' auf Basis von BI2
  • Übertrage alle geänderte Dateien aus obigem Vergleich (etwa in Form eines tar-Archivs) von COm auf COm' (hierbei sollte man ggf. keine Dateien über­schreiben, die in COm' "noch" neuer sind als die Dateien, die man überträgt)
  • Prüfe, ob Container COm' wie erwartet funktioniert; wenn ja, lösche COm
• Lösche CO0

(Spezialdateien/Geräte könnten in seltenen Fällen ein Stolperstein sein, aber ich würde u. a. /dev zunächst vom Abgleich ausschließen.)

Anstelle von rsync und der temporären Generierung von CO0 zum Zeitpunkt des Updates wäre es auch denkbar, einfach eine Prüfsummenliste aller Dateien in ein­em er­sten unveränderten Container basierend auf BI1 zu erzeugen und diese beim späteren Abgleich zu nutzen (Achtung, auch das Dateierstellungsdatum sollte hier als sinn­vol­les Vergleichskriterium mitgesichert werden; analog zu rsync sollten zudem ggf. auch gelöschte Dateien entsprechend vermerkt werden). Das hat den Vor­teil, dass man die Container auch zwi­schen­zeitlich auf andere LXC/LXD-Knoten verschieben kann, ohne auf die Archivierung/"Vorhaltung" von BI1 zu achten (dürfte Platz sparen). b3sum ist hier die schnell­ste mir be­kann­te Möglichkeit für die Erstellung derartiger Prüfsummen.

Abgesehen vom Effizienzaspekt bei Verwendung des ZFS-Backends ist obiger Ansatz natürlich dateisystemagnostisch und funktioniert, solange eine Erneuerung ei­nes Basis­ab­bilds nicht mit Seiteneffekten einhergeht (Beispiel: ABI-Änderungen bei Basisbibliotheken, wodurch "nachinstallierte" Anwendungen, die hierauf zugreifen (wol­len), ohne Anpassung nicht mehr funktionieren).

[*] Ein anderer Ansatz wäre natürlich, mit OverlayFS (oder besser: AuFS) zu hantieren, wenn es das zugrundeliegende Dateisystem unterstützt, aber auch das muss man händisch einrichten und dieser Ansatz ist eher noch aufwendiger und es gibt keine adäquaten "Bordmittel" für das ZFS-Backend in Kombination mit LXD.

(Ich selbst habe testweise mehrere WordPress-Instanzen mit jeweiligen Theme-/Plugin-Schichten und einer einzigen WordPress-Basisinstallation mit AuFS und ZFS rea­li­siert, aber das ist mehr eine Machbarkeitsstudie denn eine "naheliegende" Lösung.)

Zitat von P.Se

Soweit ich mich erinnen mag war das schon Immer(?) so.

Gerade einmal mit dem ältesten vorgehaltenen Build-Container nachgestellt – Debian 8.x (Jessie) – und Frage mit Eingabetaste beantwortet:

root@pbuilder-amd64(debian-jessie-amd64):/# apt install less
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following NEW packages will be installed:
  less
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 124 kB of archives.
After this operation, 259 kB of additional disk space will be used.
WARNING: The following packages cannot be authenticated!
  less
Install these packages without verification? [y/N] 
E: Some packages could not be authenticated
root@pbuilder-amd64(debian-jessie-amd64):/#

Zitat von KB19

Möchten Sie fortfahren? [J/n]

Ich komme ohne J/Y auf der Returntaste an und das Ding rattert los…

Klar, keine Eingabe = Vorgabe (großes "J").

Zitat von aRaphael

Nutzt von euch jemand unter Apache ModSecurity als WAF?

"Lohnt" sich das?

Ja (zusammen mit dem OWASP CRS). Ja.

Zitat von Interessent

[…] sei[t] ein paar Tagen habe ich massive Portscans und Versuche (teilweise 10000 pro Tag von der gleichen IP) sich auf dem Server per SSH einzuloggen.
[…] Gibt es keine Möglichkeit das ganze mit Fail2Ban etc zu blocken?

Ad "etc": Ich bin mit knock[d] sehr zufrieden (siehe auch diesen Diskussionsfaden).