[SAMMELTHREAD] Linux Kurze-Frage-Kurze-Antwort (KFKA)

[Evilandi666]

Ha da ist er schon, der Linux KFKA Sammelthread!

Ihr habt Fragen rund um Linux für die ein eigener Thread zu schade wäre? Dann könnt ihr sie hier stellen.

Ich fange mal an: Was ist denn bei ubuntuuusers.de los? Das sieht ja mal total komisch aus bei denen

Edit: Okay, bei mir hat sich das mobile theme im Browser aktiviert - warum auch immer. Jetzt sieht es wieder normal aus (ganz unten ist der Link zur klassischen Version.)

 

[jal2]

Mag mir mal jemand beim Aufdröseln von zwei Konsolenbefehlen helfen?

Backup:
tar -cl -b 512 -f - ./ 2>/dev/null | /usr/local/bin/mbuffer -L -s 256k -m 1G -P 85  > /dev/nst0
Wiederherstellung:
< /dev/nst0  /usr/local/bin/mbuffer -L -s 256k -m 1G -p 25 | tar -xb 512 -f - 2>/dev/null

Wenn ich das richtig verstehe, wird das aktuelle Verzeichnis ("./") genommen und mit tar in ein Archiv gepackt ("-c"), mit Blöcken zu 512x512=256kB ("-b 512") aber was genau macht -l? Man-Page sagt "print a message if not all links are dumped" aber irgendwie bin ich mir nicht ganz sicher, was dass bedeutet.

Das Output-Archiv bzw. der Stream wird dann auf die Standardausgabe gegeben ("-"), Fehlermeldungen (stderr) werden in /dev/null geschoben ("2>/dev/null"). Bis dahin richtig?

Ja, wobei IMHO das "-f -" beim tar weggelassen werden kann, stdout ist die Defaultausgabe.

Dieser Stream wird dann in mbuffer geschoben, dessen Buffer im RAM gelockt wird ("-L") - was auch immer das bedeutet. Der nutzt dann 256kB große Blöcke ("-s 256k") und insgesamt puffert er 1GB ("-m 1G"). Wenn der Puffer zu 85% oder mehr gefüllt ist, gibt er seine Daten wieder aus ("-P 85").
Was ich nun nicht verstehe: Wieso wird das Ergebnis mit > und nicht mit | auf das Bandlaufwerk (/dev/nst0) geschoben?

Weil /dev/nst0 kein Kommando, sondern ein Device ist, hinter einer Pipe muss ein Kommando stehen. Gelockter Buffer heisst, dass dieser vom Kernel nicht ins Swap gelagert werden kann.
Das Problem bei den Bandlaufwerken ist AFAIK, dass sie, wenn sie angelaufen sind, immer Daten als Input erwarten, sie können nicht anhalten und warten, wenn keine Daten vorhanden sind. Wenn der Buffer erst aus dem Swap gelesen werden muss, kann genau das aber passieren.

Der Rückweg dürfte ja genau das gleiche sein, nur eben umgekehrte Reihenfolge, aber ich hab noch nie die Art gesehen, einen Stream auszulesen/auszugeben ("< /dev/nst0" statt irgendwas mit der Pipe). Mag mir das jemand kurz erklären, was das bedeutet?

Wie oben: /dev/nst0 ist ein Device, kein Kommando. Eine längere Form wäre:

cat /dev/nst0 | /usr/local/bin/mbuffer ...

 

[cuco]

Ah super! So ergibt es Sinn, danke

Hab bisher immer buffer statt mbuffer genommen und mit -o das Output-Device angegeben, da war diese Notation neu für mich

 

[.Sun]

Ich muss seit heute morgen vor jedem startx die Rechte für /tmp anpassen. Genauer sieht es nach jedem reboot so aus

drwxr-xr-x   9 root root     0 30. Nov 12:35 tmp

