Accueil > hack, Linux > I love it when a plan comes together

I love it when a plan comes together

Quand je trouve du bon matériel je share … La il s’agit d’un Nas entrée de gamme de chez Qnap le Ts212

Qnap TS212


Je cite le fabriquant quand à leur politique d’ouverture :
«La dernière distribution Debian Lenny supporte maintenant pleinement notre TS-109, TS-209, TS-409 et la série TS-409U Turbo NAS. Comme Debian est la seule distribution Linux qui soutient activement la plate-forme ARM ainsi que son rôle de système de gestion de paquets APT qui fournit plus de 10000 logiciels. QNAP a vu sa communauté d’ouvrir au monde et le réservoir potentiel d’applications et d’utilisations que nous pourront apporter à nos Nas. Nous avons décidé de soutenir les efforts visant à ajouter Debian pour les dispositifs basés sur le Marvell Orion SoC, le processeur utilisé par l’ensemble de nos ARM à base de produits de NAS. Il peut également servir d’alternative à la norme firmware pour offrir à nos utilisateurs plus de compétitivié et maximiser l’utilisation de leur NAS.
Il y a un intérêt considérable pour les utilisateurs d’installer Linux dans un NAS , car il peut être utilisé comme un puissant et serveur personnalisable. Ils veulent un système Linux complet qui leur permet d’installer facilement des logiciels supplémentaires et de modifier l’environnement. Debian est une choix idéal pour ces utilisateurs, car elle soutient la plate-forme ARM, qui est très mature et robuste.

Bon tout est dit , bon dieu que ce fait du bien à entendre quand même … Allez on y va !!!

Tout d’abord un aperçu sur le matériel embarqué:
Proc Arm Marvell 6281 1.2GHz
256MB DDRII RAM
16 MB de flash
1 port Lan Gigabit
3 x USB2 port
2 x 3.5″ SATA I/II les disques sont non fournis
2 x UART dont 1 avec connecteur sur la carte mère
1 x ventilateur
des leds et 2 boutons en facade.
Pour les disques ,j’ai acheté ça .
Le boitier est sobre, de petite taille, et assez élégant avec son look de grille pain. Petit regret tout de même, sur l’impossibilité du wake on Lan sur l’interface réseau c’est dommage. De même pour la ram, c’est un peu light (256 Mo). Pour mon usage (rsync, unison, nfs) c’est largement suffisant mais il est sur que pour les utilisateurs voulant utiliser leur Nas pour des applications gourmandes (encodage à la volée pour du Streaming vidéo par ex) ça risque de faire un petit peu juste. Cependant, il vous suffit de passer aux gammes supérieures pour adapter le matériel à votre usage et pour cela l’offre commerciale est bien étoffée.
Avant de flasher le Nas, j’ai observé le firmware d’origine qui est très complet et qui repose sur une base de logiciel libre (mais pas seulement), en voila un petit aperçu:

généralités:
————–
bootloader uboot (dans la flash)
noyau Linux version 2.6.33.2 (dans la flash)
gcc version 4.2.1
busybox
gestion du raid par mdadm
support de ext3 ~ ext4
support ipv6
controle smart
support isci
support ldap
support SNMP
NFS
SMB
appletalk
admin par ssh / telnet
service UPNP / Bonjour

serveurs d’applications:
————————
mysql
radius
syslog
rsync
http
webdav
antivirus avec clamav
serveur tftp
serveur itunes (non libre)
serveur multimedia twonkymediaserv (non libre)
serveur d’impression cups
service time machine pour Mac OSX (non libre ?)

plateforme de telechargement:
—————————–
http/ftp/Rapidshare
bittorent

