Newsgroup: it.comp.os.linux.sys
Titolo: server sempre "up"

Salve a tutti, mi trovo a dover consigliare l'architettura hw/sw per un 
file server / router che dovrebbe stare su 24/7 con meno manutenzione 
possibile. 
Dato per scontato che consiglierò una soluzione linux, ho i seguenti dubbi: 
Software:
- è meglio fare degli script che periodicamente (che so, ogni settimana) 
riavviino i servizi più usati? Pensavo in particolare a  samba, httpd 
(anche se questo servizio verrà usato solo internamente alla lan e non si 
prevedono grandissimi carichi), firewall (flush periodico delle regole 
ipchains e ricaricamento in memoria), ecc.
E' necessario oppure sto solo perdendo tempo? 
Tenete conto che lo scopo è quello di mettere su una macchina che sia il 
più "autosufficente" possibile per limitare gli interventi di manutenzione 
per cause banali. 
- sono indeciso su come impostare (se impostare) il risparmio energetico. 
So che in ambiente windows una macchina risvegliata da uno stato di basso 
consumo probabilmente crasherà nei primi 10 minuti, con linux com'è? Ci 
saranno (sperabilmente..) ore della notte in cui la macchina non verrà 
utilizzata.
- altri consigli? Ho già in mente uno script che controlli ogni 5 minuti lo 
stato della connessione adsl.
Hadware:
Pensavo (per motivi di principio) di consigliare una macchina basata su AMD 
Athlon. Il carico di lavoro sarà principalmente sui dischi (devo ancora 
documentarmi bene, ma pensavo ad un paio di dischi scsi oppure una 
soluzione raid) e ovviamente sul processore, ma i requisiti più importanti 
sono l'affidabilità dei componenti.
Consigli?
Grazie
Marcello
-- 
antispam
ab...@libero.it
ab...@tin.it

 sono l'affidabilità dei componenti.
Direi che dovrebbe andare bene: con dei dischi SCSI in RAID (ed una
buona politica di backup) non dovresti avere grossi problemi.
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
<<   For my real address... ask the Balrog.       >>
* Sostenete la Lega per la Soppressione dei Troll *

 Consigli?
Compaq, un macchinetat prolaint con smart array, viene via con meno di 4
milioni...

 riavviino i servizi piů usati? Pensavo in particolare a  samba, 
Se riavvi Samba (se funge da server WINS, tramite nmbd) perderai la cache
dei nomi netbios ... un po' la stessa cosa che succederebbe con named ...
Io, per questa ragione, non fermerei mai dei servizi come named o samba.
-- 
Ciao ....
      Massimiliano ADAMO
   E-Mail: 
maxa...@iol.it

 po' paranoico? :)
Forse hai ragione... sono un pò paranoico... ma più che un server mi sembra 
di dover preparare un soldato per andare in guerra. 
Mi occorre una macchina veramente "blindata", e che dia meno problemi 
possibile. Tra l'altro vado contro i miei interessi perchè guadagneremo 
meno con l'assistenza ma caso mai non si fosse capito questo è un lavoro 
che non volevamo accettare e siamo stati costreti per motivi di "pubbliche 
relazioni". 
Spero tanto che il pinguino resista in quello zoo.....
Grazie dei consigli.


relazioni". 
un serverino ssh no? eventualmente un modem dial-in attaccato alla
seriale? Anche per me spesso e' un problema andare in giro, ma ho
risolto con uno o entrambi questi due accorgimenti (a seconda di quanto
e' importante il o i server). Ovvio che il dialin deve essere tenuto con
riguardo.
Ciao
-- 
Quando omni flunkus moritati (when all else fails play dead) 
Maurizio - Tannoiser - Lemmo
STIGE Srl Servizi Informatici
Founder Member of ERLUG (Emilia Romagna Linux User Group)
http://erlug.linux.it

 non saprei, potresti farti degli script (un tentativo di connessione
Non basta far partire nmbd e smbd da inetd? In quel caso, se dovessero
morire, penserebbe inetd a farli ripartire.
-- 
"Sai cosa dice il vecchio Jack Burton, in situazioni come questa?
Il vecchio Jack dice sempre: basta, adesso..."
*** Don't THINK different, BE different! ***
http://www.bugit.org

 Grazie dei consigli.
De nada.


 morire, penserebbe inetd a farli ripartire.
I problemi potrebbero esserci anche se il daemon non e' morto (pensa ad
una congestione della rete, per esempio)..


 riguardo.
Credo che la soluzione migliore sia proprio ssh, e per aumentare la
sicurezza permettere il login solo tramite certificati
digitali+passphrase.
Il dialin, sia sul firewall, che su di una macchina nella intranet, mi
sembra meno sicuro (al limite con il callback, almeno le spese le paga
il cliente :-) )
LG
-- 
*********************************************************************
Leandro Gelasi
V year Computer Science Engineering student at Siena University
gela...@lucy.dii.unisi.it
Gilles Villeneuve will live forever
*********************************************************************


