SheevaPlug

Focus sur le SheevaPlug

Sunday, 20 March 2011
|
Écrit par
Grégory Soutadé

Présentation

Un petit article pour présenter plus généralement le SheevaPlug. En effet les articles précédents se sont focalisés sur l'utilité d'un serveur de manière générale, mais il y a pas mal de questions sur le SheevaPlug en lui même. Le SheevaPlug c'est donc cette petite bête :


Il comporte (pour simplifier) :

  • Une mémoire interne (flash) de 512Mo
  • Une mémoire vive de 512Mo
  • Un processeur ARM de 1Ghz.

C'est l'équivalent d'une configuration de PC d'il y a 7 ans à peu près A défaut que celui-ci ne consomme que 5 Watts, ce qui est largement inférieur à n'importe quel PC, même basse consommation. Avec si peu de puissance il est évident qu'on ne peut pas faire tourner Crysis dessus, et c'est normal car sa fonction principale est d'être un serveur.

Un serveur c'est une machine qui va répondre à des requêtes externes pour, par exemple, servir des pages web, échanger des mails, stocker des données, et pour tout cela, point besoin de puissance. Personnellement je l'utilise, entre autre, pour faire de la compilation (voir ici un petit bench) automatique de KissCount, avoir un serveur SSH, un serveur mail, héberger mon blog, héberger une forge logicielle, accèder à mes comptes. Pour information la compilation de KissCount prend 15 minutes par version/architecture (soit 1h en tout) contre 1 minutes sur un PC de dernière génération. Elle est réalisée à 1h du matin pour ne pas peturber les autres services.

A l'intérieur du Sheeva


Concernant le système d'exploitation, le SheevaPlug est livré avec une Ubuntu toute prête. En effet on est sur un processeur ARM, donc Linux est tout choisi pour faire fonctionner le système. Bien sûr on aurait pu prendre un BSD, mais le portage n'est pas top, voir même un eCos si certains ont du temps ... MacOS on oublie tout de suite et les seuls Windows qui supportent ARM sont WindowsCE et WindowsPhone 7, mais là encore rien n'est fait pour les acceuillir. Avec Ubuntu on dispose de toute la logithèque GNU/Linux !

De plus le Sheeva ne possède pas d'écran et aucun connecteur pour en brancher un. Ce n'est évidement pas un problème car dans le monde GNU/Linux on peut parfaitement administrer une machine en ligne de commande via SSH (console à distance) en téléchargeant les logiciels et en éditant les fichiers de configuration via un éditeur en mode texte (nano, vi, emacs ...). mais une fois les bon paquets on peut aussi faire l'administration courante via des interfaces web. Les plus téméraires pourront installer un environnement graphique et/ou faire un affichage déporté via SSH, mais c'est complètement inutile et consommateur de ressources.

MAJ : NewIT propose quand même des écrans tactiles via USB (moniteurs MIMO)

Pour les bidouilleurs il faudra de toutes façons passer au moins par la sortie série (en micro USB) du Sheeva afin de modifier la séquence de lancement pour pouvoir booter sur un périphérique autre que la flash ou la carte SD. C'est très pratique pour récupérer la main sur le système quand celui-ci est cassé (comme décrit dans ce billet lorsque le SheevaPlug ne démarre plus).

512Mo de flash c'est suffisant pour le système d'exploitation, mais on se retrouve vite limité. Personnellement j'ai opté pour installer une Debian sur une clé USB 16Go, et tant qu'on ne veut pas stocker sa collection de DivX, c'est largement suffisant ! Il faut cependant faire attention avec ce port USB. Si le périphérique que vous branchez ne possède pas sa propre alimentation, le courant va être récupéré depuis le SheevaPlug, ce qui peut causer des dégâts si la demande est trop importante. Donc pour une clé USB ça passe, mais si vous branchez un disque dur ou un hub il faut faire attention à ce que ceux-ci possèdent leurs propre alimentation !!

Il y a un port eSata sur la version que j'ai acheté, mais je ne l'ai jamais utilisé, je suppose que le problème d'alimentation est le même.

