Fájlnévkódolás (Latin2->UTF8) és UID/GID remap (POSIX ACL-ekkel)?

Linux-haladó

Sziasztok!

 Egy ősi "mindenes" SaMBa@Linux szerverről kellene egy újra átmásolnom egy telepítés alatt álló SaMBa szerverre több TB-nyi fájlt úgy, hogy másolás közben a fájlok neve Latin2-ről UTF8-ra konvertálódjon, illetve figyelembe kell venni, hogy a két szerveren ugyanazon az user- és csoportnevekhez más UID/GID tartozik. Másolás közben tehát valahogy "remapelni" kell a fájlokon az UID/GID értékeket, ráadásul nem csak az alap UNIX értékekben, hanem rengeteg POSIX ACL-ben is.

 Ezen felül csak hab a tortán, hogy kvóta-értékeket is át kellene vinni.

 Ismertek ilyen eszközt, ami kifejezetten ilyen célra készült, vagy szkriptelnem kell valamit?

 Esetleg ha van itt a HUP-on olyasvalaki, aki jártas az ilyen jellegű migrációban, igénybe vennénk a szolgáltatásait, ha rövid határidővel meg tudja oldani a problémát.

( Tom | 2023. 03. 14., k – 14:04 )

Szerkesztve: 2023. 03. 14., k – 14:05

Anno a gordiuszi csomót úgy ugrottam meg hogy egy windows-ra felcsatoltam a régi és az új megosztást majd robocopy-val átmásoltam, majd a jogosultságkat kézzel utánaállítottam.

Most lehet kipróbálnám a convmv-t, a jogosultságokra meg maradna a skriptelés.

convmv jo cucc, engem soxor kihuzott a kakibol hasonlo migralasok utan.

uid/gid mappelest pedig a tar elintezi, ha az userek fel vannak mar veve az ujon passwd/group fileokba az uj id-kkel.

en igy szoktam:   ujgep:/datadir/# ssh regigep tar -cpf - /datadir | tar -xf -

a tar eloszor a nev alapjan keresi az usert/groupot, es az id-t a local konfigbol szedi, kiveve a --numeric-owner opcioval.

( Elbandi v | 2023. 03. 14., k – 14:20 )

rsync tud usernev/group szerinti masolast. ha meg a masolas alatt nem irnak az osi sambara, akkor csinalj egy hardlink copyt rola (cp -al) egy uj konyvtarba, ott atnevezed a fajlokat utf8-ra (convmv), es azt masolod rsync-el

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( Zahy v | 2023. 03. 14., k – 15:21 )

Szerkesztve: 2023. 03. 14., k – 15:25

Hát NFSv4 tud uidmappinget is, és ACL-eket is. Azaz a régi Samba szerveren kiajánlod a fájlrendszert, az újon pedig felmountolod. Készítesz egy lokális másolatot (pl. pax-szal / cp -ra -val) és a lokális másolatra ráengeded a fenti convmv-t.

De ez csak tipp, sose csináltam ilyet. Esetleg meg lehetne nézni, hogy modern tar / cpio - amelyik már elmenti az extended attributumokat is (azaz pl. ACL) - hogy viselkedik ilyen helyzetben.

Ja, a kvóta értékeket mentsd ki a túloldalon és állítsd be az újon. (Megnézném még a dump / restore parancsokat is, de nem hiszek benne, ott az uidmapping-gal lesz gond.)

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Várjunk csak... Mi van, ha egy GNU tar-t olyan chroot környezetbe rakok, ahol a régi UID-ek és GID-ek érvényesek, és egy pipe-on keresztül egy másik tar-ba átszívatom a cuccot...

Ezt mondjuk az ACL-ekre is ki kellene próbálni. Vagy netcattal átszívatni egyik szerverről a másikra... Akkor chroot és szerverleállás sem kell...

( NevemTeve | 2023. 03. 14., k – 18:32 )

Off: Sokat foglalkoztam az ékezetes betűk gondjaival, sikerült is hasznos tanulságot levonnom az ékezetes betűket tartalmazó fájlnevekre vonatkozóan is: törölni kell a francba az ilyen fájlokat.

( ggallo | 2023. 03. 14., k – 23:29 )

