Lea Linux - Contributions [fr]

Bluetooth sur EeePC

2008-05-09T01:29:32Z

Jice (phorum) : /* tests en mode graphique */

{{En construction}}
(en fait l'article est écrit par un modérateur, mais il n'est pas fini ;-)

= Le Bluetooth sur EeePC =

Malheureusement Asus n'a pas cru bon d'installer le nécessaire pour faire du bluetooth simplement avec l'EeePC. Cependant, nous allons y remédier en installant les modules Bluetooth de KDE, KdeBluetooth.

== Installation ==

Pour toutes les commandes ci-dessous, le mieux est de passer dans un shell root, en tapant <code>sudo -s</code>, ou bien d'ajouter <code>sudo</code> devant chaque commande.

=== Paquets ===

Le paquet kdebluetooth se trouve sur le dépot XEPC dont un mirroir existe chez tuxfamily. Nous allons ajouter ce mirroir à la liste des dépots de paquets .deb.

Éditez le fichier /etc/apt/sources.list (avec [[Software-soft_edit-vi|vi]], nano, kate ou obiwan kenobi) et ajoutez à la fin la ligne :

<code>deb http://download.tuxfamily.org/xepcrepo/ p701 main</code>

Par exemple, ce fichier est chez moi le suivant :
<div class="code"><pre>deb http://update.eeepc.asus.com/p701 p701 main
deb http://update.eeepc.asus.com/p701/fr-channel p701 main
# xepc mirror
deb http://download.tuxfamily.org/xepcrepo/ p701 main
</pre></div>

Les lignes qui commencent par # sont des commentaires.

Ensuite,

* installons la clef de signature du nouveau dépôt par les 2 commandes :

<div class="code"><pre>asus:/home/user> wget http://download.tuxfamily.org/xepcrepo/dists/p701/xepc-pubkey.txt
asus:/home/user> apt-key add xepc-pubkey.txt</pre></div>

La première commande télécharge la clef, la deuxième l'installe.

* mettons à jour les dépots par :

<code>apt-get update</code>

Enfin, installons kdebluetooth et les applications obex par la commande :

<code>apt-get install kdebluetooth openobex-apps</code>

qui doit donner le résultat suivant :

<div class="code"><pre>asus:/home/user> apt-get install kdebluetooth openobex-apps
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Les paquets supplémentaires suivants seront installés :
libdbus-qt-1-1c2 libkbluetooth0 libopenobex1 python-dbus python-libxml2
Les NOUVEAUX paquets suivants seront installés :
kdebluetooth libdbus-qt-1-1c2 libkbluetooth0 libopenobex1 openobex-apps
python-dbus python-libxml2
0 mis à jour, 7 nouvellement installés, 0 à enlever et 50 non mis à jour.
Il est nécessaire de prendre 1857ko dans les archives.
Après dépaquetage, 6849ko d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer [O/n] ? o
Réception de : 1 http://download.tuxfamily.org p701/main libdbus-qt-1-1c2 0.62.git.20060814-2+eeepc1 [180kB]
Réception de : 2 http://download.tuxfamily.org p701/main libopenobex1 1.3-3+eeepc1 [21,4kB]
Réception de : 3 http://download.tuxfamily.org p701/main libkbluetooth0 1.0~beta8-3+eeepc1 [301kB]
Réception de : 4 http://download.tuxfamily.org p701/main python-libxml2 2.6.27.dfsg-1+eeepc1 [170kB]
Réception de : 5 http://download.tuxfamily.org p701/main python-dbus 0.71-3+eeepc1 [118kB]
Réception de : 6 http://download.tuxfamily.org p701/main kdebluetooth 1.0~beta8-3+eeepc1 [1034kB]
Réception de : 7 http://download.tuxfamily.org p701/main openobex-apps 1.3-3+eeepc1 [33,1kB]
1857ko réceptionnés en 8s (227ko/s)
Sélection du paquet libdbus-qt-1-1c2 précédemment désélectionné.
(Lecture de la base de données... 64748 fichiers et répertoires déjà installés.)
Dépaquetage de libdbus-qt-1-1c2 (à partir de .../libdbus-qt-1-1c2_0.62.git.20060814-2+eeepc1_i386.deb) ...
Sélection du paquet libopenobex1 précédemment désélectionné.
Dépaquetage de libopenobex1 (à partir de .../libopenobex1_1.3-3+eeepc1_i386.deb) ...
Sélection du paquet libkbluetooth0 précédemment désélectionné.
Dépaquetage de libkbluetooth0 (à partir de .../libkbluetooth0_1.0~beta8-3+eeepc1_i386.deb) ...
Sélection du paquet python-libxml2 précédemment désélectionné.
Dépaquetage de python-libxml2 (à partir de .../python-libxml2_2.6.27.dfsg-1+eeepc1_i386.deb) ...
Sélection du paquet python-dbus précédemment désélectionné.
Dépaquetage de python-dbus (à partir de .../python-dbus_0.71-3+eeepc1_i386.deb) ...
Sélection du paquet kdebluetooth précédemment désélectionné.
Dépaquetage de kdebluetooth (à partir de .../kdebluetooth_1.0~beta8-3+eeepc1_i386.deb) ...
Removing obsolete conffile /etc/kde3/obexrc ...
Sélection du paquet openobex-apps précédemment désélectionné.
Dépaquetage de openobex-apps (à partir de .../openobex-apps_1.3-3+eeepc1_i386.deb) ...
Paramétrage de libdbus-qt-1-1c2 (0.62.git.20060814-2+eeepc1) ...

Paramétrage de libopenobex1 (1.3-3+eeepc1) ...

Paramétrage de libkbluetooth0 (1.0~beta8-3+eeepc1) ...

Paramétrage de python-libxml2 (2.6.27.dfsg-1+eeepc1) ...

Paramétrage de python-dbus (0.71-3+eeepc1) ...
Remove stale byte-compiled files...

Paramétrage de kdebluetooth (1.0~beta8-3+eeepc1) ...
Paramétrage de openobex-apps (1.3-3+eeepc1) ...
asus:/home/user> </pre></div>

Voilà c'est installé !

==== méthode alternative ====

Il faut déjà récupérer les paquets suivants chez [http://xnv4.xandros.com/xs2.0/upkg-srv2/ Xandros] :
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/k/kdebluetooth/qobex_0.99+1.0beta2-3_i386.deb qobex]
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/libo/libopenobex/libopenobex1_1.3-3_i386.deb libopenobex1]
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/libo/libopenobex/openobex-apps_1.3-3_i386.deb openobex-apps]
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/b/bluez-libs/libbluetooth2_3.7-1_i386.deb libbluetooth2]
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/k/kdebluetooth/kdebluetooth_0.99+1.0beta2-3_i386.deb kdebluetooth]

Pour chacun de ces paquets sauf le dernier, vous pouvez ensuite les installer avec la commande :

<code>dpkg -i le_nom_du_paquet.deb</code>

par exemple :

<code>dpkg -i qobex_0.99+1.0beta2-3_i386.deb</code>

kdebluetooth entre en conflit avec un paquet nommé "kdelibs4c2a" et essaie d'écraser des fichiers de localisation (venant du paquet kde-i18n-fr). Vous entrerez donc la commande :

<code>dpkg -i --force-overwrite --ignore-depends=kdelibs4c2a kdebluetooth_0.99+1.0beta2-3_i386.deb</code>

Pour cette raison, la méthode d'installation présentée au début doit être préférée, car il n'est jamais bon de forcer la main à dpkg ou d'ignorer les dépendances...

=== Scripts ===

Editez /etc/bluetooth/hcid.conf (avec [[Software-soft_edit-vi|vi]], nano, kate ou ce que vous voulez), et modifiez le niveau de sécurité (security level), le code PIN (passkey) et le nom (name). Voici par exemple le contenu de ce fichier chez moi :

<div class="code"><pre>#
# HCI daemon configuration file.
#

# HCId options
options {
# Automatically initialize new devices
autoinit yes;

# Security Manager mode
# none - Security manager disabled
# auto - Use local PIN for incoming connections
# user - Always ask user for a PIN
#
security none;

# Pairing mode
# none - Pairing disabled
# multi - Allow pairing with already paired devices
# once - Pair once and deny successive attempts
pairing multi;

# Default PIN code for incoming connections
passkey "1234";
}

# Default settings for HCI devices
device {
# Local device name
# %d - device id
# %h - host name
name "%h-%d";

# Local device class
class 0x3e0100;

# Default packet type
#pkt_type DH1,DM1,HV1;

# Inquiry and Page scan
iscan enable; pscan enable;

# Default link mode
# none - no specific policy
# accept - always accept incoming connections
# master - become master on incoming connections,
# deny role switch on outgoing connections
lm accept;

# Default link policy
# none - no specific policy
# rswitch - allow role switch
# hold - allow hold mode
# sniff - allow sniff mode
# park - allow park mode
lp rswitch,hold,sniff,park;
}</pre></div>

== premier lancement et tests ==

=== démarrage des services ===

Démarrez :

* les démons (daemons) bluetooth par la commande :

<code>/etc/init.d/bluetooth start</code>