Bref je possède le SheevaPlug depuis 8 mois et je n'ai eu aucun problème, une fois configuré on l'oublie, il ne chauffe pas et me permet d'héberger mes propres services sans soucis (il ne faut pas oublier de faire des sauvegardes régulières). Je ne voulais pas prendre de GuruPlug car il n'est pas plus puissant mais consomme plus à cause du Wifi et du Bluetooth. Il est aussi réputé pour des problèmes d'alimentation. Le double ethernet est bien si on veut faire une passerelle ou un pare-feu.

Le prix

La première année : 130€ chez NewIt + 4€ pour le nom de domaine (certificat SSL offert) + 5€ pour l'électricité. Donc 139€/an soit 11,58€/mois
A partir de la seconde année : 7€ pour un nom de domaine OVH + 15€ pour un certificat SSL + 5€ pour l'électricité. Donc 27€/an soit 2,25€/mois

C'est donc tout à fait raisonable (surtout à partir d'un an). On avait annoncé une baisse rapide du prix de ces joujous, mais je ne pense pas que ça arrivera un jour car les quantités vendues sont trop faibles.

Conclusion

En conclusion le SheevaPlug est l'appareil parfait pour tout ceux qui veulent un petit serveur chez eux ou se lancer dans de l'auto-hébergement !

Compilation croisée sur SheevaPlug

Wednesday, 26 January 2011
|
Écrit par
Grégory Soutadé

Dans mon article précédent je faisais une petite comparaison entre le SheevaPlug et un DELL OptiPlex quasi dernière génération. Voilà un petit retour d'expérience sur la compilation croisée depuis le Sheeva.

Pour rappel : la compilation croisée c'est compiler depuis un plateforme matérielle/logicielle A pour créer des binaires qui s'exécuteront sur une plateforme matérielle/logicielle B. Exemple : on compile sur une plateforme ARM pour une plateforme x86, ou encore une plateforme x86 64 bits vers x86 32 bits.

1) Récupérer crosstool-ng

Jusque là pas de problème, il s'installe facilement et est multi-plateforme (ce n'est que du script bash).

2) Compilation de la toolchain

La ça coince un peu plus, comme indiqué précédement j'ai eu des problèmes avec la eglibc, mais ça s'est résolu en modifiant une config d'exemple. J'ai compilé deux toolchains : une en 32 bits (i686-nptl-linux-gnu) et une en 64 bits (x86_64-nptl-linux-gnu).

3) Compilation du logiciel

Pour un simple "Hello World !" il n'y a pas de soucis, mais dès qu'on commence à construire un logiciel un peu plus costaud on a rapidement quelques ennuis.


Tout d'abord il faut préparer le Makefile à la cross compilation pour supporter la définition externe des variables type CXXFLAGS ou LDFLAGS. Cela consiste à remplacer CXXFLAGS="Quelque chose" par CXXFLAGS+="Quelque chose", idem pour LDFLAGS. Il faut aussi changer CXX=g++ en CXX=$(HOST)g++.

Les modifications pour KissCount sont dans ce commit.


Second problème : les bibliothèques externes type GTK ou dans mon cas wxWidgets. Là il faut ruser un peu plus, on ne peut pas installer directement le runtime car le paquet est compilé pour une architecture ARM donc ld ne va pas s'y retrouver. A moins de passer une option pour ignorer les différences d'architecture, mais je n'ai pas testé, et surtout je ne voulais pas installer ce paquet avec toutes ses dépendances (GTK, Xorg, ...) sur le serveur. J'ai donc importé à la fois les entêtes (headers) et les bibliothèques (.so) dans les dossiers include_wxwidgets_32 et lib_wxwidgets_32 (idem pour la version 64 bits) depuis une machine où ces paquets sont installés.


Dans le Makefile on fait appel à wx-config pour récupérer les valeurs de LDFLAGS et CXXFLAGS, j'ai donc crée un faux wx-config qui va renvoyer le chemin de include_wxwidgets_32 et lib_wxwidgets_32. Ensuite on définit HOST avec "i686-nptl-linux-gnu-" ou "x86_64-nptl-linux-gnu-", puis on déroute PATH vers ~/x-tools/i686-nptl-linux-gnu/bin:.:$PATH (le "." est l'endroit où il y a le wx-config). Enfin on lance LDFLAGS="-Wl,--allow-shlib-undefined" make. L'option "allow-shlib-undefined" permet de ne pas faire une résolution récursive des symbols dans les bibliothèques partagées, ainsi on n'a pas besoin de copier tout GTK pour pouvoir lier notre programme avec wxWidgets (qui dépend GTK).


