Beiträge von GTAzoccer

Zitat von Bud

Frage zu Docker / Portainer: ufw installieren, default deny incoming, ssh-Port freigeben, aber alles andere macht Docker dann eh selbst und setzt sich über ufw hinweg - hab ich das richtig verstanden?

Docker setzt beim Starten eines Containers ein virtuelles Sub-Netzwerk auf dem Host auf. Damit dieser in diesem virtuellem Netzwerk von Außen überhaupt erreichbar ist, setzt er selbständig Forwarding-Regeln für die - nach Container-Konfiguration gewünschten - Ports. Das "umgeht" damit auch ggfs. bereits existieren Regeln.

Ob das nun Vor- oder Nachteil ist, kann jeder für sich entscheiden. Im Sinne von "einfach zu bedienen" und "soll funktionieren" sicherlich eher vorteilhaft.

Zitat von aRaphael

(Zumindest unter Linux. Ob das unter Windows auch so ist, weiß ich nicht)

Ich teste ja gerne selber, wenn ich die Möglichkeit dazu habe, anstatt mich auf gefundenes im Internet zu verlassen. Und weils mich gerade selbst interessiert hat.

$ df -h .
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/loop0p1     10G     52M   10G    1% /media/gtazoccer/Test
$ fallocate -l 1G test.file
fallocate: fallocate failed: Die Operation wird nicht unterstützt
$ truncate -s 1G test.file
$ truncate -s 100G test2.file
$ du -hs *
0    test2.file
0    test.file
$ du -hs --apparent-size *
100G    test2.file
1,0G    test.file
$ df -h .
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/loop0p1     10G     52M   10G    1% /media/gtazoccer/Test

NTFS hat damit kein Problem. Wenn auch fallocate hier anders arbeitet (vllt auch nur anders Prüft und zu falschen Ergebnissen kommt?) als truncate.

Bildschirmfoto vom 2024-02-24 12-42-17.png

Und Windows hat hier auch kein Problem mit.

Zitat von hoedlmoser

wie restorest Du dann die permissions?

Schau dir mal --fake-super in der rsync manpage an.

Zitat von aRaphael

Backups: Push or Pull?

Wie macht ihr das, wenn ihr Backups eines Servers auf das Backupmedium übertragt?

Schiebt der Server das aktiv dorthin oder holt sich das Ziel die Dateien ab (falls möglich)? Gründe?

Beides.

Meine Netcup-Server backuppen sich auf die jeweilig anderen zum Schutz der Daten vor Eigenversagen meinerseits. Hier "pusht" jeder in eine unprivilegierte Freigabe der jeweilig anderen. Grund: Die Server sollten keinen gegenseitigen Vollzugriff auf sich haben.

Komplettes Desaster-Recovery Backup, wenn Netcup versagt, wird von meinem Homeserver "gepullt". Gründe: Keine weltoffenen Ports auf mein Fullbackup und die Server können die Daten auch selbst nicht mehr löschen.

Zitat von Virinum

Könnte sich netcup nicht für die TLD .cup bewerben?

Sicher, dass das wünschenswert ist? TLD-Verantwortliche stellen doch auch die Root-DNS-Server der Zone ...

_{... duck und weg}

Zitat von aRaphael

Ich bin verwirrt...

Ich habe gerade einen heruntergeladenen snapshot mit zstd entpackt, um das raw-Image zu erhalten, welches ich dann wieder hochladen kann. (Siehe diesen Thread)

Das hat zstd auch anstandslos gemacht.

Allerdings zeigt mir ls -lh:

-rw-r--r-- 1 root root 640G Jan 23 20:36 image.raw

Also eine 640GB große Imagedatei (So groß wie die disks des Servers, von dem der snapshot stammt)

Was irritierend ist, da der Server auf dem die Dateien liegen, nur 320GB Platz hat.

Kann also nicht sein.

du -h * zeigt mir auch nur 15 GB an:

15G image.raw

Das ist nicht sehr viel mehr als die gepackte Datei und das wird wohl stimmen.

Warum zeigt mir hier ls sowas an?

(Ich sehe, es gibt Dinge in Linux, die sind mir neu)

Alles anzeigen

Schon mal mit fallocate rumgrespielt?

ls zeigt dir halt den "reservierten" Platz an, während du den tatsächlich genutzten/verbrauchten zählt.

Zitat von mainziman

Hallo

m_ueberall

GTAzoccer

welchen Window-Manager verwendet ihr?

(wäre ja nicht ganz auszuschließen, dass es daran liegt, aber WIESO?)

GTK/Gnome unter X11.

Wayland macht bei mir, bei einigen älteren Spielen, dann leider doch Probleme.

Zitat von mainziman

ich hab mal den .bz2 File von da downgeloadet

https://ftp.mozilla.org/pub/firefox/re…x-x86_64/en-US/

in ein Verz. entpackt und den File "firefox" ausgeführt,

egal welches Linux: Fedora, CentOS, Debian, auf allen des selbe verunstaltete ...

des ist echt nicht mehr lustig ...

ich wette,

dass wenn Du das da _banking.zip bei Dir entpackst und einen der beiden HTML-Files im Browser anschaust, sieht es genauso verunstaltet aus;

im Verz. _files sind ein paar JS-Files, ich werd aus denen nicht schlau ...

Alles anzeigen

Hm ... Um mal weitere Verwirrung einzustreuen: Also mein Firefox ESR auf meinem Debian (115.6.0esr / Standard Debian 12 Repository) zeigt die HMTLs wie auf dem Screenshot von m_ueberall an.

- Kein Unterschied zwischen Privater Modus und Normal.

- Kein Unterschied zwischen meinem personalisiertem Profil und einem neu angelegtem mit allen Einstellungen auf Default.

Zitat von Bud

Soeben auf sämtlichen Servern unattende-upgrades deaktiviert, um im Nachhinein folgendes zu lesen: Fixed in version linux/6.1.66-1

Kann ich unattende-upgrades nun wieder aktivieren, oder muss ich manuell eine Version irgendwie überspringen oder ähnliches?

Nein.

Erst wenn die gefixte Kernelversion auch im Repository ist.

https://packages.debian.org/bookworm/linux-image-amd64 holt aktuell immer noch die fehlerhafte.

Edit: Und zwanzig Minuten später ist die gefixte 6.1.66-1 im Link zu sehen. Also kann man so langsam wohl mit dem Upgrades beginnen. Aber das Paket bzw. dessen Version dabei sicherheitshalber im Auge behalten.

Zitat von Paul

Man muss nur sicherstellen, dass man in der /etc/fstab die Devices richtig angegeben hat (/dev/vdx mit virtio, /dev/sdx mit scsi).

Oder die Dateisysteme einfach direkt mit ihrer UUID definieren, dann ist der Name der Blockdevice-Inode vollkommen Wurscht.

Edit: Hm .. Zu langsam ...

Zitat von RAD750

pasted-from-clipboard.png

Das ist das erste Mal dass ich dieses Problem habe, kann mir da jemand bitte schnell helfen? Bisher hat das so immer funktioniert... Ist Debian 12

Aus der manpage von adduser.

--disabled-password

Ruft passwd(1) nicht zum Setzen eines Passworts auf. Allerdings sind in den meisten Fällen Anmeldungen weiterhin möglich (beispielsweise über SSH-Schlüssel oder PAM). Die Gründe hierfür liegen außerhalb der Verantwortung von adduser. --disabled-login wird zusätzlich die Shell auf /usr/sbin/nologin setzen.

--disabled-login wird zusätzlich die Shell auf /usr/sbin/nologin setzen.

Also vielleicht su mal zusätzlich mit --shell /bin/bash aufrufen?

Zitat von Bud

Weitere Grüße aus dem Urlaub mit einem weiteren meiner Hobbys

Pizza in Pools werfen? .-.

Ich finde ja viel interessanter, dass bei modernen Smartphones, die Bilder beim reinzommen irgendwie comichaft oder AI generiert aussehen. Sieht man hier ganz gut bei der Vegetation.

Zitat von ThomasChr

Klar, den Hersteller, aber eine wirklich schuldige Person wie bei den meisten altuellen Autounfällen hast du halt nicht.

Genau. Und mehr brauchst du bei einem fundamentalem Designfehler eines Produktes auch nicht. Die Schuld hat das Unternehmen. Wie die intern damit umgehen, ist ja deren Sache.

Und darum geht es mir ja. Wenn man bei einer neuen Technik erst die Frage stellen muss, wer den Schwund abfängt, dann ist unser stand der Technik halt einfach noch nicht bereit für die Masse. Es ist nicht die Lösung, den Big-Techs jetzt einen Freifahrtschein für Gammel-Software zu geben.

Zitat von ThomasChr

Und wie wir damit klarkommen dass Menschen einfach sterben weils halt ein Softwarefehler war und es keinen wirklich schuldigen gibt ist auch so ne Frage.

Woher kommt eigentlich die Mentalität, dass Softwarefehler keine Menschlichen Versagen sind?

