mandriva-2007.1.html

la mia macchina, monta una scheda madre Asus p5b ed è provvista di un controller JMicron che faceva mooolto arrabbiare l'installer di una qualsiasi versione stable di Linux fino a qualche tempo fa -ed infatti ero sono riuscito ad installare solo su alcune distro passando al boot il parametro linux install all-generic-ide irqpoll ma ora anche su MANDRIVA funzica- tutto ok finalmente grazie al nuovo kernel 2.6.17.11(ora 2.6.17.14), era ora!!!!!

2- configuro la scheda di rete in fase di installazione senza ricorrere al Mandriva control center

il nuovo collegamento è stato realizzato con il D-Link-320 T , ho collegato il modem allo switch e i computer della rete locale allo switch stesso - uno di loro(questo) deve fungere da master però cioè deve essere settato con la scheda di rete connessa all'hub/switch con ottieni indirizzo ip automaticamente (tramite il dhcp del modem)il quale gli ammolla ip pubblico del collegamento, collegamento preso dal modem/router indipendentemente dal sistema operativo dei P.C. della rete -il sistema operativo del master(A) è indifferente può essere WinXP-WinVista-una delle mille distro linux-bsd ecc,ecc gli altri computer della lan vanno settati con indirizzo statico della scheda di rete nel range 192.168.1.2 -192.168.1.254 -si possono collegare fino a 253 computer con netmask 255.255.255.0 e gateway 192.168.1.1 poi in /etc/resolv.conf si inserisce il dns del provider o di altri.

a quel punto installo nano e il kernel-source 2.6.17.11(ora il 2.6.17.14) per prepararmi all'installazione dei driver specifici per la scheda video

Accettiamo le condizione e rispondiamo alle varie domande sempre affermativamente.

