Der GNU/Linux-Thread

[Mit müden Augen]

Unfassbar, ich war hilfreich.

[oldfield2283]

Nicht ganz freiwillig habe ich gerade einen PC OHNE WINDOWS am Wickel, der soll eigentlich in den Schrott, vorher habe ich aber noch Linux Mint 18 installiert (HDD 80 GB, RAM 3 GB, lahm ohne Ende da mind.15 Jahre alt). Ich würde zum Spielen gerne noch ein paar Anwendungen installieren ua. Virtualbox und ein Win XP darauf (nur für mein dBase/Excel WM-Tippspiel natürlich...).

Problem: Das XP ist als Paket (ZIP) zu groß für meinen Stick (FAT32 also 4GB Dateigrößen-Limit).

Linux packt mir Dateien > 4GB ein und aus, Krusader macht das, habe ich schon probiert (der PC hat noch eine alte Windows-Platte drin, wo soviele Daten da waren). Aber wie bekomme ich Dateien > 4GB da rüber auf den Computer?!

Ich würde ungern die alte Platte aus- und in meinem Haupt-PC einbauen - nur im Notfall.

Ich könnte versuchen den Stick mit NTFS zu formatieren, dann sollte das sowohl gezippt als auch ungezippt (ca 20GB) drauf gehen.

Ich könnte den Stick mit EXT4 formatieren, aber dann liest ihn mein Haupt-PC nicht so ohne weiteres ein? OK unter Windows wohl nicht, aber ich habe noch ein Dualboot-Linux hier, das könnte das Kopieren übernehmen. Sicher gibt es wieder ein Berechtigungsproblem? denn den EXT4-Stick mußte ich gerade mit CHOWN adoptieren, damit ich ihn benutzen kann. Der User heißt aber unterschiedlich....

Aber ist das so das Standardverfahren? Wie transportiert man solche großen ZIPs von/nach Linux?

[Don Rosa]

Ich könnte versuchen den Stick mit NTFS zu formatieren, dann sollte das sowohl gezippt als auch ungezippt (ca 20GB) drauf gehen.

Wie wäre es mit exFAT statt NTFS?

[Prinzessinnenschreck]

Problem: Das XP ist als Paket (ZIP) zu groß für meinen Stick (FAT32 also 4GB Dateigrößen-Limit).

Man kann eine große Archivdatei auch zerlegen in handliche Teile. Unter anderem kann 7-zip das:
  https://www.newsgroupreviews.com/7-zip- ... chive.html
(Zum Entpacken muß man die Einzelteile nicht einmal mehr zusammenfügen, weil 7-zip auch mit dem aufgeteilten Archiv zurecht kommt.)

[oldfield2283]

Ich könnte versuchen den Stick mit NTFS zu formatieren, dann sollte das sowohl gezippt als auch ungezippt (ca 20GB) drauf gehen.

Wie wäre es mit exFAT statt NTFS?

Ja gute Frage, warum nicht exFAT, Ich kannte das bisher nicht (oder habe es ignoriert), aber Windows kann das formatieren und lesen und Linux auch. Ich habe jetzt 3 Sticks eingerichtet:
- NTFS (Windows und Linux Mint lesen und schreiben problemlos, auch mehr als 4 GB)
- exFat (ebenso)
- ext4 (mein Hauptrechner kann den im Dualboot Linux lesen und schreiben, der alte Zielrechner mit Linux sowieso)

