Conseils et trucs de figaro

Comme déjà indiqué dans le post sur Lenny et Java pour avoir le dernier java de sun vous devez piocher dans testing ou dans unstable (sid) après avoir mis les dépôts correspondants dans votre sources.list, puis en faisant

apt-get update
apt-get -t unstable install sun-java6-jre sun-java6-bin sun-java6-plugin

vous aurez la dernière version disponible du java de Sun.

Par contre il est possible que vous ayez des problèmes de plugin java dans votre navigateur Firefox/Iceweasel.

Il faut vérifier dans les trois dossiers /usr/lib/firefox/plugins /usr/lib/iceweasel/plugins et /usr/lib/mozilla/plugins la présence de libjavaplugin.so.
Ce lien doit pointer vers /usr/lib/jvm/java-6-sun/jre/lib/i386/libnpjp2.so

Si ce n'est pas le cas il faut supprimer libjavaplugin.so dans ces trois dossiers et recréer un lien symbolique dans chacun de ces dossiers pointant vers le bon plugin java. Pour cela en root faire 3 fois

ln -sf /usr/lib/jvm/java-6-sun/jre/lib/i386/libnpjp2.so dossier/plugins/libjavaplugin.so

avec dossier successivement /usr/lib/firefox , /usr/lib/iceweasel , /usr/lib/mozilla

Nota: Vous ne devez pas avoir de plugin java dans le dossier plugins de ~/.mozilla ni dans celui du navigateur sous peine de conflit mais seulement dans ceux cités précédemment.

Installé de cette façon java fonctionnera également dans Opera et dans Chrome.

Le netbook Dell Mini 9 qui n'est plus commercialisé se faisait en deux versions : Ubuntu avec 5Go de stockage SSD et Windows XP avec 16 Go de stockage SSD La version Windows n'est pas fameuse et plutôt asthmatique manquant de réactivité. On peut donc souhaiter passer cette petite machine sur GNU/Linux.
La version Ubunu 8.04 de Dell n''est pas fameuse non plus et les dépôts Dell ont des problèmes, cependant la solution qui marche existe: Ubuntu propose une version Ubuntu 9.10 pour netbook "Ubuntu Netbook Remix" et l'opération est donc possible.

Pour réaliser l'opération il nous faut créer une clé USB fonctionnant en liveUSB et permettant de tester en live puis de réaliser l'installation. On commencera donc par télécharger chez Ubuntu le fichier iso. Ensuite pour réaliser la clé le plus simple est d'utiliser le petit utilitaire "Unetbootin" qui fonctionne sous Windows ou sous Linux et que l'on téléchargera.

Disposant alors de notre clé liveUSB l'on peut booter le netbbok sur la clé pour tester. La session live se lance sans problème, seul bémol le Wifi du Dell ne fonctionne pas car il nécessite un driver propriétaire qui n'est pas installé avec la session live. Le driver existe et est présent sur la clé (ou dans les dépôts) mais il n'est pas possible de l'installer pour la session live car il nécessite un reboot pour être chargé.... Pas d'inquiétude donc il sera possible de l'installer quand Ubuntu sera installé sur la machine.

Pour continuer à tester en live il convient donc de se raccorder en ethernet pour profiter du web car l'utilisation Web (navigation et mail) est la principale utilisation des netbooks. Même en liveUSB le Dell mini 9 se montre nettement plus réactif avec Ubuntu Rémix qu'avec WindowsXP.

L'on peut alors procéder à l'installation depuis le liveUSB de la façon classique d'Ubuntu. Au moment du partitionnement il vous sera proposer soit d'installer à coté de Windows en dualboot dans une partition de 5 Go, soit d'installer seul sur la totalité des 16 Go du disque mais en supprimant Windows. La solution du dualboot est tout à fait fonctionnelle 5 Go étant largement suffisant pour l'usage d'un netbook, et si l'on a besoin de stockage on pourra utiliser soit une clé USB ou une carte additionnelle le Dell disposant de cette possibilité.

