Was zum Geier habt ihr da drauf?
Das war auf den Desktop bezogen, virtuelle Server haben bei mir auch nur um die 200.
Beiträge von AutoYaST
-
-
Code
_____________________________________ / wonder why nobody has cowsay on his \ \ list... / -------------------------------------Cowsay ist ein total nettes Gimmick, bis man es auf einem Ansible controller installiert, ohne zu wissen, dass Ansible mit der `cowsay` Binary im PATH jede Zeile (sic!) automatisch via cowsay ausdruckt.
-
Achso, ich hatte "mitbringen" so verstanden, als dass die von Haus aus installiert wären.
-
Das sind bei meinem Ubuntu hier 77.302 Pakete.
Alter Fuchs, das ist Standard?
Mein openSUSE Tumbleweed Desktop hat selbst mit KDE GUI und all meinen Entwicklerextras nur
2522.
-
evtl. auch gebrauchen kann
... zwei Wochen später: "Hilfe, mein Server blinkt und pfeift und ich kann mich nicht mehr anmelden!"
-
Ich bin faul und setze auch auf Copy&Paste:
Code
Alles anzeigen<package>wicked</package> <package>vim-small</package> <package>system-group-wheel</package> <package>sudo</package> <package>snapper</package> <package>seccheck</package> <package>openssh</package> <package>openSUSE-release</package> <package>numactl</package> <!--package>irqbalance</package--> <package>grub2</package> <package>grub2-snapper-plugin</package> <package>glibc</package> <package>fish3</package> <package>firewalld</package> <package>e2fsprogs</package> <package>cryptsetup</package> <package>cron</package> <package>chrony</package> <package>btrfsprogs</package> <package>autoyast2-installation</package> <package>autoyast2</package> <package>haveged</package> <package>libhavege1</package> <package>postfix</package> <package>apparmor-utils</package> <package>ca-certificates</package> <package>ca-certificates-mozilla</package> <package>netcat-openbsd</package> <package>qemu-guest-agent</package> <package>acct</package> <package>iputils</package> <package>mlocate</package> <package>htop</package> <package>which</package> <package>openldap2-client</package> <package>lsof</package> <!--package>autofs</package> <package>sssd</package> <package>sssd-common</package> <package>sssd-krb5-common</package> <package>sssd-ldap</package> <package>sssd-tools</package-->... außer die systembedingten Pakete, die habe ich mal herausgekürzt.
Edit: Und auf KVM Hosts darf dann noch `kexec-tools` nicht fehlen - sonst schläft man beim Reboot ein, während HP jeden Byte des Arbeitsspeichers mit der Lupe untersucht.
-
weshalb ich erst mal ein OS installieren müsste
Genau, für die rsync Beispiele welche ich genannt habe, musst du auf beiden Systemen rsync installiert haben. Am einfachsten klappt das dann, wenn am neuen System das selbe Betriebssystem läuft - andernfalls ggf. aufpassen, falls die neue Distribution unterschiedliche Pfade verwendet, und entsprechend anpassen.
-
Datenbanken
Was denn für Datenbanken? Auch in Docker oder auf dem Hostsystem? Falls am Hostsystem, relationale Datenbanken kann man normalerweise via mitgeliefertem Dump-Tool sehr einfach exportieren. Alternativ direkt den gesamten Datenordner (bei MySQL beispielsweise `/var/lib/mysql`) übertragen - ähnlich wie bei obigem Docker-Volumes Beispiel via rsync - aber sicherstellen, dass am neuen System keine ältere Version der Software installiert ist und dass der Service während der Übertragung gestoppt ist.
-
Da die Rede von Docker ist, frage ich mich ob es tatsächlich ratsam ist, den Threadersteller auf eine Reise mit Rettungssystem, `dd` und Snapshots zu schicken.
Wenn alles dockerisiert ist sollte es doch ausreichen, eine SSH Konnektivität zwischen beiden Maschinen aufzubauen, und die Dockerfiles/Composedateien zu übertragen. Ggf. dann auch noch die Volumes `/var/lib/docker` via rsync verschieben, wenn man nicht alle Images/Container neu bauen und eventuelle Nutzerdaten behalten möchte.
Auf dem alten Host Docker stoppen, auf dem neuen Host Docker installieren (aber nicht starten!), dann vom alten Host:
Code# rsync -aHhP --numeric-ids /var/lib/docker/volumes/ root@example.com:/var/lib/docker/volumesDanach auf dem neuen Host Docker starten, und Container via docker/docker-compose wieder hochfahren.
In diesem Beispiel natürlich die Root-Schlüssel danach schnell wieder entfernen und Root-Login wieder unterbinden. Alternativ auf den Zielhost mit regulärem User übertragen und dann Berechtigungen manuell wieder setzen - Docker ist da aber leider oft sehr sehr zickig, daher würde es sich meiner Meinung nach schon empfehlen, das kurz via root zu machen, damit das Zielsystem die Unix-Berechtigungen direkt beibehalten kann.
-
das Domain-Linking beibehalten
Domain-Produkte sind unabhängig von VPS/RS.
-
Das das gute alte Bootstrap darf meiner Meinung nach nicht unerwähnt bleiben.
Das ist doch pures JavaScript?
-
Nur da bekomme ich meine Struktur nicht so hin wie ich das möchte. Da vereinfacht das Block System Wp doch einiges.
Ich schreibe meist nur den HTML Teil selbst und binde mir irgendein CSS Framework ein, welches die Formatierung übernimmt.
-
Ping wird ausgeführt für emnovpn.com [212.123.41.108] mit 32 Bytes Daten:
Das klingt eher nach einer Auflösung zu deinem VPN Dienst o.ä.
-
< gar nicht von openSUSE's BtrFS/Snapper Rollback verwöhnt
-
Ist die Neu ? Bisher ist die nie gekommen.
Deine bisherigen Ausfällen dauern immer noch an?
-
Das Zielverzeichnis /usr/bin ( ~/usr/bin) liegt innerhalb der chroot.
Achso! Dann macht das schon Sinn.
-
Edit: /bin ist letztlich auch nur ein symbolischer Link auf /usr/bin
Vermutlich eher ein bind-mount o.ä., denn symbolische Links lösen in einer chroot nicht nach außen auf.
-
Man ist halt faul und nutzt die alten Scripts gerne weiter…
Faule Ausrede, gibt einen iptables zu nftables Konverter.
Edit: oh, ich war zu spät
-
Läuft auf denen (als Gastsystem) überhaupt noch irgendein unterstütztes OS?
Mich würde ja das Hostsystem interessieren, ernährt sich vermutlich vollständig von Backports.
-
"Fehler! Fehler beim Starten der Anwendung!"
Die Meldung verstehe ich nicht ganz, meinst du 0x8002342 ?