Jetzt kommt das große Aber: auf allen 3 Sticks gab es Schreib-Lese-Fehler. Teils mit Abbruch, teils mit MD5 Fehler (ich checke das immer). Okay nun ist es müßig, darüber nachzudenken, ob die Sticks alle 3 im Arsch waren (es sind alte Bestände, die mein Freund im Pflegeheim hatte und "robust" damit umgegangen war, nicht trennen, 100.000 Einzeldateien draufschreiben usw. Oder ob der alte Zielrechner noch mehr Macken hat zB beim USB, könnte sehr gut sein. Egal, nun habe ich nach mehreren Kopierversuchen alles da und verifiziert. Es war doch ganz schön viel, die 80 GB sind voll und auch nur so nebenbei nimmt das viel Zeit und Nerven von mir. SIehe dazu auch die Antwort im nächsten Beitrag

[oldfield2283]

Problem: Das XP ist als Paket (ZIP) zu groß für meinen Stick (FAT32 also 4GB Dateigrößen-Limit).

Man kann eine große Archivdatei auch zerlegen in handliche Teile. Unter anderem kann 7-zip das:
  https://www.newsgroupreviews.com/7-zip- ... chive.html
(Zum Entpacken muß man die Einzelteile nicht einmal mehr zusammenfügen, weil 7-zip auch mit dem aufgeteilten Archiv zurecht kommt.)

Ja ich weiß, und ich nutze das auch ziemlich intensiv. Sowohl 7zip pur als auch eine selbstgestrickte Scriptlösung mit ARJ, ZIP und 7ZIP. Ich traue Einzeldateien über 1 GB auch selten und zerlege daher immer in 1 GB Päckchen. Das Problem hier war, die Päckchen sind alle im Windows entstanden (TotalCommander bzw mein Script) und ich hatte faul nicht alles "umpacken" wollen, so daß auch mein Krusader im Linux das versteht. Denn das war genau der Knackpunkt: Krusader brachte Fehler egal ob Linux/Krusader oder Windows gepackt hatte, die Archive waren alle mit einer merkwürdigen Fehlermeldung abgestürzt. Aber nur die "großen", wo Dateien > 1 GB oder so drin waren. Vielleicht auch ein Cache-Problem im Zielsystem. Keine Ahnung, also Lesefehler bei der ZIP selbst und dann wenn das heil drüben ist dann wieder Fehler beim Auspacken, das hat mich doch anständig genervt und das kenne ich so nicht.

Vielleicht wäre ich besser gefahren, wenn ich die ganze Software-Sammlung vor dem Kopieren einmal neu "umgepackt" hätte mit 7Zip vielleicht in 40 Päckchen je 1 GB - aber hinterher ist man immer schlauer.

Morgen wird der Rechner verschrottet, so oder so - Platte(n) raus, der Rest der Hardware ist knapp aus diesem Jahrhundert.

EDT: Hätte nie gedacht, daß es besser ist, eine 18 GB VDI Datei so auf den Stick zu übertragen, als letztlich 5x mit ZIP & Co zu scheitern, wobei die ZIPs eigentlich seit 3 Jahren existieren und mehrfach erprobt wurden auf 3 Rechnern schon....

[oldfield2283]

Nachtrag: PC hat ausgespielt, wurde auseinander genommen und nur die kleine Linux-Platte aufgehoben.

Was mir noch aufgefallen ist und vielleicht jemand anderes auch kennt? Linux tut sich furchtbar schwer mit dem Auspacken von 7z teils auch ZIP. Ja beim Auspacken, nicht beim Packen das würde ich ja verstehen, wenn 7zip erstmal loslegt, schreit mein Windows PC auch schon mal auf wie sonst nur beim Android-Studio. Aber nein, es ist NUR das Auspacken, und das dauert auch um den Faktor 10 länger, ist also furchtbar langsam (gewesen). Hat jemand anderes das auch beobachtet?

Ich bin sogar schon dazu übergegangen, mit folgendem Trick zu "schummeln": VirtualBox Windows XP auf, Zugriff auf den shared folder von Linux/Host und dann packt da der TotalCommander ganz normal schnell aus! Dann VirtualBox wieder zu. Das ist sicher von den Fans von Linux und Krusader nicht so geplant und akzeptierbar - aber es ist so, wiederholbar auch in anderen Linuxen. Beim 7zip bzw Zip auspacken bricht sich das System oder auch nur der Krusader dermaßen einen ab

[Mit müden Augen]

Nö, das muss an deinem System liegen. Ich habe hier Xfce+Xarchiver+7zip+die eigentlichen (Ent)packer für diverse Formate und es funktioniert prima.

[oldfield2283]

Es ist bei allen Linux die ich habe (Mint, Debian, Ubuntu, 32 oder 64bit, virtuell oder pur). Es könnte am Krusader oder den Archiver Erweiterungen liegen.

Ich habe es gestern extra noch mal ausprobiert. VirtualBox auf und XP mit Totalcommander, 7zip auspacken auf dem shared folder, 2GB Archiv und ca 50.000 Einzeldateien). In 4 Minuten hatte ich das. Dagegen direkt im Linux auspacken mit Krusader, da kannste schlafen gehen oder 2 Filme gucken. Zudem noch Abbruch wahrscheinlich wegen Pfad zu lang oder Namen mit falschen Zeichen.

Naja gut. Ich quäl mich halt so rum als Wanderer zwischen den Systemen. Und diesmal wollte ich mich mal ganz bewusst auf Linux verlassen ohne Windows Fallschirm... Aber geht nicht immer

[Mit müden Augen]

Hast du es mal direkt im Terminal versucht? Ist es da schneller?

Code: Alles auswählen

7z x archive.zip

EDIT: Interessant wäre auch ob der Kram multithread nutzt oder nicht. Was für eine CPU hast du (wie viele Kerne)? Mal mit einem passenden Tool (ich mag Mate-System-Monitor) die CPU-Last usw beim Entpacken beobachtet?

[uhu72]

Ein paar Gedanken meinerseits ...
Mate basiert auf Ubuntu welches auf Debian basiert. Wenn da ein systematischer Fehler in einem Paket steckt, werden alle drei darunter leiden.
Wenn das Entpacken unter einem anderen OS auf der selben Hardware schneller läuft, dürfte uns allen klar sein, dann ist es eine Softwareproblematik. Eine bekannte Hardwareproblematik ist die langsame Schreibgeschwindigkeit von elektronischen Speichermedien. So kann das Installieren einer Linux Distribution (ausschließlich Schreibvorgänge) auf einen USB Stick (oder vergleichbares) mal ein Vielfaches an Zeit benötigen gegenüber einer langsamen mechanischen Festplatte. Beim Systemstart, hauptsächlich lesen, ist es dann wieder anders herum.
Grundsätzlich kann es beim Entpacken von Archiven auf unterschiedlichen Systemen mit unterschiedlichen Textformaten und Fileformaten zu Problemen kommen. So muss man beim Entpacken von LHa Archiven von Amiga Systemen auch vorsichtig sein, die entpackt man auch besser auf einem Amiga, wenigsten einem emulierten. Einfache Textdateien sind wegen der unterschiedlichen Handhabung von Wagenrücklauf und Zeilenumbruch auch so ein Problemchen.
Krusader ist ja ein Filemanager von/für KDE, stellt sich die Frage, was der beim Aufruf eines Archives macht. Nimmt er das im System installierte zum Archiv passende Archivierungstool oder kommt er vielleicht auf die Absurde Idee, das Entpacken des Archives mit Hilfe einer eigenen, in einer Scriptsprache (schlechte Performence) geschriebenen Routine zu erledigen.
Der Mate System Monitor, ein Fork vom Gnome System Monitor, kann hier vielleicht Aufschluss geben. Neben Flaschenhälsen im System, zu wenig RAM oder zu schlappe CPU, sieht man ja auch, welcher Prozess am meisten System Ressourcen belegt.

Viel Erfolg!

[oldfield2283]

Ich habe Mint Cinnamon nicht Mate. Einen Sytemmonitor gibt es da auch, aber ich kam noch nicht dazu das zu analysieren. Nun gut, der kleine alte PC ist ja nun Schrott abet ich weiss, es tritt immer auf. Das mit dem 7z im Terminal kann ich auch mal probieren, vielleicht liegt es auch am 7z Format, das ist ja enorm rechenintensiv aber eigentlich eher beim Packen als beim Entspacken.

Die Hardware könnte eine Rolle spielen, so stark sind meine Rechner alle nicht und zumindest in den Linuxen im den virtuellen Maschinen hatte ich immer nur 1 höchstens 2 Kerne und wenig Ram. Fur mich bleibt erstmal als kurioser Fakt, das ich über den beschriebenen Umweg mit dem uralt Windows System um eine Größenordnung bis 10 schneller mit den Zip/7z umgehen kann als mit Krusader selbst. Ja KDE...

[Mit müden Augen]

Ich poste das mal hier, könnte interessant sein aber ich selber kann es nicht gucken (Geoblock...): https://www.ardmediathek.de/video/dokus ... MWIzYmI2Yg

Erzählt wird die Geschichte des legendären Chaos Computer Club (CCC) und seiner Gründerseele Wau Holland (Dr. Wau). Vom Computer-Nerd zum Datenkünstler, vom Einsiedler zum Medienstar, vom subversiven Hacker zum Verfechter der Demokratie: Der energiegeladene Dokumentarfilm zeigt mit cleveren Montagen, wie die großen Fragen der Gegenwart das Leben und Wirken Wau Hollands auch schon damals durchzogen.

[Mit müden Augen]

NedT: smartctl kann tatsächlich auch "SMART overall-health self-assessment test result: FAILED!" anzeigen/ausgeben. Das hatte ich bisher noch nie gesehen, auch nicht bei Platten die schon deutlich ramponiert waren.

[Reinhard]

Klingt danach: es ist Zeit für ein Backup. Entweder eins machen, oder eins rausholen.

[Mit müden Augen]

Da ist nicht viel zu sichern, ich hatte die Platte gerade gelöscht. Hab ich geschenkt bekommen, ungefähr "Lösch meine Daten und mach dann mit der Platte was du willst, ich brauche die nicht mehr" -> dd if=/dev/zero usw und dann routinemäßig smartctl. Das Ding ist wohl reif für den Elektroschrott...

EDIT: Der alte Eigentümer hat kaum Ahnung von IT, er wusste garantiert nichts über den schlechten Zustand der Platte.

EDIT2: 1+4x5

[The Poet]

EDIT2: 1+4x5

Ohoooo!

Noch 49981 bis zum Integer-Overflow.

(Bzw. 17213, falls jemand vorher ein "stop sign[ed]" hochhält... und zwar der signed-int-dude.)



Also... sofern es ein uint16_t ist. Anderenfalls (uint32_t/int32_t) hast du noch jede Menge Holz zu hacken. ^^

[Mit müden Augen]

Es dürfte wohl uint64_t sein, das schafft selbst ein Bot nicht...

[The Poet]

Es dürfte wohl uint64_t sein, das schafft selbst ein Bot nicht...

Das schafft nur Nuck Chorris!

[The Poet]

Da Technikfragen im Gegensatz zu Fragen zu Psychologie, dem Universum, dem Leben und dem ganzen Rest meistens lösbar sind ... vielleicht hatte jemand von euch schon mal dieses Problem... ich komm nicht weiter, und bevor ich weiter Unsummen an Lebenszeit da reinstecke:

Thema: ACLs

Mein tägliches Server-Backup-Script (rsync) rennt immer gegen die Wand, weil ein Ordner nicht die korrekten rights gesetzt hat - das könnte man manuell vorher rekursiv mit "setfacl -R usw." fixen, aber eigentlich *sollte* das Problem gar nicht auftreten, da ich default ACLs gesetzt habe, die dem backupuser (der per SSH von remote das Backup fährt und das komplette /home [da liegen nicht nur User-Daten drin, sondern auch /var/www, bzw. das "echte" /var/www softlinked auf einen Unterordner im /home] des Servers auf ein entferntes Gerät dupliziert) automatisch jede Datei zugreifbar machen sollten (durch default-ACL-Vererbung über die directories, wissenschon). Klappt aber offenbar nicht.

Ganz konkret hab ich das Problem jetzt eingegrenzt auf das Folgende. Also der Reihe nach:

/home sieht so aus (die beiden wichtigen Zeilen sind mit "############" markiert):

Code: Alles auswählen

me@server:$ getfacl /home
# file: home
# owner: root
# group: root
user::rwx
user:backupuser:r-x    ############
group::r-x
mask::r-x
other::r-x
default:user::rwx
default:user:backupuser:r-x    ############
default:group::r-x
default:mask::r-x
default:other::r-x

und darin sind die User-Ordner wie zum Beispiel:

Code: Alles auswählen