* le bus permettant aux applications de communiquer entre elles :

<code>/etc/init.d/dbus start</code>

* et l'interface bluetooth par :

<code>hciconfig hci0 up</code>

À ce point là, la diode de ma clef USB bluetooth se met à clignoter.

=== tests en ligne de commande ===

Une interface bluetooth est comparable à une interface réseau, avec hciconfig remplaçant ifconfig. En tapant <code>hciconfig</code> dans la console, l'EeePC affiche l'état de l'interface :

<div class="code"><pre>hci0: Type: USB
BD Address: 11:11:11:11:11:11 ACL MTU: 678:8 SCO MTU: 48:10
UP RUNNING PSCAN ISCAN
RX bytes:91 acl:0 sco:0 events:10 errors:0
TX bytes:37 acl:0 sco:0 commands:10 errors:0</pre></div>

De plus, en tapant <code>dmesg</code> pour voir les messages système, entre le branchement de la clef et le lancement des services bluetooth, je vois les lignes suivantes :

<div class="code"><pre>[15968.260000] usb 2-1: new full speed USB device using uhci_hcd and address 2
[15978.430000] usb 2-1: configuration #1 chosen from 1 choice
[15978.570000] Bluetooth: Core ver 2.11
[15978.580000] NET: Registered protocol family 31
[15978.580000] Bluetooth: HCI device and connection manager initialized
[15978.580000] Bluetooth: HCI socket layer initialized
[15978.580000] Bluetooth: HCI USB driver ver 2.9
[15978.590000] usbcore: registered new interface driver hci_usb
[15990.020000] Bluetooth: L2CAP ver 2.8
[15990.020000] Bluetooth: L2CAP socket layer initialized
[15990.050000] Bluetooth: RFCOMM socket layer initialized
[15990.050000] Bluetooth: RFCOMM TTY layer initialized
[15990.050000] Bluetooth: RFCOMM ver 1.8</pre></div>

Nous allons maintenant tester rapidement en ligne de commande, afin de voir que nous voyons et pouvons établir une communication. Activez donc le bluetooth sur votre appareil (téléphone, PDA, clavier...).

Pour celà, nous allons utiliser l'outil <hcitool> :

Regardons d'abord le périphérique local :

<div class="code"><pre>asus:/home/user> hcitool dev
Devices:
hci0 11:11:11:11:11:11
</pre></div>

Puis cherchons les périphériques bluetooth environnants :

<div class="code"><pre>asus:/home/user> hcitool inq
Inquiring ...
00:15:DE:04:84:65 clock offset: 0x193a class: 0x520204
</pre></div>

ou avec leur nom :

<div class="code"><pre>asus:/home/user> hcitool scan
Scanning ...
00:15:DE:04:84:65 Nokia 6111
</pre></div>

Ici on voit le nom de mon téléphone mobile.

Note : les chaînes du type 00:15:DE:04:84:65 s'appellent "l'adresse MAC" du périphérique et l'identifient de façon unique (enfin normalement, car mon adaptateur USB à comme adresse 11:11:11:11:11:11 ce qui ne me semble pas très "unique" ;-)