Az rsync tud iconv-al dolgozni! Én másoltam így át Latin2-es FreeBSD-ről UTF8-as Debian-ra szintén Samba megosztás alatt lakó ékezetes nevű állományokat sikerrel.
A szintaxis: --iconv=local,remote (pl. új szerveren futtatva --iconv=utf8,iso88592) A legnagyobb gondom az volt, hogy a FreeBSD-s rsync alapból iconv nélkül került fel ports-ból és újra kellett fordítanom ezzel az opcióval.

Az UID/GID viszont szerintem script lesz, én sem hallottam még olyan tool-ról, amit ezt megoldaná automatikusan.

Én úgy állnék neki, hogy az rsync után az UID/GID-et fájl szinten rendbe tenném egy script-tel (egy uid/gid megfeletető táblát használva simán find PATH -user OLD -exec chown -h NEW {} \; és ugyan ez a csoportokra)
A jogosultságokat meg úgy, hogy getfacl a teljes eredeti struktúráról fájlba, ott lecserélném az összes érintett értéket, majd az új helyen setfacl a teljes struktúrára a szerkesztett fájlból.

Mondjuk én inkább megtartanám az UID/GID-et az eredetit, és akkor az rsync után kész vagyok (persze csak ha nem muszáj változtatni műszaki okból)...

( Zs | 2023. 03. 15., sze – 07:43 )

Az UID/GID konverzió nem egyszerű, különösen nem akkor, amikor ACL-lel is meg van fűszerezve az egész.

Ha ez új telepítésű rendszer, akkor mennyire ördögtől való az, hogy összes user/csoport gyalu, újra létre hoz, de létrehozáskor szigorúan megadva, hogy melyik user milyen UID-del, melyik csoport milyen GID-del kerüljön létre hozásra?
Elsőként a csoportokat célszerű létre hozni, mert az user létrehozáskor mindenképp kap egy default csoportot, aminek tagja - nem haszontalan, ha ekkor a kérdéses csoport már létezik.

el kene olvasni az rsync mant:

       -o, --owner
              This option causes rsync to set the owner of the destination file to be the same as the source file, but only if the receiving rsync is being run as the  super-user  (see
              also the --super and --fake-super options).  Without this option, the owner of new and/or transferred files are set to the invoking user on the receiving side.

              The  preservation of ownership will associate matching names by default, but may fall back to using the ID number in some circumstances (see also the --numeric-ids option
              for a full discussion).

       -g, --group
              This option causes rsync to set the group of the destination file to be the same as the source file.  If the receiving program is not running as  the  super-user  (or  if
              --no-super  was  specified),  only  groups  that  the  invoking user on the receiving side is a member of will be preserved.  Without this option, the group is set to the
              default group of the invoking user on the receiving side.

              The preservation of group information will associate matching names by default, but may fall back to using the ID number in some circumstances (see also the --numeric-ids
              option for a full discussion).

szoval ha a forras oldalon mancika 123 idvel van, de a cel oldalon 234 id, akkor az rsync jol bellitja a uid/gui-et, hogy tovabbra is mancika legyen az owner.

De ha meg ez se lenne jo, akkor ott van a        --usermap=STRING, --groupmap=STRING opciok.

vegszukseg eseten meg ottvan a find, amivel lehet generalni chown parancsokat:

find -printf "chown %u:%g %p\n" >ezt_kell_a_celhelyen_futtatni.sh

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

ha már man és idézgetés, akkor - az eredeti probléma ismeretében - én nem hagynám ki az alábbi kapcsolót sem:

       -A, --acls
              This option causes rsync to update the destination ACLs to be the same as the source ACLs.  The option also implies --perms.

              The source and destination systems must have compatible ACL entries for this option to work properly.  See the --fake-super option for a way to backup and restore ACLs  that  are  not
              compatible.
 

( nice | 2023. 03. 16., cs – 09:05 )

