Repository non ufficiali: differenze tra le versioni

Vai alla navigazione Vai alla ricerca

Repository non ufficiali (visualizza wikitesto)

Versione delle 21:24, 11 apr 2006

928 byte aggiunti ,  11 apr 2006
m
nessun oggetto della modifica
mNessun oggetto della modifica
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]]
MaXeR
1 487

contributi

Estratto da "https://guide.debianizzati.org/index.php/Speciale:DiffMobile/13197"

Menu di navigazione