La compilation se passe bien ... en 32 bits ! On peut même exécuter le programme sans problème sur une autre machine. Mais en 64 bits ça coince lors de l'édition de lien finale avec les erreurs suivante :

undefined reference to `__libc_csu_init'
undefined reference to `__libc_csu_fini'

Cela vient du fait que la libc 32 bits (de la plateforme de compilation) ne définit pas ces symbols et le compilateur (même 64 bits) utilise la libc de l'hôte. Personnellement j'ai fait deux liens symboliques :

ln -s /lib64     ~/x-tools/x86_64-nptl-linux-gnu/x86_64-nptl-linux-gnu/sys-root/lib/
ln -s /usr/lib64 ~/x-tools/x86_64-nptl-linux-gnu/x86_64-nptl-linux-gnu/sys-root/usr/lib/

On met à jour LDFLAGS dans le Makefile avec -L/lib64 et -L/usr/lib64 et le tour est joué !

4) Compilation automatique (Nightly build)

Pour courronner le tout, j'ai fait un petit script qui va s'exécuter chaque nuit (via crontab), vérifier depuis le dépôt git s'il n'y a pas une nouvelle version pour chaque branche et si c'est le cas, la compiler pour chaque architecture ! Il suffit alors de feinter inDefero en utilisant un liens symbolique "Nightly_Build_${branche}_${ARCH}.tar.bz2" pour rendre la nouvelle version disponible. De plus le script envoie un mail en cas d'echec ou de réussite (que demander de plus ??).

Ma hierarchie de dossier est la suivante :

/KissCount
|-- lib_wxwidgets_32/
|-- include_wxwidgets_32/
|-- lib_wxwidgets_64/
|-- include_wxwidgets_64/
|-- wx-config
|-- mega_compile.sh
|-- lib_i686/                  # Spécifique KissCount
|-- lib_x86_64/            # Spécifique KissCount
|-- kisscount_master/
|-- kisscount_dev/


Attention : lors du clone du dépôt git, il faut cloner un dépôt public, sinon il demande le mot de passe pour faire un pull.

Mon script de compilation mega_compile.sh

Et dans /etc/crontab :

0  2    * * *  www-data cd /KissCount && ./mega_compile.sh > /dev/null

L'auto hébergement, pourquoi ?

Monday, 06 December 2010
|
Écrit par
Grégory Soutadé

L'auto hébergement, qu'est ce que c'est ? Et bien tout d'abord, ce n'est pas l'hébergement de voitures ! C'est tout simplement le fait d'héberger des données chez soi et de les rendre accessible depuis l'Internet. En fait c'est le but premier d'Internet : interconnecter des machines sur un réseau mondial. L'auto hébergement, donc l'Internet, est pourtant quelque chose qui se perd. En effet les internautes choisissent la plupart du temps de confier leurs données à des sites tiers (mails, photos, blogs ...). Pourquoi donc ? Les principales raisons sont techniques : jusqu'à présent un internaute avec une connexion moyenne n'avait ni la bande passante nécessaire ni les connaissances techniques pour la création d'un "serveur", du coup il est plus simple de confier ses données à un tiers qui possède les compétences et le matériel permettant un hébergement efficace.