Mivel a forrásgép oprendszere olyan régi, hogy a rajta lévő GNU tar nem támogatja még az ACL-eket sem, a hálózaton keresztüli átszívatás nem fog menni :-( Most viszont az az ötletem, hogy a VMware backendjéül szolgáló storage megfelelő NFS kötetét kiajánlom az új VM-nek közvetlen 10Gb-os hálózaton keresztül, és egy snapshotban lévő - pár órás - VMDK-t felmountolok loop + device mapper segítségével úgy, hogy RW eszköz legyen belőle (mert az ext3 mount, pláne az esetlegesen szükséges fsck RO blokkezsközön nem működik), és helyben próbálkozok az UID/GID konverzióval rsync vagy GNU tar és convmv segítségével.

Ezután már csak az a kérdés, hogy egy új - 4.16-os - SaMBa hogy dolgozza fel, hogy POSIX ACL-ek vannak alatta. Nem fog nagyon máshogy viselkedni, mint egy régi 3-as?

( djsmiley v | 2023. 03. 16., cs – 17:35 )

Forrás gépen: getfacl -R /path > jogosultsagok.txt

Cél gépen: setfacl --restore=jogosultsagok.txt

Nyilván a path-el úgy játszol ahogy szeretnél. Az átnevezést szerintem bízd a convmv-re, teljesen rendben meg tudja csinálni, de én még a forrás gépen megtenném, majd jogok mentése, sync, jogok visszatöltése. Készen is vagy :)

( nice | 2023. 03. 20., h – 12:37 )

Hát, jó. Addig eljutottam, hogy a VMware hátteréül szolgáló NFS storage snapshotjaiban lévő flat.vmdk lemezképmásból csináltam egy írható snapshotot LVM nélkül: https://linuxgazette.net/114/kapil.html

Felmountoltam róla a forrásrendszer megfelelő fájlrendszerét és lefuttattam rajta a convmv-t, illetve kudumpoltam a teljes getfacl kimenetet. A getfacl-t egy olyan chroot környezetben futtattam, amiben a forrásrendszer /etc/passwd és /etc/group fájljai voltak, így az ottani felhasználó- és csoportnevek vannak a dumpban. Most már elvileg csak egy setfacl futtatás, illetve a fájlok átmásolása lenne hátra. A célgép egyébként AlmaLinux 9-es oprendszert futtat.

Még olyan kérdéseim lennének, hogy:

-A `getent group` parancs nem mutatja az AD-s csoportok tagjait. Mi lehet ennek az oka? Orvosolható valahogy?

-A forrásrendszeren 3.2.5-ös SaMBa van, a célgépen 4.16.4-es. Mennyire lesznek ezek kompatibilisek a fájlrendszerjogosultságok értelmezésében (különös tekintettel az ACL-ekre)?

-Okozhat-e problémát, hogy a célgépen SELinux van, és security labelek vannak a fájlokon? Vajon mi lehet a teendő ezen a téren?

Biztosan kell a convmv? Azt írtad, át akarod másolni a fájlokat - azaz lesz egy forrás fájlrendszer és egy cél filerendszer. A forrás fájlrendszer mount opciói között kell megadni a megfelelő kódolást, ha nem detektálja automatikusan, (ami lehet nem is ISO-Latin2, hanem CP1250, ez picit különbözik az ISO változattól, és a windózok ezt használják), és ennyi. A Linuxok már igen régóta unicode-ok "by default". A convmv-vel dupla utf8-asítást kockáztatsz.

Szerintem kell a convmv. Legjobb tudomásom szerint a natív linuxos fájlrendszerek (ext3/ext4, stb.) egyáltalán nem törődnek a fájlnevek kódolásával, és a kernel semmikor nem konvertálja a fájlneveket ezen fájlrendszerek használatakor. FAT, CIFS, NTFS fájlrendszerek esetében történik fájlnévkonverzió, de ext3-nál semmi. Azt kézzel kell megcsinálni. Remélem, nem tévedek.

Csak arra utaltam, hogy ha felmountolunk egy latin-2 fájlneveket tartalmazó ext3-as fájlrendszert, majd onnan másolunk egy utf-8 fájlneveket tartalmazó ext4-es fájlrendszerre, akkor a kernel nem fog semmilyen fájlnévkonverziót végrehajtani, sőt, nem is foglalkozik vele, hogy lenne-e szükség ilyesmire vagy nem.

- getent: jó lenne tudni, hogy milyen megoldással vannak az userek behúzva az nsswitch-be (ha ez valami helyi móka, akkor ezt tuti tudod orvosolni, ha AD, akkor ott winbind enum* paraméterekre gugliznék.

- jogosultságok: nem lesz gond, de google samba map_acl*

- selinux: okozhat, ha nem előírás én lekapcsolnám, mert ellenkező esetben egész sok munkát okozhat