L'installation terminée au bout de 25 minutes environ, on reboute la machine et on se retrouve sous Ubuntu Netbook Remix 9.10. La première chose à faire est de vérifier la configuration du clavier en clavier français et de l'étendre à toute la machine depuis l'utilitaire clavier dans l'onglet Système. Puis l'on procèdera à l'installation du driver propriétaire du Wifi depuis l'utilitaire des Drivers. L'on reboutera et l'on pourra alors se connecter sur le réseau Wifi depuis l'icône de la barre des taches.

Ensuite il convient de procéder à la mise à jour. Cela concerne 162 paquets. L'opération prendra environ 15 à 20 minutes. Ne pas oublier un sudo apt-get clean pour supprimer les paquets téléchargés après installation car il n'y a que 5 Go de disque et le système va en occuper environ 2.5 Go.

Il ne vous reste plus qu'à terminer la personnalisation en ajoutant les bons addons et plugins dans firefox, vos favoris, les fonts liberation, paramétrer la messagerie, les codecs pour la video, etc .... Tout ceci vous étant dans l'ensemble proposé par Ubuntu quand le besoin s'en fait sentir, mais pour les vidéos en ligne voir mon post sur le sujet. Vous pouvez supprimer compiz sans intérêt sur cette machine.

Si vous voulez Skype installez celui disponible sur le site de Skype en prenant la version Debian 2.1 qui intégre la video et pulseaudio. La machine ne disposant pas de micro intégré il vous faudra un micro externe.

A noter que la machine est cliente par défaut sur le réseau Windows et procède au montage des dossiers distants ce qui vous permet d'accéder aux autres machines du réseau sans problème particulier depuis le navigateur de fichiers nautilus. Par contre si vous voulez un samba complètement fonctionnel dans les deux sens il vous faudra vous référer à mes tutos.

Le Dell mini 9 est très agréable sous Ubuntu Netbook Remix et autrement utilisable que sous Windows XP en particulier démarrage en 40 secondes dont 10 pour Grub (ce qui peut se régler dans le fichier /etc/default/grub), et extinction en 6 secondes contre une éternité avec windows ....

Je parcours régulièrement les forums Debian et Ubuntu. Je suis abasourdi par les problèmes que les gens se fabriquent.

En effet sous prétexte d'avoir les dernières versions de logiciel, ils mettent dans leur fichier sources.list des tas de dépôts dans n'importe quel ordre et en plus se fabriquent un fichier préférences totalement déraisonnable.

Résultat: des versions stables complètement déstabilisées et des plantages à répétition.

Pour utiliser les fichiers "sources.list" et "preferences" il faut savoir comment cela fonctionne et le principe des algorithmes des scripts qui les utilisent. Donc un conseil : potassez votre distribution (il y a de bons bouquins pour Debian) et apprenez comment on peut dans une distribution stable utiliser des versions de logiciels plus récentes non intégrées. A noter que les dépôts backports apportent souvent la solution

Sachez toutefois que les problèmes de sécurité seront toujours traités et intégrés dans la distribution stable de Debian.

La distribution Debian Testing n'est pas exempte de dangers et certains en ont fait l'expérience récemment à leurs dépends.

Extraits de la FAQ officielle de Debian sur ce sujet :

I - Faut-il installer testing ou unstable ?

C'est plutôt subjectif. Il n'existe pas de réponse parfaite mais seulement une « estimation sage » à faire lors du choix entre unstable et testing. L'auteur conseille dans l'ordre de préférence : stable, unstable puis testing. Le problème est le suivant :

* Stable est solide comme un roc. Elle est incassable.

* Testing est cassée moins souvent que unstable. Mais lorsque cela arrive, la correction met du temps à être appliquée. Des fois il peut s'agir de plusieurs jours, et dans certains cas plusieurs mois.

* Unstable change beaucoup, et peut être cassée à n'importe quel moment. Cependant, les problèmes sont souvent corrigés en quelques jours et cette distribution offre toujours les dernières versions des logiciels empaquetés pour Debian.

II - Pourquoi testing peut-elle être cassée pendant plusieurs mois ? Les correctifs introduits dans unstable n'arrivent-ils par directement dans testing ?

