Newsgroup: it.comp.os.linux.sys
Titolo: Non ce la faccio piu', mi affido a voi

Giuro, non ce la faccio, non capisco:
Server linux che sta in piedi 4-5 giorni, poi muore. Spiego.
Server gestito da remoto (non posso lavorarci fisicamente), 
distribuzione Fedora core 1 aggiornato (fedora core 1 e' da qualche mese 
in legacy project), demoni ssh, sftp, web server apache, pop3, smtp, 
mysql. Iptables molto banale e senza log. Server web apache molto 
sfruttato (100.000 pagine php/giorno), mysql abbastanza, server di posta 
quasi per nulla. Pochissimi utenti abilitati, lo stretto indispensabile 
per la gestione. Apache senza cgi, senza perl, senza openproxy, senza 
https, minimo indispensabile, html e php con mysql.
Ogni 4-5 giorni il server raggiunge, piu' o meno di colpo, una 
situazione incomprensibile. Risponde ai ping, e' in grado di aprire le 
porte ma non emette all'esterno dati. Top non mostra problemi, % cpu a 
0,qualcosa. Free non mostra problemi. Impossibile entrare in ssh per via 
del fatto che il server apre le porte ma non emette dati anche se sembra 
riceverli (ho fatto delle prove cercando di entrare "alla cieca" con 
utenti sbagliati e il tentativo di accesso viene loggato con il nome 
utente casuale che ho inserito). Una volta sono riuscito a sorprendere 
l'esplosione del server mentre ero gia' in ssh e ho visto la macchina 
mooooooolto lenta (top negava carichi sulla cpu). Ps mostrava molti 
processi httpd aperti (forse perche' siccome la macchina era lenta 
doveva lanciare molti sottoprocessi httpd per rispondere a tutte le 
pagine richieste che si accumulavano), molti piu' della norma. Tentando 
di fare lo shutdown la macchina non andava giu'! In ps risultava uno 
script dedicato allo shutdown e init risultava in runlevel 6 ma la 
macchina era ancora li'. Solo killando httpd e rifacendo lo shutdown 
sono riuscito a fare il reboot della macchina.
Ho una serie di script che verifica lo stato di incasinamento del 
server, riescono a rilevarlo ma non riescono a far riavviare il server.
Ora dico, cos'e', cosa succede, cosa posso fare?
Non so piu' dove sbattere la testa.
Mi sto quasi rassegnando all'idea di mettere un timer che riavvii la 
macchina ogni 4 giorni di notte. Possibile che sia l'unica soluzione?

 
A parte che di feTora mi fido assai poco...
Che roba ci gira li sopra? 
Chiaviche pesantissime tipo phpBB o phpNuke ??
Immagina che con questi cosi e con un DB estremamente poco indicizzato, ho
visto macchine schiattare per molto meno.
Magari il tuo problema č qualche spider o qualche "lamer" che mirrora il
sito e la macchina si siede.
Cerca di capire se anche mysql č nel goco del carico pesante...
Max

 sito e la macchina si siede.
In questi casi noterei uso di mysql, uso di cpu, uso di banda, invece da 
top vedo che mysql usa poca cpu, il totale della cpu e' oltre il 90% in 
idle e la banda e' nella norma, anzi quando il server scoppia il 
traffico (lo vedo da una applicazione di monitoring offerta dall'isp su 
cui sono in hosting) in entrata diminuisce a livelli minimi e il 
traffico in uscita pure.

 traffico in uscita pure.
Uhmmm...
Ma se killi apache, torna tutto normale senza rebootare ?
Prova ad abilitare i syncookies tramite sysclt.
Quello che mi viene in mente qualche syn flood, ad esempio, che si mette a
far forkare apache succhiando risorse, filehandle compresi, e alla fine la
macchina schiatta.
I log (non solo di apache) non dicono nulla ??
Lo spazio su /var ce l'hai sufficiente ?
Max

 Server linux che sta in piedi 4-5 giorni, poi muore. Spiego.