me@server:$ getfacl /home/userx
# file: home/userx
# owner: userx
# group: userx
user::rwx
user:backupuser:r-x    ############
group::r-x
mask::r-x
other::r-x
default:user::rwx
default:user:backupuser:r-x    ############
default:group::r-x
default:mask::r-x
default:other::r-x

Ein als root manuell ausgeführtes

"mkdir /home/neu"

erstellt wie zu erwarten einen neuen leeren Ordner mit diesen ACLs:

Code: Alles auswählen

root@server:$ getfacl /home/neu
# file: neu
# owner: root
# group: root
user::rwx
user:backupuser:r-x    ############
group::r-x
mask::r-x
other::r-x
default:user::rwx
default:user:backupuser:r-x    ############
default:group::r-x
default:mask::r-x
default:other::r-x

...und

"touch /home/userx/testfile"

oder

"mkdir /home/userx/testdir"

erzeugt ebenfalls neue Dateien und Ordner mit gesetztem ACL "user:backupuser:r-x" (bzw. zusätzlich "default:user:backupuser:r-x" bei directories).

Also soweit alles tutti.


→ Jetzt das, wo es hakt:

Jedes Mal, wenn ich einen neuen User anlege ("adduser --disabled-password kangaroo") und Stück für Stück die neuen Dateien & Ordner wie .profile, .bash_history, .bashrc, .nano im Ordner /home/kangaroo auftauchen (plus: es kommt - direkt nach dem "adduser ..." - auch noch ein ".ssh"-Ordner dazu, den ich samt dem [zu dem Zeitpunkt noch leeren] ".ssh/authorized_keys"-file automatisch von dem sh-Script anlegen [und auf chmod 600 bzw. 700 setzen] lasse, das vorher das besagte "adduser --disabled-password kangaroo" ausführt), bekommt - völlig random, scheinbar - maximal nur ein Teil der Dateien die "user:backupuser:r-x"-ACL-Info (bzw. zusätzlich die default-ACL, wie gesagt, bei directories) vererbt .

Ich habe noch nicht rausgefunden, welche Dateien das sind ... also ob "nur Ordner" oder "nur Dateien mit einem führenden Punkt" oder was auch immer. ".nano" z.B. hat zwar eine ACL bekommen, die enthält aber nur ein:

Code: Alles auswählen

root@sever:$ getfacl /home/kangaroo/.nano
# file: .nano
# owner: kangaroo
# group: kangaroo
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::r-x
default:mask::r-x
default:other::r-x

(Das könnte aber auch von einem anderen automatischen Script gekommen sein, muss ich noch mal schauen, dass ich diese Möglichkeit ausschließe.)

".ssh" hingegen scheint die default-ACL mit der backupuser-Info zu haben (auch wenn ich grad nicht 100%ig sicher bin, ob ich das aus Versehen beim Probieren gerade aus Versehen manuell hinzugefügt habe ... kann gut sein, denn dort ist zwar die default ACL vorhanden, aber dafür nicht die normale "user:backupuser:r-x" ).

Die anderen Dateien haben allesamt gar keine ACLs - außer die, die ich jetzt im Nachhinein manuell via Shell in dem Ordner anlege.


Also schlimmstenfalls ist es relativ unvorhersehbar, bestenfalls ist meine Beobachtungsgabe gerade etwas getrübt (oder ich habe zuviel random "monkey-getippt & -getestet") und gar keine Datei bekommt eine ACL vererbt (die vorhandenen ACLs kämen dann von mir gerade), aber selbst im besten Fall:

Das soll so ja nicht sein!

"/home" hat definitiv einen default ACL für den backupuser gesetzt, sobald der neue Ordner "/home/kangaroo" angelegt wird, bekommt dieser automatisch die ACLs "user:backupuser:r-x" & "default:user:backupuser:r-x", und als letztes sollten ja alle neuen Objekte in "/home/kangaroo" automatisch die ACLs "user:backupuser:r-x" und bei directories auch "default:user:backupuser:r-x" erben.

Tun sie aber nicht. (Außer, wie gesagt, die manuell von mir in einer regulären Terminal-Session erzeugten.)

Hatte jemand von euch schon mal was Vergleichbares und hat rausbekommen, was dahinter steckte?