Archivi categoria: informatica

Impazzire con la mail

Ho diversi sistemi linux-based sparsi in giro per la provincia. In tutti ho uniformato la configurazione del sistema di gestione della posta elettronica, impostando un funzionamento come “satellite” ed usando gmail per il lavoro “sporco”.

Uno dei miei sistemi, con sistema operativo Debian 9.4 si è sempre rifiutato di inviare la mail a “se stesso”. L’errore che ho sempre ottenuto è:

DNS Error: 21091730 DNS type ‘mx’ lookup of linuxade responded with code NXDOMAIN Domain name not found: linuxade

Ho controllato l’output del comando:
root@linuxade:/etc# exim4 -bP primary_hostname
primary_hostname = localhost

Ho provato un sacco di strade diverse. L’unica azione che ha risolto il problema è stata la riconfigurazione di /etc/hosts nella sezione ipv6 passando dalla prima alla seconda versione. La prima scrittura penso sia stata una configurazione temporanea per fare qualche prova.

# The following lines are desirable for IPv6 capable hosts
::1  localhost ip6-localhost ip6-loopback linuxade

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback

Cambiato il contenuto del file, riavviato exim4, adesso il comando viene eseguito correttamente:
root@linuxade:/etc# exim4 -bP primary_hostname
primary_hostname = linuxade

Finalmente mi arrivano le email con gli errori dovuti all’esecuzione degli script!

Please follow and like us:

USB Disk Docking Adapter. Pare facile!

Come passare un paio di ore a debuggare un problema.

Disco1 e Disco2 sono due HD identici della Western DIgital da 4TB che utilizzo per fare i backup off-line. Copio i files e poi li stacco e li metto in un cassetto. Disco1 lo uso prevalentemente con una docking station USB della Sabrent, modello DS-UBLK USB3.0, collegata al desktop con sistema operativo Linux. Prendo il disco, creo la partizione (GPT) e ci metto supra un bel File System ext4. Copio i files tutto funziona bene. Succede poi che io debba usare Disco1 per fare il backup con “Clonezilla” di una macchina che non è nella mia stanza. Prendo Disco1, un adattatore SATA USB della Vultech, avvio Clonezilla e non trovo la partizione. Vabbè, ho fretta e prendo quindi Disco2 (sempre attaccato al Vultech), creo una partizione ed un FS e procedo aul backup.

Tornato in ufficio tutto funziona: Disco1 nella docking, Disco2 attaccato al Vultech e posso spostare i files come mi pare.

Per fare una prova e cercare di capire come mai sul Vultech non riesco a leggere Disco1, inverto la posizione dei dischi: Disco1 e Disco2 sono illeggibili se scambio gli adattatori (Disco2 è attaccato alla docking e visto come /dev/sdc, Disco1 è collegato alla Vultech e visto come /dev/sdd):

root@hp-ufficio:~# fdisk -l /dev/sdc
Disk /dev/sdc: 3,7 TiB, 4000787030016 bytes, 976754646 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33550336 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device Boot Start End Sectors Size Id Type
/dev/sdc1 1 4294967295 4294967295 16T ee GPT

root@hp-ufficio:~# fdisk -l /dev/sdd
GPT PMBR size mismatch (976754645 != 3519069871) will be corrected by w(rite).
Disk /dev/sdd: 3,7 TiB, 4000787030016 bytes, 7814037168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device Boot Start End Sectors Size Id Type
/dev/sdd1 1 976754645 976754645 465,8G ee GPT

Le dimensioni riportate da fdisk sono completamente errate e non posso accedere alle partizioni:

root@hp-ufficio:~# blockdev –getbsz /dev/sdc1
blockdev: cannot open /dev/sdc1: No such file or directory
root@hp-ufficio:~# blockdev –getbsz /dev/sdd1
blockdev: cannot open /dev/sdd1: No such file or directory
root@hp-ufficio:~#

Tuttavia la dimensione dei dischi viene correttamente rilevata con i comandi a basso livello:

root@hp-ufficio:~# sg_readcap –16 /dev/sdc
Read Capacity results:
Protection: prot_en=0, p_type=0, p_i_exponent=0
Logical block provisioning: lbpme=0, lbprz=0
Last logical block address=976754645 (0x3a3817d5), Number of logical blocks=976754646
Logical block length=4096 bytes
Logical blocks per physical block exponent=0
Lowest aligned logical block address=0
Hence:
Device size: 4000787030016 bytes, 3815447.8 MiB, 4000.79 GB
root@hp-ufficio:~# sg_readcap –16 /dev/sdd
Read Capacity results:
Protection: prot_en=0, p_type=0, p_i_exponent=0
Logical block provisioning: lbpme=0, lbprz=0
Last logical block address=7814037167 (0x1d1c0beaf), Number of logical blocks=7814037168
Logical block length=512 bytes
Logical blocks per physical block exponent=0
Lowest aligned logical block address=0
Hence:
Device size: 4000787030016 bytes, 3815447.8 MiB, 4000.79 GB
root@hp-ufficio:~#

Mi gratto la testa ed inizio a cercare qualche notizia in rete. Incappo in un paio di post in cui si parla di problemi analoghi e di questo problema. Decido quindi di aggiornare il firmware della docking, seguendo le istruzioni trovate in questo sito. L’aggiornamento è fattibile solo in ambiente windows. Il firmware originale del dispositivo (acquistato a febbraio 2018) è davvero vecchio. Installo la versione 124. Dopo l’aggiornamento la situazione è questa:

Disco2, creato con Vultech e messo nella docking station funziona perfettamente.
Disco1, creato con la docking prima dell’aggiornamento, collegato alla Vultech non viene visto, se collegato alla docking idem. Problema risolto? Provo a ricreare una partizione ed un file system su Disco1 nella docking. Adesso funziona tutto, il Vultech vede il disco e la partizione e li usa correttamente!

RSS
Facebook
Google+
http://www.iz6cus.it/blog/category/vita-e-sopravvivenza/informatica">
Twitter
LinkedIn

Please follow and like us: