Repository non ufficiali: differenze tra le versioni

Repository non ufficiali (visualizza wikitesto)

Versione delle 21:24, 11 apr 2006

928 byte aggiunti , 11 apr 2006

m

nessun oggetto della modifica

MaXeR

1 487

contributi

@@ Riga 1: / Riga 1: @@
-Ho provato a rendere pi� leggibile il codice della pagina lasciando un rigo vuoto per ogni entry. In questo modo si evita di usare i br e non � necessario mettere pi� link sulla stessa riga per avere una spaziatura verticale omogenea. Secono me � importante renedere facilmente modificabile questa pagina.
+==Premessa==
+Di seguito riporto un elenco delle principali variabili del kernel relative a netfilter impostabili a run-time.
-In questo modo aumenta leggermenta la spaziatura verticale (confrontare la sezione "Browser Web" con il resto) ma aumenta parecchio la facilit� di editing IMHO.
+Per ciascuna di esse � indicato:
+* nome della variabile;
+* tipo (booleano, integer, ecc ...);
+* una breve descrizione.
-: [[Utente:TheNoise|~ The Noise]] 14:08, Nov 9, 2005 (EST)
+Queste variabili possono essere impostate in vari modi. Ad esempio potremmo scrivere in un terminale (o inserire in uno script):
-Ottimo!
+ # echo $VAL > /proc/sys/net/VARIABLE
-Pensavo che, anche se una descrizione di ogni programma sarebbe comoda, la cosa sia praticamente irrealizzabile (o meglio, non mantenibile)...
+dove $VAL � il valore booleano o intero che si vuole assegnare alla variabile ''VARIABLE''.
-eventualmente, quando � presente una scheda, la si potrebbe linkare a fianco del nome...:
+Per impostare alcuni variabili al boot possiamo editare <tt>/etc/sysctl.conf</tt> aggiungendo:
-<pre>
-nomeprogramma - scheda
-</pre>
-che ne dite?
+ net/VARIABLE = val
-altra cosa...
+notare che � stato omesso <tt>/proc/sys</tt>.
-si potrebbe variare leggermente la struttura...
-magari:
-{|
-|Categoria
-|Closed
-|Free
-|-
-|Browser Web
-|Opera
-|Firefox
-|}
-usando la 'sezione' che utilizziamo ora per la singola applicazione per le categorie...
-: [[Utente:MaXeR|MaXeR]] 12:10, Nov 13, 2005 (EST)
+Altra documentazione (in inglese) si trova allegata ai sorgenti del kernel all' interno di '''Documentation/networking/ip-sysctl.txt'''
-Ottima l'idea di affincare il link della scheda se presente ;-). In questo modo possiamo tranquillamente inserire i link alle homepage, che poi non devono essere rimossi se c'� anche una scheda. Inoltre cos� � facilissimo vedere i programmi che hanno la scheda.
+Buona lettura!
-Per la modifica sulla struttura... ehm non ho capito cosa intendi.
+==Variabili a run-time==
-: [[Utente:TheNoise|~ The Noise]] 02:46, Nov 14, 2005 (EST)
+'''ip-forward (boolean)'''
+Permette il forwarding dei pacchetti
-ho apportato qualche miglioria grafica...
+'''ipfrag_high_thresh (integer)'''
+Massima memoria utilizzabile per riassemblare i pacchetti frammentati. I pacchetti eccedenti vengono scartati fino a che non si raggiunge nuovamente la soglia settata da '''ipfrag_low_thresh
-ho pensato di aggiungere delle icone, cos� da vedere subito quali sistemi operativi sono supportati da questi programmi...
+'''ipfrag_time (integer)'''
+Tempo massimo per mantenere un frammento IP in memoria
-Altra cosa: ho suddiviso il tutti in categorie pi� grandi... resta solo da ordinare le voci alfabeticamente :-D
+'''tcp_syn_retries (integer)'''
+Numero massimo di tentativi di ritrasmissione per stabilire una connessione (valore max=255)
-[[Utente:MaXeR|MaXeR]] 11:22, Nov 24, 2005 (EST)
+'''tcp_synack_retries (integer)'''
+Idem come sopra, ma per le connessioni passive
-Bellissimo lavoro MaXeR! La nuova veste grafica � di gran lunga pi� accattivante.
+'''tcp_keepalive_time (integer)'''
+Indica quanto spesso verr� inviato il messaggio TCP KEEPALIVE
-: [[Utente:TheNoise|~ The Noise]] 13:15, Nov 24, 2005 (EST)
+'''tcp_keepalive_probes (integer)'''
+Indica quanti pacchetti TCP PROBES inviare prima di considerare la connessione BROKEN
-ho modificato ed ampliato la sezione degli editor di testo... ma manca ancora un sacco di roba! :-D
+'''tcp_keepalive_interval (integer)'''
+Indica quanto frequentemente vengono inviati i pacchetti TCP PROBES. Moltiplicando questo valore per il '''tcp_keepalive_probes''' si ottiene il timeout per il KILL di una connessione
-pensavo che moltissimi software open source possono anche girare, previa ricompilazione, su MacOSX e anche su win+Cygwin, ed � probabile che esistano in rete anche gi� ricompilati.
+'''tcp_retries1 (integer)'''
+Numero di tentativi/richieste prima che al network layer del kernel venga segnalato che qualcosa non va
-magari si pu� aggiungere una nota a riguardo nell'intro, voi che dite?
+'''tcp_retries2 (integer)'''
+Numero di tentativi/richieste prima che una connessione TCP '''attiva''' venga terminata
-:[[Utente:Tindal|Tindal]] 10:10, Dic 18, 2005 (EST)
+'''tcp_orphan_retries (integer)'''
+Idem come sopra, ma senza considerare attiva la connessione
-D'accordo sulla nota iniziale. Dovremmo comunque decidere quando un programma � considerato compatibile con un dato sistema.
+'''tcp_fin_timeout (integer)'''
+Indica per quanto tempo mantenere una connessione in stato FIN WAIT 2
-Si dovrebbe fare un po' di chiarezza anche riguardo il software Mac: intendiamo MacOS oppure MacOSX? Io direi di orientarci su quest'ultimo dato che ormai MacOS � solo una versione obsoleta IIRC. Con MacOSX la questione della compatibilit� � '''molto''' diversa che con MacOS (e quanto meno nelle entry da me inserite mi riferivo a MacOSX). Se dite si aggiungo la X a MacOS nella legenda ;-).
+'''tcp_max_tw_buckets (integer)'''
+Numero massimo di sockets simultanee in timewait mantenute dal sistema
-Inoltre come regola generale direi di focalizzarci sui programmi principali (in base a maturit�/funzionalit�/usabiltit�) pittosto che elencare proprio ogni programma di cui si conosce l'esistenza (ad esempio eviterei i programmi di cui siano disponibili solo versioni CVS).
+'''tcp_max_orphans (integer)'''
+Numero massimo di sockets TCP che possono rimanere non collegate a ''file handlers'' aperti dal sistema
-: [[Utente:TheNoise|~ The Noise]] 12:18, Dic 18, 2005 (EST)
+'''tcp_abort_on_overflow (boolean)'''
+Permette il reset di una connessione se un servizio in LISTENING � troppo lento nella risposta
-Effettivamente non avevo valutato la differenza tra MacOS e MacOSX... ne sono un po' fuori...
+'''tcp_syncookies (boolean)'''
+Opzione valida solo se il kernel � stato compilato con il supporto dei SYNCOOKIES, previene possibili attacchi di tipo ''syn flood''
-riguardo le accoppiate ''win+Cygwin'', metterei, come avete gi� proposto, una nota nell'introduzione, ma non di pi�...altrimenti diventerebbe un po' troppo pesante come cosa...
+'''tcp_timestamps (boolean)'''
+Abilita/disabilita il timestamp
-Sono completamente d'accordo, inoltre, sulla scelta delle applicazioni secondo la maturit�... sia per seriet� (non si pu� suggerire ad un utente un programma in alpha) sia per stabilit� :-)
+'''tcp_ecn (boolean)'''
+Abilita/disabilita la notifica di possibili congestioni della rete
-[[Utente:MaXeR|MaXeR]] 08:35, Dic 20, 2005 (EST)
+'''ip_local_port_range (2 integers)'''
+Definisce l' intervallo delle porte locali utilizzate da TCP e UDP. Il primo valore � l' estremo inferiore ed il secondo quello superiore dell' intervallo. Il valore di default dipende dalla memoria ram disponibile.
-== riguardo la scheda dei singoli programmi... ==
+'''ip_dynaddr (boolean)'''
+Se diverso da 0, abilita il supporto per gli indirizzi dinamici
-anche secondo me � un'ottima idea... solo che invece di:
+'''icmp_echo_ignore_all (boolean)'''
+Ignora i ''ping'' (ICMP ECHO REQUEST)
-::nomeprogramma - <nowiki>{{icone}}</nowiki> - scheda
+'''icmp_echo_ignore_broadcasts (boolean)'''
+Se settato (deve esserlo anche il precedente) il sistema ignora i ''ping'' verso indirizzi di broadcast e multicast
-si potrebbe fare un template anche per le schede e metterci un'icona, una cosa tipo
+'''log_martians (boolean)'''
+Logga i pacchetti provenienti da indirizzi IP impossibili
-::nomeprogramma - <nowiki>{{icone}} - {{scheda}}</nowiki>
+'''accept_redirects (boolean)'''
+Abilita la ricezione di pacchetti ICMP REDIRECT
---[[Utente:Hanska|hanska]] 05:06, Gen 8, 2006 (EST)
+'''forwarding (boolean)'''
----------------
+Abilita il forwarding per una specifica interfaccia
-avrei qualche dubbio su protools, nella sezione audio: forse sono rimasto un po' in dietro, ma da quello che mi risulta protools dipende da hardware dedicato, e non so se c'entra con il resto.
-:[[Utente:Tindal|Tindal]] 17:47, 10 Apr 2006 (EDT)
+'''proxy_arp (boolean)'''
-----
+Abilita il proxy ARP
-Si protools richiede hardware dedicato a livello di consolle di missagio e interfacce audio varie, ma ''che io sappia'' gia su dei mac. Ovviamente non l'ho mai provato dato che si parla di hd/sw da 10.000� a salire, e non lo conosco di persona.
-Tuttavia lo conosco dai continui raffronti che se ne fa con ardour. Infatti, fin dalla homepage, ardour viene presentato come una DAW in grado si sostituire le soluzioni HW/SW dedicate: http://ardour.org/key_features. Diversi studi di registrazione usano gi� ardour (certo sono ancora una minoranza ;-). Inoltre sulla ml LAU (linux-audio-users) vengono continuamente fatte comparazioni tra le features dei due, quindi accostarli mi � apparso del tutto naturale.
+'''secure_redirects (boolean)'''
+Accetta ICMP REDIRECT solo dai gateways configurati
-Effettivamente l'accostamento � un p� al limite per gli scopi della tabella. Ma il concetto � che con un pc ad-hoc ed interfacce audio standard (schede audio multicanale e superfici di controllo) puoi fare un sistema di HD recording realtime a 24 canali, che con soluzioni proprietarie costerebbe un occhio della testa.
+----
-Comunque... se pensi sia forzato come accostamento lo togliamo. Pensi che la parte pro-audio sia troppo specialistica per la tabella software (al limite potremmo spostarla in una pagina separata)?
-Ciao ;-)
+Autore: [[Utente:Keltik|Keltik]] 13:28, Jun 11, 2005 (EDT)
-: [[Utente:TheNoise|~ The Noise]] 03:51, 11 Apr 2006 (EDT)
+[[Categoria:Server]][[Categoria:Firewalling]]