perchč?

 dei servizi.
Ehm... solo a livello di Lan SERIE, vero?
Perche' io uso, a casa, un'unica macchina che fa tutto....


 perchč?
Perche' un firewall non deve *MAI* offrire servizi. Deve solo fare il
suo lavoro, il firewall, punto. Ti servono a questo punto due macchine,
una per il firewall e l'altra per i servizi che intendi offrire
all'utenza.


 Perche' io uso, a casa, un'unica macchina che fa tutto....
Beh se qualcuno ti buca uno dei servizi che offri (se per es. non
configuri bene il firewall) sono cazzi tuoi.


perchč?
Da come la vedo io, per due motivi contrapposti:
Un firewall non dovrebbe fare da file server, visto che meno servizi
girano su un firewall, meno ne hai soggetti ad exploit.
Un file server high-available non dovrebbe essere il firewall, perche'
se si intestardiscono, prima o poi, se anche non lo compromettono, te lo
tirano giu', interrompendoti anche il servizio di file sharing.
Diamo a cesare quel che e' di cesare, a ad ogni macchina la sua
funzione.
-- 
           |Save our planet!
  Ciao     |Save wildlife;
  roberto  |For your E-MAIL use only recycled Bytes !!
           |roberto poggi  
rpo...@softhome.net

Perche' io uso, a casa, un'unica macchina che fa tutto....
e' evidente. Ovvio che se hai un unica macchina fai di virtu'
necessita', ma di solito, in situazioni un po' piu' grandi e' poco furbo
mettere il firewall/router su una macchina che offre servizi. Il
firewall deve occuparsi di filtrare accessi non autorizzati, ma se allo
stesso tempo devi offrire servizi, la cosa potrebbe rivelarsi
complicata o inefficace.
Ciao.
-- 
I used up all my sick days, so I'm calling in dead.


 sono l'affidabilità dei componenti.
Ho letto il tread  e mi assoccio al parere di molti per il software, mentre
per l'hardware mi sento di consigliarti di abbandonare l'idea dell'AMD,
credo che non sia ancora maturo per entrare in un'archittettura server per
HA, piutosto un PIII 800, per il resto penso anche io che un Compaq Proliant
sia una soluzione ottima al momento. Se riesci a usare (non per capacità, ma
per spesa) un RAID 1, ti puoi anche dimenticare di fare il backup.
Non restartare mai i servizzi piutoso monitorizali con un sistema di
allarmistica e tieniti un accesso, come già diceva qualcun'altro, in ssh o
in dial-in (è più probabile un kernel panic di un crash di Apache!!! cioe
molto remoto).
Ciao e Buon Lavoro
Marco Pinna

 
Gią, questo č un aspetto che avevo sottovalutato.... mi sa che dovrņ 
ridiscutere parte dell'accordo.... e blindare 2 macchine anzichč una 
sola....
sigh!
:-(
Grazie a tutti!!


 crash di Apache!!! cioe molto remoto).
Si, questo è quello che ho capito anche io dalle riposte del ng. L'unico 
sevizio critico, a quanto ho capito, è l'ADSL. 
Grazie a tutti per i consigli (mi avete evitato degli errori!)


  piuttosto che l'altro, ecc.)
Diciamo le cose come stanno, _se_ per caso hai dei problemi con gli
Athlon, non prendertela con AMD, ma con VIA, i problemi li danno sempre
i suoi chipset, tanto che il driver del 2.4 per questi chipset non era
stabile, e poteva causare crash, ora (credo) il driver dovrebbe essere
funzionante, quindi
- Usi i kenel recenti (Non il 2.4.4. che ha problemi di gestione della
  memoria, al massimo il 2.4.3 o la serie 2.4.4 "ac" di Alan Cox)
- Usi i chipset di AMD, che in genere vanno lisci come l'olio (mai
  sentito uno che si lamentava)
Ciao, Andrea
-- 
Andrea Carosi, just another linux user on a Debian woody

 Da come la vedo io, per due motivi contrapposti:
Esiste anche un motivo molto sciocco ma importante:
un file server ha decine e decine di utenti, molti dei quali hanno
password del tipo "pippo", "password" "password uguale allo username" e
cosě via ....


  girano su un firewall, meno ne hai soggetti ad exploit.
ok! capito.
grazie ad entrambi
ciao

 configuri bene il firewall) sono cazzi tuoi.
Si, ok, ma io NON offro servizi all'esterno... ;)


Si, ok, ma io NON offro servizi all'esterno... ;)
Irrilevante. Se baypasso il firewall arrivo ai servizi, poco importa che
siano all'interno o meno.
Inoltre se trovi qualche simpatico che ti tira una smurfata, non solo la
tua lan diventa cieca verso internet, ma rischia di avere anche i
servizi giu'. Ripeto, se e' una cosa seria, non si tengono firewall e
file sharing sulla stessa macchina. :-)


 Si, ok, ma io NON offro servizi all'esterno... ;)
Allora non dire cose idiote.


 file sharing sulla stessa macchina. :-)
Ok. Grazie.


 Allora non dire cose idiote.
Calma. Quali sarebbero le cose idiote?


Interessante... manco pensavo si potesse bypassare un firewall... ;)
ma sai, a volte basta un piccolo errore nelle regole, o qualcosa che tu
non avevi previsto... o che non aveva previsto il creatore di ipchains,
insomma la security out-of-the-box te la puoi pure scordare. :-)
-- 
Around computers it is difficult to find the correct unit of time to
measure progress.  Some cathedrals took a century to complete.  Can you
imagine the grandeur and scope of a program that would take as long?
		-- Epigrams in Programming, ACM SIGPLAN Sept. 1982


  Interessante... manco pensavo si potesse bypassare un firewall... ;)
Se è configurato male certo che si, ma, configurato in modo che:
- tutte le porte in ingresso siano chiuse di default
- apri solo a quei 4 indirizzi ip del provider per scaricare mail/news
- apri tutte le porte non privilegiate a pacchetti con flag SYN non
  settato (! -y) per cose tipo rdate, traceroute, etc...
Allora non c'è script kiddies che tenga, NON ti possono forare


 Calma. Quali sarebbero le cose idiote?
Rileggi cio' che hai scritto riguardo l'offrire o meno servizi e
riconsidera la tua inutile risposta.


importanti sono l'affidabilità dei componenti.
Ho conosciuto un tale che vendeva degli "scatolotti" simili a quello
che vorresti  fare tu, e  mi ricordo  che "underclockava" la  CPU :)
IMHO, un RAID SCSI credo sia cosa buona e giusta.
-- 
 __
| _         "The Internet is slow, could you please reboot it ?"
|__|iambo   mailto:
gabr...@giambonini.com
 
www.giambonini.com

 riconsidera la tua inutile risposta.
Ok ma qualcuno (adesso non ho il post sottomano) ha detto che anche NON
offrendo servizi verso l'ESTERNO (ma solo all'interno della LAN) possono
esserci problemi.
E comunque non serve essere cosi' acidi.


 
Dipende: con linux hai un dizionario, e quando l'utente cambia pass gli
impedisce di usare le parole contenute nel dict., passs = user,
pass=user+numeri etc etc

  allarmistica e tieniti un accesso, come già diceva qualcun'altro, in ssh o
mi riintrometto:
consigli su uno di questi sistemi?
bastano un paio di link
grazie!
ciao!

 esserci problemi.
Un discorso e' una regola sbagliata con ipchains ed un'altra e' offrire
servizi che con un firewall non c'entrano niente. Se non capisci la
differenza non dare la colpa alla mia acidita' ma ripassa qualcosa.


 pass=user+numeri etc etc
Dipende: agli utenti questa pratica non piace.


 Dipende: agli utenti questa pratica non piace.
Agli utenti ovviamente no, infatti il problema e' piu' "politico"
che effettivo, cioe' trovare uno schema di password che sia
"umano" e che consenta una certa sicurezza (meno possibilita' che
la password venga indovinata). Ad un estremo ci sono le password
generate dal computer (tipo ajlkcul189b), che obbligano gli utenti
a scriverle su pezzi di carta (di solito appiccicati al video),
dall'altro estremi ci sono le password "come ti pare" che in
sostanza non sono piu' password... Tutto sta' a vedere se ti
riesce di implementare una seria politica di password senza fare
incazzare tutti gli utenti...
Davide

  incazzare tutti gli utenti...
Una sana politica di password? dici agli utenti di usare i loro giornali
preferiti:
Linux&C. di questo mese:
Pagine: 84
titolo principale: RUBY.....
prendi i dati essenziali e ci aggiungi caratteri speciali:
ruby@lin84
Logicamente puoi usare libri, riviste, quotidiani, donna moderna....
