Re: Gestione indirizzi ip del Dhcpd

[Gollum1]

Il 06 febbraio 2016 20:58:49 CET, Davide Prina  ha 
scritto:
>On 06/02/2016 16:13, Fabrizio Carrai wrote:
>> Se il PC non fa un DHCP release [1] esplicito, l' IP viene mantenuto
>> allocato al richiedente per la durata del lease time.
>
>ma se io mi connetto al sistema, ottengo un IP dinamico dal DHCP,
>subito 
>dopo mi sconnetto e mi ripresento con un IP fisso (senza passare dal
>DHCP).

Attento a metterlo però al di fuori del pool di indirizzi del dhcp, riusciresti 
altrimenti di duplicare un indirizzo già in uso.

>
>Il mio IP dinamico che mi aveva assegnato il DHCP al primo ingresso
>l'ho 
>perso?

L'hai perso perché non lo stai usando, e fino a che non è scaduto il release 
time, nessun altro lo può acquisire.
> O meglio se mi sconnetto, tolgo l'IP fisso e mi riconnetto... 
>riottengo l'IP dinamico che mi aveva dato il DHCP o nel frattempo se lo
>
>può aver preso qualcun altro?

Se non è ancora scaduto il release time, mi pare di ricordare che il server 
riconoscendo il mac address, dovrebbe riassegnarti lo stesso indirizzo. Se il 
release time è trascorso, l'indirizzo è tornato disponibile, ma se nessun altro 
nel frattempo se lo è preso, è molto probabile che ti venga riassegnato lo 
stesso indirizzo.

Byez

-- 
Gollum1

Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità e gli 
errori di battitura (maledetto correttore ortografico).

Re: Gestione indirizzi ip del Dhcpd

[Davide Prina]

On 06/02/2016 16:13, Fabrizio Carrai wrote:

Se il PC non fa un DHCP release [1] esplicito, l' IP viene mantenuto
allocato al richiedente per la durata del lease time.


ma se io mi connetto al sistema, ottengo un IP dinamico dal DHCP, subito 
dopo mi sconnetto e mi ripresento con un IP fisso (senza passare dal DHCP).


Il mio IP dinamico che mi aveva assegnato il DHCP al primo ingresso l'ho 
perso? O meglio se mi sconnetto, tolgo l'IP fisso e mi riconnetto... 
riottengo l'IP dinamico che mi aveva dato il DHCP o nel frattempo se lo 
può aver preso qualcun altro?


:-)

Ciao
Davide

--
Dizionari: http://linguistico.sourceforge.net/wiki
Perché microsoft continua a compiere azioni illegali?:
http://linguistico.sf.net/wiki/doku.php?id=traduzioni:ms_illegal
GNU/Linux User: 302090: http://counter.li.org
Non autorizzo la memorizzazione del mio indirizzo su outlook

Re: --reinstall e mancanza file...

[Marco Gaiarin]

Mandi! Giovanni Toraldo
  In chel di` si favelave...

> sudo apt-get -o Dpkg::Options::="--force-confmiss" install --reinstall cups

Bingo! Quindi il problema è che /etc/init.d/cups è un conffile, e in quando
conffile potrebbe essere, a mia discrezione, essere eliminato. Corretto?

Mi segno questa cosa, grazie.


PS: tutto questo l'ho fatto DOPO aver recuperato il FS con e2fsck. Ed è una
vecchissima ubuntu, /etc/init.d/cups è nel pacchetto CUPS.

-- 
  Ventiquattromilapensierialsecondofluisconoinarrestabili
  alimentando voglie e necessita`.  (CSI)

Re: [MASSMAIL]Samba 4 AD + share

[dea]

Guarda, la scorsa settimana ho configurato 3 DC con 3 file server Debian Samba
4.1 (Debian) in join con il DC e con i permessi estesi attivati.

Non so xfs, ma ext4 usa di default i permessi estesi, che devi poi specificare
in Samba per la gestione.

Gli utenti gli erediti dal DC con UID e GID specifici (io li uso dal 1 in
su), puoi impostare l'owner dell'utente di rete.

wbinfo -u (devi vedere gli utenti dal file server che ti passa il DC)
getent passwd (devi visualizzarti in coda gli utenti che ti passa il DC
compresi uid e gid).

Luca

Re: Gestione indirizzi ip del Dhcpd

[GiancFir]

On 06/02/2016 16:13, Fabrizio Carrai wrote:

Se il PC non fa un DHCP release [1] esplicito, l' IP viene mantenuto
allocato al richiedente per la durata del lease time. Non dovrebbe
essere un problema aggiungere il comando di release alla procedura di
shutdown.