Les corrections de bogues et les améliorations introduits dans la distribution unstable atterrissent dans testing après un certain nombre de jours. Disons que ce seuil est de 10 jours. Les paquets d'unstable arrivent dans testing seulement si aucun bogue critique pour la publication (« RC » pour « Release Critical ») n'est signalé à leur égard. Si un bogue RC est signalé sur un paquet d'unstable, il n'entrera pas dans testing avant les 10 prochains jours.

En effet on considère que si le paquet a un problème, celui-ci sera découvert par les utilisateurs d'unstable et sera corrigé avant que le paquet puisse atteindre testing. Cela permet à testing de rester utilisable la plupart du temps. Le concept est génial la plupart du temps, mais les choses ne sont jamais si simples. Considérez par exemple la situation suivante :

* Vous êtes intéressé par le paquet XYZ.

* Le 10 juin, la version dans testing est XYZ-3.6 et dans unstable XYZ-3.7

* 10 jours après, XYZ-3.7 migre d'unstable vers testing.

* Donc le 20 juin, testing et unstable ont toutes deux XYZ-3.7.

* Un utilisateur de la distribution testing repère qu'une nouvelle version de XYZ est disponible et met à jour sa version XYZ-3.6 en XYZ-3.7.

* Le 25 juin, quelqu'un utilisant testing ou unstable découvre un bogue RC dans XYZ-3.7 et le signale dans le BTS.

* Le responsable de XYZ corrige ce bogue et l'envoie vers unstable le 30 juin. On suppose ici que 5 jours sont nécessaires au responsable pour corriger et envoyer la nouvelle version. Ce chiffre de 5 ne doit pas être pris au pied de la lettre ; il peut être supérieur ou inférieur, suivant la sévérité du bogue RC.

* Cette nouvelle version arrivée dans unstable, XYZ-3.8 est programmée pour atteindre testing le 10 juillet.

* Mais le 5 juillet, un autre utilisateur découvre un autre bogue dans XYZ-3.8.

* Considérons que le responsable de XYZ corrige ce nouveau bogue et envoie la nouvelle version en 5 jours.

* Ainsi le 10 juillet, testing propose XYZ-3.7 alors que unstable propose XYZ-3.9.

* Cette nouvelle version XYZ-3.9 est reprogrammée pour atteindre testing le 20 juillet.

* Puisque vous utilisez testing et que XYZ-3.7 est boggué, vous ne pourrez sans doute utiliser XYZ qu'après le 20 juillet. Ainsi vous aurez passé près d'un moins avec une version XYZ cassée.

La situation peut être bien plus compliquée, si par exemple XYZ dépend de 4 autres paquets. Cela peut rendre la distribution testing inutilisable pendant plusieurs mois. Le scénario ci-dessus est fictif et peut se produire dans la réalité, même si de tels cas sont rares.

C'est pour cela qu'il ne faut sous testing tant qu'elle n'est pas gelée ne faire que des aptitude safe-upgrade , cela vous sauvera la mise la plupart du temps et toujours faire une simulation au préalable avec l'option -s .

Et si vous tenez absolument à être à jour des dernières nouveautés passez à sid comme le conseille l'auteur des FAQ ainsi que cep, mais cela peut être sportif de temps en temps.

De plus en plus de sites Web introduisent dans leurs pages Google Analytics : c'est un petit script qui relève des informations lors de votre connexion sur les différentes pages.

Si vous voulez éviter cela de façon définitive et absolue, il vous suffit d'éditer le fichier /etc/hosts et d'y rajouter les lignes suivantes:

#les blocages des espions
127.0.0.1 google-analytics.com
127.0.0.1 www.google-analytics.com

Fini l'espionnage de Google.

Pour ceux qui veulent gérer leur système (sauvegarde, restauration, partitionnement, etc..) il y a des tas d’outils sur liveCD qui permettent de travailler sur les partitions non montées, et en particulier celui de SystemeRescueCd (site officiel)

Mais l’on peut aussi installer SystemRescue sur son disque dur dans une petite partition de 300 Mo environ, et alors plus besoin de booter sur le CDRom et gain de vitesse dans le lancement des applications.

