Mount CIFS share protetto su client Solaris

Montare uno share da server Solaris Express (Opensolaris o derivati) in join a dominio Active Directory.
Lo share è protetto da utente di AD password.
Lo si vuole in /etc/vfstab opzionalmente montabile in automatico al boot.

smbutil view "//DOMAIN;user@filedepot"
Share Type Comment
-------------------------------
c$ disk Default Share
docs disk
IPC$ IPC Remote IPC
sii disk

Attiviamo il client cifs:

svcadm enable smb/client

Registriamo le credenziali in locale tramite smbutil, in modo da non aver una richiesta di password al mount e non dover adottare soluzioni poco pulite come mettere le credenziali in chiaro in qualche script o in vfstab:

smbutil login DOMINIO/user
Password for DOMINIO/user: XXXXXXX

Ora montiamo lo share a mano:
mount -Fsmbfs -onoac,noprompt "//DOMINIO;user@filedepot/sii" /sii

O mettendolo in vfstab:
cat /etc/vfstab|grep sii
//DOMINIO;user@filedepot/sii - /sii smbfs - yes noac,noprompt

Potete avere una descrizione delle options da passare al mount con:

man smbfs
man mount
man mount_smbfs

Montare una ISO su Opensolaris

Su Solaris, per montare la iso di un CD, era necessario prima di tutto creare un device Lofi e poi montarlo.

# lofiadm -a /example.iso
# mount -F hsfs /dev/lofi/1 /mnt

Questo creava un device lofi/1 che poi poteva essere montato.
Su Opensolaris, almeno dalla 2008.11, il comando mount chiama da se in background lofiadm, creando il device. Quindi è sufficiente dare il file di immagine direttamente a mount:

# mount -F hsfs example.iso /mnt

Farà tutto lui per voi.

Montare UFS in Linux

La tabella dei types da passare al comando mount in Linux per montare filesystems ufs

• old : Old format of ufs, this is the default, read only. (Don’t forget to give the -r option.)
• 44bsd : For filesystems created by a BSD-like system like NetBSD,FreeBSD, and OpenBSD
• sun : For filesystems created by SunOS or Solaris on Sparc.
• sunx86 : For filesystems created by Solaris on x86.
• hp : For filesystems created by HP-UX, read-only.
• nextstep : For filesystems created by NeXTStep (read only).
• nextstep-cd : For NextStep CDROMs (block_size == 2048),
• openstep : For filesystems created by OpenStep (currently read only). The same filesystem type is also used by MacOSX

es:

# mount -t ufs -o ufstype=sun /dev/sdb1 /mnt

Globaldevices su LOFI

Ora Sun Cluster permette di utilizzare un device LOFI per il Global Device Namespace.
E' sufficiente creare un file con mkfile (di almeno 100 Mb) e passarlo a lofiadm.
Con scinstall in typical mode viene poi richiesto se si vuole usare un LOFS come globaldevice.

Pressochè inutile ... direte ... si, se non si pensa di dover mettere Sun Cluster su una macchina già con Solaris preinstallato senza spazio su disco per creare una slice da dedicare al Global Device Namespace.

Info qui

SMI e EFI label

Per cambiare la label di un disco è necessario usare il comando format in modalità enhanced.

# format -e
format> label
[0] SMI Label
[1] EFI Label
Specify Label type[0]:

Quando ci si trova a rifare una macchina con relativo storage connesso potrebbe tornare utile. Ad esempio con Veritas Volume Manager è fondamentale labellizare correttamente il disco per poter utilizzare un formato in particolare durante la sua inizializzazione.
Da ricordare che la EFI label è il default che viene usato per dischi da 1 Terabyte in su.
Da ricordare anche che dischi con label EFI non sono compatibili in Diskgroups vxvm CDS, Cross-Platform Data Sharing, che è il formato che li rende importabili su qualsiasi piattaforma e OS per cui è disponibile VxVM.

Cheatsheets