Oui, mais ! Les choses ont évoluées depuis l'ère du 56k limité à 50h. D'une part la bande passante des utilisateurs a énormément augmentée, de nos jours même une connexion de mauvaise qualité est suffisante. D'autre part les connaissances techniques nécessaires pour la création d'un "serveur" sont bien moins importantes. Il existe des solutions prêtes à fonctionner en dehors de la boîte (Apache, Joomla! ...). Dans l'esprit commun un "serveur" reste une grosse machine très puissante, alors qu'en réalité un serveur est juste un ordinateur qui va répondre à des requêtes. Les requêtes les plus connues sont les requêtes HTTP (http://...), mais il y a aussi le mail, l'accès distant comme SSH, des serveurs de jeu ... Il suffit donc d'un simple PC connecté au réseau pour pouvoir répondre aux requêtes de l'Internet.


Vous me direz : quel est l'intérêt de posséder ses données chez soi plutôt que dans un gros serveur ? Et bien l'intérêt principal est de conserver une partie de sa vie privée. Les photos, vidéos, écrits sont et restent la propriété de la personne qui les héberge (et dont il est l'auteur). Elles sont disponibles et peuvent être modifiées à n'importe quel moment par l'administrateur du serveur. Si je choisis de confier ces données à un tiers, il peut potentiellement en faire ce qu'il veut. Bien sûr il ne faut pas être trop paranoïaque, la plupart des fournisseurs de support respectent un minimum de confidentialité quant à ces données. Et c'est tout dans leurs intérêts car cela génère de la publicité (ciblée ou non) donc des revenus. Un service qui ne le respecterait pas suffisamment se verrait déserté rapidement.

Néanmoins il ne faut pas se leurrer, réaliser un serveur n'est pas trivial du moment qu'on dépasse le simple serveur web. Mais il y a plein de personnes qui ont eu cette problématique et tout le monde (informaticien ou non) possède un ami qui s'appelle Google qui lui connait toutes les personnes qui ont eu des problèmes et qui ont des solutions à apporter. Il suffit d'être un tout petit peu curieux. Les utilisateurs de GNU/Linux seront naturellement avantagés car l'installation et la configuration d'un serveur Apache sur ce dernier système est vraiment aisée. Reste l'aspect consommation : avoir un PC qui tourne 24h/24h, 7j/7j ça coûte. Personnellement j'ai adopté la solution d'un SheevaPlug qui est un "mini PC" à très faible consommation (5W), ce qui représente une consommation d'environ 5€/an (allumé 24h/24 7j/7). Il suffit donc de le brancher à la *box,(FreeBox, LiveBox, NeufBox, AliceBox ...), de le configurer une première fois, puis on l'oublie, on se contente juste d'ajouter des données (photos, vidéos ...) le moment voulu par l'interface web (et aussi de faire les mises à jours logicielles).

Seuls deux points peuvent être bloquant :

  • La sauvegarde des données n'est de base pas assurée. On peut utiliser le réseau, le port eSata ou USB, mais il faut mettre en place une solution de sauvegarde (manuelle ou automatique).
  • Si le serveur ou la connexion internet tombe, les services hébergés ne sont plus accessibles (ce qui peut être gênant pour le mail, mais reste acceptable pour un serveur web).


Parmi les outils permettant de monter un serveur on trouve :

  • Serveur web : Apache2 ou IIS
  • Gestionnaire de contenus (CMS, le site web pour résumer) : Wordpress, Joomla!
  • Serveur FTP
  • Serveur mail : Postfix, Dovecot
  • Serveur SSH (accès distant)
  • Serveur de base de données : MySQL, PostgreSQL
  • Serveur de gestion de version : Subversion, Mercurial, Git
  • Forges logicielle : Trac, inDefero, Redmine ...
  • Serveur de chat : IRC, Jabber
  • Serveur de jeu : Quake, Counter-Strike, Unreal, Wow


Le composant fondamental est le serveur web. A partir de là on peut héberger les services web classiques : photos, vidéos, blog ... Le reste étant réservé à une utilisation avancée.

Pour ceux qui auraient un peu de temps, il y a une conférence de Benjamin Bayart aux RM2L de 2007 qui est la conférence référence : Internet ou Minitel 2.0.
Ici un wiki en français sur la marche à suivre pour l'installation et la configuration du serveur : http://wiki.auto-hebergement.fr/

SheevaPlug qui ne boot pas après mise à jour du noyau

Wednesday, 27 October 2010
|
Écrit par
Grégory Soutadé

C'est rare mais les gars du projet Debian se sont planté. Peut être que j'ai loupé un truc, mais après avoir redémarrer suite à la mise à jour de mon SheevaPlug vers le noyau 2.6.32-5-kirkwood, le système sortait en kernel panic lors de l'initialisation du réseau. Pas pratique ...

Une petite recherche sur le web m'indique le liens suivant : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597302#35
Le problème vient du fait que la commande flash-kernel n'est pas appellée après la mise à jour du noyau. La marche à suivre est de rajouter l'option ipv6.disable=1 à la ligne de commande (setenv bootargs ipv6.disable=1) lors du boot. Evidement chez moi ça ne fonctionne pas.

Bref un système inutilisable (puisqu'il plante avant le boot). Ma configuration est la suivante :
- Ubuntu d'origine dans la mémoire flash intégrée
- Debian installée sur la clé USB avec les partitions suivantes :
/dev/sda1    /boot
/dev/sda2    /
/dev/sda3    swap
/dev/sda4    /home

Heureusement on a accès à la clé USB depuis l'Ubuntu d'origine, cela va permettre de remettre en marche tout ça. Il faut d'abord démarrer sous Ubuntu (sortir le cable USB pour accéder à l'interface RS232 via putty ou screen), monter la clé, se chrooter (c'est donc "comme" si on avait booté sur la clé). Hélàs /dev/sdaX n'est pas automatiquement détecté par udev (les événements ne lui sont pas envoyé pour qu'il crée les périphériques), on va donc le faire à la main avec mknod. Puis on monte /boot et /proc avant de pouvoir lancer flash-kernel. On revient sous Ubuntu, un petit fsck sur les partitions modifiées et on peut enfin redémarrer normalement sur notre ancien système !

mount -t ext2 /dev/sda2 /media chroot /media mknod /dev/sda1 b 8 1            # 8 2 pour /dev/sda2, 8 3 pour /dev/sda3 ... mount -t ext2 /dev/sda1 /boot mount -t proc /proc /proc flash-kernel exit reboot

redémarrer sous Ubuntu

fsck /dev/sda1 fsck /dev/sda2 reboot

J'ai remarqué que lorsqu'on débranche brutalement l'alimentation, il ne boote plus sur la clé USB. L'astuce consiste à démarrer sur l'Ubuntu d'origine, monter la partition, faire un ls, démonter la partition, faire les fsck sur les partitions modifiées (sinon il va le faire au boot de la clé et comme le système a été modifié va redémarrer ...), puis redémarrer le Sheeva (via un reboot).

mount -t ext2 /dev/sda2 /media ls /media umount /media fsck /dev/sda2 reboot

L'idéal est de créer un script et de le rajouter dans le crontab d'Ubuntu pour qu'il s'exécute toutes les 10 minutes. Comme ça si le redémarrage intervient pendant la nuit ou quand on n'a pas accès au SheevaPlug il revient tout seul sur Debian. Les 10 minutes permettent de désactiver le crontab quand on a des choses à faire sous Ubuntu (comme un flash-kernel par exemple ...).

SheevaPlug

Wednesday, 04 August 2010
|
Écrit par
Grégory Soutadé

SheevaPlug

 

Après plusieurs années de silence, il est de retour ! Et oui j'ai craqué, je viens de remonter un petit serveur, "cybelle" de son prénom. C'est désormais ce petit engin qui trône à côté du PC principal et qui est chargé de répondre aux requêtes de l'Internet.

Petit ? Tout à fait mon cher ami, 10cmx6cmx4cm mais pas en reste pour autant. En effet pour ceux qui ne le connaissent pas encore le SheevaPlug est un "plug computer", c'est à dire un ordinateur que l'on branche sur une prise de courant. Ceci est rendu possible grâce au SoC (System on Chip) Marvell à base d'ARM. Pour ceux qui seraient perdus il s'agit de mettre un ordinateur complet dans une seule puce. Ce système n'est pas nouveau, on le retrouve dans des appareils du quotidien (smartphone, GPS ...) mais en plus puissant.

Au niveau caractéristiques techniques on a donc :

  • Un processeur ARM v5 (ARM9) cadencé à 1,2 Ghz
  • 512Mo de RAM
  • 512Mo de Flash NAND
  • 1 port USB
  • 1 port ethernet
  • 1 port eSata
  • 1 port pour carte SD

La puissance du processeur peut sembler faible, mais en réalité elle est largement suffisante pour un serveur web à faible charge, et puis nous sommes sur ARM donc plus performant que les processeurs x86 à fréquence égale. Quant à la connectique elle se suffit à elle même, l'administration se fait grâce au port ethernet (et au port USB supplémentaire pour accéder à la séquence de démarrage). Pour ceux qui ne l'auraient pas encore compris, ce petit joujou tourne sous GNU/Linux, sur une Debian pour être plus précis. Dans cette configuration tout (ou presque) se fait via ssh en ligne de commande.

!!! Attention !!! Le SheevaPlug n'est pas capable de délivrer beaucoup de puissance sur son port USB. C'est à dire que tout va bien pour une clé USB, mais dès qu'on commence à rajouter un hub (avec plusieurs périphériques) ou un disque dur il faut que ceux-ci soient auto-alimenté (reliés à une prise de courant).

Pourquoi un serveur ? Je détaillerai dans un autre article les avantages d'avoir un serveur chez soi. Dans mon cas la première motivation était de pouvoir faire tourner une instance de inDefero accessible depuis Internet. En effet je trouve un peu cher l'offre payante et pas forcément adaptée à mes besoins, quant à l'offre gratuite ... elle est un peu trop réduite à mon goût. Je suis donc parti en quête d'un serveur ultra basse consommation compatible avec ma distribution préférée. Et là le SheevaPlug détrône tous ses concurrents (notamment ceux à base d'Atom ou de Geode), consommation annoncée : 5 watts soit 50 fois moins que pour un PC moyenne gamme. Petit calcul rapide : 1h d'utilisation d'un PC = 2 jours de connexion pour le SheevaPlug, dégagement de chaleur et encombrement en moins, le miens est planqué derrière l'écran du PC principal et même s'il chauffe un peu ce n'est rien en comparaison d'un écran.

Bref j'ai craqué, cette petite bête ne coûte "que" 130€ (frais de port compris) (~105£). La commande a été passée un dimanche après midi sur NewIT et reçue le mercredi, j'ai pris la version eSata (surtout parce qu'elle était en stock). Une fois reçu, petite installation d'une Debian sur une clé USB Toshiba 16Go avec les conseils trouvés sur le net :

Le CD d'installation ne contient pas de manuel de démarrage, mais pour information le mot de passe par défaut de root sur l'Ubuntu de base est "nosoup4u", on note tout l'humour des développeurs :)

Les services hébergés sur cybelle sont :

  • Serveur web (apache2)
  • Serveur mail (smtp, pop, imap) (postfix et dovecot)
  • Forge inDefero
  • Serveur MySQL
  • Serveur SSH

Un petit awstats pour les statistiques et Joomla!, accompagné du premier template sympa trouvé, pour la partie web. En effet je ne voulais toucher que le moins possible à la gestion et au contenu web. Un blog me direz vous, et bien oui un blog. Je continu néanmoins à défendre l'idée qu'un blog c'est comme un site web, c'est destiné à mourir, car on arrête rapidement de l'alimenter, mais bon "qui vivra verra". Je vais essayer de le faire vivre le plus longtemps possible. De ce côté là mon cousin m'a donné l'idée de faire une petite section cinéma (qui sera certainement la plus active) étant donné que je m'y retrouve toute les semaines (voir plusieurs fois par semaine), mais pour plus de détails il y a la section dédiée. Et puis qui sait, peut être que mes envies de rédaction reviendront !

"Enfin" me dirait ma tante, un informaticien qui n'a pas de présence sur le web c'est fou non ? C'est un peu comme un garagiste sans voiture !! Je me suis donc honteusement approprié le domaine de toute la famille avec ce magnifique soutade.fr, mais au moins je peux frimer en donnant ma nouvelle adresse gregory sur ce même nom de domaine.

En conclusion on peut monter un petit serveur pour 130€ + 7€ par an pour le nom de domaine (chez OVH). Cela requiert un minimum de connaissance en administration (et beaucoup de recherches sur le net), mais une fois les outils installé tout roule tout seul et on est complètement maître de ses données ! Seule limite la bande passante, ce qui est très correct pour mes 3 visiteurs quotidien (enfin j'exagère, je ne suis pas encore référencé).