Newsgroup: it.comp.os.linux.sys
Titolo: bind di due directory con -o remount

/tmp ï¿œ una directory (ma dai? che novitï¿œ)
per farla in noexec, devo procedere in questo modo:
mount --bind /tmp /tmp
mount --bind -o remount,noexec /tmp
ovvero, fare il bind per poi rimontarlo in sola lettura.
due passaggi.
Come mai non ï¿œ possibile fare un singolo passaggio tipo.
mount --bind -o noexec /tmp /tmp
?
Altra cosa: affidabilitï¿œ di questa situazione? Che differenze
ci sono tra il creare un fs separato e montare quello in noexec
rispetto a fare il bind di una directory su se stessa e poi il
remount in noexec?
a parte il doppio passaggio, fare il bind di svariate directory
semplificherebbe di molto il partizionamento dei server virtuali,
che possono partire tutti da un filesystem comune e poi in base
alle necessitï¿œ rimontare le directory (senza partizionare ogni
volta in base alla destinazione d'uso)

 mount --bind -o remount,noexec /tmp
Perche` non fai direttamente 
mount -o remount,noexec /tmp
?? C'e` qualcosa che non so?
Bye.

 ?? C'e` qualcosa che non so?
Perchè /tmp non è su un filesystem separato
per cui non è montato e di conseguenza il
remount non va.
(mi dice: "Remount de che, /tmp nun c'è sta in fstab,
me stai a pija per er culo?)
/tmp è una banalissima directory, che devo
mettere in noexec,nodev,nosuid senza stare
a creare un FS separato (secondo disco o
immagine in loop)
Per questo motivo devo fare due passaggi,
prima lo monto in bind, poi lo rimonto con
i nuovi parametri.
Quel che non capisco è coma mai mount non
da peso ai parametri "noexec, nodev, nosuid"
direttamente al singolo passaggio.
Un bug?

 volta in base alla destinazione d'uso)
Dipende per cosa servono i vari filesystem e comunque ci sono dei drawbacks, 
p.es
.:
- Lo spazio ï¿œ condiviso, quindi un'applicazione puï¿œ esaurire tutto lo spazio 
e inficiare il funzionamento delle altre o del sistema.
- Il filesystem ï¿œ unico, quindi non puoi scegliere filesystem diversi per 
scopi diversi; per certe cose ï¿œ meglio ext3, per altre reiserfs, per altre ï¿œ 
necessario fare tuning, 
p.es
. per le news
- Si corrompe un filesystem e perdi tutto, negli altri casi perdi solo 
quell'insieme di dati
- Un filesystem con molti accessi concorrenti tende a degradare in modo piï¿œ 
significativo di uno con accesso singolo e se hai un DB la differenza puï¿œ 
essere molto sensibile
- Certe opzioni non sono utilizzabili con --bind, 
p.es
. mand
- Varie ed eventuali :-)
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 - Varie ed eventuali :-)
Quindi tu nel caso di serverini web sconsiglieresti ugualmente il
mount delle directory?
(in riferimento al kilometrico thread dove parlavo di un cluster di
web, adesso che ci penso potrei fare tutto monopartizione e montare
in bind solo la /tmp e la /www.
Se si corrompe il fs, butto via tutto e ricreo una seconda vm, tanto i
dati sono su storage esterno e le configurazioni sono su database)

 mount delle directory?
No. Io uso regolarmente directories montate in bind in svariati contesti. 
Solo devi valutare se ne vale la pena alla luce di quanto precedentemente 
esposto :-)


 precedentemente esposto :-)
Be questo ï¿œ chiaro.

 preso mentre /proc/mounts conferma quanto da te asserito.
Uhm...bizzarro, davvero.

 preso mentre /proc/mounts conferma quanto da te asserito.