. (Das führt bei KDE-Start zu einem "...lnusertemp failed...".

Woran kann das liegen? Möglicherweise an einem der folgenden Paketen?

[2015-11-27 16:32] [PACMAN] Running 'pacman -Syu'
[2015-11-27 16:32] [PACMAN] synchronizing package lists
[2015-11-27 16:32] [PACMAN] starting full system upgrade
[2015-11-27 16:33] [ALPM] transaction started
[2015-11-27 16:33] [ALPM] upgraded glib2 (2.46.2-1 -> 2.46.2-2)
[2015-11-27 16:33] [ALPM] upgraded libdbus (1.10.2-1 -> 1.10.4-1)
[2015-11-27 16:33] [ALPM] upgraded dbus (1.10.2-1 -> 1.10.4-1)
[2015-11-27 16:33] [ALPM] upgraded harfbuzz (1.1.1-1 -> 1.1.2-1)
[2015-11-27 16:33] [ALPM] upgraded calibre (2.44.1-1 -> 2.45.0-1)
[2015-11-27 16:33] [ALPM] upgraded harfbuzz-icu (1.1.1-1 -> 1.1.2-1)
[2015-11-27 16:33] [ALPM] upgraded opus (1.1-1 -> 1.1.1-1)
[2015-11-27 16:33] [ALPM] upgraded thunderbird (38.3.0-3 -> 38.4.0-1)
[2015-11-27 16:33] [ALPM] upgraded thunderbird-i18n-de (38.3.0-1 -> 38.4.0-1)
[2015-11-27 16:33] [ALPM] transaction completed
[2015-11-29 18:30] [PACMAN] Running 'pacman -Syu'
[2015-11-29 18:30] [PACMAN] synchronizing package lists
[2015-11-29 18:30] [PACMAN] starting full system upgrade
[2015-11-29 18:30] [ALPM] transaction started
[2015-11-29 18:30] [ALPM] upgraded bash (4.3.042-3 -> 4.3.042-4)
[2015-11-29 18:30] [ALPM] upgraded kmod (21-2 -> 22-1)
[2015-11-29 18:30] [ALPM] upgraded libsystemd (227-1 -> 228-3)
[2015-11-29 18:30] [ALPM] upgraded libutil-linux (2.27-6 -> 2.27.1-1)
[2015-11-29 18:30] [ALPM] upgraded util-linux (2.27-6 -> 2.27.1-1)
[2015-11-29 18:30] [ALPM] upgraded systemd (227-1 -> 228-3)
[2015-11-29 18:30] [ALPM] upgraded cups-filters (1.1.0-4 -> 1.2.0-1)
[2015-11-29 18:30] [ALPM] upgraded device-mapper (2.02.133-1 -> 2.02.134-1)
[2015-11-29 18:30] [ALPM] upgraded gnutls (3.4.6-1 -> 3.4.7-1)
[2015-11-29 18:30] [ALPM] installed dcadec (0.1.0-1)
[2015-11-29 18:30] [ALPM] upgraded ffmpeg (1:2.8.2-1 -> 1:2.8.3-1)
[2015-11-29 18:30] [ALPM] upgraded libgit2 (1:0.23.3-1 -> 1:0.23.4-1)
[2015-11-29 18:30] [ALPM] upgraded lvm2 (2.02.133-1 -> 2.02.134-1)
[2015-11-29 18:30] [ALPM] upgraded nano (2.4.2-2 -> 2.4.3-1)
[2015-11-29 18:30] [ALPM] upgraded python-setuptools (1:18.6.1-1 -> 1:18.7-1)
[2015-11-29 18:30] [ALPM] upgraded python2-setuptools (1:18.6.1-1 -> 1:18.7-1)
[2015-11-29 18:30] [ALPM] upgraded systemd-sysvcompat (227-1 -> 228-3)
[2015-11-29 18:30] [ALPM] transaction completed
[2015-11-29 18:30] [PACMAN] Running 'pacman --color auto -Sy'
[2015-11-29 18:30] [PACMAN] synchronizing package lists

 

[vlooe]

Eigentlich jedes init system bietet die möglichkeit, dass bei einem neustart /tmp geleert bzw neu angelegt wird.
In deinem Fall ist das systemd.

Um das Probelm zu lösen musst du systemd umstellen.
Entweder /tmp behalten und 1mal rechte von hand anpassen.
Oder in der systemd config die passenden rechte setzten.

Da ich systemd nicht verwende kann ich dir leider keine genauere lösung beschreiben.

 

[.Sun]

Danke. Systemd wars. Ich habe als temporäre Lösung erst einmal auf 227-1 downgegraded. Mir die config anzugucken hab ich gerade keine Zeit.

Ich musste bei jedem Neustart die Rechte anpassen (#chmod 1777 /tmp). Ist vielleicht aus dem Post nicht ganz klar geworden.

 

[vlooe]

Hab schon verstanden dass /tmp jedes mal falsch angelegt wird.
Ich formuliere es nochmals anders.:thumbup:

An einer config änderung kommst du nicht vorbei.
Entweder systemd so einstellen, dass es /tmp nicht mehr löscht.(einmal rechte von hand setzen nötig)
Oder systemd so einstellen, dass es /tmp mit den richtigen rechten löscht und neu anlegt.

 

[SammysHP]

systemd erledigt das über folgende Datei: /usr/lib/tmpfiles.d/tmp.conf

 

[.Sun]

227-1

# Clear tmp directories separately, to make them easier to override
v /tmp 1777 root root 10d
v /var/tmp 1777 root root 30d

228-3

# Clear tmp directories separately, to make them easier to override
q /tmp 1777 root root 10d
q /var/tmp 1777 root root 30d

Das wars.

@vlooe: Dann hab ich dich wohl falsch verstanden

 

[SammysHP]

v: Create a subvolume if the path does not exist yet, the file system supports subvolumes (btrfs), and the system itself is installed into a subvolume (specifically: the root directory / is itself a subvolume). Otherwise, create a normal directory, in the same way as d. A subvolume created with this line type is not assigned to any higher-level quota group. For that, use q or Q, which allow creating simple quota group hierarchies, see below.

q: Similar to v. However, makes sure that the subvolume will be assigned to the same higher-level quota groups as the subvolume it has been created in. This ensures that higher-level limits and accounting applied to the parent subvolume also include the specified subvolume. On non-btrfs file systems, this line type is identical to d. If the subvolume already exists and is already assigned to one or more higher level quota groups, no change to the quota hierarchy is made. Also see Q below. See btrfs-qgroup(8) for details about the btrfs quota group concept.

Ist recht neu, sollte das aber nicht beeinflussen. Die Rechte sind ja gleich geblieben. Nutzt du ein festes Verzeichnis oder ein tmpfs (vgl. /usr/lib/systemd/system/tmp.mount)?

 

[cuco]

Noch eine Ergänzung zu #2101 bzw. #2102 - das ganze funktioniert nur, wenn das Archiv auf ein Tape passt. Bei Archiven größer als ein Tape klappt es nicht, die Ausgabe mit > aufs Tape zu schieben. Am Ende des Tapes kommt zwar die Meldung, man solle das Tape wechseln, aber mit neuem Tape wird dann die Meldung ausgegeben, dass das ganze "read only" sei. Daher gebe ich nun doch wieder mit "-o /dev/st0" (bzw. /dev/nst0) das Output-Device an, anstatt es mit > rüberzuschieben. Man zu mbuffer sagt zum "-o" auch "needs to be given for multi volume support". Scheint also wohl bekannt zu sein, dass es mit > nicht geht.

Falls es jemanden interessiert, der mal via Google hier drauf stößt, ich nutze nun

tar -clpM --acls --totals -b 256 -V="[Kommentar]" -f - Verzeichnis1 Verzeichnis2 | mbuffer -L -s 256k -m 4G -P 85 -v 4 -o /dev/st0

 

[jal2]

Falls es jemanden interessiert, der mal via Google hier drauf stößt, ich nutze nun

tar -clpM --acls --totals -b 256 -V="[Kommentar]" -f - Verzeichnis1 Verzeichnis2 | mbuffer -L -s 256k -m 4G -P 85 -v 4 -o /dev/st0

Wie schon oben gesagt, mindestens beim GNU tar kannst Du

-f -

weglassen, die Ausgabe auf stdout ist Default.
Was macht

-v 4

beim mbuffer?

 

[cuco]

Was macht

-v 4

beim mbuffer?

Setzt das Verbose-Level auf "Information messages". Meine Ausgabe mit dem obigen kompletten Befehl sieht dann z.B. so aus:

mbuffer: Numblocks = 16384, Blocksize = 262144, totalmem = 4294967296
mbuffer: allocating memory for 16384 blocks with 262144 byte (4194304 kB total)...
mbuffer: memory locked successfully
mbuffer: blocksize is 4096 bytes on output device
mbuffer: no device on input stream
mbuffer: inputThread: starting with threadid 139822910174976...
in @ 138 MB/s, out @ 138 MB/s, 1413 GB total, buffer 100% full
mbuffer: end of volume - last block on volume: 5787378
mbuffer: time for writing volume: 3:04:52.805981
in @ 0.0 kB/s, out @ 0.0 kB/s, 1413 GB total, buffer 100% full
volume full - insert new media and press return when ready...
in @ 0.0 kB/s, out @ 0.0 kB/s, 1413 GB total, buffer 100% full
mbuffer: tape-change took 33603.674456sec. - continuing with next volume
OK - continuing...
in @ 139 MB/s, out @ 139 MB/s, 2736 GB total, buffer 100% full
[...]

 

[.Sun]

Ist recht neu, sollte das aber nicht beeinflussen. Die Rechte sind ja gleich geblieben. Nutzt du ein festes Verzeichnis oder ein tmpfs (vgl. /usr/lib/systemd/system/tmp.mount)?

Mit v geht es, mit q nicht. Mit q werden die Rechte aber auch nicht richtig gesetzt.

tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1200988k,mode=700,uid=1000,gid=100)

Hilft dir das weiter?

 

[SammysHP]

Keine Ahnung, gestern Abend aktualisiert und es geht absolut problemlos. Irgendwas wirst du gemacht haben, das von der Standardkonfiguration abweicht.

 

[cuco]

Kann ich irgendwie den Tastaturbuffer leeren, bevor ein Programm die Eingabe angenommen hat? Oder wo auch immer das ganze zwischengespeichert wird?

Hatte gestern Abend folgendes Problem: In dem Terminal/Screen, in dem mein Backup lief, habe ich aus Versehen Enter gedrückt. Die Software hat natürlich weiter gearbeitet und Stunden später vermeldet, dass das Medium (Tape) voll sei und ich bitte ein neues einlegen solle, was ich am Ende mit Enter bestätigen soll. Offenbar hat es mein Enter von ein paar Stunden zuvor noch im Buffer gehabt und als Quittierung aufgefasst. Daraufhin wurde mein Tape mit dem nächsten Teil des Backups wieder komplett überschrieben, wie ich eben feststellen musste. Mit einem fehlenden Teil bringt einem das ganze Backup nichts mehr und die 18 Stunden waren für die Katz Kann ich sowas irgendwie beim nächsten mal verhindern und mich gegen ein gepuffertes Enter oder ein im falschen Fenster ausgeführtes Strg+C "wehren"? Immerhin dauert der ganze Vorgang gut 30 Stunden und alle 3 Stunden muss das Medium einmal gewechselt und der Wechsel mit Enter bestätigt werden. Wenn man das Fenster nebenbei die ganze Zeit offen hat, um zu schauen, wie weit er ist und ob der nächste Medienwechsel ansteht, dann kann man schon mal schnell aus Versehen eine Eingabe absetzen, wenn das Fenster aus Versehen im Fokus ist.

 

[cuco]

Ich habe hier eine HDD mit LUKS. Diese lässt sich per Keyfile und per PW entschlüsseln. Keyfile ist noch vorhanden, das PW leider nicht mehr. Wie kann ich rausfinden, welcher der beiden Keyslots zu dem PW gehört, damit ich den Slot löschen kann?

 

[blafoo]

https://wiki.ubuntuusers.de/LUKS#Passwoerter-verwalten

Schau mal hier, über dump solltest du an die Infos kommen und dann kannste die löschen.

Grüße

 

[cuco]

Leider eben nicht...

luksDump spuckt nur folgendes aus (ein paar Werte ausge-x-t).

Daraus kann ich leider nicht erkennen, welcher Slot was ist.

LUKS header information for /dev/sdb

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha1
Payload offset: 4096
MK bits:        512
MK digest:      [xxx]
MK salt:        [xxx]
                [xxx]
MK iterations:  75375
UUID:           [xxx]


Key Slot 0: ENABLED
        Iterations:             305489
        Salt:                   [xxx]
                                [xxx]
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: ENABLED
        Iterations:             306219
        Salt:                   [xxx]
                                [xxx]
        Key material offset:    512
        AF stripes:             4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED

 

[blafoo]

Dann würd ich einfach ein neues PW hinzufügen, die 2 alten entfernen, somit wandert das neue PW auf Slot1 und dann ggf. noch nen Keyfile wieder hinzufügen.

Achja ... und du weist ja .. Backup

 

[linrunner]

Das Wiki sagt:

Diesen [Slot] findet man am einfachsten heraus, wenn mit cryptsetup luksOpen -v einen Container oder eine Partition einhängt. Dort ist dann auch der Slot angegeben, der, basierend auf dem Schlüssel, benutzt wurde.