F.
si, ma sono telefoni cellulari, probabilmente il comando di release lo 
inviano solo quando staccano il wifi, non quando si allontanano.
Se ho capito bene devo giocare con il lease time affinchè il server non 
finisca gli ip del range e contemporaneamente i client non abbiano 
problemi di ip duplicati nella rete.

Grazie!

--
”Questo è Unix. Ti dà abbastanza corda per impiccarti da solo.”
Miquel van Smoorenburg
“Unix E’ user friendly. . . E’ solo selettivo su chi può essergli amico.”
Tollef Fog Heen

Re: --reinstall e mancanza file...

[Gian Carlo]

[...]

la macchina è ripartita, e sostanzialmente funziona.

controllando con fsck il filesystem risulta ok?
se no, pensa prima a rimettere a posto il filesystem
se sì, "dpkg -s cups" ti dice che è installato?
se no, "apt-get install cups"
se sì, "apt-get remove cups" e poi "apt-get install cups"
HTH

gc

Re: Gestione indirizzi ip del Dhcpd

[Luca Cravero]

il dhcp server deve attendere la scadenza del lease prima di poter 
nuovamente assegnare un indirizzo IP già assegnato in precedenza.
quando si incorre nel problema da te descritto conviene aumentare il 
pool (ove possibile) e/o ridurre il lease time.


ciao

luca

On 06/02/2016 15:51, GiancFir wrote:
Mi domandavo ma se i demone finisce gli ip di un certo range, come fa 
a sapere se alcuni degli indirizzi che ha dato sono ancora in uso 
oppure no?
Mi spiego meglio, un client chiede ed ottiene un indirizzo ip con 
lease time di 3 ore, dopo un ora di collegamento viene spendo il pc, 
il demone si accorge che quell'indirizzo ip è di nuovo disponibile 
anche se non è passato tutto il lease time?


Ciao

Re: --reinstall e mancanza file...

[Giovanni Toraldo]

Ciao,

2016-02-06 16:35 GMT+01:00 Marco Gaiarin :
> Mandi! tar...@aruba.it
>   In chel di` si favelave...
>
>> la butto lì.
>> prova un purge (non credo che il reinstall lo faccia) e poi install.
>
> Eh, no, troppo facile: se faccio purge elimino tutto, compreso le
> configurazioni, ed è esattamente quello che NON voglio fare...

sudo apt-get -o Dpkg::Options::="--force-confmiss" install --reinstall cups

-- 
Giovanni Toraldo
http://gionn.net

Re: --reinstall e mancanza file...

[Davide Prina]

On 05/02/2016 10:48, Marco Gaiarin wrote:


Ma alcune cose non mi tornano, stile è finito in lost+found
/etc/init.d/cups, ma se faccio:

apt-get --reinstall install cups

non viene ripristinato. Qualcuno sa dirmi perchè?


Io sono su una testing

$ apt-file -x search /etc/init.d/cups$
cups-daemon: /etc/init.d/cups

Ciao
Davide

--
Dizionari: http://linguistico.sourceforge.net/wiki
Fate una prova di guida ... e tenetevi la macchina!:
http://linguistico.sf.net/wiki/doku.php?id=usaooo2
Non autorizzo la memorizzazione del mio indirizzo su outlook

Re: --reinstall e mancanza file...

[Marco Gaiarin]

Mandi! tar...@aruba.it
  In chel di` si favelave...

> la butto lì.
> prova un purge (non credo che il reinstall lo faccia) e poi install.

Eh, no, troppo facile: se faccio purge elimino tutto, compreso le
configurazioni, ed è esattamente quello che NON voglio fare...

-- 
  Quante persone che non contano, e invece contano
  e si stanno contando gia`
  Stanno solo aspettando un segno, Capata`z (F. De Gregori)

Samba 4 AD + share

[Alessandro Baggi]

Salve ragazzi,
premetto che sull'argomento non solo molto serrato ma veniamo al dunque.
Ho un samba 4 configurato come AD server. Inoltre ho configurato uno 
share basilare.
La macchina win riesce a joinare il dominio, riesce a connettersi allo 
share ma non riesce ad effettuare nessuna operazione sullo share per via 
dei permessi.

Impostando i permessi sulla dir a 777, funziona.
Su molte guide ho visto che si parla del gruppo 'Domain Users' e che 
assegnano con chmod e chgrp i permessi sullo share.

È come se il sistema non riuscisse a vedere gli user/group di samba.

Ho provato a cercare in rete qualcosa riguardo all'assegnazione dei 
permessi delle directory ma nulla.