/etc/mtab e` solo per compatibilita` all'indietro e per applicativi
pensati per altri sistemi unix. Su linux, quello che fa fede e`
/proc/mounts
Enrico

 /proc/mounts
Questo non è propriamente corretto. /proc/mounts rispecchia la situazione 
che vede il kernel, quindi quella effettiva, ma /etc/mtab ha comunque una 
sua importanza in quanto è il file che rispecchia le invocazioni di mount e 
che viene letto da mount quando viene eseguito senza parametri.
Considerando che molti script e programmi agiscono in funzione del contenuto 
di /etc/mtab (direttamente o appunto tramite mount) è importante che vi sia 
congruenza tra quel che dovrebbe essere e quel che è.
Il link simbolico tra /proc/mounts e /etc/mtab non deve essere la soluzione 
dato che vi sono controindicazioni.


 soluzione dato che vi sono controindicazioni.
Non risolverebbe comunque il problema.
il mount in binding tra due directory con i parametri
noexec non si può fare.
Sia che /etc/mtab rispecchi /proc/mounts oppure no.
AFAIK, se eseguo un comando in una noexec è il kernel che
controlla se la directory in cui sono è in noexec in base
al contenuto di /proc/mounts (o meglio, in base a cosa sa il
server riguardo quel mountpoint).
Se io sincronizzo /etc/mtab con /proc/mount il kernel non sa
e continuerà a non sapere che /tmp è in noexec.
Per me è un bug di mount che aggiorna mtab e non istruisce il kernel
a riguardo ma lo fa solo con un remount.
Leggevo su google (ma andavo di fretta) che anche altri hanno avuto
questo problema e si pensava ad un bug di mount. Non so a che
conclusione siano arrivati. Secondo alcuni è un comportamento normale
e corretto, ma non ne riesco a trovare ne i pregi ne i vantaggi.
a me sa tanto di bug.

 ?
Nel man di mount sta scritto chiaro:
| Note that the filesystem mount options will remain the same as those on
| the  original  mount  point,  and  cannot  be changed by passing the -o
| option along with --bind/--rbind.
Il workaround è appunto fare prima il bind da solo, e poi rimontarlo
cambiando le opzioni: due passaggi invece di uno.
Quando mi ero interessato della cosa, ricordo di aver letto che molti
auspicavano che i futuri kernel risolvessero. Ad oggi ancora nulla
di nuovo sotto il pinguino... ehm... pare.
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
____________________________________________________________________________
Non sprecare i cicli idle della tua CPU: 
http://boinc.berkeley.edu/index.php

 di nuovo sotto il pinguino... ehm... pare.
Quindi, in altre parole, è un bug.
Non vedo motivazioni valide per cui non interpretare le opzioni
di mount al primo passaggio.

 senza parametri.
MdI suggeriva, tempo fa, un ln -s di /proc/mounts a /etc/mtab.
Quali sono le controindicazioni, per te?

 Quali sono le controindicazioni, per te?
Il motivo per cui lo avevo tolto era il problema con l'uso dei loop-device 
che non venivano liberati se mtab era un link a mounts. Ora non so se è 
ancora così (e non ho voglia/tempo di testare) ma non penso sia cambiato.
Questo è un vecchio articolo che trattava pro e contro delle soluzioni.
http://www.linuxfromscratch.org/pipermail/hints/2002-November/001360.html
Io mtab lo linko a mounts solo su filesystem ro o dove so non dover usare 
mai loop device (veramente raro perché anche sui server lo uso spesso).


 spesso).
Ad esempio, lo usi per fare cosa un loop su un server?
Hai detto spesso, deve esserci una casistica frequente, un banale
swap file o una tmp in loop non la considero.


Per esempio per montare immagini ISO di prodotti oppure per alcuni software 
come havp che richiedono un device con mandatory locking e che di default si 
fa un suo loop device, ecc.ecc.
Poi dipende dal server e dal tipo di utilizzo. Per esempio ho un server per 
il boot via PXE per installare alcune altre macchine e lì montare l'initrd 
di boot in loop è all'ordine del giorno...


 l'initrd di boot in loop è all'ordine del giorno...
Direi che sei stato esaustivo.
+10 punti. ;-)

 quell'insieme di dati
Si, ma a fronte di una pianificazione piï¿œ meticolosa all'inizio.
Ne vale la pena?
Ritornando sempre al discorso di VM web monosito:
mi si corrompe la /var/www son cazzi e ripristino il backup
mi si corrompe la / poco male, ripristino il backup o reinstallo tutto
mi si corrompe la /var/lib/mysql son cazzi e ripristino il backup.
In tutti i casi, i dati piï¿œ importanti se corrotti mi costringono ad
un restore.
Parlando di VPS, il restore di un miniserver da 10GB impiega pochi
minuti.
Conviene pianificare la suddivisione delle partizioni in questa
casistica?

 in un server monosito?
Non ï¿œ una domanda cui si puï¿œ dare una risposta sensata di primo acchito.
Se il tuo obiettivo primario ï¿œ utilizzare al meglio lo spazio senza 
rinunciare ad alcune features di sicurezza come il noexec (e non hai paura 
se si riempie un filesystem), il bind ï¿œ certamente indicato.
Se il tuo obiettivo ï¿œ mantenere la separazione netta dei filesystem a costo 
di sprecare spazio allora i volumi sono la scelta migliore.


 paura se si riempie un filesystem), il bind ï¿œ certamente indicato.
Non ï¿œ che non mi fa paura il riempimento di un filesystem.
Semplicemente, se si riempe il filesystem con mysql, mi collassa anche
tutto il web. (oggigiorno, quasi tutti i siti fanno uso di db).
Se si riempie il filesystem con i log, mi collassa anche apache (non
dovrebbe, ma mi ï¿œ giï¿œ capitato su due server)
Allora, dato che il riempimento di un filesystem mi fa collassare
ugualmente i servizi principali, tanto vale mettere tutto in un
singolo filesystem. Root riuscirï¿œ comunque ad accedere grazie al
5% di spazio riservato.
Questo ovviamente vale per delle piccole vps, in caso di server veri
e con grossi dischi, il partizionamento ï¿œ d'obbligo, o meglio, molto
consigliato.
Ma su una vps ci vuole piï¿œ tempo a partizionare che a mettere in piedi
la macchina stessa, non so se ne vale la pena.

 dovrebbe, ma mi ï¿œ giï¿œ capitato su due server)
Io ormai per apache uso |logger e dall'altra raccolgo con rsyslog.
Mi sono semplificato enormemente la vita. :-)


 Mi sono semplificato enormemente la vita. :-)
E' quello che devo sperimentare io tra oggi e domani.
Pappa pronta: mi mandi la sezione inerente apache di rsyslog? :-D
Non ho avuto modo di lavorare seriamente su rsyslog ma mi piacerebbe
fare, nel serverone centralizzato, una struttura di questo tipo:
/var/log/servers/<hostname>/<servizio>/<anno>/<mese>/<giorno>.log
e per i vhost qualcosa di leggermente differente, bypassando il
server, che non mi interessa:
/var/log/servers/apache2/<vhost>/<anno>/<mese>/<giorno>-access.log
Non dovrebbe essere troppo difficile, devo solo guardare come fare.
Inoltre, ho letto che ï¿œ possibile istruire rsyslog sui client per
loggare sia in remoto, che in locale.
Potrei tenere in remoto lo storico di molto tempo (anni?) in locale
invece solo gli ultimi 2-3 giorni o l'ultima settimana.
Adesso che mi viene in mente, io ho creato il filesystem separato per i
log, che ï¿œ superfluo, loggando in remoto, mannaggia alla fretta!!

 loggare sia in remoto, che in locale.
Sï¿œ


 per non rompere le linee.
Grazie mille!

 fare, nel serverone centralizzato, una struttura di questo tipo:
Personalmente, piu` che salvare su file, stavo pensando di interfacciare
rsyslog con un database (PostgreSQL nel mio caso), in quanto la
struttura delle tabelle mi e` sembrata abbastanza razionale (senza
contare che con le apposite query mi estraggo molto piu` facilmente i
dati che mi interessano)
Enrico
P.S. sarebbe interessante valutare anche dsyslog, in quanto la sintassi
di configurazione e` simile a syslog-ng e le sue funzionalita` sono
comparabili a rsyslog (supporto a RDBMS compreso). Purtroppo il suo
biglietto da visita (ovvero il suo sito) non lascia presagire nulla di
buono, in quanto non riporta alcuna informazione (a quanto pare e` una
laconica pagina bianca)

 /var/log/servers/apache2/<vhost>/<anno>/<mese>/<giorno>-access.log
Il server prendilo lo stesso, hai visto mai che domani metti su qualcosa
in round-robin...
-- 
ValeRyo
CBR600F "Cerbero" - 
http://www.slimmit.com/go.asp?6YT
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

 in round-robin...
Non domani, ma oggi.
Saranno in cluster bilanciati con LVS.
A che potrebbe servirmi salvare l'hostname del worker?

 dati che mi interessano)
Sarebbe interessante valutarne le prestazioni ed il carico sul database.
Il problema � sapere se gestisce tabelle multiple od una sorta di
rotazione delle stesse.
Su un server ben trafficato, ti ritroveresti in poco tempo (ore?) con
milioni di record in una singola tabella.

 ha scritto
nel messaggio news:h3hffu$5t2$
1...@peregrinotuc.motzarella.org

Non lo so, in generale pi� informazioni ho e pi� mi sento tranquillo.
Se un applicativo non va, perch� c1 ha le gd 2.0.35-20 e c2
le gd 2.0.35-20a, l'informazione mi torner� utile :-)
Ovviamente se sei organizzato perch� questo non accada, oppure
salvi anche l'hostname nei log, averli in un unico file � pi� comodo.


 salvi anche l'hostname nei log, averli in un unico file ï¿œ piï¿œ comodo.
Perï¿œ, concordo sul fatto di avere piï¿œ informazioni, per cui, salviamoci
anche l'hostname, tanto ï¿œ gratis ;)

 milioni di record in una singola tabella.
Devo ripetermi per la terza volta? :)
Enrico

 Devo ripetermi per la terza volta? :)
Tu quindi useresti viste, indici, partizionamento, trigger... ?
:)

 che vuoi (viste, indici, partizionamento, trigger...)
Ok, vada per il db con prestazioni accettabili.
Perderesti però la possibilità di fare scripting sui log.
Ad esempio, un controllo incrociato con awk|sed|quelchevuoi se
hai tutto su db non sarebbe più possibile.

 :)
Si, in quanto sono gli strumenti che permettono di gestire e manipolare
i dati:
 - Voglio fare delle trasformazioni ai dati inseriti dall'applicativo?
   Aggancio alla tabella un trigger che provvedera` a tutte le
   manipolazioni che mi servono. Il vantaggio e` che tali manipolazioni
   saranno trasparenti all'applicativo ma avranno come conseguenza un
   rallentamento nelle operazioni di insert (senza contare che
   potrebbero esserci perdite di dati dovute a bug nel trigger che
   abbiamo scritto).
 - Mi serve accedere ad un solo sottoinsieme di dati? Creo una vista,
   che altro non e` una query specifica su cui vado a fare le mie
   analisi. Il vantaggio in questo caso e` che posso trattare la vista
   come una tabella qualsiasi e, mediante l'uso di appositi trigger,
   posso gestire anche degli inserimenti su di essa
 - Necessito di ottimizzare l'accesso ai dati? Creo un indice sulla
   tabella tenendo conto dei criteri di ricerca che andro` ad
   utilizzare. L'accesso ai dati sara` notevolmente velocizzato, con lo
   svantaggio di avere un piccolo rallentamento durante la fase di
   insert, in quanto il dato oltre ad essere scritto nella tabella deve
   essere notificato nell'indice.
 - Prevedo che la tabella avra` milioni e milioni di record? La
   partiziono (logicamente, visto che nessun RDBMS FLOSS supporta
   attualmente il partizionamento fisico). L'accesso ai dati sara`
   notevolmente piu` veloce, in quanto le query si riferiranno ad un
   solo sottoinsieme, mentre per l'applicativo la cosa sara` totalmente
   trasparente. Il costo dell'operazione e` che ti si complica la
   gestione della tabella (non hai un solo oggetto, ma tanti piccoli
   oggetti aggregati) e che le operazioni di insert potrebbero
   rallentare sensibilmente a causa dei controlli necessari per gestire
   i dati.
Ovviamente tieni presente una cosa: tutti i rallentamenti di cui parlo
sono percettibili solamente in caso la mole di inserimenti superi le
centinaia di migliaia di record al secondo. In altri casi, difficilmente
sara` per te un problema
Enrico

 Perderesti però la possibilità di fare scripting sui log.
Falso, i controlli li fai lo stesso cambiando gli strumenti o aggirando
l'ostacolo in altre maniere. Per il primo caso, basta che usi Perl,
Python, Ruby od un qualsiasi altro linguaggio di scripting che abbia le
librerie necessarie all'accesso al database. Per il secondo caso, basta
che ti fai restituire un output formattato dal client che usi per
connetterti al database e poi lo redirigi agli strumenti che ti
interessano
Enrico

 interessano
... perchè se devi fare una operazione in fretta non puoi tutte le volte
dover passare da mysql e fare una select.
Tu diresti di fare qualcosa tipo:
mysql --silent -e "SELECT CONCAT_WS(' ', campo1,campo2,campo3)" | grep 
cicciopasticcio -A 3 -B 5 | awk '{print $9}' ?
In pratica ti spari furoi da mysql un output analogo ad un file di log
per poi processarlo con tutti gli altri tools?
IMHO, è solo una complicazione.
Tutto dipende da che controlli e con quanta frequenza devi interrogare i
log.

 log.
Ripeto, gli unici problemi che vedo sono dovuti alla pigrizia
dell'utente e all'uso di strumenti di analisi che accedono direttamente
ai file di log. In tutti gli altri casi, l'uso di un dbms per tenere i
dati di log secondo me e` una idea fattibile e buona
Enrico

 dati di log secondo me e` una idea fattibile e buona
A di, non so che dire.
Potrei anche mettere tutti i log su mysql ma ho paura che sia solo
uno spreco di risorse ed una complicazione inutile.
Alla fin fine, devi configurare due cose: rsyslog e mysql.
Salvando su testo, configuri solo rsyslog, fa tutto lui.
Salvando su mysql, devi anche creare un database e configurarlo
a modo.
Altre persone che loggano abnormi quantità di dati su mysql?
Pareri?

 Salvando su testo, configuri solo rsyslog, fa tutto lui.
Non e` vero, come minimo devi configurare anche logrotate, altrimenti
rischi di trovarti dei file di log dannatamente ingestibili (e.g. devi
fare il parsing di un file contenenti milioni di righe scansionandolo
in modalita` sequenziale). Con un RDBMS tutto questo non serve, in
quanto il sistema e` pensato per contenere e gestire milioni di record a
prescindere, mettendo a disposizione dell'utente gli strumenti necessari
per gestire una tale mole di dati (e.g. indici)
Enrico
P.S. ho visto che nomini spesso MySQL. Un consiglio: evitalo

 per gestire una tale mole di dati (e.g. indici)
IMHO ogni strumento ha pregi e difetti. Un DB va bene quando devi manipolare 
i dati, e questo riesce bene quando hai un'interfaccia che inserisce i dati, 
li estrae, li elabora, ecc.ecc.
Ma una cosa banale come la consultazione dei log o la loro archiviazione 
diventa un calvario con un DB e il file di testo � sicuramente la scelta 
migliore.
Se per esempio devi cercare il motivo per cui una cavolo di mail viene 
rifiutata dal tuo amato postfix con un file di testo � sufficiente che usi 
less, cerchi i dati e leggi la riga ed eventualmente le 20/30 righe successive.
Con un DB diventi scemo. Non puoi farti la select completa perch� sono 
troppi dati e ammazzi la macchina, i dati sono strutturati e quindi non 
facilmente interpretabili, per vedere quel che accade nei dintorni del 
momento incriminato ti costa altre query. Solo con un'interfaccia dedicata 
puoi semplificarti la vita, ma ne vale la pena?
E l'archiviazione su file � quanto di pi� semplice possa esistere; perch� 
complicarsi la vita con un DB?


 
Hai espresso esattamente il mio pensiero.
Al limite, potrebbe essere utile spostare su db i log archiviati.
Trovare un log di 8 mesi fa tramite db � sicuramente pi� facile
che cercare un log attuale, questo per due motivi:
1) un log di 8 mesi fa lo vai a vedere, esagerando, 1 volta nella vita, 
un log attuale lo guardi, in certe circostanze, 100 volte al giorno (se 
devi fare del debug ad esempio)
2) un log di 8 mesi fa pu� stare benissimo su un serverino mysql 
dedicato, con una select se ammazzi la macchina poco importa, la lanci
ed intanto ti bevi un caff�. Se ammazzi la macchina che ti sta loggando,
perdi anche tutti i nuovi record.
3) per cercare un log di 8 mesi fa, magari andando a memoria,
� sicuramente pi� conveniente fare una select su un db con ricerca 
fulltext.
Diventa grosso qualche petabyte, ma ti permette di fare ricerche pi�
avanzate rispetto ad un banale grep o qualche sorta di scripting in bash.
Al limite, si potrebbe fare uno script che legge un log e lo butta su
mysql. Cos� facendo, se devi fare interrogazioni evolute importi il
log e poi interroghi il database, ma solo in caso di necessit�, evitando
di complicarsi la vita a prescindere.

 P.S. ho visto che nomini spesso MySQL. Un consiglio: evitalo
(a tutto il resto ti ha risposto Zipman)
Perch� dovrei evitare MySQL ? Tra i miei clienti non ho nessuno
che fa Facebook di nome (che usa mysql) per cui non vedo quale
problema possa dare mysql rispetto a postgresql, se non andando
a prendere o qualche benchmark o qualche casistica ben particolare
e ben tarata per far risaltare postgresql.
Probabilmente mysql manca di qualche funzionalit�, ma se a me non
servono, perch� dovrei evitare un rdbms in favore di un altro solo
perch� quest'ultimo ha 5 features in pi� che non user� mai?
(e poi, cosa ancora pi� importante, non metter� mai in produzione
un sistema che non conosco, con postgresql non so nemmeno creare un
database da linea di comando, figuriamoci se lo posso mettere in
produzione per archiviare i log)

 produzione per archiviare i log)
psql -U utente -W password template1
create database pippo;
\l [lista dei DB]
\c nomedb [si collega al db]
\d [ti da` la lista delle tabelle]
\h [help in linea dei comandi sql]
\h create table [help completo del comando create table]
\? [help in linea di tutti i comandi \qualcosa]
quit
Amministrare postgres da linea di comando e` anche piu` semplice che 
amministrare mysql che, fino alla 5.x, non aveva nemmeno l'help in linea.
L'unica cosa che ho trovato "difficile" appena iniziato era che mysql 
usava root senza password come utente per tutto, mentre con postgres devi 
per forza definire gli utenti e le loro autorizzazioni. Capito quello vai 
come un missile.
Bye.

 come un missile.
Non usa root senza password, usa un utente root, la password poi la
cambi te in base alle necessità, così come creare altri 545 utenti,
se servono.

 servono.
Infatti ho scritto "usava". Stiamo parlando di mysql 3.23, quando ho 
iniziato a usarlo. E praticamente dappertutto veniva installato come 
root, senza password, e tutti gli script php che si trovavano in giro lo 
usavano in quel modo. Sembrava non ci fosse altro modo per accedere.
Quando ho iniziato a usare Postgres (6.5 se non ricordo male) e ho visto 
che c'erano gli utenti, mi sono chiesto se non ci fossero anche in mysql, 
e ho iniziato a usarli, mettendo anche una password a root. :)
Bye.

 complicarsi la vita con un DB?
Anche con un RDBMS l'archiviazione e` quanto di piu` semplice ci possa
essere, visto che si tratta di eseguire un dump e di copiarlo sul
supporto di backup. Per quanto riguarda l'ultima domanda, secondo me non
ti complichi la vita, ma te la semplifichi, visto che i RDBMS sono nati
apposta per definire una interfaccia semplice e comune per l'estrazione
e la manipolazione dei dati
Enrico

 e la manipolazione dei dati
Ma nell'analisi dei log non fai estrazione e manipolazione.
Fai consultazione che è un'attività sequenziale di lettura di informazioni 
(non strutturate).
IMHO la soluzione ideale è quella di fare il doppio salvataggio dei dati di 
log, su file e su DB, lasciando su quest'ultimo solo l'ultima settimana per 
la consultazione dei dati tramite interfaccia (normalmente per il cliente), 
mentre l'archiviazione e la consultazione da parte del sistemista avviene 
dal mitico vecchio e bistrattato file di testo :-)
E ricordati che un file di testo non si corrompe mai :-D