A partir de la version SystemRescueCd-1.0.0 l'installation sur disque dur a été simplifiée, il vous faut donc une version 1.0.0-rc2 ou plus récente pour pouvoir appliquer les instructions suivantes données sur le site de Systemerescuecd.

L'installation est décomposée en étapes:

- Il faut en premier copier les fichiers qui sont sur le disque de SystemRescueCd vers votre disque dur.
- Ensuite il faut installer ou mettre a jour votre gestionnaire d'amorçage (grub sous Linux) pour que les fichiers puisse être pris en compte au démarrage.

Quatre noyaux sont fournis avec SystemRescueCd: rescuecd, rescue64, altker32, altker64. Ce chapitre explique l'installation en utilisant le noyau par défaut: rescuecd.

1 -Création d'une partition dédiée à SystemRescue.

Sur votre disque dur vous devez créer une petite partition systemrescue en ext2 ou ext3 de 500 Mo environ. Relevez son identité Linux (hdxy), vous en aurez besoin plus tard.

2- Copie des fichiers

Cette étape est vraiment très facile. Il faut juste copier les fichiers du disque de SystemRescueCd sur la partition de votre disque dur. La copie peut être faite depuis Linux tant que le système de fichiers est reconnu par le système. Vous pouvez même copier les fichiers depuis SystemRescueCd lui même si vous n'avez pas de système installé sur la machine.

Vous devez créer un dossier /sysrcd/ dans la racine de la partition, pas dans un sous-dossier. Vous pouvez copier ces fichiers sans avoir à graver l'image de SystemRescueCd sur un disque car sous Linux vous pouvez accéder au fichier de l'image iso en montant l'image (ex: mount -o loop systemrescuecd-x86-x.y.z.iso /mnt/cdrom).

Les fichiers nécessaires doivent être recopies sans reprendre la structure d'origine des fichiers sur le disque. Vous devez donc copier les 7 fichiers suivants :

• sysrcd.dat,
• sysrcd.md5,
• initram.igz,
• rescuecd,
• rescue64,
• altker32,
• altker64

depuis le CDRom vers le dossier (/sysrcd/) de votre partition systemrescue du disque dur . Certains de ces fichiers se trouvent dans le dossier isolinux sur le CDRom.

3- Mise à jour de grub

Vous allez ajouter plusieurs lignes au fichier de configuration de grub (/boot/grub/menu.lst). Il sera nécessaire d'adapter la configuration donnée ici à votre situation. Avec grub, il est nécessaire de connaître le nom de la partition sur laquelle vous avez copié les fichiers. Les noms de disques sous grub sont différents des noms sous linux. Par exemple (hd0,0) signifie hda1 et (hd0,1) au lieu de hda2, ...

Il faut aussi adapter les options de démarrage passées a SystemRescueCd concernant votre type de clavier(setkmap=xx), pour un clavier français mettre setkmap=fr

Exemple pour GRUB

Voci un exemple de configuration pour Grub dans le fichier /boot/grub/menu.lst

Dans cet exemple votre partition sytemrescue est la partition /dev/hda8. Le nom de disque correspondant dans grub est (hd0,7) (il faut enlever 1 au numéro de la partition, donc 8-1=7)

title SystemRescueCd sur le disque dur
root (hd0,7)
kernel /sysrcd/rescuecd subdir=sysrcd setkmap=fr
initrd /sysrcd/initram.igz
boot

• Attention: dans grub, les disques IDE, SATA et SCSI (/dev/hda et /dev/sda) ont toujours un nom du type (hd0). Il ne faut pas écrire (sd0) pour les disques SATA ou SCSI.
  
• Vous devez replacer setkmap=fr par votre type de clavier si c'est différent de l'exemple.
  

4- Utilisation.

Lors du boot dans le menu de grub vous choisissez SystemRescueCd et lorsque vous arriverez au prompt de systemrescue tapez wizard puis return pour lancer l'interface graphique, un menu de choix du serveur X vous sera proposé. Normalement Xorg doit fonctionner, mais en cas de problème vous pourrez utiliser Xvesa.