e ricerchiamo la riga Driver "vesa" o Driver "nv"(dipende dalla configurazione iniziale di X che è stata fatta durante l'installazione):

poi dal control center >>hardware>>effetti 3d>>spunto 3d desktop settaggi avanzati spunto beryl>>
installa i pkg richiesti, Ma al rientro nella nuova sessione noto un inconveniente le finestre sono senza bordi -con i settaggi di beryl ed emerald non risolvo allora:

There are still some parameters that needs to be added to the /etc/X11/xorg.conf file in order to use the composite extension:

First, add o modifica the Extensions section to the end of the file se non presente :

noto però un inconveniente:la mia mandriva non effettua il montaggio automatico dei device CD/DVD

install ntfs-3g alle dipendenze vedi fuse 2.6.3 ci pensa lui

poi
[root@localhost ~]# mkdir /mnt/win
[root@localhost ~]# mount -t ntfs-3g /dev/hda1 /mnt/win
WARNING: Old FUSE kernel module detected. This means, some driver features
are not available (swap file on NTFS, boot from NTFS by LILO),
and unmount is not safe unless you make sure the ntfs-3g process
naturally terminates after calling 'umount'. The safe FUSE kernel
driver is included in the official Linux kernels since version
2.6.20-rc1, or in the FUSE 2.6 software package. Please see the
next page for more help: http://www.ntfs-3g.org/support.html#fuse26
[root@localhost ~]#

poi ho ricondiziono /etc/fstab per il montaggio automatico al boot della partizione for all ed ho tolto il montaggio in ro nel moint point /mnt/win_c

questo il nuovo statement
/dev/sda1 /mnt/winntfs-3g umask=0,rw,users 0 0
bingooooooooooo!!!!!

ps-a dir la verità mi aveva trovato un errore nel file di log ntfs che ho risolto su suo consiglio riavviando Xp e facendo shutdown

da http://www.java.com/it/download/linux_manual.jsp
si scarica il Java Runtime Environment (JRE) 5.0 Update11(il pacchetto più aggiornato al momento in cui scrivo) Scegli il file di tipo Linux RPM auto-estraente. Quindi installalo:
#chmod 755 jre-1_5_0_11-linux-i586-rpm.bin

# ln -s /usr/java/jre1.5.0_11/plugin/i386/ns7/libjavaplugin_oji.so /usr/lib/mozilla/plugins

ora configuro l'account su thunderbird
come?
lanciamo>>nuovo account>>nome:kio -indirizzo email:kio@virgilio.it >>server in ingresso:localhost>>nome utente in ingresso:
kio@virgilio.it >>nome account:kio@virgilio.it >>fine
poi in impostazioni del server :settiamo la porta su 2000 anzichè 110!
poi clikkiamo su scarica messaggi >>inseriamo la password e bingo!!!!

e se volessi far partire il demone allo startup senza lanciarlo manualmente?
verifico la situazione con

se usando chkconfig volessi bloccare il run level 3, ad es.? niente di più facile con

ps-prime impressioni :bella,velocissima(migliorabile il tempo di boot**) ergonomica e con pochissimi bug davvero una grande distro!!!!

ps-tramite gli update sono praticamente passato via via alla RC2 uscita il 15/03/2007 poi alla RC3

infine sono approdato alla versione finale della spring poichè è praticamente una foto di Cooker fatta il 7/4/2007!!!!

* *per migliorare il tempo di boot seguendo i consigli espressi in un post sul portale ho disattivato 2 delle tre interfacce di rete non collegate ma impostate con clent dhcp ed ho risparmiato circa 15 sec. al boot passando dagli 80 secondi ai 65 circa ma sono incappato in un inconveniente il file /etc/resolv.conf ad ogni reboot veniva updato e i server dns venivano cancellati -come risolvere senza reimpostare ogni volta i valori?????

<chattr imposta gli attributi di un file su un file system linux di tipo ext2/ext3.
Andando a lavorare su particolari attributi peculiari di questi file system chattr non è un comando unix standard.

chattr [-RV] [-v versione ] [+/-= attrib] file ...
-R Ricorsivo
-V Stampa gli attributi modificati
-v versione Imposta la versione di un file.

Attributi
a il file può essere aperto solo in append mode.
d Non verrà eseguito il backup su di esso dall' utility dump.
i Il file non può essere modificato in alcun modo.
s Il file è cancellato e i suoi blocchi sono azzerati e scritti su disco.
S I cambiamenti sono scritti in modo sincrono su disco>

Ho provato l'applicazione su una Slackware 10.2 e tutto è andato a buon fine, vedere lo screenshot per credere :-)
Nella directory di installazione (/home/nomeutente/googleearth) è presente inoltre uno script per la disinstallazione del programma.>

- entrare nella configurazione del vostro Router/Access Point e cambiare la password di accesso: in questo modo nessuno potrà entrare nel pannello di configurazione apparte voi.

- disabilitare se possibile il DHCP, in questo modo un intruso non può ricevere automaticamente un ip valido per connettersi.
CONTRO: dovrete utilizzare ip statici nella vostra rete, e ciò non può essere fattibile se i client sono variabili e molti. Inoltre basta conoscere la classe di ip esatta e chiunque, impostando un ip statico (casuale ma valido), può connettersi.

- filtrare gli indirizzi MAC delle schede di rete, in modo da abilitare solo quelle conosciute.
CONTRO: infattibile se i client sono molti e variabili; Non tutti sanno che l’indirizzo MAC di una scheda di rete può essere cambiato!! Su linux è facilissimo… è un semplice comando da terminale. Conoscendo quindi un mac abilitato, l’intruso può connettersi indisturbato.

- abilitare almeno la protezione WEP. Questa è la prima protezione introdotta per i sistemi wireless 802.11, ed è ESTREMAMENTE insicura. Per ottenere una chiave WEP bastano un comune pc, uno sniffer e pochi pacchetti da analizzare. In rete si trovano facilmente tutti i tool e le guide necessarie. In 2 ore si può ottenere una qualsiasi chiave WEP alfanumerica di lunghezza variabile. Non è un problema della password, è proprio una vulnerabilità del protocollo di sicurezza! Chiunque può essere in grado di farlo. Non serve essere un hacker!
E’ estremamente sconsigliato utilizzare il WEP per proteggere la propria rete, certo è meglio di niente, ma è come chiudere la porta e lasciare la chiave nella serratura…

Spesso anche programmi di terze parti per la gestione della rete in automatico si appoggiano a Wpa Supplicant per la gestione del WPA (per es Network-Manager e Kwlan).

per rendere quasi sicura questo tipo di cifratura(Wep ):
-entra nella configurazione del Router/Access Point e cambia la password di accesso
-filtra gli indirizzi MAC delle schede di rete, in modo da abilitare solo quelle conosciute
-Spegni quando non serve
-cambia ogni 1/2 giorni la password Wep a 128bit di 26 caratteri
cosi da creare una serie di ostacoli che singolarmente sono superabili , ma cumulativamente sono una tale pena che l'eventuale l'intruso cambia aria.

ok -il router spara -la scheda è riconosciuta come realizzo il collegamento??????

Dunque l'aggiornamento è andato bene al 90%.
Premetto che la mia installazione di KDE è Full con tutti i pacchetti possibili ed immaginabili, probabilmente una versione più normale avrà meno problemi.

1) Ho eseguito l'aggiornamento come descritto nella news ma per alcuni pacchetti alcuni pacchetti ho ricevuto l'errore di installazione fallita.