<zap>
Io ho un server che ogni tanto fa la stessa cosa, pero' fa molto di 
piu' come servizi. Ancora non siamo riusciti a capire che accidenti
combina. Soluzione: APC Power Switch. Un bel reboot da remoto e via.
Intanto abbiamo ordinato un nuovo server.
Davide
-- 
The three "R"s of Microsoft support: Retry Reboot Reinstall-- Mark Atwood
You forgot one: Repeat-- Lars Balker Rasmussen

 writes:
M> Server linux che sta in piedi 4-5 giorni, poi muore. Spiego.
Somiglia molto ai  miei, salvo per il web che ancora  non e` migrato dal
vecchio server (ma e` attivo).  Ho anch'io FC1 (BTW, ho appena scaricato
l'ISO del DVD di FC3, uscita ieri)  e i miei server ora sono "up" da 181
giorni, ossia da quando un guasto  sulla scheda in fibra dello switch mi
ha impallato  la rete  interna obbligandomi a  far ripartire i  server a
Ferragosto (scontato, no ?).
Ho avuto  problemi di blocchi  improvvisi all'inizio, con il  kernel SMP
che  veniva caricato  di  default  (CPU Xeon):  'yum  update kernel'  ha
risolto il problema, intanto andavao con il kernel "normale". Ovviamente
ho  aggiornato anche  librerie  e  pacchetti critici:  prova  a fare  lo
stesso.
Il kernel  bacato aveva problemi proprio  nel settore rete,  anche se il
bug era legato  piu` a NFS. Nel tuo caso potrebbe  essere anche colpa di
un modulo della scheda di rete difettoso (tanto per fare ipotesi diverse
da quelle degli altri :-)).
Saluti,
Luca Polo.
-- 
Luca...@gest.unipd.it
 --- 
http://www.gest.unipd.it/~jake
----------------------------------------------------------
One Ping to rule them all. One Ping to find them.
One Ping to bring down them all.
And in the darkness crash them.         [The Lord of the Pings]

 


 macchina ogni 4 giorni di notte. Possibile che sia l'unica soluzione?
Potrebbe non essere disprezzabile. Magari prima prova a mettere in cron 
un restart del servizio "network" o di apache, se il leak è causato da 
loro potrebbe essere sufficiente anche quello, senza bisogno di uno 
shutdown totale.
HTH,
bye!
-- 
Fabrizio "Hermooz" Ermini

 macchina ogni 4 giorni di notte. Possibile che sia l'unica soluzione?
Se pensi che il problema sia apache, riavvia solo quello via cron-job.
-- 
Giambo - Occhio al filtro antispam _e_ alla whitelist !

 e usa quello. Fedora usa ancora il 2.4 ?
Il 2.4 per i servers allo stato attuale mi sembra meglio...
imho ovviamente.
MAx 

 Lo spazio su /var ce l'hai sufficiente ?
Assolutamente si', 30 giga... :)

 bug era legato  piu` a NFS. Nel tuo caso potrebbe  essere anche colpa di
Niente nfs sul mio server.

 Non puoi liberarti di Fedora e usare una distribuzione seria, come
E' una macchina remota, non e' cosi' facile purtroppo... Anche a me non 
sta affatto simpatica la fedora.

 Assolutamente si', 30 giga... :)
Uhm...versione di apache?
-- 
Per non dimenticare:
http://snipurl.com/SdC_ed_il_vino
Le sigarette a volte danno buoni consigli:
http://snipurl.com/sigarette

 porte ma non emette all'esterno dati. 
A me era capitata la stessa cosa !!
Era iptables , in particolare ipconntrack , che raggiungeva il max num di conn .
Risolto tunando a manina il numero di giorni che si doveva tenere nella tabella e ricompilando il kernel .
Non so se il tuo caso cmq da un dmsg dovreti notarlo per bene ..
Ciauz

> Uhm...versione di apache?
httpd-2.0.51-1.4.legacy

 sta affatto simpatica la fedora.
Il mio era un tentativo di innescare una flame-war :-) ...


 httpd-2.0.51-1.4.legacy
Non so...c'e' in giro un DoS per httpd <= 2.0.52...


 troppi child e sovracarica la macchina ...