Enfin, comme avec un réseau filaire ou wifi, on peut faire un "ping" (ping pong entre l'EeePC et le périphérique bluetooth) :

<div class="code"><pre>asus:/home/user> l2ping 00:15:DE:04:84:65
Ping: 00:15:DE:04:84:65 from 11:11:11:11:11:11 (data size 44) ...
0 bytes from 00:15:DE:04:84:65 id 0 time 30.98ms
0 bytes from 00:15:DE:04:84:65 id 1 time 25.58ms
0 bytes from 00:15:DE:04:84:65 id 2 time 29.55ms
0 bytes from 00:15:DE:04:84:65 id 3 time 11.55ms
0 bytes from 00:15:DE:04:84:65 id 4 time 19.50ms
5 sent, 5 received, 0% loss
</pre></div>
(on arrête en tapant [Ctrl]-[C].)

Cela montre que les 2 périphériques sont prêts à s'échanger des données.

=== tests et configuration en mode graphique ===

Vous pouvez maintenant repasser en utilisateur normal (plus besoin de sudo). Ouvrez une nouvelle concole, et tapez : <code>kbluetooth &</code>. Le logo bluetooth doit apparaître dans la zone de notification de la barre des tâches.

[[Image:Notify_bt.png]]

Faites un clic droit sur l'icone bluetooth, puis "Configuration" et enfin "Adapters...".
Ici vous pouvez choisir la classe (en l'occurence "laptop") et rendre l'EeePC "discoverable", c'est à dire visible par les autres périphériques Bluetooth.

[[Image:Bt_adapter_config_kde.png]]

Vous pouvez également changer le nom de votre EeePC tel que les autres périphériques bluetooth le voient, et consulter l'adresse MAC de votre adaptateur bluetooth.

== automatiser ces commandes ==

== utilisation ==

=== transfert de fichiers ===

=== utiliser le téléphone comme un modem ===

=== connecter un clavier et/ou une souris bluetooth ===

= Copyright =
Copyright © 1/5/2008, Jean-Christophe Cardot
{{CC-BY-SA}}

Fichier:Bt adapter config kde.png

2008-05-09T01:26:10Z

Jice (phorum) : KDE bluetooth adapter configuration

KDE bluetooth adapter configuration

EeePC

2008-05-09T01:06:19Z

Jice (phorum) : /* Outils */

[[Category:Configurer votre matériel]]
= EeePC =

<div class="leatitre">l'EeePC d'Asus</div><div class="leapar">par Jice<div class="leadesc">Un ultraportable sous Linux, et à ce prix là, Léa ne pouvait pas laisser passer ça !</div>
----

Alors ca y est j'ai craqué pour un EeePC. Enfin, ca fait un bout de temps déjà. Connaisseur de Linux depuis 1994, et aujourd'hui utilisateur de Mandriva, je l'ai pourtant laissé sous sa distribution de base, une Xandros modifiée par Asus, et en mode facile (Easy Mode) qui plus est. Pourquoi ? Car cela me convient ;-)

Avec quelques outils dont on parlera plus bas, et quelques améliorations que je détaillerai aussi (par exemple l'utilisation du bluetooth pour transférer des fichiers avec mon téléphone portable), c'est parfait pour l'utilisation que j'en ai : surfer avec [http://www.mozilla-europe.org/fr/products/firefox/ Firefox], messagerie instantanée avec [http://www.pidgin.im/ Pidgin] et webcam avec Skype - je suis expatrié, bien sûr la bureautique avec [http://fr.openoffice.org/ OpenOffice.org] (le clavier est petit mais très utilisable). J'ai aussi installé Google Earth, et je fragge même des bots avec [http://assault.cubers.net/ Assault cube] pour me défouler le soir... [http://amarok.kde.org/ Amarok] est parfait pour écouter ma musique (dois-je préciser que j'ai ajouté une SDHC de 16 Go ?) ; j'ai même visionné un film en avion depuis mon disque dur externe 2.5 pouces...

Bref, finalement beaucoup d'utilisation pour peu de bidouille, et aussi l'irremplaçable temps de démarrage de Xandros par rapport aux autres distributions sur EeePC me font pour le moment rester fidèle aux logiciels livrés avec mon joujou (ceci dit je testerai la Mandriva 2008.1 sur ma carte SD, car on en dit beaucoup de bien ; j'en parlerai aussi ici :-)

== Outils ==
[[Launcher tools#SimpleUI Editor|SimpleUI Editor]] et [[Easy Mode Editor]] : l'interface d'Asus Easy Mode n'est pas configurable simplement (ajouter une icône, créer un sous-répertoire...). Ces logiciels comblent ce manque.

[[Launcher tools]] : créer une nouvelle icône au format EeePC, rafraîchir l'interface Easy Mode sans relancer la machine ni même X Window...

[[TweakEEE]] : plein de bidouilles automatisées, des installations de logiciels supplémentaires...

[[Theeemer]] : changer le thème graphique de l'EeePC (fond d'écrans, gestionnaire de fenêtres, couleurs...)

== Tutoriels et Trucs & astuces ==

les outils présentés ci-dessus on rendus inutiles un grand nombre de tutoriels qu'on trouve sur le net. Néanmoins, il reste quelques manipulations à faire manuellement.

[[Bluetooth sur EeePC]]

[[Un FPS sur l'EeePC : Assault Cube]]

[[Lancement de logiciels au démarrage sur EeePC]]

[[Déplacer une fenêtre trop grande sur l'EeePC]]

[[GoogleEarth sur l'EeePC]]

== Liens ==

=== Les blogs ===
Je les lis presque tous les jours, car le monde de l'EeePC bouge vite.
en français :
* [http://www.blogeee.net/ Blogeee.net]
* [http://www.eeepc-logiciels.com/ EeePc Logiciels]
* [http://www.eee-pc.fr/ EeePc-FR]
* [http://leeenux.blogspot.com/ Leeenux]
* [http://tuxeee.org/ Tuxeee]
* [http://nawer.freecontrib.org/index.php BlogORabais]
en anglais :
* [http://www.eeeuser.com/ EeeUser.com]
* [http://www.3eportal.com/ 3eportal], des outils pour EeePC

=== Les wikis ===
Ils regroupent des tutoriels pour aller plus loin.
en français :
* [http://wikeee.fr/index.php/Accueil Wikeee]
en anglais :
* [http://wiki.eeeuser.com/ EeeUser wiki]

TweakEEE

2008-05-09T01:03:39Z

Jice (phorum) :

http://www.infinitedesigns.org/archives/category/software

[[EeePC|Retour à la page EeePC]]

Easy Mode Editor

2008-05-09T01:00:40Z

Jice (phorum) :

http://download.projectsakura.com/eeepc/emeditor.html

[[EeePC|Retour à la page EeePC]]

Easy Mode Editor

2008-05-09T00:59:49Z

Jice (phorum) :

http://download.projectsakura.com/eeepc/emeditor.html

Bluetooth sur EeePC

2008-05-03T13:04:36Z

Jice (phorum) : /* Paquets */ méthode propre avec xepc miroir tuxfamily

= Le Bluetooth sur EeePC =

Malheureusement Asus n'a pas cru bon d'installer le nécessaire pour faire du bluetooth simplement avec l'EeePC. Cependant, nous allons y remédier en installant les modules Bluetooth de KDE, KdeBluetooth.

== Installation ==

Pour toutes les commandes ci-dessous, le mieux est de passer dans un shell root, en tapant <code>sudo -s</code>, ou bien d'ajouter <code>sudo</code> devant chaque commande.

=== Paquets ===

Le paquet kdebluetooth se trouve sur le dépot XEPC dont un mirroir existe chez tuxfamily. Nous allons ajouter ce mirroir à la liste des dépots de paquets .deb.

Éditez le fichier /etc/apt/sources.list et ajoutez à la fin la ligne :

<code>deb http://download.tuxfamily.org/xepcrepo/ p701 main</code>

Par exemple, ce fichier est chez moi le suivant :
<div class="code><pre>deb http://update.eeepc.asus.com/p701 p701 main
deb http://update.eeepc.asus.com/p701/fr-channel p701 main
# xepc mirror
deb http://download.tuxfamily.org/xepcrepo/ p701 main
</pre></div>

Les lignes qui commencent par # sont des commentaires.

Ensuite,

* installons la clef de signature du nouveau dépôt par les 2 commandes :

<div class="code"><pre>asus:/home/user> wget http://download.tuxfamily.org/xepcrepo/dists/p701/xepc-pubkey.txt
asus:/home/user> apt-key add xepc-pubkey.txt</pre></div>

La première commande télécharge la clef, la deuxième l'installe.

* mettons à jour les dépots par :

<code>apt-get update</code>

Enfin, installons kdebluetooth et les applications obex par la commande :

<code>apt-get install kdebluetooth openobex-apps</code>

qui doit donner le résultat suivant :

<div class="code"><pre>asus-581860474:/home/user> apt-get install kdebluetooth openobex-apps
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Les paquets supplémentaires suivants seront installés :
libdbus-qt-1-1c2 libkbluetooth0 libopenobex1 python-dbus python-libxml2
Les NOUVEAUX paquets suivants seront installés :
kdebluetooth libdbus-qt-1-1c2 libkbluetooth0 libopenobex1 openobex-apps
python-dbus python-libxml2
0 mis à jour, 7 nouvellement installés, 0 à enlever et 50 non mis à jour.
Il est nécessaire de prendre 1857ko dans les archives.
Après dépaquetage, 6849ko d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer [O/n] ? o
Réception de : 1 http://download.tuxfamily.org p701/main libdbus-qt-1-1c2 0.62.git.20060814-2+eeepc1 [180kB]
Réception de : 2 http://download.tuxfamily.org p701/main libopenobex1 1.3-3+eeepc1 [21,4kB]
Réception de : 3 http://download.tuxfamily.org p701/main libkbluetooth0 1.0~beta8-3+eeepc1 [301kB]
Réception de : 4 http://download.tuxfamily.org p701/main python-libxml2 2.6.27.dfsg-1+eeepc1 [170kB]
Réception de : 5 http://download.tuxfamily.org p701/main python-dbus 0.71-3+eeepc1 [118kB]
Réception de : 6 http://download.tuxfamily.org p701/main kdebluetooth 1.0~beta8-3+eeepc1 [1034kB]
Réception de : 7 http://download.tuxfamily.org p701/main openobex-apps 1.3-3+eeepc1 [33,1kB]
1857ko réceptionnés en 8s (227ko/s)
Sélection du paquet libdbus-qt-1-1c2 précédemment désélectionné.
(Lecture de la base de données... 64748 fichiers et répertoires déjà installés.)
Dépaquetage de libdbus-qt-1-1c2 (à partir de .../libdbus-qt-1-1c2_0.62.git.20060814-2+eeepc1_i386.deb) ...
Sélection du paquet libopenobex1 précédemment désélectionné.
Dépaquetage de libopenobex1 (à partir de .../libopenobex1_1.3-3+eeepc1_i386.deb) ...
Sélection du paquet libkbluetooth0 précédemment désélectionné.
Dépaquetage de libkbluetooth0 (à partir de .../libkbluetooth0_1.0~beta8-3+eeepc1_i386.deb) ...
Sélection du paquet python-libxml2 précédemment désélectionné.
Dépaquetage de python-libxml2 (à partir de .../python-libxml2_2.6.27.dfsg-1+eeepc1_i386.deb) ...
Sélection du paquet python-dbus précédemment désélectionné.
Dépaquetage de python-dbus (à partir de .../python-dbus_0.71-3+eeepc1_i386.deb) ...
Sélection du paquet kdebluetooth précédemment désélectionné.
Dépaquetage de kdebluetooth (à partir de .../kdebluetooth_1.0~beta8-3+eeepc1_i386.deb) ...
Removing obsolete conffile /etc/kde3/obexrc ...
Sélection du paquet openobex-apps précédemment désélectionné.
Dépaquetage de openobex-apps (à partir de .../openobex-apps_1.3-3+eeepc1_i386.deb) ...
Paramétrage de libdbus-qt-1-1c2 (0.62.git.20060814-2+eeepc1) ...

Paramétrage de libopenobex1 (1.3-3+eeepc1) ...

Paramétrage de libkbluetooth0 (1.0~beta8-3+eeepc1) ...

Paramétrage de python-libxml2 (2.6.27.dfsg-1+eeepc1) ...

Paramétrage de python-dbus (0.71-3+eeepc1) ...
Remove stale byte-compiled files...

Paramétrage de kdebluetooth (1.0~beta8-3+eeepc1) ...
Paramétrage de openobex-apps (1.3-3+eeepc1) ...
asus:/home/user> </pre></div>

Voilà c'est installé !

==== méthode alternative ====

Il faut déjà récupérer les paquets suivants chez [http://xnv4.xandros.com/xs2.0/upkg-srv2/ Xandros] :
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/k/kdebluetooth/qobex_0.99+1.0beta2-3_i386.deb qobex]
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/libo/libopenobex/libopenobex1_1.3-3_i386.deb libopenobex1]
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/libo/libopenobex/openobex-apps_1.3-3_i386.deb openobex-apps]
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/b/bluez-libs/libbluetooth2_3.7-1_i386.deb libbluetooth2]
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/k/kdebluetooth/kdebluetooth_0.99+1.0beta2-3_i386.deb kdebluetooth]

Pour chacun de ces paquets sauf le dernier, vous pouvez ensuite les installer avec la commande :

<code>dpkg -i le_nom_du_paquet.deb</code>

par exemple :

<code>dpkg -i qobex_0.99+1.0beta2-3_i386.deb</code>

kdebluetooth entre en conflit avec un paquet nommé "kdelibs4c2a" et essaie d'écraser des fichiers de localisation. Vous entrerez donc la commande :

<code>dpkg -i --force-overwrite --ignore-depends=kdelibs4c2a kdebluetooth_0.99+1.0beta2-3_i386.deb</code>

=== Scripts ===

Editez /etc/bluetooth/hcid.conf (avec [[Software-soft_edit-vi|vi]], nano, kate ou ce que vous voulez), et modifiez le niveau de sécurité (security level), le code PIN (passkey) et le nom (name). Voici par exemple le contenu de ce fichier chez moi :

<div class="code"><pre>#
# HCI daemon configuration file.
#

# HCId options
options {
# Automatically initialize new devices
autoinit yes;

# Security Manager mode
# none - Security manager disabled
# auto - Use local PIN for incoming connections
# user - Always ask user for a PIN
#
security none;

# Pairing mode
# none - Pairing disabled
# multi - Allow pairing with already paired devices
# once - Pair once and deny successive attempts
pairing multi;

# Default PIN code for incoming connections
passkey "1234";
}

# Default settings for HCI devices
device {
# Local device name
# %d - device id
# %h - host name
name "%h-%d";

# Local device class
class 0x3e0100;

# Default packet type
#pkt_type DH1,DM1,HV1;

# Inquiry and Page scan
iscan enable; pscan enable;

# Default link mode
# none - no specific policy
# accept - always accept incoming connections
# master - become master on incoming connections,
# deny role switch on outgoing connections
lm accept;

# Default link policy
# none - no specific policy
# rswitch - allow role switch
# hold - allow hold mode
# sniff - allow sniff mode
# park - allow park mode
lp rswitch,hold,sniff,park;
}</pre></div>

== premier lancement et tests ==

=== démarrage des services ===

Démarrez :

* les démons (daemons) bluetooth par la commande :

<code>/etc/init.d/bluetooth start</code>

* le bus permettant aux applications de communiquer entre elles :

<code>/etc/init.d/dbus start</code>

* et l'interface bluetooth par :

<code>hciconfig hci0 up</code>

À ce point là, la diode de ma clef USB bluetooth se met à clignoter.

=== tests en ligne de commande ===

Une interface bluetooth est comparable à une interface réseau, avec hciconfig remplaçant ifconfig. En tapant <code>hciconfig</code> dans la console, l'EeePC affiche l'état de l'interface :

<div class="code"><pre>hci0: Type: USB
BD Address: 11:11:11:11:11:11 ACL MTU: 678:8 SCO MTU: 48:10
UP RUNNING PSCAN ISCAN
RX bytes:91 acl:0 sco:0 events:10 errors:0
TX bytes:37 acl:0 sco:0 commands:10 errors:0</pre></div>

De plus, en tapant <code>dmesg</code> pour voir les messages système, entre le branchement de la clef et le lancement des services bluetooth, je vois les lignes suivantes :

<div class="code"><pre>[15968.260000] usb 2-1: new full speed USB device using uhci_hcd and address 2
[15978.430000] usb 2-1: configuration #1 chosen from 1 choice
[15978.570000] Bluetooth: Core ver 2.11
[15978.580000] NET: Registered protocol family 31
[15978.580000] Bluetooth: HCI device and connection manager initialized
[15978.580000] Bluetooth: HCI socket layer initialized
[15978.580000] Bluetooth: HCI USB driver ver 2.9
[15978.590000] usbcore: registered new interface driver hci_usb
[15990.020000] Bluetooth: L2CAP ver 2.8
[15990.020000] Bluetooth: L2CAP socket layer initialized
[15990.050000] Bluetooth: RFCOMM socket layer initialized
[15990.050000] Bluetooth: RFCOMM TTY layer initialized
[15990.050000] Bluetooth: RFCOMM ver 1.8</pre></div>

Nous allons maintenant tester rapidement en ligne de commande, afin de voir que nous voyons et pouvons établir une communication. Activez donc le bluetooth sur votre appareil (téléphone, PDA, clavier...).

Pour celà, nous allons utiliser l'outil <hcitool> :

Regardons d'abord le périphérique local :

<div class="code"><pre>asus-581860474:/home/user> hcitool dev
Devices:
hci0 11:11:11:11:11:11
</pre></div>

Puis cherchons les périphériques bluetooth environnants :

<div class="code"><pre>asus-581860474:/home/user> hcitool inq
Inquiring ...
00:15:DE:04:84:65 clock offset: 0x193a class: 0x520204
</pre></div>

ou avec leur nom :

<div class="code"><pre>asus-581860474:/home/user> hcitool scan
Scanning ...
00:15:DE:04:84:65 Nokia 6111
</pre></div>

Ici on voit le nom de mon téléphone mobile.

Note : les chaînes du type 00:15:DE:04:84:65 s'appellent "l'adresse MAC" du périphérique et l'identifient de façon unique (enfin normalement, car mon adaptateur USB à comme adresse 11:11:11:11:11:11 ce qui ne me semble pas très "unique" ;-)

Enfin, comme avec un réseau filaire ou wifi, on peut faire un "ping" (ping pong entre l'EeePC et le périphérique bluetooth) :

<div class="code"><pre>asus-581860474:/home/user> l2ping 00:15:DE:04:84:65
Ping: 00:15:DE:04:84:65 from 11:11:11:11:11:11 (data size 44) ...
0 bytes from 00:15:DE:04:84:65 id 0 time 30.98ms
0 bytes from 00:15:DE:04:84:65 id 1 time 25.58ms
0 bytes from 00:15:DE:04:84:65 id 2 time 29.55ms
0 bytes from 00:15:DE:04:84:65 id 3 time 11.55ms
0 bytes from 00:15:DE:04:84:65 id 4 time 19.50ms
5 sent, 5 received, 0% loss
</pre></div>
(on arrête en tapant [Ctrl]-[C].)

Cela montre que les 2 périphériques sont prêts à s'échanger des données.

=== tests en mode graphique ===

Vous pouvez maintenant repasser en utilisateur normal (plus besoin de sudo). Ouvrez une nouvelle concole, et tapez : <code>kbluetoothd &</code>. Le logo bluetooth doit apparaître dans la zone de notification de la barre des tâches.

[[Image:Notify_bt.png]]

== automatiser ces commandes ==

== utilisation ==

=== transfert de fichiers ===

=== utiliser le téléphone comme un modem ===

= Copyright =
Copyright © 1/5/2008, Jean-Christophe Cardot
{{CC-BY-SA}}

Bluetooth sur EeePC

2008-05-01T20:40:20Z

Jice (phorum) : /* premier lancement et tests */

Bluetooth sur EeePC

2008-05-01T20:03:05Z

Jice (phorum) :

= Le Bluetooth sur EeePC =

Malheureusement Asus n'a pas cru bon d'installer le nécessaire pour faire du bluetooth simplement avec l'EeePC. Cependant, nous allons y remédier en installant les modules Bluetooth de KDE, KdeBluetooth.

== Installation ==

=== Paquets ===

Il faut déjà récupérer les paquets suivants chez [http://xnv4.xandros.com/xs2.0/upkg-srv2/ Xandros] :
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/k/kdebluetooth/qobex_0.99+1.0beta2-3_i386.deb qobex]
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/libo/libopenobex/libopenobex1_1.3-3_i386.deb libopenobex1]
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/libo/libopenobex/openobex-apps_1.3-3_i386.deb openobex-apps]
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/b/bluez-libs/libbluetooth2_3.7-1_i386.deb libbluetooth2]
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/k/kdebluetooth/kdebluetooth_0.99+1.0beta2-3_i386.deb kdebluetooth]

Pour chacun de ces paquets sauf le dernier, vous pouvez ensuite les installer avec la commande :

<code>dpkg -i le 'nom du paquet'</code>

par exemple :

<code>dpkg -i qobex_0.99+1.0beta2-3_i386.deb</code>

kdebluetooth entre en conflit avec un paquet nommé "kdelibs4c2a" et essaie d'écraser des fichiers de localisation. Vous entrerez donc la commande :

<code>dpkg -i --force-overwrite --ignore-depends=kdelibs4c2a kdebluetooth_0.99+1.0beta2-3_i386.deb</code>

=== Scripts ===

Editez /etc/bluetooth/hcid.conf (avec [[Software-soft_edit-vi|vi]], nano, kate ou ce que vous voulez), et modifiez le niveau de sécurité (security level), le code PIN (passkey) et le nom (name). Voici par exemple le contenu de ce fichier chez moi :

<div class="code"><pre>#
# HCI daemon configuration file.
#

# HCId options
options {
# Automatically initialize new devices
autoinit yes;

# Security Manager mode
# none - Security manager disabled
# auto - Use local PIN for incoming connections
# user - Always ask user for a PIN
#
security none;

# Pairing mode
# none - Pairing disabled
# multi - Allow pairing with already paired devices
# once - Pair once and deny successive attempts
pairing multi;

# Default PIN code for incoming connections
passkey "1234";
}

# Default settings for HCI devices
device {
# Local device name
# %d - device id
# %h - host name
name "%h-%d";

# Local device class
class 0x3e0100;

# Default packet type
#pkt_type DH1,DM1,HV1;

# Inquiry and Page scan
iscan enable; pscan enable;

# Default link mode
# none - no specific policy
# accept - always accept incoming connections
# master - become master on incoming connections,
# deny role switch on outgoing connections
lm accept;

# Default link policy
# none - no specific policy
# rswitch - allow role switch
# hold - allow hold mode
# sniff - allow sniff mode
# park - allow park mode
lp rswitch,hold,sniff,park;
}</pre></div>

== premier lancement et tests ==

= Copyright =
Copyright © 1/5/2008, Jean-Christophe Cardot
{{CC-BY-SA}}

Bluetooth sur EeePC

2008-05-01T20:02:15Z

Jice (phorum) : /* Paquets */

= Le Bluetooth sur EeePC =

Malheureusement Asus n'a pas cru bon d'installer le nécessaire pour faire du bluetooth simplement avec l'EeePC. Cependant, nous allons y remédier en installant les modules Bluetooth de KDE, KdeBluetooth.

== Installation ==

=== Paquets ===

Il faut déjà récupérer les paquets suivants chez [http://xnv4.xandros.com/xs2.0/upkg-srv2/ Xandros] :
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/k/kdebluetooth/qobex_0.99+1.0beta2-3_i386.deb qobex]
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/libo/libopenobex/libopenobex1_1.3-3_i386.deb libopenobex1]
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/libo/libopenobex/openobex-apps_1.3-3_i386.deb openobex-apps]
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/b/bluez-libs/libbluetooth2_3.7-1_i386.deb libbluetooth2]
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/k/kdebluetooth/kdebluetooth_0.99+1.0beta2-3_i386.deb kdebluetooth]

Pour chacun de ces paquets sauf le dernier, vous pouvez ensuite les installer avec la commande :

<code>dpkg -i le 'nom du paquet'</code>

par exemple :

<code>dpkg -i qobex_0.99+1.0beta2-3_i386.deb</code>

kdebluetooth entre en conflit avec un paquet nommé "kdelibs4c2a" et essaie d'écraser des fichiers de localisation. Vous entrerez donc la commande :

<code>dpkg -i --force-overwrite --ignore-depends=kdelibs4c2a kdebluetooth_0.99+1.0beta2-3_i386.deb</code>

=== Scripts ===

Editez /etc/bluetooth/hcid.conf (avec [[Software-soft_edit-vi|vi]], nano, kate ou ce que vous voulez), et modifiez le niveau de sécurité (security level), le code PIN (passkey) et le nom (name). Voici par exemple le contenu de ce fichier chez moi :

<div class="code"><pre>#
# HCI daemon configuration file.
#

# HCId options
options {
# Automatically initialize new devices
autoinit yes;

# Security Manager mode
# none - Security manager disabled
# auto - Use local PIN for incoming connections
# user - Always ask user for a PIN
#
security none;

# Pairing mode
# none - Pairing disabled
# multi - Allow pairing with already paired devices
# once - Pair once and deny successive attempts
pairing multi;

# Default PIN code for incoming connections
passkey "1234";
}

# Default settings for HCI devices
device {
# Local device name
# %d - device id
# %h - host name
name "%h-%d";

# Local device class
class 0x3e0100;

# Default packet type
#pkt_type DH1,DM1,HV1;

# Inquiry and Page scan
iscan enable; pscan enable;

# Default link mode
# none - no specific policy
# accept - always accept incoming connections
# master - become master on incoming connections,
# deny role switch on outgoing connections
lm accept;

# Default link policy
# none - no specific policy
# rswitch - allow role switch
# hold - allow hold mode
# sniff - allow sniff mode
# park - allow park mode
lp rswitch,hold,sniff,park;
}</pre></div>

== premier lancement et tests ==

Bluetooth sur EeePC

2008-05-01T19:56:05Z

Jice (phorum) : /etc/bluetooth/hcid.conf

= Le Bluetooth sur EeePC =

Malheureusement Asus n'a pas cru bon d'installer le nécessaire pour faire du bluetooth simplement avec l'EeePC. Cependant, nous allons y remédier en installant les modules Bluetooth de KDE, KdeBluetooth.

== Installation ==

=== Paquets ===

Il faut déjà récupérer les paquets suivants chez [http://xnv4.xandros.com/xs2.0/upkg-srv2/ Xandros] :
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/k/kdebluetooth/qobex_0.99+1.0beta2-3_i386.deb qobex]
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/libo/libopenobex/libopenobex1_1.3-3_i386.deb libopenobex1]
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/libo/libopenobex/openobex-apps_1.3-3_i386.deb openobex-apps]
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/b/bluez-libs/libbluetooth2_3.7-1_i386.deb libbluetooth2]
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/k/kdebluetooth/kdebluetooth_0.99+1.0beta2-3_i386.deb kdebluetooth]

Pour chacun de ces paquets sauf le dernier, vous pouvez ensuite les installer avec la commande :

<code>dpkg -i <le nom du paquet></code>

par exemple :

<code>dpkg -i qobex_0.99+1.0beta2-3_i386.deb</code>

kdebluetooth entre en conflit avec un paquet nommé "kdelibs4c2a" et essaie d'écraser des fichiers de localisation. Vous entrerez donc la commande :

<code>dpkg -i --force-overwrite --ignore-depends=kdelibs4c2a kdebluetooth_0.99+1.0beta2-3_i386.deb</code>

=== Scripts ===

Editez /etc/bluetooth/hcid.conf (avec [[Software-soft_edit-vi vi]], nano, kate ou ce que vous voulez), et modifiez le niveau de sécurité (security level), le code PIN (passkey) et le nom (name). Voici par exemple le contenu de ce fichier chez moi :

<pre>#
# HCI daemon configuration file.
#

# HCId options
options {
# Automatically initialize new devices
autoinit yes;

# Security Manager mode
# none - Security manager disabled
# auto - Use local PIN for incoming connections
# user - Always ask user for a PIN
#
security none;

# Pairing mode
# none - Pairing disabled
# multi - Allow pairing with already paired devices
# once - Pair once and deny successive attempts
pairing multi;

# Default PIN code for incoming connections
passkey "1728";
}

# Default settings for HCI devices
device {
# Local device name
# %d - device id
# %h - host name
name "%h-%d";

# Local device class
class 0x3e0100;

# Default packet type
#pkt_type DH1,DM1,HV1;

# Inquiry and Page scan
iscan enable; pscan enable;

# Default link mode
# none - no specific policy
# accept - always accept incoming connections
# master - become master on incoming connections,
# deny role switch on outgoing connections
lm accept;

# Default link policy
# none - no specific policy
# rswitch - allow role switch
# hold - allow hold mode
# sniff - allow sniff mode
# park - allow park mode
lp rswitch,hold,sniff,park;
}</pre>

== premier lancement et tests ==

Bluetooth sur EeePC

2008-05-01T19:47:49Z

Jice (phorum) : installation

= Le Bluetooth sur EeePC =

Malheureusement Asus n'a pas cru bon d'installer le nécessaire pour faire du bluetooth simplement avec l'EeePC. Cependant, nous allons y remédier en installant les modules Bluetooth de KDE, KdeBluetooth.

== Installation des paquets ==

Il faut déjà récupérer les paquets suivants chez [http://xnv4.xandros.com/xs2.0/upkg-srv2/ Xandros] :
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/k/kdebluetooth/qobex_0.99+1.0beta2-3_i386.deb qobex]
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/libo/libopenobex/libopenobex1_1.3-3_i386.deb libopenobex1]
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/libo/libopenobex/openobex-apps_1.3-3_i386.deb openobex-apps]
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/b/bluez-libs/libbluetooth2_3.7-1_i386.deb libbluetooth2]
* [http://xnv4.xandros.com/xs2.0/upkg-srv2/pool/main/k/kdebluetooth/kdebluetooth_0.99+1.0beta2-3_i386.deb kdebluetooth]

Pour chacun de ces paquets, vous pouvez ensuite les installer avec la commande :

<code>dpkg -i '''le nom du paquet'''</code>

Sauf kdebluetooth, qui entre en conflit avec un paquet nommé "kdelibs4c2a" et essaie d'écraser des fichiers de localisation. Vous entrerez donc la commande :

<code>dpkg -i --force-overwrite --ignore-depends=kdelibs4c2a kdebluetooth_0.99+1.0beta2-3_i386.deb</code>

Soyez SMART

2006-04-06T16:42:09Z

Jice (phorum) : /* Configuration de smartd */ correction de tag mal fermé + tableau

[[Category:Les plus du matériel]]
= Soyez Smart ! =

<div class="leatitre">Soyez Smart !</div><div class="leapar">par [mailto:pubz@free.fr Erwan]<br />

On entend très souvent à grand coup de publicité que la toute dernière technologie va vous simplifier la vie et rendre votre ordinateur plus fiable et tout cela bien sûr, à un coût non négligeable. Et pourtant il existe des technologies déjà largement diffusées mais méconnues qui peuvent vous aider à fiabiliser votre ordinateur.

</div>

== La mauvaise aventure ==

Elle est malheureusement classique, arrive tous les jours et provoque larmes, crises de nerfs et déceptions. La perte d'un disque dur est toujours un moment pénible. Il contenait bien évidement « LE » dossier à rendre demain, les photos de votre famille, votre configuration réalisée pendant vos week-ends au prix de longues heures de travail, votre musique, vos meilleurs scores à Frozen Bubble, etc...

Ce problème devient d'autant plus important que la taille des disques augmente de manière considérable. Il est aujourd'hui, en mars 2005, classique de posséder un disque d'une capacité allant de 80 à 160 Giga-octets ! Les derniers modèles atteignent même la barre des 400 Go. La conséquence est simple à comprendre et elle sera de plus en plus courante : on possède de très grosses capacités de stockage donc on y stocke énormément de données. Si le disque est amené à tomber en panne la quantité d'informations perdues est gigantesque. Le temps nécessaire au redémarrage d'une machine identique en sera d'autant plus long, voire impossible !

== Les solutions classiques ==

Une fois que cette mauvaise aventure vous est arrivée, la question qui vient rapidement c'est : comment faire pour que cela ne se reproduise pas ?

Plusieurs solutions s'offrent à vous :

# installer un système de disque RAID sur votre machine
# acheter un deuxième disque dur sur lequel on placera les sauvegardes

La première solution vous permet de créer un miroir d'un disque sur un autre (RAID 1), ou une répartition des données sur plusieurs disques avec un contrôle de parité pour retrouver l'information manquante en cas de panne d'un des disques (RAID 3 et 5). Ceci peut être réalisé soit de manière logicielle, soit de manière matérielle : dans ce cas, il faudra donc prévoir l'achat d'une carte spécialisée.

Le RAID logiciel ne permet pas de bonnes performances en RAID 3 et 5 car le contrôle de parité est réalisé par votre processeur. Cette solution ne permet pas non plus une grande qualité de service car seules les partitions de données sont prises en comptes et non l'ensemble du disque comme le fait un RAID matériel. Le secteur d'amorçage, par exemple, n'est pas dupliqué, le redémarrage en cas de défaillance du disque primaire risque d'être compliqué.

La solution de sauvegarde sur un autre disque nécessite soit de prendre une bonne habitude de sauvegarde manuelle, soit la mise en place de scripts ou d'applications spécialisées pour assurer une bonne cohérence entre les deux disques dur. Cette méthode fonctionne très bien mais attention à la fiabilité du disque de sauvegarde.

== Petit rappel sur la fiabilité des disques durs ==

Ces solutions restent fiables modulo le type de disque dur utilisé : la loi des séries existe et il faut s'en méfier.

Les disques durs d'une même série sont un mélange de mécanique et d'électronique montés à la chaîne dans des conditions identiques. Un exemple valant mieux qu'un long discours, voici un exemple de ce qui peut arriver : un administrateur système monte un RAID 1 matériel. Deux disques durs, de même marque, même modèle, sont donc installés dans cette machine. Il fait sa configuration, met sa machine en production. Il peut se reposer sur la technologie RAID pour compenser la panne possible d'un des deux disques durs. Oui, mais ce modèle de disque dur a eu un taux de retour de 25% en usine à cause d'un défaut de série.

L'administrateur a bien eu une panne sur son premier disque, il le retire et prépare son remplacement par un nouveau le plus rapidement possible. Il n'aura pas eu le temps de le faire car le second possédant le même défaut est tombé également en panne. Le résultat est simple, il a tout perdu et le RAID n'y peut rien. Même avec un RAID 5, il est quasi impossible de faire face à une série aussi rapide de pannes !

Cette petite histoire nous rappelle qu'un disque dur reste un élément fragile dans un ordinateur et représente la pièce la plus faible de celui-ci car elle contient de la mécanique qui reste nettement moins fiable que l'électronique.

Cependant plutôt que d'être mis devant le fait accompli d'un disque inutilisable, une autre approche est possible.

Mieux vaut prévenir que guérir.

Ce vieil adage amène les questions suivantes :

* « Ne pourrais-je pas anticiper la panne de mon disque ? »
* « N'y a-t-il pas un moyen de connaître l'état d'usure d'un disque dur ? »

En effet, si nous étions capable de connaître l'état d'usure d'un disque dur, cela nous permettrait d'anticiper une panne liée à l'usure (prématurée ou pas) de celui-ci. La technologie SMART (Self-Monitoring, Analysis and Reporting Technology systems) permet de connaître et d'analyser l'état physique de vos disques durs. Elle est disponible sur les disques dur IDE depuis la fin des années 90 et pourtant très peu de personnes en connaissent l'existence. Preuve de la méconnaissance de cette technologie, la plupart des administrateurs systèmes et réseaux ne savent pas qu'un tel outil peut les aider à gérer leur parc informatique (serveurs et/ou postes de travail). SMART n'est pas une technologie « super-héros », elle ne peut pas ressusciter un disque dur cassé ou empêcher celui-ci de tomber en panne. Une panne matérielle violente liée à une sur-tension, ou à un choc violent sera difficilement prévisible. Néanmoins, même si du point de vue de l'utilisateur un disque dur donne l'impression de tomber en panne brutalement, un certain nombre de signes d'usure sont déjà présents et leur observation permet de prévoir qu'une panne va « bientôt » survenir. La vitesse de rotation du plateau, la hauteur de la tête de lecture, le temps de positionnement de la tête, les taux d'erreurs de lecture/écriture sont autant d'informations utiles pour analyser l'état de santé d'un disque.

SMART n'est pas non plus une technologie « madame soleil », elle n'est pas capable de vous indiquer que votre disque dur va casser le 18 février à 15h30 et 10 secondes. Elle peut juste vous indiquer qu'un élément de votre disque dur se dégrade trop rapidement et que cela peut causer une panne dans les quelques jours/semaines à venir. Mais préfère-t-on sauvegarder les données de ce disque vers un disque neuf même si celui-ci fonctionne encore ou attendre que le disque soit définitivement cassé pour se dire « Ah oui, j'aurais peut-être dû faire une sauvegarde » .

Le cas extrême est d'acheter un disque dur neuf, d'effectuer un test SMART dessus et de se rendre compte que celui-ci annonce déjà une panne probable. Les causes sont multiples (mauvais transport, mauvais stockage, défaut de fabrication) mais on peut se dire que sur un disque neuf, la panne se ne produira pas tout de suite. On peut faire ce pari mais il y a de fortes chances que quelques semaines après, les premiers fameux « I/O errors » apparaissent et il faudra donc changer le disque dans l'urgence. La règle d'or est donc « Mieux vaut prévenir que guérir », il est donc impératif de changer un disque qui annonce une panne prochaine même si celui n'est pas très vieux ou s'il fonctionne encore bien. Les éléments d'usure observés par SMART et leur conséquences sur le fonctionnement du disque sont complètement invisibles et inaccessibles à l'utilisateur. Si vous attendez de vous rendre compte d'une panne sur votre disque pour le changer, dîtes-vous que ce sera déjà trop tard.

== Fonctionnement de SMART ==

SMART définit un protocole de communication via les canaux IDE/SCSI entre un disque dur et une application. Celui-ci peut interroger un disque afin d'obtenir une liste d'attributs (une caractéristique physique) et les valeurs associées. Le disque dur s'auto-teste de manière autonome à la demande de l'utilisateur. Les performances seront certes un peu inférieures pendant la durée de ce test mais le disque dur restera fonctionnel. Le test n'est pas bloquant pour le système d'exploitation ou l'utilisateur. La liste d'attributs est commune à l'ensemble des constructeurs mais cela n'empêche pas ces derniers d'en implémenter d'autres qui leur sont spécifiques et bien sûr non documentées.

Certains constructeurs de disques durs vous proposent de télécharger un logiciel pour tester votre disque dur avant de le renvoyer en « Service Après Vente » . Bien entendu, ce logiciel n'est ni plus ni moins qu'une application qui va exécuter des tests puis lire les informations SMART de votre disque dur mais il est probable que cette application utilise également les attributs spécifiques de la marque.

=== Les attributs SMART ===

Voici la liste des attributs habituels que l'on trouve sur un disque dur :

{| width="80%"
| '''Nom de l'attribut'''
| '''Rôle'''
|-
| <code>Raw_Read_Error_Rate</code>
| Fréquence d'apparition d'erreurs pendant la lecture de données brutes
|-
| <code>Spin_Up_Time</code>
| Temps de mise en rotation du disque
|-
| <code>Start_Stop_Count</code>
| Nombre de cycles arrêt/démarrage de l'axe de rotation
|-
| <code>Reallocated_Sector_Ct</code>
| Nombre de secteurs ré-alloués
|-
| <code>Seek_Error_Rate</code>
| Fréquence d'erreurs pendant le positionnement de la tête magnétique
|-
| <code>Power_On_Hours</code>
| Nombre d'heures de fonctionnement
|-
| <code>Spin_Retry_Count</code>
| Nombre de mises en rotation forcée du disque
|-
| <code>Power_Cycle_Count</code>
| Nombre de cycles de mise sous tension
|-
| <code>Temperature_Celsius</code>
| Température interne du disque en degrés Celsius
|-
| <code>Hardware_ECC_Recovered</code>
| Nombre de corrections ECC réalisées
|-
| <code>Current_Pending_Sector</code>
| Nombre de secteurs en attente de ré-allocation
|-
| <code>Offline_Uncorrectable</code>
| Nombre de secteurs non ré-allouables
|-
| <code>UDMA_CRC_Error_Count</code>
| Nombre d'erreurs de CRC pendant un accès Ultra DMA
|}

Une liste plus exhaustive des attributs est disponible sur ce site : http://smartlinux.sourceforge.net/smart/attributes.php Chaque constructeur de disque dur implémente un composant électronique responsable de la surveillance de ces valeurs et de les rendre accessibles via le protocole SMART.

Voici un exemple de valeurs:

=== Analyse des valeurs ===

A chaque attribut est associé un type, un mode de mise à jour, une valeur brute (RAW), une valeur WORST, une valeur THRESH, une valeur VALUE.

La valeur brute représente la valeur mesurée de l'attribut. Dans le cas de l'attribut « Temperature », elle représente la température du disque dur.

VALUE représente un indice de fiabilité actuelle de cet attribut. THRESH, représente la valeur limite avant une dégradation des performances et un risque de panne élevé : si l'indice VALUE est inférieur ou égal à l'indice THRESH alors le disque risque de tomber en panne. WORST représente la plus petite valeur de VALUE enregistrée.

Les valeurs de THRESH sont décidées par le constructeur du disque dur pour un modèle donné. Ces valeurs peuvent donc changer en fonction des configurations.

Le type d'attribut <code>Old-age</code> indique que si l'indice VALUE est inférieur à THRESH alors cela indique que le produit est en fin de vie du fait d'une usure normale. L'attribut <code>Pre-Fail</code> indique que si l'indice VALUE est inférieur à THRESH alors une panne est imminente, il faut prévoir un remplacement.

Il existe deux méthodes pour mettre à jour les valeurs des attributs. La première dite « always » est la plus commune. Le composant électronique observe en permanence cet attribut. A chaque consultation de l'attribut, on peut y lire la valeur en cours. Ainsi, la température, le nombre d'erreurs ECC sont à jour en permanence. Les attributs dits « offline » ne seront remis à jour que lors d'un test du disque avec l'un des quatre modes : offline, short, long, conveyance.

Le champ WHEN_FAILED indique la probabilité de panne :

* « FAILING_NOW » indique une panne imminente,
* « In_the_past » indique de l'indice VALUE est déjà passé une fois sous la valeur THRESH : il faudra surveiller ce disque de près.

L'absence de valeur indique que le disque fonctionne normalement.

La lecture des attributs est assez fastidieuse. Pour cela, les outils de la suite smartmontools vont nous permettre de consulter, d'analyser et d'intervenir en cas de nécessité.

== Utilisation de smartmontools ==

Il existe plusieurs implémentations d'outils permettant la consultation des attributs SMART.

Dans le cadre de cet article, nous utiliserons smartmontools car il est aujourd'hui sous Linux l'outil le plus complet et le plus à jour. Mais il est également disponible dans sa version Windows, OpenBSD, NetBSD, FreeBSD, OS/2 (à partir de la 5.34), Mac OSX (sauf SCSI). Cependant, les concepts et les lignes de commandes qui vont être expliqués dans cette partie doivent être facilement adaptables à d'autres outils SMART.

Installez smartmontools sur votre système à l'aide d'urpmi si vous êtes sur Mandrakelinux, apt si vous êtes sous Debian ou téléchargez la dernière version de smartmontools sur http://smartmontools.sf.net puis compilez et installez la sur votre système.

La version 5.33 est utilisée dans cet article, certaines fonctionnalités ne sont disponibles que depuis la 5.30.

L'outil smartctl vous permet maintenant de consulter les attributs SMART de vos disques durs. Tout d'abord, nous devons nous assurer que la partie SMART de votre disque dur est active. Certains BIOS possèdent une option en relation avec SMART : celle-ci permet généralement de vérifier rapidement que le disque dur ne présente pas de risque de panne élevé avant le démarrage de la machine. Dans ce cas, le BIOS bloque la procédure. Certains BIOS activent également avec cette option le contrôleur SMART du disque, mais ce n'est pas toujours le cas. Il est donc préférable de le faire manuellement : une seule fois suffit durant la vie du disque.

La commande suivante vous permet d'activer SMART, de sauvegarder automatiquement la sauvegarde des attributs ainsi que la mise à jour automatique des attributs « offline » du disque.

<div class="code">

[root@] smartctl --smart=on --offlineauto=on --saveauto=on /dev/hdx

</div>

Il est à noter que, dans tous les exemples, la lettre « x » de /dev/hdx devra être remplacée par la lettre correspondant *à votre disque dur.

Le résultat suivant vous indique que SMART est maintenant bien activé et qu'une mise à jour des attributs « offline » sera effectuée toutes les quatre heures (cette valeur dépend du modèle et de la marque de votre disque dur).

<div class="code">

=== START OF ENABLE/DISABLE COMMANDS SECTION ===
SMART Enabled.
SMART Attribute Autosave Enabled.
SMART Automatic Offline Testing Enabled every four hours.
Vous pouvez consulter la liste des attributs ainsi que leurs valeurs à l'aide de l'option « -A » .
[root@] smartctl -A /dev/hdx
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 28
194 Temperature_Celsius 0x0022 043 046 000 Old_age Always - 43
Dans cet exemple, on peut voir que le disque a déjà subi 28 cycles d'allumage et que sa température actuelle est de 43° celsius.
Vous pouvez également déclencher manuellement un test court avec la commande suivante:
[root@] smartctl -t short /dev/hdx
Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 1 minutes for test to complete.
Test will complete after Wed Feb 18 11:51:46 2004

</div>

La durée des tests de type short, long et conveyance est définie dans la mémoire du disque lui-même, vous ne pouvez pas modifier cette valeur.

Une fois le test terminé, vous pouvez consulter le résultat du test à l'aide de l'option « -l » de smartctl. Cette option va lire dans la mémoire de votre disque (si celui-ci le permet) les traces (log) des dernières opérations réalisées sur celui-ci.

<div class="code">

<nowiki>[root@] smartctl -l selftest /dev/hdx
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 4913 -
# 7 Short offline Aborted by host 40% 595 -</nowiki>

</div>

Dans cet exemple, le test 1 (le dernier que l'on vient d'exécuter), de type test court, s'est déroulé sans erreur, votre disque est donc en bon état.

Le test 7 montre que l'utilisateur a interrompu le test à l'aide de l'option<code> -X</code>.

Ces quelques commandes vous permettent assez simplement de vérifier l'état de votre disque dur, mais tout ceci nécessite une exécution manuelle de l'outil. L'automatisation de ce processus est bien entendu nécessaire et obligatoire pour obtenir une surveillance permanente de vos disques durs.

Le démon smartd le permet, avec une remontée d'erreurs selon la méthode qui vous convient le mieux. Si smartmontools détecte une erreur dans les attributs ou lors d'un test alors celui peut déclencher une action pour vous prévenir : envoyer un mail, un sms, ou même afficher un « wall » sur la machine.

=== Configuration de smartd ===

smartmontools fournit le démon smartd dont le fichier de configuration est /etc/smartd.conf. Celui-ci dispose d'une syntaxe assez simple. Nous allons configurer celui-ci pour émettre un mail en cas de problème.

<div class="code">

DEVICESCAN -H -l error -l selftest -t -m a@a.com -M exec /bin/mail -s (S/../.././02|L/../../6/03)

</div>

La directive DEVICESCAN indique que l'on souhaite appliquer cette configuration à tous les disques dur détectés comme compatible SMART sur le système. Elle peut-être remplacée par le nom d'un périphérique (/dev/hdx, /dev/sdx, ...). L'ajout de cette ligne dans le fichier de configuration permet d'émettre un email à a@a.com en utilisant la commande mail de votre système.

L'option <code>-t</code> indique que nous souhaitons être informé au cas où l'attribut « Pre-Fail » ou « Old-age » présente des erreurs, si le test de santé (option <code>-H</code>) échoue ou si les journaux d'erreurs error et selftest évoluent (-l). On peut choisir parmi un panel d'options afin d'ajuster au mieux en fonction de ses besoins. On peut par exemple décider d'ignorer volontairement un attribut à l'aide de l'option <code>-I</code>. L'ajout de l'option -I 194 indique que nous souhaitons recevoir un mail en cas de panne mais en ignorant l'attribut numéro 194 (la température).

L'option -s permet de définir la périodicité des tests à réaliser ( version >5.30 nécessaire). Dans cet exemple, nous réalisons un test court (S/) tous les jours à 2 heures du matin, et un test long tous les samedi à 3 heures du matin. Il est également possible de modifier le mail qui sera envoyé par smartd en cas de panne. Il suffit de créer un script qui sera appelé à la place de <code>/bin/mail</code>.

<div class="code">

/dev/hdx -a -m admin@mondomain.com -M exec /usr/local/bin/report_smart

</div>

Voici le contenu de <code>/usr/local/bin/report_smart</code>

<div class="code">

<nowiki>#! /bin/bash
# Sauvegarde du corps de mail standard
cat > /root/smartmail
# On ajoute le résultat de « smartctl -a » dans le corps de mail
/usr/sbin/smartctl -a -d $smartd_DEVICETYPE $smartd_DEVICE >> /root/smartmail
# On émet le mail
/bin/mail -s "$smartd_SUBJECT" $smartd_ADDRESS < /root/smartmail
rm -f /root/smartmail</nowiki>

</div>

Les scripts appelés par smartd peuvent faire référence à 9 variables d'environnement (voir le man pour plus de détails):
{|
! Variable
! Rôle (valeur par défaut)
|-
| smartd_MAILER
| Argument de -M exec (/bin/mail)
|-
| smartd_DEVICE
| Périphérique en cause, /dev/hdx, ...
|-
| smartd_DEVICETYPE
| Type de périphérique : ata, scsi, 3ware
|-
| smartd_DEVICESTRING
| Idem sauf pour les raid 3ware
|-
| smartd_FAILTYPE
| Raison de l'alerte
|-
| smartd_ADDRESS
| Destinataire du mail
|-
| smartd_MESSAGE
| Corps du message d'alerte
|-
| smartd_TFIRST
| Date et heure de la première erreur
|-
| smartd_TFIRSTEPOCH
| Nombre de secondes depuis 1970
|}

Il est à remarquer que l'option « -m » permet d'ajouter des destinataires pour l'email d'alerte mais que celle-ci peut être positionnée sur « nomailer » dans le cas d'exécution d'un simple script, exemple:

<div class="code">

/dev/hdx -a -m <nomailer> -M exec /usr/local/bin/wall_smart

</div>

Voici le contenu de <code>/usr/local/bin/wall_smart</code>

<div class="code">

<nowiki>#! /bin/bash
# Avertir les utilisateurs de la machine
wall 'Problem detected with disk: ' "$smartd_DEVICESTRING"
wall 'Warning message from smartd is: ' "$smartd_MESSAGE"
wall 'Shutting down machine in 60 seconds... '
# Arrêter la machine
/sbin/shutdown -t 60 -h</nowiki>

</div>

Avec ces quelques exemples, il est facile de modifier la décision à prendre en cas de panne prévue d'un disque. A vous de choisir la solution qui vous convient le mieux (mail, sms, wall, etc..).

== Comment démarrer SMART pour diagnostiquer une panne ? ==

Cet exemple est inspiré d'un cas réel et permet de comprendre concrètement comment SMART peut aider au diagnostic d'une machine en panne. Une machine vient de « planter » et le redémarrage semble impossible car il provoque des « I/O errors » et la réparation du système de fichiers est excessivement lente.

La machine n'utilisait pas SMART donc on ne peut pas savoir si une panne du disque dur était prévisible. Il faut donc tester dans un premier temps l'état du disque dur sans utiliser le disque de celle-ci. Il faut éviter au maximum d'utiliser le disque dur afin de ne pas le détériorer. Ce test permettra de s'assurer que c'est bien une panne matérielle et non logicielle (système de fichiers corrompu).

Le projet smartlinux (http://smartlinux.sf.net) intègre sur une disquette, tous les outils nécessaires au diagnostic et la réparation du disque dur. Naturellement, smartmontools 5.33 est disponible sur smartlinux 0.4. Deux solutions sont disponibles, utiliser une disquette 1.44MB ou utiliser PXE.

Téléchargez smartlinux 0.4 sur le site du projet puis installez-le sur une disquette grâce à l'utilitaire « dd » sous Linux ou rawwrite sous Microsoft Windows. Démarrez l'ordinateur en panne avec la disquette. Attention les lecteurs de disquette USB ne sont pas supportés.

L'autre solution, consiste à utiliser PXE (Pre eXecution Environment) qui permet de démarrer un système d'exploitation via le réseau. Cette solution, permet de rendre accessible à toutes les machines d'un réseau possédant un serveur PXE l'exécution de smartlinux sans utiliser de disquette. Copiez smartlinux dans le répertoire TFTP de Pxelinux (/var/lib/tftpboot/X86PC/linux). Pour plus d'informations à propos de PXE vous pouvez consulter la documentation disponible sur http://clic.mandriva.com/documentation/pxe/.

La configuration du serveur PXE nécessite une petite astuce dans le fichier de configuration de Pxelinux (Pxelinux.cfg) qui consiste à charger smartlinux comme kernel et comme initrd.

<div class="code">

label smart
KERNEL smart-0.4.dsk
APPEND initrd=smart-0.4.dsk root=/dev/ram

</div>

Une fois smartlinux démarré par PXE ou par disquette, vous pouvez utiliser « smartctl » comme décrit dans cet article. On pourra réaliser une analyse de l'état du disque avec l'option <code> -A</code> puis le tester avec l'option <code>-t short</code> ou <code>-t long</code>. Une fois le test terminé, l'option <code>-l selftest</code> vous permet de consulter le résultat du test. smartlinux possède également d'autres outils pour réparer les disques (dd_rescue, disc-recovery-utils, disktype, e3, fwipe, magicrescue, rescuept, wipe). Pour plus d'informations sur ces outils, consultez les documentations respectives de ces outils (http://smartlinux.sourceforge.net/#packages).

== SMART et les disques SCSI ==

Les jeux de commande SCSI sont disponibles sur plusieurs couches de transport : SCSI Parallel Interface (SPI), Fibre Channel (FCP), Serial Attached SCSI (SAS), IEEE1394 (SBP) et USB (mass storage).

Les couches de transport SAS ou SPI (celles que l'on utilise sur un système carte SCSI + disque SCSI interne), permettent également l'utilisation du jeu de commande ATA : celui de vos disques IDE.

Ainsi une commande émise via la couche SAS, atteint le périphérique qui la traduit dans son équivalent ATA. Cette traduction est parfois uniquement réduite aux demandes de lecture et d'écriture. Certains périphériques ne supportent donc pas les commandes SMART, ce sera le cas des périphériques connectés via le port USB.

Le protocole SMART n'est pas normalisé mais est intégré sous différentes formes dans les normes ATA et SCSI. SMART était initialement développé sur les disques SCSI sous forme d'extensions propriétaires. Les constructeurs intègrent aujourd'hui le protocole défini par la norme mais aussi leurs extensions spécifiques pas toujours documentées. La norme SMART intégrée à SCSI étant plus limitée que celle implémentée dans ATA, les attributs seront moins nombreux et certains spécifiques au SCSI. Ainsi on pourra consulter, la marque, le modèle et le numéro de série du disque dur, sa température.

On pourra également consulter le nombre d'erreurs mineures et majeures générées, le nombre d'erreurs corrigées et incorrigibles ainsi que la taille des données qui ont transité sur le disque. Il est a noter que le nombre d'erreurs mineures peut augmenter assez vite car le disque en optimisant les accès aux données produit quelques fautes de positionnement qu'il corrige aussitôt.

Les commandes ainsi que les configurations de smartmontools ne diffèrent pas entre un système de disque ATA et un système de disque SCSI.

== SMART et les systèmes RAID matériels ==

Une carte RAID se comporte comme un périphérique SCSI ou ATA qui retranscrit les commandes qu'elle reçoit vers son bus interne. Les disques connectés à la carte RAID ne sont donc pas accessibles directement, ils sont masqués par celle-ci. Il n'est pas pas possible d'adresser directement à un disque une commande SMART.

Les disques d'un système RAID sont soumis aux mêmes risques de pannes qu'un disque isolé : une panne dégrade les performances d'un volume RAID, plusieurs peuvent atteindre à l'intégrité de celui-ci. Puisque les disques sont masqués, il n'est pas possible d'utiliser les informations SMART des disques pour prévenir les pannes et planifier les interventions. L'utilisateur ou l'administrateur sera donc mis devant le fait accompli, il devra attendre que le volume RAID soit en mode dégradé à cause de la perte d'un disque pour pouvoir prévoir son intervention.

Cependant, certaines marques implémentent un protocole permet de transmettre les commandes SMART vers les disques qui composent le volume RAID. Les cartes 3ware par exemple, permettent de créer des volumes RAID SCSI avec des disques IDE, le pilote permet ensuite à SMART l'accès aux disques réels.

Le premier volume RAID composé par exemple de 3 disques IDE sera disponible en tant que disque SCSI nommé /dev/sda, le second volume RAID /dev/sdb etc...

La commande <code>smartctl -a -d 3ware,n /dev/sda</code> permet d'adresser la commande SMART au nième disque réel du premier volume RAID (nommé /dev/sda). Dans cet exemple, « n » pourra prendre les valeurs 0,1,2. La valeur 0 correspond au premier disque IDE du volume.

Avec ce type de carte RAID, il est donc possible de surveiller l'état des disques qui composent le volume RAID afin d'en prévenir les pannes.

== Conclusion ==

La technologie SMART permet la prévision des pannes liées à l'usure des disques durs mais ne doit pas empêcher les stratégies de sauvegarde. Ce n'est qu'un outil de plus pour faciliter l'administration et le diagnostic des machines.

Les ordinateurs portables et les serveurs sont des plate-formes de choix pour SMART. Un portable étant souvent déplacé, secoué, il est soumis de fait aux risques de chocs et donc de pannes. Le serveur est quant à lui indispensable au bon fonctionnement d'une entreprise, tout arrêt non planifié de celui-ci peut avoir des conséquences importantes. SMART vous permet donc d'anticiper et de planifier le remplacement de vos disques dur sans être mis devant le fait accompli. Un outil vraiment indispensable pour tout le monde.

J'espère avoir contribué à la diffusion de cette technologie trop méconnue et sous-utilisée alors que déjà bien diffusée.

Je voudrais remercier Bruce Allen pour smartmontools, Zbigniew Chlondowski pour smartlinux ainsi que pour son site rempli d'informations utiles sur SMART, à Christophe Guittenit pour ses explications précieuses, Anne pour ses relectures, ses commentaires et son sang froid sur mes fautes d'orthographes et de grammaire, ainsi que tout ceux qui m'encouragent à écrire mes articles.

<div class="merci">Cette page est issue de la documentation 'pré-wiki' de Léa a été convertie avec HTML::WikiConverter. Elle fut créée par Erwan le 30/03/2005.</div>

= Copyright =
Copyright © 30/03/2005, Erwan
{{CC-BY-NC-SA}}