2) Dando il comando rpm -qa | grep 3.5.6 ho visto i pacchetti non corretti:

kdetoys-kweather-3.5.6-6mdv2007.1
kdetoys-3.5.6-6mdv2007.1
kdeaddons-searchbar-3.5.6-3mdv2007.1
libkdetoys1-kweather-3.5.6-6mdv2007.1
kdegraphics-common-3.5.6-1mdv2007.1
kdeaddons-3.5.6-3mdv2007.1
task-kde-3.5.6-5mdv2007.1

3) Ho dato il comando urpme libkdetoys1-kweather-3.5.6 e sono saltati alcuni pacchetti

To satisfy dependencies, the following 8 packages will be removed (23 MB):
kdepim-common-3.5.7-3mdv2007.1.i586
 (perchÃ© manca libsloxwizard.so)
kdepim-kmail-3.5.7-3mdv2007.1.i586
 (perchÃ© non Ã¨ soddisfatto kdepim-common >= 1:3.5.7-3mdv2007.1)
kdepim-knode-3.5.7-3mdv2007.1.i586
 (perchÃ© non Ã¨ soddisfatto kdepim-common == 1:3.5.7-3mdv2007.1)
kdepim-kontact-3.5.7-3mdv2007.1.i586
 (perchÃ© manca kdetoys-kweather,
  perchÃ© non Ã¨ soddisfatto kdepim-knode == 1:3.5.7-3mdv2007.1,
  perchÃ© non Ã¨ soddisfatto kdepim-korganizer == 1:3.5.7-3mdv2007.1,
  perchÃ© non Ã¨ soddisfatto kdepim-kmail == 1:3.5.7-3mdv2007.1)
kdepim-korganizer-3.5.7-3mdv2007.1.i586
 (perchÃ© non Ã¨ soddisfatto kdepim-common == 1:3.5.7-3mdv2007.1)
kdetoys-kweather-3.5.6-6mdv2007.1.i586
 (perchÃ© manca libkdeinit_kweatherreport.so,
  perchÃ© non Ã¨ soddisfatto libkdetoys1-kweather == 1:3.5.6-6mdv2007.1)
libkdetoys1-kweather-3.5.6-6mdv2007.1.i586
task-kde-3.5.6-5mdv2007.1.noarch
 (perchÃ© manca kdepim-kontact)
Rimuovo 8 pacchetti? (s/N) s
rimozione di kdepim-common-3.5.7-3mdv2007.1.i586 kdepim-kmail-3.5.7-3mdv2007.1.i586 kdepim-knode-3.5.7-3mdv2007.1.i586 kdepim-kontact-3.5.7-3mdv2007.1.i586 kdepim-korganizer-3.5.7-3mdv2007.1.i586 kdetoys-kweather-3.5.6-6mdv2007.1.i586 libkdetoys1-kweather-3.5.6-6mdv2007.1.i586 task-kde-3.5.6-5mdv2007.1.noarch

4) Con il comando urpmi kdetoys-kweather-3.5.7 kdetoys-3.5.7 ho reinstallato alcuni pacchetti rimossi (gli altri me li sono dimenticati).

5) Ho rimosso altri pacchetti con il comando urpme kdeaddons-searchbar kdeaddons

6) Li ho reinstallati con il comando urpmi kdeaddons-searchbar-3.5.7 kdeaddons-3.5.7

7) Per finire ho semplicemente aggiornato l'ultimo pacchetto con urpmi kdegraphics-common-3.5.7

Ora con rpm -qa | grep 3.5.6 non ho più pacchetti del vecchio KDE e tutto funziona quasi a meraviglia.

Come per Cooker sono sparite alcune voci di menu relative alla configurazione di KDE, occorre lanciare il comando kcontrol.

Con il comando urpmi kdepim-korganizer-3.5.7 ho reinstallato i pacchetti di kdepim precedentemente rimossi che mi ero dimenticato di reinstallare.>

APPENDICE-7
controllo remoto di mandriva con ssh
<lo scopo principale di SSH è quello di fornire una shell remota all' utente**..............................

A questo punto ci sembra opportuno dedicare un po di spazio alla configurazione del server ssh, sshd....... Per le sue caratteristiche OpenSSH una volta installato in genere è già configurato per funzionare perfettamente per un utilizzo tipico. Questo articolo non sarà quindi orientato a spiegare ogni singola opzione offerta da sshd, che in genere vanno bene così a meno di casi particolari.

I file di configurazione di ssh, sia lato client che server sono presenti nella directory /etc/ssh. Nel nostro caso parleremo in particolare di /etc/ssh/sshd_config. All'interno di questo file tutte le righe che iniziano con # (e ovviamente quelle vuote) sono considerate commento. Come prima cosa cerchiamo nel file l' opzione Port, in genere situata all inizio del file. Questa opzione consente di specificare su quale porta lasciare in ascolto SSH.

Di default SSH è in ascolto sulla porta 22, ma può essere un' idea come primo accorgimento quello di usare un' altra porta. Nonè una misura molto affidabile, in quanto nonè difficile riconoscere che su una determinata porta èin ascolto SSH, ma è pur sempre un' ulteriore misura preventiva che potrebbe metterci al riparo da qualche script kiddie.

Inoltre è certamente un' idea quella di impedire l' accesso diretto all' utente root. Non consentendo a un utente di eseguire un ssh root@server costringiamo chiunque voglia utilizzare i permessi di amministratore di loggarsi come normale utente e in seguito lanciare su per assumere l'identità di root. Questo ha il vantaggio di richiedere la conoscenza della password di due account per poter accedere come "superuser". Se anche la password di root fosse conosciuta a un attaccante, questo non saprebbe cosa farsene senza un regolare account come normale utente. Inoltre l' utente root non è l' unico utente certamente presente sulla macchina, consentirne l' accesso diretto faciliterebbe anche un attacco basato su brute force. Per impedirlo basta inserire all' interno del file sshd_config una riga con: PermitRootLogin no
A questo punto sempre per maggiore sicurezza disabilitiamo l' accesso a tutti gli utenti con password "vuota" presenti sul server. Per questo possiamo usare l' opzione PermitEmptyPassword no.> da
http://linux.html.it/articoli/leggi/1230/cifrare-le-connessioni-con-ssh/

facciamo le modifiche suggerite dal grande Scrimieri al file /etc/ssh/sshd_config
#service sshd restart

poi da un clent della lan es. fedora ci connettiamo all'host remoto(mandriva)
$ssh kio@192.168.1.7
password: XXXXXX
e bingoooooooooooooo
e se avessimo windows come ne usciamo ???
installiamo putty http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

PuTTY è un client che permette di connettersi ad una terminale Unix sfruttando i protocolli SSH, Telnet o rlogin.

É una suite di software libero, inizialmente disponibile solo per win, ma adesso può girare anche su varie piattaforme Unix.È in corso il porting verso i sistemi Mac.

ovvero dato che l'uso di ssh permette una connessione sicura da un server X locale ad un application server remoto.

* Impostiamo i parametri di X11Forwarding e AllowTcpForwarding a yes in /etc/ssh/sshd_config sull'host remoto.

* Lanciamo ssh per stabilire una connessione col sito remoto.

$ ssh -q -X -l kio 192.168.1.7
Password:
.....
bingoooooooooooo!!!

poi entrati sulla shell remota lanciamo un applicativo grafico
$ konqueror e bingo!!!!

Questo metodo permette la visione dell'output del client X remoto come fosse connesso localmente attraverso uno UNIX domain socket

** uno degli usi che ne possiamo fare è quando il sitema non risponde e siamo costretti a resettare brutalmente a meno che non apriamo una sessione cifrata sull'host killiamo kde ad es. ovvero facciamo restart e saremo così in grado di riprendere il controllo della macchina difatti:

piano piano sta emergendo il vero problema della spring :
ottima-veloce-bella distro ma con la tendenza a freezare -a me succede con beryl e ad esempio googlearth o con beryl e clamav ovvero con beryl e ppracer !!!!!

Trovare una chiave privata a partire da una pubblica è infatti praticamente impossibile, e certamente più difficile di trovare una password. Se la mancanza di richiesta di password vi sconvolge pensate che comunque per assegnarla al server sarà necessario il login: non è quindi un'operazione che possono svolgere tutti, ma solo coloro che hanno già le giuste credenziali di accesso.

In pratica genereremo una coppia di chiavi, una pubblica e una privata. Quella pubblica verrà copiata sul server. Quando il server ci chiederà chi siamo, il nostro client genererà una firma a partire dalla nostra chiave pubblica. Il server, in possesso della chiave pubblica, può controllare se quella firma è stata generata da una chiave privata corrispondente alla chiave pubblica in suo possesso. In caso positivo verrà dato accesso al sistema.

~$ ssh kioss@192.168.10.2
Password:

ed entro

$cat /home/kioss/id_dsa.pub >> /home/kioss/.ssh/authorized_keys

poi si può modificare il file /etc/ssh/sshd_config con 

PasswordAuthentication no
e poi riavviare il servizio 
#service sshd restart

contrariamente da quanto affermato nel tutoriale per funzionare il tutto ho dovuto tenere commentati i tre statement
nel file /etc/ssh/sshd_config con 

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile	.ssh/authorized_keys
infine

[kio@Fedora ~]$ ssh kio@192.168.1.80
Last login: Thu May 31 20:01:56 2007 from 192.168.10.2
[kioss@Mandriva ~]$
bingoooooooooooooooooooooooooo!!!!


in conclusione 

<La soluzione generale raccomandata dagli sviluppatori di ssh qualora ci
sia necessita di automatizzare le operazioni usando ssh/sftp e` quella
di usare l'autenticazione basata su chiavi, non quella di incorporare
la password in vari script (o peggio fornirla da riga di comando),
procedura alquanto insicura.Andando sul pratico, usare l'autenticazione basata su chiavi
consiste in

1) generare la coppia di chiavi pubblica/privata mediante ssh-keygen,
preferibilmente usando la stessa dimensione in bit e tipo di quelle
usate sul server. per la verita` non ho mai provato a fare
diversamente, a spanne dovrebbe funzionare ma non lo so.

Tipicamente:

codice:ssh-keygen -t dsa -f chiave
NON METTERE LA PASSPHARASE per la chiave in questa fase!

Altrimenti verra` richiesta la detta frase in fase di connessione: scopo diverso, risultato identico, 
quindi nulla di fatto.

2) copiare la chiave PUBBLICA cosi` generata (chiave.pub nell'esempio succitato) sul server deputato.

La chiave deve essere aggiunta al file ~/.ssh/authorized_keys

3) verificare i permessi: dovrebbero essere drwx------ (0700) per ~/.ssh e -rw------- (0600) per ~/.ssh/authorized_keys


per ulteriori aspetti vedi 

http://www.gentoo.org/doc/it/articles/openssh-key-management-p1.xml