Esattamente qui una serie di cheatsheet per avere a portata di mano i comandi per fare un sacco di cose.

Grazie a http://www.datadisk.co.uk/

Netinstalling Solaris Vs. Linux "Broken" NFSd

La fiera delle stranezze che l'implementazione NFS di linux riesce a metter su ogni volta, è incredibile.
Questa volta, installando da rete Solaris 10 U6 ... al momento di montare via NFS il cdrom, l'installer fallisce, verificando i logs sull'install server Debian, mi trovo un:

Feb 24 23:53:39 debian mountd[8682]: Unauthorized access by NFS client 192.168.5.11.
Feb 24 23:53:39 debian mountd[8682]: Blocked attempt of 192.168.5.11 to mount /extra/media

Mmhh ... comincio a giocare senza troppa convinzione col file /etc/exports ... mmh; l'unica cosa che rimane è invariata è l'asterisco che indica che tutti gli hosts hanno permesso di montare l'export:

/srv/sol/Boot *(sync,ro,no_root_squash,all_squash,insecure)
/srv/media *(sync,ro,no_root_squash,all_squash,insecure)

Allora mi ricordo di aver letto qualcosa durante le passate ricerche alle prese con altri problemi legati a nfsd su linux. E cambio così:

/srv/sol/Boot 192.168.5.0/255.255.255.0(sync,ro,no_root_squash,all_squash,insecure)
/srv/media 192.168.5.0/255.255.255.0(sync,ro,no_root_squash,all_squash,insecure)

Funziona!!
E i log confermano:

Feb 25 00:01:18 debian mountd[8758]: NFS mount of /extra/media attempted from 192.168.5.11
Feb 25 00:01:29 debian mountd[8758]: /extra/media has been mounted by 192.168.5.11

Pazzesco ... segno qui da ricordare anche questa scocciatura

ZFS Vs, Data Rot

Quite simply, data rot is the result of tiny changes in the magnetic particles that make up the media in hard disks. The effect this has on your data is random but predictable: data loss.

Ho scoperto questo interessante articolo su BigAdmin, che, oltre ad avermi illuminato su questa interessante anomalia dei dischi fissi, parla di come il più rivoluzionario filesystem degli ultimi anni, ZFS, (che non è mio "amico", ma che un giorno lo diventerà) a detta dell'autore, risponde a questo inconveniente.

Si può leggere qui

Nautilus: piccole curiosità

Navigando il filesystem sul mio portatile conil Nautilus di Gnome, ho dedicato un pò di tempo per imparare qualcosa sui settaggi possibili e migliorare l'usabilità tramite di essi. Questo manager utilizza Gvfs, il Gnome Virtual Filesystem, di recentissima concezione e composto di alcuni demoni e librerie. La visualizzazione degli oggetti può essere a elenco o a icone. La prima restituisce un elenco, uno per riga, di files e directories e i loro attributi; la visualizzazione a icone permette di vedere il contenuto nella classica modalità dove più icone occupano lo spazio su file e colonne identificate dal loro nome a fianco o in basso.

E' possibile decidere quali informazioni sugli oggetti visualizzare dal pannello Preferenze. Tra queste vi è la dimensione. Abilitato i flag dimesione e possibile in modalità elenco, ordinare le dimensione i files. Nel caso di directories, però, non viene visualizzata la dimensione; per loro in questo campo viene conteggiato il numero di oggetti che contiene, siano essi files o dirs.

Ordinando per dimensione i contenuti di una directory mista filess e dirs, verranno visualizzati prima i files e poi le directories, rispettivamente sistemati dal più grande al più piccolo in numero di Megabytes e in numero di oggetti.

Nautilus può essere lanciato con diversi flags, tra i quali, mi è capitato di usare:

--no-desktop per lanciare il file-manager senza il supporto alla gestione della scrivania. Molto utile per utilizzare Nautilus su un altro WM/DE, ad esempio;
--browser server ad aprire una finestra in modalità esplorazione