Il filesystem è xfs.

Cosa sto sbagliando?

Grazie in anticipo.

Re: Corruzione filesystem?

[Marco Gregorio]

Ciao,

gli array sono tutti assemblati e risultano clean.
Il problema è che se invece di fare tardi la notte per lavoro stessi a
lettuccio al caldo, non avrei bisogno di disturbare la lista eseguendo *fsck
su un array piuttosto che su un file system.*

Ovviamente lanciando fsck sulle partizioni piuttosto che sugli interi
array, non risulta alcun problema.

L'ora tarda e questo link ufficiale
https://raid.wiki.kernel.org/index.php/Growing (sezione Extending the
Filesystem) mi hanno tratto in inganno.

Forse potrebbe essere il caso di segnalare l'inesattezza?

In ogni caso chiedo venia per la figura barbina, e grazie a Felipe per la
dritta.

Adesso è tutto OK.

Buon we.

Marco

Il giorno 6 febbraio 2016 10:44, Felipe  ha
scritto:

> In data sabato 6 febbraio 2016 01:46:54, Marco Gregorio ha scritto:
> > Salve a tutti,
> >
> > Primo messaggio in lista, spero di non sbagliare a postare qua.
> >
> > Cerco di spiegare brevemente la situazione e poi vado dritto al punto.
> >
> > Ho due macchine, Fileserver e Backupserver.
> >
> > Fileserver ha / su SSD, e /storage su un RAID 10 mdadm (/dev/md127) con 4
> > dischi da 1 TB.
> > Backupserver ha / su SSD, e un RAID 5 mdadm (/dev/md0) con 5 dischi da 1
> TB
> > come target iSCSI.
> >
> > Backupserver mette a disposizione il target /dev/md0 a Fileserver via
> SCST.
> > Fileserver si connette al target con open-iscsi, e vede l'array come
> > /dev/sdf, con unica partizione sdf1 e filesystem ext4.
> >
> > /dev/sdf1 è montato come /backup.
> >
> > 2 volte al giorno Fileserver esegue backup di /storage usando dirvish
> > (quindi sostanzialmente rsync) su /backup.
> >
> > Nei giorni scorsi ho sostituito i dischi da 1 TB con dischi da 4 TB.
> > Partizionati con gdisk, riaggiunti con mdadm uno ad uno, estendo l'array
> a
> > 16 TB per Backupserver e ad 8 TB per Fileserver.
> >
> > Fin qui, tutto bene.
> > Ora inizia la parte strana.
> >
> > Vado per estendere il filesystem, e per scrupolo eseguo su Backupserver,
> > con servizio SCST arrestato e quindi ad array smontato il comando *fsck
> > /dev/md0.*
>
> Se hai /dev/md0* l'array dovrebbe essere assemblato, diversamente non credo
> sia corretto lanciare fsck su dischi facenti parte di array assemblati con
> RAID che implicano lo striping. Almeno per quanto riguarda lo striping (0),
> fsck va lanciato su md assemblati, diversamente ci può stare che vada in
> pappa.
>
> >
> > Il terminale risponde :
> >
> > fsck from util-linux 2.25.2
> > e2fsck 1.42.13 (17-May-2015)
> > ext2fs_open2: Valore magic non corretto nel super-blocco
> > fsck.ext2: Superblock invalid, trying backup blocks...
> > Super-blocco has an non valido journal (inode 8).
> > Azzera? - rispondo no
> > fsck.ext2: Numero di inode non valido controllando il journal ext3 per
> > /dev/md0
> >
> > Quindi mi insospettisco e provo a montare in locale /dev/md0. *Fallisce
> > miseramente* con il classico
> >
> > mount: wrong fs type, bad option, bad superblock on /dev/md0,
> >missing codepage or helper program, or other error
> >
> >In some cases useful info is found in syslog - try
> >dmesg | tail or so.
> >
> > Ripristino il link iSCSI, e stavolta da Fileserver eseguo* fsck /dev/sdf
> > (cioè l'array md0 di Backupserver)*
> >
> > Di nuovo :
> >
> > fsck from util-linux 2.25.2
> > e2fsck 1.42.13 (17-May-2015)
> > ext2fs_open2: Valore magic non corretto nel super-blocco
> > fsck.ext2: Superblock invalid, trying backup blocks...
> > Super-blocco has an non valido journal (inode 8).
> > Azzera? - rispondo no
> > fsck.ext2: Numero di inode non valido controllando il journal ext3 per
> > /dev/sdf
>
> Ora non mi sovviene il perché restituisca /dev/sdf, quando tu hai il file
> system su /dev/sdf1. Fsck lo lanci su /dev/sfd1 giusto?
> Noto che, fra l'altro, su un file system ext4 lui (fsck.ext2!) parla di
> ext3(!).
> Anche qui, come lanci fsck? Forse il modo più corretto è quello di invocare
> fsck.ext4? Sto ipotizzando.
>
> > *DUBBIO ATROCE*
> >
> > Smonto /storage, e lancio fsck /dev/md127
> >
> > fsck from util-linux 2.25.2
> > e2fsck 1.42.13 (17-May-2015)
> > ext2fs_open2: Valore magic non corretto nel super-blocco
> > fsck.ext2: Superblock invalid, trying backup blocks...
> > Super-blocco has an non valido journal (inode 8).
> > Azzera? - rispondo no
> > fsck.ext2: Numero di inode non valido controllando il journal ext3 per
> > /dev/md127
> >
> > *Provo a montare /dev/sdf1 su /backup e tutto funziona perfettamente.*
> >
> > *Monto di nuovo /dev/md127 si /storage ed è tutto ok.*Riesco a vedere i
> > file, a leggerli, a scrivere senza alcun problema.
> >
> > Qualcuno ha idea di cosa stia succedendo, e dove o cosa stò sbagliando??
> > E anche se possa essere lontanamente intelligente dire a fsck di fare il
> > suo lavoro?
>
> Penso di no. Penso che tu ti stia muovendo bene. Fsck lunge dall'essere la
> soluzione a questo tipo di problemi. Il modo più corretto di interpretare
> l'utilità di fsck è quello di usarlo per il nome 

Re: Gestione indirizzi ip del Dhcpd

[Fabrizio Carrai]

Se il PC non fa un DHCP release [1] esplicito, l' IP viene mantenuto
allocato al richiedente per la durata del lease time. Non dovrebbe essere
un problema aggiungere il comando di release alla procedura di shutdown.

F.


[1]
https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#DHCP_releasing

Il giorno 6 febbraio 2016 15:51, GiancFir  ha
scritto:

> Mi domandavo ma se i demone finisce gli ip di un certo range, come fa a
> sapere se alcuni degli indirizzi che ha dato sono ancora in uso oppure no?
> Mi spiego meglio, un client chiede ed ottiene un indirizzo ip con lease
> time di 3 ore, dopo un ora di collegamento viene spendo il pc, il demone si
> accorge che quell'indirizzo ip è di nuovo disponibile anche se non è
> passato tutto il lease time?
>
> Ciao
>
>
>
> --
> ”Questo è Unix. Ti dà abbastanza corda per impiccarti da solo.”
> Miquel van Smoorenburg
> “Unix E’ user friendly. . . E’ solo selettivo su chi può essergli amico.”
> Tollef Fog Heen
>
>


-- 
*Fabrizio*

Gestione indirizzi ip del Dhcpd

[GiancFir]

Mi domandavo ma se i demone finisce gli ip di un certo range, come fa a 
sapere se alcuni degli indirizzi che ha dato sono ancora in uso oppure no?
Mi spiego meglio, un client chiede ed ottiene un indirizzo ip con lease 
time di 3 ore, dopo un ora di collegamento viene spendo il pc, il demone 
si accorge che quell'indirizzo ip è di nuovo disponibile anche se non è 
passato tutto il lease time?


Ciao



--
”Questo è Unix. Ti dà abbastanza corda per impiccarti da solo.”
Miquel van Smoorenburg
“Unix E’ user friendly. . . E’ solo selettivo su chi può essergli amico.”
Tollef Fog Heen

Re: Corruzione filesystem?

[Felipe]

In data sabato 6 febbraio 2016 01:46:54, Marco Gregorio ha scritto:
> Salve a tutti,
> 
> Primo messaggio in lista, spero di non sbagliare a postare qua.
> 
> Cerco di spiegare brevemente la situazione e poi vado dritto al punto.
> 
> Ho due macchine, Fileserver e Backupserver.
> 
> Fileserver ha / su SSD, e /storage su un RAID 10 mdadm (/dev/md127) con 4
> dischi da 1 TB.
> Backupserver ha / su SSD, e un RAID 5 mdadm (/dev/md0) con 5 dischi da 1 TB
> come target iSCSI.
> 
> Backupserver mette a disposizione il target /dev/md0 a Fileserver via SCST.
> Fileserver si connette al target con open-iscsi, e vede l'array come
> /dev/sdf, con unica partizione sdf1 e filesystem ext4.
> 
> /dev/sdf1 è montato come /backup.
> 
> 2 volte al giorno Fileserver esegue backup di /storage usando dirvish
> (quindi sostanzialmente rsync) su /backup.
> 
> Nei giorni scorsi ho sostituito i dischi da 1 TB con dischi da 4 TB.
> Partizionati con gdisk, riaggiunti con mdadm uno ad uno, estendo l'array a
> 16 TB per Backupserver e ad 8 TB per Fileserver.
> 
> Fin qui, tutto bene.
> Ora inizia la parte strana.
> 
> Vado per estendere il filesystem, e per scrupolo eseguo su Backupserver,
> con servizio SCST arrestato e quindi ad array smontato il comando *fsck
> /dev/md0.*

Se hai /dev/md0* l'array dovrebbe essere assemblato, diversamente non credo 
sia corretto lanciare fsck su dischi facenti parte di array assemblati con 
RAID che implicano lo striping. Almeno per quanto riguarda lo striping (0), 
fsck va lanciato su md assemblati, diversamente ci può stare che vada in 
pappa.

> 
> Il terminale risponde :
> 
> fsck from util-linux 2.25.2
> e2fsck 1.42.13 (17-May-2015)
> ext2fs_open2: Valore magic non corretto nel super-blocco
> fsck.ext2: Superblock invalid, trying backup blocks...
> Super-blocco has an non valido journal (inode 8).
> Azzera? - rispondo no
> fsck.ext2: Numero di inode non valido controllando il journal ext3 per
> /dev/md0
> 
> Quindi mi insospettisco e provo a montare in locale /dev/md0. *Fallisce
> miseramente* con il classico
> 
> mount: wrong fs type, bad option, bad superblock on /dev/md0,
>missing codepage or helper program, or other error
> 
>In some cases useful info is found in syslog - try
>dmesg | tail or so.
> 
> Ripristino il link iSCSI, e stavolta da Fileserver eseguo* fsck /dev/sdf
> (cioè l'array md0 di Backupserver)*
> 
> Di nuovo :
> 
> fsck from util-linux 2.25.2
> e2fsck 1.42.13 (17-May-2015)
> ext2fs_open2: Valore magic non corretto nel super-blocco
> fsck.ext2: Superblock invalid, trying backup blocks...
> Super-blocco has an non valido journal (inode 8).
> Azzera? - rispondo no
> fsck.ext2: Numero di inode non valido controllando il journal ext3 per
> /dev/sdf

Ora non mi sovviene il perché restituisca /dev/sdf, quando tu hai il file 
system su /dev/sdf1. Fsck lo lanci su /dev/sfd1 giusto?
Noto che, fra l'altro, su un file system ext4 lui (fsck.ext2!) parla di 
ext3(!).
Anche qui, come lanci fsck? Forse il modo più corretto è quello di invocare 
fsck.ext4? Sto ipotizzando. 

> *DUBBIO ATROCE*
> 
> Smonto /storage, e lancio fsck /dev/md127
> 
> fsck from util-linux 2.25.2
> e2fsck 1.42.13 (17-May-2015)
> ext2fs_open2: Valore magic non corretto nel super-blocco
> fsck.ext2: Superblock invalid, trying backup blocks...
> Super-blocco has an non valido journal (inode 8).
> Azzera? - rispondo no
> fsck.ext2: Numero di inode non valido controllando il journal ext3 per
> /dev/md127
> 
> *Provo a montare /dev/sdf1 su /backup e tutto funziona perfettamente.*
> 
> *Monto di nuovo /dev/md127 si /storage ed è tutto ok.*Riesco a vedere i
> file, a leggerli, a scrivere senza alcun problema.
> 
> Qualcuno ha idea di cosa stia succedendo, e dove o cosa stò sbagliando??
> E anche se possa essere lontanamente intelligente dire a fsck di fare il
> suo lavoro?

Penso di no. Penso che tu ti stia muovendo bene. Fsck lunge dall'essere la 
soluzione a questo tipo di problemi. Il modo più corretto di interpretare 
l'utilità di fsck è quello di usarlo per il nome che porta, file system check. 
Tutto quello che viene dopo (l'eventuale decisione di farlo proseguire per 
tentare di correggere) deve essere preceduto da backup, analisi, 
approfondimento e speranza.  

> E' possibile che fsck si sbagli, o è molto probabile che ci sia un problema?
> 
> I filesystem sono tutti EXT4.
> 
> Io per precauzione stò facendo il backup di tutto su un NAS, ma la cosa mi
> preoccupa.

Bravo :)

> Grazie a tutti