Fosse anche, perche'? Io non vedo motivazione. La macchina lavora 
egregiamente con un basso uso di cpu per 5 giorni alternando carichi 
piu' pesanti di giorno e carichi piu' leggeri di notte, poi ad un 
tratto, a volte (ma piu' raramente) anche in piena notte con basso 
carico, smette di funzionare, di colpo, senza picchi di richieste in 
entrata, senza picchi di traffico in uscita, senza cron che partono, 
senza programmi strani in memoria, senza nessun genere di log, di nessun 
genere, non sono riuscito neppure una singola riga in concomitanza 
all'incarinamento del server, neanche una riga che non c'entrasse nulla, 
non viene registrato nulla di particolare.
Che apache sovraccarichi la macchina io per ora non posso confermarlo 
ne' smentirlo. Che generi troppi child ho il sospetto che sia solo un 
effetto del problema e non la sua causa dal momento che non c'e' nessuna 
ragione logica per cui apache debba mettersi di colpo a creare decine e 
decine e decine di child.

> Non so...c'e' in giro un DoS per httpd <= 2.0.52...
Parli di questo?
Fixed in Apache httpd 2.0.53-dev
important: Memory consumption DoS CAN-2004-0942 
An issue was discovered where the field length limit was not enforced 
for certain malicious requests. This could allow a remote attacker who 
is able to send large amounts of data to a server the ability to cause 
Apache children to consume proportional amounts of memory, leading to a 
denial of service. 
Affects: 2.0.52, 2.0.51, 2.0.50, 2.0.49, 2.0.48, 2.0.47, 2.0.46, 2.0.45, 2.0.44, 2.0.43, 2.0.42, 2.0.40, 2.0.39, 2.0.37, 2.0.36, 2.0.35
Si parla di "to send large amounts of data" e io non ho mai notato 
picchi d'uso di banda in occasione dell'incasinamento del server.
Oltre al fatto, come gia' detto, che il casino appare sempre a distanza 
di 4-5 giorni dall'ultimo reboot. Mai una volta prima, mai una volta 
dopo.
Non so, cosi' a pelle non credo sia questo il problema.

 un restart del servizio "network" o di apache, se il leak è causato da 
Non e' una brutta idea, tentero' sicuramente.

 Non so se il tuo caso cmq da un dmsg dovreti notarlo per bene ..
Nulla di nulla in dmsg.

 archiviate e soprattutto perche' non le butta via dopo un tot?
Chiamare 'imbecille' iptables senza mostrare grande cognizione di causa
non ti fa molto onore.
Chiediti, piuttosto, se hai davvero bisogno di trackare le connessioni
http, invece di spararle grosse.


 http, invece di spararle grosse.
Sicuramente non mi e' necessario, d'altra parte non ho neanche chiesto 
che cio' venisse fatto. Cosa intendi con trackare le connessioni http? 
Chi lo fa? A cosa serve? Cosa succede se lo si toglie? Dove lo si 
toglie?

 toglie?
ip_conntrack è un modulo di netfilter che serve a garantire la
statefulness di netfilter stesso.
Si usa tipicamente sui firewall che si vuole stateful.
Su un webserver, a rigore, non dovrebbe servire (ma dipende
ovviamente dalla situazione).
E se non serve, si evita di caricarlo allo startup, semplicemente.
Ma ribadisco: è ancora da capire quale sia l'effettivo problema del
tuo server.
I log del sistema proprio non aiutano?
-- 
"Io mi sarei aspettato un intervento più misurato dall’assessore Ascoli, 
nel senso che, ospite in questo paese, poteva avere maggiore rispetto..."
(Giannotti di Forza Italia all'assessore Ascoli, ebreo italiano)
http://snipurl.com/antisemitafi

M'arrovello quindi sono wrote:
 >... gzip...
ho letto tutto il thread e mi sono fatto un'idea, e cioè che tu abbia un 
bel worm su quella macchina. I sintomi possono essere simili, e a me era 
capitato.
Quindi prova a scaricare f-prot per linux che è free, lancialo a partire 
dalla root, se ti trova il worm OSF-A so cazzi...
No tranquillo, se te lo trova dimmi che ho un programmino che mette 
rimendio senza fare reboot, perchè f-prot non riesce a cancellarlo.
Sono convinto cmq nel tuo caso si tratti di un worm. Per linux ce ne 
sono pochi ma cmq qualcuno ogni tanto rompe...
xero°kelvin
xe...@xerolab.com
 --> se rispondi, forwarda anche qui che spesso non leggo..

 Non e' una brutta idea, tentero' sicuramente.
no... l'avevo fatto anche io, è solo un workaround, ma più che di worm 
qui si parla di un rootkit che si rende invisibile, non hai la 
possibilità di vederlo con ps, top e via dicendo, tra l'altro apre una 
backdoor sulla porta 3089 mi pare... che con netstat ovviamente non 
vedi. Come primo workaroud impedisci alla macchina di ricevere 
connessioni tranne che dalla porta 80 dalla WAN...
xero°kelvin

   sta cambiando davvero...
mah, adesso pare che per contratto impediscano ai propri dipendenti di
lavorare a progetti opensource nel loro tempo libero...

 dalla root, se ti trova il worm OSF-A so cazzi...
Ho tentato di installare f-prot ma mi ha detto che gli manca una 
libreria wwwlib-perl o qualcosa del genere, pacchetto che tra l'altro 
sono poco dell'idea di installare per i risvolti di sicurezza e di 
stabilita' del server. Mi chiedo cosa se ne faccia un antivirus di una 
simile libreria... Che lameri...
Ad ogni modo mi sono studiato il virus osf e si tratta appunto di un 
virus, non di un worm. Significa che non entrera' mai dall'estero 
sfruttando vulnerabilita' ma sarei io a dover eseguire in locale un file 
infetto e siccome ci sto attento a cosa eseguo...
Comunque ho anche fatto qualche test in base al comportamento del virus 
(aumento della dimensione dei file infetti) e non risulta nulla del 
genere.

> combina. Soluzione: APC Power Switch. Un bel reboot da remoto e via.
Spiegalo ai miei capi che vorrebbero un uptime del 100%. =)

 I log del sistema proprio non aiutano?
Proprio no. Se ci fosse almeno mezza riga mi attaccherei a quella ma non 
c'e'. L'unica, piccola, minima cosa e' che nei log di apache, se 
normalmente trovo roba tipo
10:13:02 /pippo.php
10:13:05 /pippo.php
10:13:22 /pippo.php
10:13:29 /pippo.php
10:13:33 /pippo.php
durante il casino del server trovo
10:13:02 /pippo.php
10:06:20 /pippo.php
10:13:22 /pippo.php
10:16:39 /pippo.php
10:07:54 /pippo.php
cioe' si perde l'ordine cronologico, credo per via del forte carico 
della macchina che fa si' che l'elaborazione delle pagine impieghi 
minuti e minuti e non e' piu' detto che la pagina eseguita per prima 
termini per prima se nel frattempo ne viene eseguita una seconda e una 
terza e tutto si accavalla su se stesso.
Che casino...

 firewall. E vediamo come vanno le cose...
Nessuno casino al server con un uptime di 10 giorni, fantastico! Quindi 
pare proprio che tutta la colpa sia di quel cazzo di iptables!

   sta cambiando davvero...
Guarda il mio User-Agent, e valuta anche alla luce di questo.
I computer Apple sono macchine fantastiche. Li adoro. Hanno
un'ingegnerizzazione superba. 
Il G5 e` un processore fantastico.
Resta una questione... MacOS X e` un bellissimo sistema operativo
desktop (mi si perdoni, ma complessivamente al momento attuale e dal mio
punto di vista migliore di GNU/Linux, nonostante io adori GNOME).
Tuttavia su un server scala meno di GNU/Linux. IMHO sotto carico di
lavoro intensivo una bella Linux Box (eventualmente su hardware Apple)
e` ancora imbattibile.
-- 
RiK0
Non credo negli schemi non vincenti.