Wenn ein physisches Bauteil einen Unfall begünstigenden Designmangel aufweist, kommt es schnell zu Rückrufaktionen und in der Produktentwicklung und/oder Management rollen Köpfe. Ggfs. kommen sogar Schadensersatzforderungen. Aber Softwarefehler sind Naturkatastrophen. Kann man nichts machen ... Da waren ja schließlich keine Menschen an Planung, Entwicklung und QS beteiligt.

Schon mal versucht eine "normale" Screensitzung zu öffnen und erst innerhalb dieser java -jar -Xmx6G spigot-1.20.1.jar nogu zu starten?

Dann würdest du zumindest schon mal die (Fehler-)Meldungen des Javaprozesses sehen können, weil sich Screen nicht mehr direkt nach dem Beenden schließt.

Rein theoretisch könnte man dann seinen Router neustarten für eine neue IP.
FritzBoxen haben sogar einen Button bei den Internetoptionen, der sie veranlasst eine neue IP anzufordern. Ohne Neustart. Also theoretisch.

Sollte du hinter CG-NAT stecken, ists allerdings ein Glücksspiel, ob du danach einem Neuen zugewiesen wirst.

IPv6? Erneuer einfach den DHCP-Lease deines PCs.

Beim rekonstruieren des Fehlers in einer VM, um dir sagen zu können, wie du erkennst ob er weg ist, ist mir noch eine Kleinigkeit aufgefallen.

Nach

dpkg-reconfigure openjdk-17-jre openjdk-17-jre-headless --force

Muss stattdessen ein

apt install ca-certificates-java

folgen. Das Paket ist nämlich nicht nur in einem unkonfiguriertem Zustand sondern die Installation vollständig gescheitert/abgebrochen.

Zitat von Bud

Wie kann ich mir den Fehler davor anzeigen lassen, und wie danach überprüfen, ob das funktioniert hat?

Um das nun aber zu beantworten.

Erstens wird dich jede Datenbank veränderte apt Aktion (apt install/autoremove/remove/purge usw.) an den inkonsistenten Zustand der drei Pakete erinnern, bis dieser Umstand behoben ist.

Zweitens zeigt dir dpkg --list ca-certificates-java openjdk* den Zustand der Pakete an.

Aus

+++-====================-============-============-=====================================
iF  ca-certificates-java 20230103     all          Common CA certificates (JKS keystore)
un  openjdk-11-jdk-headless       <keine>            <keine>      (keine Beschreibung vorhanden)
iU  openjdk-17-jre:amd64          17.0.7+7-1~deb12u1 amd64        OpenJDK Java runtime, using Hotspot JIT
iU  openjdk-17-jre-headless:amd64 17.0.7+7-1~deb12u1 amd64        OpenJDK Java runtime, using Hotspot JIT (headless)

sollte also

+++-====================-============-============-=====================================
ii  ca-certificates-java 20230103     all          Common CA certificates (JKS keystore)
un  openjdk-11-jdk-headless       <keine>            <keine>      (keine Beschreibung vorhanden)
ii  openjdk-17-jre:amd64          17.0.7+7-1~deb12u1 amd64        OpenJDK Java runtime, using Hotspot JIT
ii  openjdk-17-jre-headless:amd64 17.0.7+7-1~deb12u1 amd64        OpenJDK Java runtime, using Hotspot JIT (headless)

werden.

Das Problem hatte ich beim Upgrade von Debian 11 auf 12 ebenfalls. Hier drehen sich wohl leider die Abhängigkeiten des JRE und der Java Cert Library im Kreis.

Das heißt beide sind von einem vollständig installierten/konfigurierten Version des anderen abhängig. Was nicht funktionieren kann, wenn der Konfigurationsprozess von ca-certificates-java bereits java-code ausführt.

Meine Lösung war:

dpkg-reconfigure openjdk-17-jre openjdk-17-jre-headless --force
dpkg-reconfigure ca-certificates-java

Also die Konfiguration der JRE erzwingen und danach die Cert Library (normal) konfigurieren.

Zitat von Bud

Well... War nicht bewusst, aber warum darf ich das nicht machen?

Auch zu bedenken ist, dass Minecraft nie unter Annahme als root gestartet zu werden entwickelt wurde und somit keinen Privilege-Drop durchführt. Der Prozess/Dienst wird also alle Aufgaben weiterhin als root ausführen.

Und ein Dienst, der alle Netzwerk/User Inputs mit den höchsten Systemprivilegien verarbeitet, ist sicherheitstechnisch eine Katastrophe.