On trouve même du cloud … Mais bon comme disait Lefinnois « vas mourir avec ton nuage loin et en silence »
Pour compléter le tout, précisons la possibilité de plugin sous forme de paquets ipkg avec un choix intéressant d’applications.
A ce jour, c’est vraiment le firmware le plus complet que j’ai vu pour cette catégorie de matériel (entrée de gamme). A noter aussi la cohérence dans le choix des systèmes de fichiers utilisés et dans le support du raid par mdadm. En effet, il y a trop de matériel lié à des solutions obscures (autant sur le raid que sur les systèmes de fichier). Dans ce cas, l’utilisateur est pieds et mains liées au fabriquant du Nas et l’intérêt d’utiliser celui-ci pour un système de sauvegarde devient non fondé. Que faire des données de ses disques quand le matériel rend l’âme et que le fabriquant ne supporte plus la technologie ou pire, quand le fabriquant disparaît. C’est vraiment un point crucial sur le choix d’un Nas.
On se pose donc la question: au vu de tant de fonctionnalités pourquoi flasher ?
1°) parce que l’on peut le faire
2°) parce qu’ aucun firmware aussi complet soit-il ne pourra vous donner entière satisfaction.
3°) parce que vous aurez la garantie de pouvoir migrer facilement dans le futur vers une autre plateforme matérielle quand celle-ci sera devenue obsolète. Par exemple ,il ne ma fallu qu’une paire d’heures pour réorganiser mes services de sauvegardes , syncro, surveillance SNMP etc… depuis mon ancien Nas à celui-ci
Bon sur ces considérations assez traîné c’est parti !!
Le firmware d’origine nous donne accès à un shell root via ssh, pas besoin de bidouiller quoi que ce soit pour ça (merci les gars). On trouve un petit script tout fait pour installer proprement une squeeze de derrière les fagots. Le script copie la netinstall dans la flash. Il suffit de rebooter et de poursuivre l’installation normalement. la démarche est largement commentée dans de nombreux wiki / forums.
A noter que pour Squeeze, il faut prévoir pas mal de place pour le rfs, même allégée la distribution pèse pas loin de 800 Mo.
Le kernel s’installera dans la mémoire flash. Aussi, on peut utiliser le raid et lvm y compris pour la partition racine ce qui est vraiment intéressant (si le noyau était installé sur le disque dur, il aurait fallu que le bootloader gère le raid ce qui n’est pas le cas je pense avec uboot)
Pour les disques dont je dispose, voila la partitionnement que j’ai choisi (identique sur les deux disques):
sda1 Linux raid autodetect 898,63 MB
sda2 Linux swap / Solaris 511,71 MB
sda3 Linux raid autodetect 1998984,94 MB
Donc deux matrices raid1:
md0 avec le couple sda1/sdb1 et md1 avec sda3/sdb3.
Le RFS est sur md0 et les data sur md1. J’utilise ensuite lvm sur md1 pour plus de souplesse.
Une fois votre installation et vos logiciels favoris correctement configurés, il ne reste plus qu’à s’intéresser à la gestion de la température , des leds etc … Ici, point d’ACPI et c’est tant mieux. La squeeze s’est installée avec un paquet nommé qcontrol. Voila ce qu’ on peut lire sur la page du projet:
« Most of the Marvell Orion based devices have a microcontroller that is used to control the power state, LEDs, buttons, buzzer, etc. Usually this is connected to the second UART so the easiest way to implement this functionality is in userspace. »

Tiens un PIC en l’occurrence un PIC16F690. Ça sent la bonne bidouille …
Qcontrol se présente donc comme un programme user mode. Une communication via le second UART est établie. Cette communication est bidirectionnelle. Des codes sont envoyés par le PIC concernant l’état des leds, la température CPU l’état du ventilateur etc…
Dans l’autre sens, on peut envoyer des commandes pour gérer les leds, la vitesse de rotation du ventilo, le buzzer …
Un socket est ouvert lorsque qcontrol est lancé en mode démon. Il suffit ensuite de dialoguer avec, par exemple :
#qcontrol fanspeed low
#qcontrol statusled green1hz etc…