A noter qu'il y a un firefox intégré et si vous disposez d'une connexion internet, vous pourrez vous connecter au web et cherchez éventuellement de l'aide.
Vous devrez rajouter l'option dodhcp dans la ligne de boot du menu.lst pour que la connexion au réseau se fasse automatiquement sur votre routeur lors du boot.

GRUB le boot manager Linux est un outil remarquable mais dont le fonctionnement en tiroirs successifs crée pas mal de problèmes aux débutants en particulier en cas de multiboot d'OS Linux et/ou Windows.

En effet il installe par défaut dans le MBR du disque son loader pointant vers le boot de l'OS ce qui ne va pas manquer de créer des problèmes en cas d'installations successives de différents OS, en particulier de Windows qui reprend systématiquement possession du MBR pour son bootloader.

Il en sera de même en cas d'installation de nouveaux OS GNU/Linux où l'on risque de perdre les différentes options de boot sur les autres OS.

Le rétablissement d'un GRUB opérationnel est toujours possible à partir d'un liveCD sous Linux (voir le blog de cep) ainsi que le reparamétrage du menu.lst, mais cela peut présenter des difficultés pour un néophyte.

Pour éviter tous ces casses têtes je préconise lors de l'installation des différents OS Linux de mettre systématiquement le loader de Grub dans la partiion système de l'OS (cette option existe dans tous les installeurs lors de l'installation de grub) et d'installer dans le MBR un simple boot manager que l'on fera pointer vers les différentes partitions boot des systèmes y compris celle de Windows si l'on a conservé cet OS sur son PC.

Ce système a l'avantage de rendre les différents Grub incassables en cas de réinstallation ou d'installation d'OS suplémentaire.

Le plus simple pour cela est sans aucun doute d'utiliser GAG que l'on trouvera ici.

On procèdera après téléchargement de GAG à la création du CD GAG, ensuite vous bouterez sur ce CD et vous pourrez alors faire la création de la liste de choix de GAG pointant vers les partitions de boot des différents OS, ensuite faites enregistrer sur le disque dur. Au boot suivant vous aurez l'écran d'accueil de GAG avec la liste de choix des OS.

Cette opération peut se faire avant l'installation des différents OS pourvu que vous ayez défini les partitions qui seront les partitions de boot de ces OS, ou après l'installation de chaque nouvel OS.

Nota: le fichier téléchargé contient l'image iso pour graver le CD et d'autres utiliaires ainsi qu'un dossier avec toutes les explications détaillées d'installation en anglais.

Sur son réseau familial, on peut souhaiter incorporer (monter) un dossier distant d'un PC serveur Samba sur un PC client ce qui donne plus de souplesse pour utiliser ce dossier partagé que l'utilisation de parcours du réseau Samba.

On suppose que le PC serveur est booté donc disponible sur le réseau condition indispensable, et on va paraméter le PC client pour que lors du boot il monte automatiquement le dossier distant dans son arborescence.

On va commencer par créer un point de montage pour le dossier distant sur le PC client.

# mkdir /media/partage

On va rajouter une ligne dans le fichier /etc/fstab.

# gedit /etc/fstab

Et on ajoute sur une seule ligne à la fin du fichier :

//IpPCdistant/Partage /media/partage cifs
uid=utilisateur,gid=utilisateur,user=admin,pass=passeadmin 0 0

Mais avec ce système le passe de l'administrateur du réseau est visible en clair dans le fstab. Pour des raisons de sécurité évidentes on va être amené à cacher ces informations pour qu'elles ne soient pas visibles par l'utilisateur du PC en dehors de l'administrateur du réseau.

On modifie donc la ligne dans la partie des options les deux paramètres user et pass en les remplaçant par le paramètre credentials pour avoir :

//IpPCdistant/Partage /media/partage cifs
uid=utilsateur,gid=utilsateur,credentials=/root/.smbcredentials 0 0

Le fichier .smbcredentials est un simple fichier texte comprenant sur deux lignes les renseignements suivants:

username=admin
password=passeadmin

On va donc le créer et y mettre ces deux lignes.

# gedit /root/.smbcredentials

On cache ce fichier (avec le point devant) dans le répertoire /root avec les permissions 600 et avec l'administrateur du réseau comme propriétaire.

# chown admin:admin /root/.smbcredentials
# chmod 600 /root/.smbcredentials

Normalement au boot suivant l'utisateur du PC client va trouver dans son arborescence le dossier distant monté dans /media/partage, mais cet utilisateur ne pourra pas lire le dossier caché .smbcredentials et donc connaitre le passe de l'administrateur du réseau.

PS: on peut ajouter également dans les options de montage file_mode=0640,dir_mode=0755 ce qui va restreindre l'accès aux comptes en dehors de root, de l'administrateur du réseau, et du groupe tout en laissant tout le monde scanner le dossier monté.

Petit condensé de la façon de créer son petit réseau familial sécurisé entre PC sous GNU/Linux.

Je suppose que vous savez déjà paramétrer les différents PCs comme indiqués dans les posts précédents sur Samba et que votre réseau Samba fonctionne mais que vous avez quelques problèmes de sécurisation des accès. Le problème est double car il faut gérer les permissions Samba d'accès aux dossiers et les permissions Unix dans les dossiers.

Nous allons donc reprendre point par point les étapes d'installation de ce réseau.

Pour être tranquille et avoir un réseau familial à accès sécurisé, on procèdera de la façon suivante.

En préliminaire dans les fichiers smb.conf des différents PCs on harmonise le nom du groupe de travail (workgroup) et on définit l'option security = user c'est primordial (abandonnez définitivement la notion d'accès libre, car vous pourrez toujours faire un dossier à accès public en secutiry = user si vous le désirez) puis dans l'ordre

A- Sur tous les PCs client et sur le PC serveur on va :

1- créer un compte unix à tous les utilisateurs ainsi qu'un compte samba
2- créer un groupe partagefamille et mettre dedans l'administrateur du réseau et les autres utilisateurs.

B- Sur le PC serveur uniquement:

1- pour chaque dossier partagé mettre comme propriétaire l'administrateur du réseau
2- pour les dossiers où le seul utilisateur est l'administrateur réseau mettre son groupe et comme user samba (valid users = nomadministrateur)
3- pour les dossiers où il y a un seul utilisateur mettre son groupe et comme user samba (valid users = nomutilisateur)
4- sur les autres dossiers partagés mettre comme groupe partagefamille et comme valid user le groupe partagefamille (valid users =+partagefamille)
5- faire un chmod -R 750 sur tous les dossiers partagés (ou 770 sur les dossiers accessible par partagefamille si l'on veut que le groupe partagefamille puisse écrire)
6- faire un set gid sur les dossiers accessibles à partagefamille pour que le groupe ne change pas qui que cela soit qui écrive dans ce dossier. Pour avoir cela commandes à exécuter dans l'ordre en root ou en sudo :

sudo chmod -R g=rx dossier -> fixe les permissions du groupe (rwx s'ils peuvent écrire)
sudo chmod -R g+s dossier -> pose le setgid
sudo chmod -R u-s dossier -> enlève le setuid éventuel
sudo chmod -R u=rwx dossier -> fixe les permissions du propriétaire

les détails à propos du setgid sont là

Nota: S'il doit y avoir des dossiers partagés accessibles sur d'autres PC du réseau on les traite comme ceux du PC serveur.

Pour avoir un java à jour sur Lenny, il faut choisir le java de Sun qui est disponible dans les dépôts non free, les autres solutions "libres" sont un peu en retard au niveau des versions.

Pour être sur d'avoir la dernière version 1.6.0_14, vous devrez choisir d'installer celle qui est disponible dans les dépôts testing non free (à mettre dans votre sources.list préalablement) puis:

apt-get update
apt-get -t testing install sun-java6-jre sun-java6-bin sun-java6-plugin

eusuite un $ apt-cache policy sun-java6-plugin vous confirmera que vous avez bien la dernière version.