resize LVM e FS su Linux

Devi dare un paio di Giga a quel filesystem su cui stanno i datafiles di Oracle ...

# lvextend -L +2G /dev/vg/ora_data

Dopodichè, essendo il volume già dimensionato alla nuova misura basta:

#resize2fs /dev/vg/ora_data

per riempire il nuovo spazio con un filesystem ext2/ext3.
Con un kernel 2.6 è possibile fare il grow del filesystem online.

Sun Cluster Proxy File System

Finalmente, sebbene in un blog, qualcuno in Sun ha deciso di spendere qualche parola e un pò di tempo per spiegarci qualcosa sul PXFS (Proxy File System) di Sun Cluster.

Si può leggere qui.

A q2uando la documentazione ufficiale?

Mount e l'opzione size

Una opzione di mount e' size. Questa option dipende dal filesystem in uso. Su Solaris, ad esempio, non e' disponibile con UFS, ma e' usabile con TMPFS. Offre quindi la possibilita' di decidere a boot-time la dimensione del tmpfs

Cosi':

# mount -F tmpfs -o size=1g swap /tmp

Oppure permanente:

# cat /etc/vfstab
swap - /tmp tmpfs - yes size=Xg

Ramdisk puro in Solaris

Come fare un ramdisk in Solaris? tmpfs, il pseudo filesystem utilizzato anche per lo swap, utilizza la Virtual Memory; in Solaris la Virtual Memory e' controllata dal sistema e utilizza la memoria fisica e le eventuali slices allocate per lo swap tagliate su uno o piu' dischi duri. Questo mix non e' gestibile, quindi questa non e' strada percorribile per avere un ramdisk puro. Inoltre un tmpfs non ha un device logico e non supporta la formattazione per spalmarci sopra qualcosa come UFS, QFS o VxFS.

Ramdisk, e' un driver del kernel Solaris, per creare block o raw devices in RAM. Con ramdiskadm e' possibile creare e distruggere ramdisks. Notare che per la creazione del ramdisk la RAM necessaria deve essere disponibile, pena messaggio d'errore e mancata creazione:

# vmstat
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr m0 m1 m4 m5 in sy cs us sy id
0 0 0 23058496 7046264 0 1 0 0 0 0 0 0 12 0 0 371 156 432 0 0 99
# ramdiskadm -a ramb 8g
ramdiskadm: couldn't create ramdisk "ramb": Resource temporarily unavailable

Creiamo:

# ramdiskadm -a rama 1g
/dev/ramdisk/rama

# ls -la /dev/ramdisk/rama
lrwxrwxrwx 1 root root 38 Aug 14 22:13 /dev/ramdisk/rama -> ../../devices/pseudo/ramdisk@1024:rama
1 # ls -la /dev/rramdisk/rama
lrwxrwxrwx 1 root root 42 Aug 14 22:13 /dev/rramdisk/rama -> ../../devices/pseudo/ramdisk@1024:rama,raw

Ci possiamo fare piu' o meno quello che ci pare; creiamoci su un normalissimo filesystem UFS:

# newfs /dev/rramdisk/rama
/dev/rramdisk/rama: Unable to find Media type. Proceeding with system determined parameters.
newfs: construct a new file system /dev/rramdisk/rama: (y/n)? y
/dev/rramdisk/rama: 2097000 sectors in 3495 cylinders of 1 tracks, 600 sectors
1023.9MB in 219 cyl groups (16 c/g, 4.69MB/g, 2240 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
32, 9632, 19232, 28832, 38432, 48032, 57632, 67232, 76832, 86432,
2006432, 2016032, 2025632, 2035232, 2044832, 2054432, 2064032, 2073632,
2083232, 2092832

Montiamolo:

# mount /dev/ramdisk/rama /mnt

# df -n|grep "^/mnt"
/mnt : ufs

Creiamo un file e compariamo i tempi di creazione con quelli di un file identico creato su hard disk SAS:

*ramdisk ufs
# time mkfile 700m /mnt/700mega

real 0m5.368s
user 0m0.091s
sys 0m5.272s

*SAS interno ufs
# time mkfile 700m /FS/700mega

real 0m12.301s
user 0m0.081s
sys 0m2.907s

*FC array qfs
# time mkfile 700m /qfs_di_prova/700mega

real 0m5.866s
user 0m0.074s
sys 0m3.973s

La differenza nei tempi di creazione tra un disco interno al server SAS e il ramdisk e' ovviamente enorme; interessante vedere come sia necessario lo stesso tempo per la creazione del file su una lun residente su array FC, che fa il suo buon uso della sua cache.

Va bene! Gli usi possibili di un ramdisk sono tra i piu' disparati, diamoci da fare!

Filesystems about in linux e unix

Tra le altre cose, il comando df e' utile per conoscere il tipo di un filesystem.
Se su Solaris e' visualizzabile con:

# df -n
/ : ufs
/devices : devfs
/system/contract : ctfs
/proc : proc
/etc/mnttab : mntfs
/etc/svc/volatile : tmpfs
/system/object : objfs
/platform/sun4u-us3/lib/libc_psr.so.1: lofs
/platform/sun4u-us3/lib/sparcv9/libc_psr.so.1: lofs
/dev/fd : fd
/var : ufs
/tmp : tmpfs
/var/run : tmpfs
/dev/vx/dmp : tmpfs
/dev/vx/rdmp : tmpfs
/REPLICA_BACKUP : samfs

Su Linux:

# df -T
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/sda2 ext3 20161204 16495184 2641880 87% /
varrun tmpfs 387640 76 387564 1% /var/run
varlock tmpfs 387640 0 387640 0% /var/lock
udev tmpfs 387640 56 387584 1% /dev
devshm tmpfs 387640 0 387640 0% /dev/shm
lrm tmpfs 387640 39776 347864 11% /lib/modules/2.6.24-20-generic/volatile
/dev/sdb2 ext3 117188268 98941524 12293860 89% /mmedia
/dev/sda3 ext3 16247640 13169908 2252396 86% /extra
overflow tmpfs 1024 92 932 9% /tmp

Su Solaris e' possibile farlo anche con:

# ' fstyp /dev/vx/dsk/bootdg/rootvol

ufs

Areanetworking: articolo QFS

Il mio recente blog sull'aggiunta di nuovi hosts a un filesystem QFS shared e' stato pubblicato su Areanetworking, del quale sono staff; era da una vita che non pubblicavo un articolo sul sito, e son contento di questo contributo ... magari mi dara' lo sprint per essere produttivo come lo ero qualche tempo fa (prima che le trasferte mi togliessero pure il tempo di allacciarmi le scarpe e stirarmi le camicie):

E' disponibile qui, contiene parte del blog rivisto e corretto e alcuni cenni di premessa su cos'e' QFS e com'e' composto

Files in uso ma rimossi: trovarli

Ringrazio Massimo per questa segnalazione che annoto di seguito qui pronto per essere trovato quando mi serve:

In questo post (http://wikis.sun.com/display/BigAdmin/Checking+for+Deleted+Files+Held+Open+in+UFS+File+Systems) in fondo c'è un commento dove si suggerisce di usare il "find" per scovare processi che hanno files aperti ma cancellati.

Il comando è:

find /proc/*/fd -type f -links 0 -exec ls -l {} \;

Lo segnalo giusto come elemento di analisi in più per quelle situazioni "simili" già capitate in passato.

Aggiungere hosts a uno shared QFS

Ecco gli steps necessari ad aggiungere dei servers agli hosts che sharano un fs qfs denominato "qfs" .
I files da configurare sono 2 + 1 da verificare. La directory contenente la config è /etc/opt/SUNWsamfs

root@box3 # ls /etc/opt/SUNWsamfs/
VERSION.4.6 hosts.qfs notify.cmd
startup mcf scripts

- hosts.qfs , basta editarlo su uno degli hosts e copiarlo sugli altri.

root@box3 #cat hosts.qfs
box1 172.30.10.1 1 - server
box2 172.30.10.2 2 -
box3 172.30.10.3 3 -

Si commenta da se. Il server è la macchina 1, gli altri sono potenziali
metadata servers nell'ordine di diritto dato dal numero nella terza colonna.

- mcf:
root@box3 # cat mcf
qfs 10 ma qfs - shared
/dev/dsk/c4t6d0s0 11 mm qfs -
/dev/dsk/c4t6d0s7 12 mr qfs -

Contiene la struttura di volume e filesystem. Va definito uno stesso
filesystem su tutte le macchine, specificando un identico nome (in
questo caso "qfs") e definendo come sopra data e metadata slices, ma soprattutto mettendo la dicitura shared.
Attenzione a un'errore banale, ma facile che possa capitare di incapparci. Il
logical device path della lun in uso dalle 4 macchine va definito localmente
su ogni host, appunto ha significanza locale, con il path "corretto". Ad esempio su box1 è
/dev/dsk/c3t6d0 mentre sulla 3 /dev/dsk/c4t6d0. Cambia il controller per la stessa lun da sharare, è un errore non accorgersene andando a inserire un device errato nell'mcf.

mcf è il file dove si va ad agire quando si intende ingrandire il filesystem. Qui si aggiungono le luns da assegnare come spazio per dati e metadati.

- /etc/inittab . Contiene la riga:
sf:023456:respawn:/usr/lib/fs/samfs/sam-fsd
Verificare che non sia stata precedentemente commentata (ad esempio in seguito a shutdown del demone qfs conseguente a rimozione del filesystem shared.

Potrebbe essere necessario avviare i demoni:
/etc/init.d/samfs.shared start

Si lancia il comando
root@box3 # samsharefs -u qfs

Che rilegge il file hosts.qfs e aggiorna la configurazione del demone in accordo ad esso.
Se il filesystem è smontato su uno degli hosts, allora usa:
root@box1 # samsharefs -u -R qfs # !!! OKKIO !!! usare l'opzione -R solo se il fs è SMONTATO , se è MONTATO si rischia una corruzione, usare solo -u
root@box1 # samd config
Configuring SAM-FS

partendo dal metadata server e passando poi alle altre macchine.
Quest'ultimo comando applica i cambiamenti. E' possibile montare i filesystems se non lo si è già fatto.

Un paio di comandi di verifica, utili anche nel caso di problemi durante operazioni del genere:
- samsharefs qfs
- samfsinfo qfs

root@box3 # samsharefs qfs
#
# Host file for family set 'qfs'
#
# Version: 4 Generation: 28 Count: 4
# Server = host 2/box3, length = 138
#
box1 172.30.10.1 1 -
box2 172.30.10.2 2 -
box3 172.30.10.3 3 - server

root@box3 # samfsinfo qfs
samfsinfo: filesystem qfs is mounted.
name: qfs version: 2 shared
time: SatAug 1 22:00:00 CET 2008
count: 2
capacity: 000000000047f000 DAU: 64
space: 0000000000370a40
meta capacity: 0000000000080000 meta DAU: 16
meta space: 00000000000706e0
ord eq capacity space device
0 11 0000000000080000 00000000000706e0 /dev/dsk/c4t6d0s0
1 12 000000000047f000 0000000000370a40 /dev/dsk/c4t6d0s7

Rimane da testare il corretto switch del server; il freeze del
filesystem durante lo switch è abbastanza trasparente, discretamente veloce, e comunque tutte le operazioni vengono messe in attesa e portate a termine appena il sistema torna disponibile.
E' possibile forzare lo switch così:
root@box3 # samsharefs -s HOSTNAME qfs

Si vedrà qualcosa di molto simile:
Aug 1 15:36:06 box1 samfs: [ID 145691 kern.notice] NOTICE: SAM-QFS:
qfs: Failing over to new server box3, frozen (2000821)
Aug 1 15:36:06 box1 samfs: [ID 668864 kern.notice] NOTICE: SAM-QFS:
qfs: Set client: new server box3 (2000821), 1.3, fl=0
Aug 1 15:36:06 box1 samfs: [ID 665295 kern.notice] NOTICE: SAM-QFS:
qfs: Reset leases, then send resync message to new server box3,
thawing (4000821)
Aug 1 15:36:10 box1 samfs: [ID 999740 kern.notice] NOTICE: SAM-QFS:
qfs: New server box3 (8800811) responded to resync message, thawing
(4800821)
Aug 1 15:36:10 box1 samfs: [ID 515541 kern.notice] NOTICE: SAM-QFS:
qfs: Waiting for new server box3 (8800811): thawing (4800821)
Aug 1 15:36:12 box1 samfs: [ID 206251 kern.notice] NOTICE: SAM-QFS:
qfs: Received faildone message from new server box3, thawing (4c00821)
Aug 1 15:36:12 box1 samfs: [ID 685965 kern.notice] NOTICE: SAM-QFS:
qfs: Failed over to new server box3: (21)

Dovrebbe essere tutto. Per aggiunte, correzioni, estensioni, commenti:
FALLE in un commento, scrivimi a alex.t@areanetworking.it e diventeranno a disposizione su questo blog

Rimuovere shared QFS

Un QFS shared su una LUN mappata dall'array a 4 hosts.
Rimuovere due hosts.
Oltre all'editing del file hosts.xxx sulle macchine rimanenti per eliminare i riferimenti a quelle da rimuovere è fondamentale:
* smontare il filesystem
* lanciare samsharefs -Ru
* samd config
* stoppare il qfs sulle macchine rimosse
* rinominare files hosts.xxx e mcf sulle macchine rimosse
* importante ... nel file inittab delle macchine rimosse, c'è una entry che riguarda il QFS che causa il respawn del demone sam-fsd, questa va COMMENTATA!! In caso contrario, nonostante lo stop dei demoni tramite script presente /etc/init.d/ le macchine continueranno a inviare richieste a quella che è conosciuta come l'ultimo host server del filesystem shared; di per sè non causa nulla di male saltare questo passo, ma non è pulito e, non si sa mai, potrebbe causare o essere concausa di problemi
* sulle macchine rimanenti samd config restituisce un errore che seppur non bloccante, fa ben capire che non ha del tutto digerito i cambiamenti; infatti, parla di qualche problema con le macchien eliminate. Questo viene fixato da un reboot, potrebbe esserci altra soluzione ma non la conosco
* Rimuovere le entries del filesystem qfs dal file /etc/vfstab delle macchine rimosse
* Last but not least: switchare il server da una macchina all'altra per assicurarsi che tutto funzioni a dovere.

Playing Linux Raid and Logical Volumes

Stasera si gioca col software Raid di linux.
Ho un Multipack di Sun, quello da 6 dischi scsi SCA (esiste il modello da 12) ... è pieno.
Ho Linux e in questo momento desidererei Solaris :)
Ma non demordo mica ... ho 6 dischi da 32 Gb e il bisogno di un volume per metterci "files artistici di futuristica visione commentanti un domani possibile", dicasi Star Trek; tanti ST!

Valuto che sarebbe bene un Raid5, meglio se ha spalmato sopra un volume e filesystem dinamici, per riorganizzare in seguito gli spazi.

Avendo a disposizione un Jbod e un HBA scsi senza RAID hardware, andrei per un Raid5 software con sopra quella che chiamerei una soft partition ... se solo avessi Solaris ... due comandi è il gioco è fatto.

SMETTILA!!

Il Software Raid di linux (mdraid) e lvm2 fanno al caso mio, quindi si comincia.
Su ogni disco fisico creo una partizione a colpi di:

# fdisk /dev/sdX

X va da a a a f.
Queste partizioni le darò in pasto a mdadm per creare il bimbo raid5, praticamente così:

#/sbin/mdadm --create --verbose /dev/md0 --level=5 \
--raid-devices=6  \
/dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1
mdadm: layout defaults to left-symmetric
mdadm: chunk size defaults to 64K
mdadm: size set to 35559744K
mdadm: array /dev/md0 started.

E questo è quanto, il disco logico raid5 è fatto; la palla passa a LVM2
Si tratta di tirare dentro md0 come PV, Phisical Volume, e creare un VG, Volume Group
che lo contiene ... esso avrà un nome, il mio si chiama multipack.

#pvcreate /dev/md0
Physical volume "/dev/md0" successfully created
#vgcreate multipack /dev/md0
Volume group "multipack" successfully created

Ok, infine, dando i Pe disponibili nel VG, visualizzabili col comando vgdisplay alla riga Free PE
si crea il Logical Volume:

lvcreate -l 43407 multipack -n DATA
Logical volume "DATA" created

Ora possiamo dire di avere il nostro bel volume, eccolo in tutto il suo splendore:

lvdisplay /dev/multipack/DATA
--- Logical volume ---
LV Name                /dev/multipack/DATA
VG Name                multipack
LV UUID                Db0D3T-2xo0-uik3-hZdk-ykd4-61X0-Y1tUXY
LV Write Access        read/write
LV Status              available
# open                 0
LV Size                169,56 GB
Current LE             43407
Segments               1
Allocation             inherit
Read ahead sectors     0
Block device           253:0

169 Gb protetti, non male, speriamo anche funzioni come si deve;
devo dire che fin'ora, su macchine di produzione che mi sono capitate è
andato sempre tutto liscio.
Non rimane che scegliere un filesystem e crearcelo su, poi è pronto per essere montato.

lofs delirium

Un amico mi chiama sottoponendomi un problema che sta avendo.
Riguarda un'immagine iso montata sotto Solaris, che non si comporta come dovrebbe o ... come lui vorrebbe.
Dice di aver creato il lofs con lofiadm e di averlo montato con successo. Al momento di accedere al mountpoint, però, riceve un:

cd /mnt2
-bash: cd: /mnt2: Not a directory

mmh.
Allora si parte con le domande di rito:
Fai un ls -la di /mnt2:
ls -la /mnt2
brw------- 1 root sys 144, 1 mag 18 21:19 /mnt2

Mmmhh, un block device file. Qualcosa non quadra. Sarebbe necessario capire cosa ha fatto durante la procedura di creazione del loFS e del successivo mount.

Niente history... ma dopo qualche smanettamento infruttuoso m'illumino:
Smonto il filesystem e distruggo il device file; notando che /mnt2 non è una directory ma un device file, sono convinto che abbia montato il device specificando a mount non che si tratta di un'immagine iso, ma appunto di un lofs ... che si può assimilare a distrazione o più probabilmente al fatto di conoscere la procedura, essersi distratto e non aver ben capito cosa si stia facendo. Quindi mount l'ha montato come quello che è, ragionando correttamente (almeno lui).

Ora da vuoto, rifaccio tutto:
creo il device con lofiadm, /dev/lofi/1 , poi creo la dir /mnt2, e lo monto:
mount -F hsfs /dev/lofi/1 /mnt2

df -h|grep lofi
/dev/lofi/1 450M 450M 0K 100% /mnt2

cd /mnt2
ls
sparc worm x64

Perfetto. Funziona.
Il problema è riproducibile, dopo aver creato il lofs desiderato, montandolo cosi:

mount -F lofs /dev/lofi/1 /mnt2

e verificando che /mnt2 è un block device file e non il mountpoint sotto il quale si voleva montare la iso.
Distrazione o errato ragionamento.
Morale;
Montando un loFS, bisogna specificare il tipo di FS al quale esso fa riferimento, e non definendolo come loFS, quando si usa l'opzione -F di mount.