Des scripts lua sont ensuite disponibles pour gérer finement les interactions entre les capteurs et le ventilo, les leds etc …
En parcourant ces scripts et les sources de qcontrol, on ne trouve pas exactement le modèle concerné (le TS212). Aussi, afin de configurer au mieux le système, je me suis fendu d’un bout de code en C pour voir les codes renvoyés par le Marvell en temps réel afin de vérifier que le prog était bien compatible et c’est le cas. J’en ai aussi profité pour afficher sur la sortie standard la température du système ce qui m’a permis d’affiner les paramètres de ventilation lors de la montée en température du système.
Pour le code ça ce passe ici.
Pour la compilation il suffit d’installer gcc et ces dépendances sur le système embarqué ce qui évite une cross compilation. J’ai aussi installé le paquet smartmontools qui en plus de surveiller l’état des disques permet de visualiser leur température.
Apres quelques tests, voila ce que j’ai pu observer:
La température du HDD juste au dessus de la carte mère ce confond avec la température CPU. La température du deuxième HDD juste au dessus du premier est toujours plus basse de 1°C (ce qui est normal). On peut donc se baser uniquement sur les paramètres de la température CPU pour la gestion du ventilateur.
En fonctionnement normal sans activité, on est au environ de 37°C. Le ventilo sera en mode silence. Lors d’une montée en charge il faudra mettre le mode low à partir de 38°C et medium à partir de 40°C. C’est très efficace et de plus très discret quand au bruit du ventilateur.
Les modes high et full du ventilateur positionnés au delà de 42 °C ne se sont pour l’instant pas déclenchés.
J’ai eu du mal au début à éteindre le Nas par l’appui sur le bouton Power en facade. C’est d’ailleurs une des raisons qui m’a poussée à étudier le code de qcontrol et à faire le prog C susnommé. Je pensais que le Pic ne renvoyait pas le code correspondant à l’appui sur le bouton. En fait il le fait, mais c’est assez délicat. Le doigt doit rester appuyé 3 secondes sur le bouton power avant que le code ne soit renvoyé par le PIC. Le problème c’est que si on dépasse un peu ce délai, on obtient l’extinction brutale du Nas par coupure de l’alimentation. C’est pas vraiment ergonomique. Aussi, pour plus de sécurité, j’ai attribué le second bouton de façade (media_button) à l’extinction. Voila comment ca se code dans le lua de qcontrol.conf:
function media_button( time )
piccmd(« usbled », « 8hz »)
os.execute(« poweroff »)
end

Une belle led bleu se met à clignoter et le système s’éteind proprement, parfait.
Je posterai le script lua complet lorsque ma configuration sera finalisée et que le Nas clignotera comme un arbre de Noël.
A noter aussi le mode autopower géré par le PIC. Ce mode permet si il est activé de rallumer automatiquement le Nas si d’aventure l’alimentation était coupée. A la remise de celle-ci, le Nas redémarre tout seul, c’est pratique.
Enfin, il est important pour compléter notre système de pouvoir connecter une console série.
Bien que celle-ci ne soit pas nécessaire pour les opérations précédemment décrites, c’est pourtant indispensable à des fins de maintenance. Une console permettra de voir ce qui ce passe en cas de non démarrage du système. Elle permettra aussi de jouer avec uboot y compris pour la restauration du firmware d’origine si le besoin s’en fait sentir. Apres démontage du boitier on trouve un connecteur avec le brochage suivant : GND (white), RX (black), VCC (green), TX (red)

branchement port série


Le connecteur est de type JST PHR-4, si vous n’en disposez pas vous pouvez aussi souder…
Les niveaux de tensions TTL sont de 3.3 V, le plus simple donc est d’utiliser un câble usb-série de type TTL-232R-3V3. Attention, dans le cas d’utilisation d’un tel câble, il ne faudra pas connecter VCC !!.
La communication se fera à 115200 bauds.

Voila donc pour ce petit aperçu qui j’espère vous donnera envie d’acquérir ce matériel et de l’adapter à vos besoins. Bonnes bidouilles ….

Catégories :hack, Linux Étiquettes : , , ,
  1. Aucun commentaire pour l’instant.
  1. décembre 21, 2011 à 4:45

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :