Re: Suggerimento controller SATA
Cherubini Enrico wrote: Ciao, Wed, Jun 28, 2006 at 12:33:27PM +0200, automatic_jack wrote: http://linux-ata.org/ quel che c' è da sapere :) il problema e' che fanno (giustamente forse) riferimento al chipset, ma non sempre (diciamo mai ?) il chipset e' scritto sulla confezione, per cui e' sostanzialmente inutile. A me interessava marca e modello :) comunque penso che optero' per il promise fasttrack tx2300 che mi dicono essere ben supportato e non costa un patrimonio (suglio 80 euro). Mi permetto di sottolineare ancora quanto ti e' stato consigliato: se vuoi una soluzione RAID hardware, gli unici controller sata degni di questo nome sono i 3ware, che sono supportati gia' da molto tempo nel kernel. Tutto il resto e' robaccia, perche' sono dei finti RAID hardware, il lavoro e' fatto in parte dal driver in software, in parte dal firmware del controller. Se non vuoi spendere per un controller 3ware (costicchiano, ma valgono), scegli senza ombra di dubbio la soluzione software md + mdadm. Ne ho gestiti in passato parecchi di RAID 1 software cosi', sono veloci, facili da manutenere e molto stabili. Inoltre, in mirroring o striping, l'impatto di md sulla CPU e' veramente minimo. Infine, mdadm e' veramente un gran bel programma e se hai problemi di qualsiasi tipo su un array, hai un ottimo tool per rimettere le cose a posto. Al contrario, molto spesso i firware dei controller, se hanno un problema con i dischi (al livello di assemblamento dell'array), finiscono col prendere la decisione sbagliata ed addio file-system. Una volta mi e' capitato di perdermi un RAID 5 di quattordici dischi SCSI (piu' di un tera e mezzo di file system), perche' al riavvio della macchina dopo le vacanze estive il controller ha riconosciuto un solo disco dell'array e non c'e' stato verso di fargli capire che gli altri tredici facevano parte dello stesso array. Meno male che il file system era praticamente vuoto. Bhe, direbbero gli inglesi: my 2 cents ;-) Saluti, F.
Re: knokd iptables
Giovanni Cataldi wrote: Il fatto è che saper di poter accedere al mio pc da remoto in ogni momento mi mette sicurezza... metti che ti serve un documento o che vuoi controllare la posta scaricandotela da remoto sul tuo pc, o controllare che amuled non sia crashato. Insomma, da bravo ignorante della materia, mi diverto a pensare ad inutili esperimenti per conoscere poco a poco sempre meglio il mio bel pinguino. Insomma questo povero portatile lo tieni sempre acceso ! Il bello di Linux (e dei sistemi Unix in generale) e' proprio questo: hai il controllo della tua macchina sempre e dovunque tu sia. Tornando a knock, volevo quindi chiederti un esempio specifico del file da inserire nel file /etc/knock.conf e in iptables. Bhe, come ti ho scritto, non conosco knockd quindi non posso essere piu' specifico... comunque, partendo dalla configurazione che hai postato nel primo messaggio, sostituendo il -A con un -I nella riga command = dovrebbe funzionare. Per quanto riguarda iptables, vale quello che ti scrivevo riguardo al firewall. Inoltre, esiste un knocker anche per windows (da usare, presumo, con putty?? in questo modo potrei adoperarlo in pratica da qualsiasi postazione remota. Non ne ho assolutamente idea ;-) Ma ricorda che Google e' tuo amico ! Saluti, Fabrizio
Re: knokd iptables
Giovanni Cataldi wrote: Venia di che Fabrizio? Anzi, grazie per l'utilissima spiegazione! Bhe, mi riferivo al fatto di aver postato un'informazione sbagliata riguardo al -m tcp... Probabilmente ho sbagliato a copiare ed incollare qui nella mail il file (visto che l'ho abbondantemente commentato). Capita ;-) Per quanto riguarda -I, potrebbe in effetti essere una soluzione. L'unica che mi viene in mente... Effettivamente hai ragione sul prima mettere il firewall e solo *poi* knockd. Il fatto è che tanto con Nmap vedo questo risultato, quindi alla fine non vedo la necessità di crearmi policies ad hoc. O sbaglio (conta che è il mio laptop personale)? 21/tcp open ftp ProFTPD 1.3.0 22/tcp open ssh OpenSSH 4.3p2 Debian-2 (protocol 2.0) 25/tcp open smtp Exim smtpd 4.62 111/tcp open rpcbind (rpcbind V2) 2 (rpc #10) 113/tcp open identOpenBSD identd 631/tcp open ipp CUPS 1.2 2628/tcp open dict dictd 1.10.2/rf Certo che conta... o meglio, molto conta che uso ne fai, il tuo grado di paranoia al riguardo, come usi il tuo collegamento ad internet, dove lo usi e per quanto tempo... insomma sono molti i fattori che possono spingere all'uso di un firewall ed altrettanti quelli che contano nella scelta della configurazione dello stesso. A guardare il risultato del tuo nmap, personalmente, terrei visibili dall'esterno solo la porta 22 e la 21 (non per farmi gli affari tuoi, ma a che ti serve un server ftp sul portatile ?). In linea generale, comunque, la domanda che mi pongo di solito e' questa: a quali servizi ho bisogno di accedere dall'esterno ? Per la ml effettivamente dovrei guardarla... se mi dici anche per favore quale (così non sbaglio :D ) Bhe, io leggo questa tramite news... c'e' debian.firewall, linux.debian.maint.firewall, comp.security.firewalls giusto per citerne alcune... Comunque mi suggerisci un firewall con GUI (quale) o iptables? Bhe, sempre con iptables finisci... nel senso, di GUI ne trovi tante per linux (una di cui ho sentito parlar bene e' shorewall, per gnome se non erro) ma alla fine non fanno altro che creare uno script che imposta una serie di regole con iptables. Dipende anche quanto ne capisci e sopratutto quanto ti interessa capirne. Se la cosa ti interessa e ti diverte, prova a scrivertelo tu da solo con iptables (un ottimo inizio e' leggersi un po ' di documentazione qui: http://netfilter.org/documentation/index.html e frequentare le mailing lists di cui sopra). Se, al contrario, non te ne frega niente di capire e ti interessa solo il risultato finale, vai senza ombra di dubbio per una GUI. Saluti, Fabrizio
Re: adduser (risorse limitate)
Pol Hallen wrote: Ciao gruppo :-) vorrei creare degli utenti nel mio sistema che abbiamo risorse hw limitate. Tipo che possano usare la cpu fino ad un 10% e non oltre, idem per la memoria. Esiste qualche tools che semplifichi il tutto?! Grazie ;-) Pol Dai un occhio a /etc/security/limits.conf Mai usato personalmente, ma da quanto ho capito configuri in modo system-wide (volendo anche a gruppi) le risorse che controlli con ulimits. Saluti, Fabrizio -- Per REVOCARE l'iscrizione alla lista, inviare un email a [EMAIL PROTECTED] con oggetto unsubscribe. Per problemi inviare un email in INGLESE a [EMAIL PROTECTED] To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: knokd iptables
Giovanni Cataldi wrote: Premetto che non conosco knockd, ma credo di aver capito cosa fa... In primo luogo ho configurato /etc/default/knockd, cambiando il valore della decima riga (START_KNOCKD) da 0 a 1: # control if we start knockd at init or not # 1 = start # anything else = don't start START_KNOCKD=1 # command line options #KNOCKD_OPTS=-i eth0 Dopodiché ho modificato, così come dice l'articolo, il file /etc/knockd.conf, in questo modo: [options] logfile = /var/log/knockd.log Interface = eth0 [openSSH] sequence= 1234:tcp, 1000:tcp, 2000:udp seq_timeout = 5 command = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPT tcpflags= syn cmd_timeout = 10 stop_command = /usr/sbin/iptables -D INPUT -s -p tcp --syn --dport 22 -j ACCEPT Attenzione che la la regola che vuoi cancellare con -D deve essere *esattamente* uguale a quella inserita con -A (o con -I). Nel tuo caso ci vedo un --syn di troppo ed un %IP% di meno... dovrebbe essere: /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT Inoltre ovviamente ho chiuso la porta 22 di iptables (sennò non serve a nulla): # iptables -A INPUT -p tcp -m tcp --dport 22 -j DROP Per quel che ne so, -m tcp e' sbagliato e dovrebbe darti errore... Mi e' sembrato di capire che non hai un firewall configurato. Sotto un profilo puramente logico dovresti prima di tutto approfondire la questione firewall e solo dopo avere un firewall correttamente configurato e funzionante, metterti a giocare con knockd. Tuttavia, questa non mi sembra la sede appropriata per discutere di firewalls... c'e' una mailing list apposita, dagli uno sguardo... Comunque, per rispondere al tuo quesito, se non hai un firewall configurato, la POLICY di default per la catena di INPUT e' ACCEPT, ovvero accetti tutti i pacchetti entranti a meno di specifica regola diversa, che pero' non hai. Ora, tu aggiungi una regola in cui droppi le connessioni ssh. In seguito, quando lanci knock, viene *aggiunta* da knockd una seconda regola in cui accetti la connessione. Tuttavia, quando provi a connetterti, il tuo tentativo di connessione viene matchato dalla *prima* regola, quindi (corretamente) droppata. Il sistema di netfilter, una volta ottenuto un match, non prosegue nella scasione della tavola. Per risolvere il tuo problema, nella configurazione di knockd, invece di usare -A, che aggiunge una regola *in coda* alle altre, dovresti usare -I, che inserisce una regola *in testa* alle altre. In questo modo, quando knockd esegue iptables, la regola che accetta i pacchetti ssh viene messa *prima* di quella che droppa. A questo punto, la cosa dovrebbe funzionare... Per verificare: iptables -L -v -n prima e dopo aver lanciato knock Comunque, ripeto: pensa prima a configurarti un buon firewall. a questo punto mi sarei aspettato che dopo un # /etc/init.d/knockd start, tutto sarebbe andato: $ knock 192.168.123.105 1234:tcp 1000:tcp 2000:udp $ ssh -l nome_utente 192.168.123.105 Ma non è così: la porta 22 non viene aperta da iptables e pertanto non ottengo risposta. Dove sbaglio? Saluti, Fabrizio
Re: knokd iptables
Fabrizio Ferraro wrote: # iptables -A INPUT -p tcp -m tcp --dport 22 -j DROP Per quel che ne so, -m tcp e' sbagliato e dovrebbe darti errore... Hem... Ho scritto una cavolata, e' perfettamente valido e funzionante. A mia parziale discolpa, posso solo dire che in effetti e' ridondante, visto che le estensioni caricate con -m tcp (tra cui il --dport) sono in realta' gia' state caricate con il -p tcp. In verita' non l'ho mai usato ne mai visto usare (ed ho anche guardato male la man page di iptables quando mi sono chiesto a cosa serviva ;-) ). Comunque, chiedo venia... Saluti, Fabrizio -- Per REVOCARE l'iscrizione alla lista, inviare un email a [EMAIL PROTECTED] con oggetto unsubscribe. Per problemi inviare un email in INGLESE a [EMAIL PROTECTED] To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Accoppiamento schede di rete
Claudio M. wrote: Ciao Immaginate di avere tre computer con due schede di rete ciascuno e due hub/switch, immaginate ora di collegare la prima scheda di rete di ogni computer sul primo switch e la seconda scheda al secondo switch, ora assegnate a ciascuna coppia di schede LO STESSO indirizzo IP, e' possibile? se si come? In pratica vorrei fare in modo che questa rete possa funzionare anche con uno dei due hub/switch fermo (guasto), e' fattibile? esiste il modo di assegnare lo stesso IP alle due schede di rete di uno stesso computer??? Bye Non direttamente, ma tramite un apposito driver (e' un modulo del kernel) che si chiama bonding. Sostanzialmente crea una interfaccia di rete virtuale (bond0), a cui attacchi come slave le due (o piu') interfacce fisiche (eth0, eth1, etc.). Poi configuri l'interfaccia bond come se fosse una normale eth. Ho visto girare un server di dischi con un bond di 4 schede gigabit in load-balancing: volava... ;-) (E' questo giocattolo qui: http://www.max-t.com/products/sledgehammernas.html) Nel tuo caso, devi configurare il bond in modalita' active-backup: non aumenti la velocita' ma ottieni il risultato di fault tolerance che ti interessa. Trovi un'esauriente documentazione in /usr/src/linux/Documentation/networking/bonding.txt Saluti, Fabrizio -- Per REVOCARE l'iscrizione alla lista, inviare un email a [EMAIL PROTECTED] con oggetto unsubscribe. Per problemi inviare un email in INGLESE a [EMAIL PROTECTED] To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
