groupadd, gid

Linux-kezdő

Live-omon ilyesmit csináltam:

while ! getent group ntfsrw >/dev/null; do
    groupadd -r ntfsrw
    sleep 1
done
"$CONFDIR"/makeswap &

CONFDIR értéke rendben. A makeswap script érdekes része:
MOUNT_OPTIONS='-o noatime,gid=ntfsrw,fmask=0117'
...
mount $MOUNT_OPTIONS "$maxpart" "/mnt/$SWAPDIRNAME"

Az id és a getent group ntfsrw is 983-as gid-et ad vissza, miközben az érintett ntfs filerendszeren root:982 tulajdonossal, 0660 joggal rendelkeznek a file-ok. Miért? A groupadd után lett indítva a makeswap script, amelyben a mount van, a hivatkozás group névvel történt.

Mondanom sem kell, ennek következtében hiába vagyok az ntfsrw csoportban, nincs jogom a file-ok eléréséhez.

Ami külön „jó”:

mount -o remount,noatime,gid=ntfsrw,fmask=0117 /mnt/mountpoint
echo $?
0-t ad vissza, ám a file-ok listázásakor továbbra is 982-es gid-et látok. Ezzel a gid-del egyébként nincs létrehozva csoport.

  • 1485 megtekintés

( Szenti v | 2015. 06. 05., p – 14:46 )

Az ntfs-3g man oldala szerint:

OPTIONS
Below is a summary of the options that ntfs-3g accepts.

uid=value and gid=value
Set the owner and the group of files and directories. The values are numerical. The defaults are the uid and gid of the current process.

( SzBlackY | 2015. 06. 05., p – 15:00 )

Off-topic: ha esetleg systemd-t használsz, vess egy pillantást a systemd-sysusers-re, pont erre tervezték (stateless/non-persistent rendszereken automatikus uid/gid allokálás)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Azzal, hogy nem kell ciklusban várakozva próbálkoznod, hogy létezik-e :) [ez mondjuk véd pl. a script újrafuttatásakor előjövő hiba ellen, de szvsz. nem egy túl elegáns megoldász]

Poettering írt valahol egy egész szép hosszú blogbejegyezést (ebben említette először az új eszközt - itt: http://0pointer.de/blog/projects/stateless.html), hogy a gyári beállításra visszaállítható és teljesen állapot nélküli rendszereket hogyan lehetne csinálni. Igazából szvsz. értelme akkor van, ha nekiállsz csomagokat is gyártani ezekből a scriptekből, hogy később legózni tudj velük, akkor jól jön ez a deklaratív, moduláris leírás.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

A ciklusnak prózai oka van. Úgy tűnt, nagyon ritkán ugyan, de nem sikerült elsőre a groupadd. (Jobban belegondolva ez rég volt, már nem emlékszem, lehet, hogy hibás diagnózis. Viszont nehéz ritkán bekövetkező hibát keresni. Mindegy, a ciklusból baj nem lehet, legfeljebb felesleges.)

Ami ijesztő, hogy ilyen-olyan oknál fogva bizonyos dolgok nem feltétlen hajtódnak végre elsőre. Például ilyen a mount, ott is van, ahol ciklust használok. Konkrétan kidebugoltam, s azt hiszem, megelőzte önmagát: elsőre nem sikerült, mert még nem tudta létrehozni a loop device-t.

Egy olyan mount-ról beszélünk, amelyben van offset, a filerendszer nem a block eszköz elejénél kezdődik. Erre lehet mount-ot csinálni, de valójában hívja a losetup-ot, csak tudnám, miért nem várja meg annak eredményes visszatérését. Úgy látszik, ezek aszinkron folyamatok.

Csúnya megoldásként azt csinálom, megpróbálkozom négyszer egymás után 2 másodperces szünetekkel, aztán, ha negyedik alkalommal sem sikerül, akkor úgy tekintem, nincs ott a filerendszer. Leggyakrabban elsőre összejön neki, néha nem, akkor második körben sikerül.

Tudom, gány, de mit csináljak, ha már egy mount parancsban sem bízhat az ember, miközben a filerendszer tuti ott van, hiszen azon a pendrive-on van, amelyiken a live image is, amelyről a rendszer fut. Az érintett filerendszer valahol hátrább van a pendrive-on az image mögött.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem gondolom. Egy mount parancsot elég nehéz elszúrni szerintem.

DEVICE="`blkid /dev/sd? | grep 'Fedora.*live' | head -n1 | cut -d: -f1`"
bs=1048576
((OFFSET=SEEK*bs))
if [ ! -z "$LNAME" -a ! -z "$DEVICE" ]; then
    mkdir -p "/mnt/$LNAME"
    repeat=4
    for ((mnt_cnt=repeat; mnt_cnt>0; mnt_cnt--)); do
        mount -o loop,offset=$OFFSET,noatime "$DEVICE" "/mnt/$LNAME" && break
        umount "/mnt/$LNAME"
        ! sleep 1
    done || rmdir "/mnt/$LNAME"
    log 'Mount repeat count:' "$((repeat+1-mnt_cnt))"
fi

Az umount csak azért van, ha esetleg sikerül a mount, de hibával térne vissza, akkor lecsatolja a filerendszert. Teszem azt, részben sikerül, például ro mount-ol, ilyesmire gondolok.

A logolás meg így néz ki:

LOG='/tmp/rclocal.log'
[ x"$LOGGING" = x'1' ] || LOG='/dev/null'
exec {logfd}>&2 2>"$LOG"

log() {
    echo -e "`date '+%F %T.%06N'`\t" "$@" 1>&2
}

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem véletlenül idéztem a scriptből. Egy mount parancson mégis mit lehet elrontani? Ha mégis sikerülne elszúrni, akkor sohasem csatolná a filerendszert. Ha meg nem, akkor mindig csatolódnia kellene. Ebben egyetértés van köztünk. Aztán a tapasztalat merőben más.

Arra tippelek, a loop mount nem lett alaposan tesztelve, és lehetnek benne aszinkron dolgok, amelyben borul a sorrend. Ez szerintem bug. Teszem azt, losetup, de a loop device még nem jött létre, próbálkozik a mount, elbukja a dolgot, visszatér hibával. Ugyan a mount automatikusan hívja a losetup-ot, mert jófej, de lehet, elhamarkodja utána a teendőit.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE