OpenBrick

De Cliss XXI
Sauter à la navigation Sauter à la recherche

Description

http://openbrick.org/

Sorte de mini-PC, qui peut jouer par exemple le rôle de passerelle vers l'Internet.

Entre autres, un port Ethernet, un lecteur de cartes Flash (sur /dev/hda), une carte Flash 64Mo. 106 Mo de RAM une fois le système en route. On peut brancher un adaptateur USB<->Ethernet pour obtenir une interface réseau supplémentaire.

La version que j'ai eu à manipuler tourne sous une Mandrake, créée avec umibuilder.

ToDo: comment mettre à jour cette distribution?

Liens

Séquence de démarrage

(probablement spécifique à umibuilder)

Le système démarre depuis la carte Flash. Un système de fichier est créé en mémoire RAM, puis le fichier config.tgz est extrait à la racine. config.tgz est donc l'endroit privilégié pour faire des opérations de maintenance.

Modification de la configuration

Comme le système ne possède pas de disque-dur, toute modification permanente (càd qui survit à une coupure électrique) doit être enregistrée sur la carte flash.

Méthode 1: monter la carte depuis l'OpenBrick

mkdir /tmp/cf && mount /dev/hda1 /tmp/cf

Méthode 1: monter la carte dans un lecteur externe

  • Éteindre par SSH avec 'poweroff'
  • Éteindre physiquement (bouton à droite de la face arrière)
  • Enlever la carte mémoire (en dessous de la carte PCMCIA, toujours a l'arrière)
  • Brancher la carte dans un lecteur multi-carte (Cliss XXI en possède un)
  • Monter la carte (automatique dans /media/usbdisk - taper dmesg et chercher le bon /dev/sd* sinon)

Mise à jour proprement dite

En tant que root (pour éviter des problemes de permissions ou de propriétaire), extraire usbdisk/config.tgz:

mkdir /tmp/config
cd /tmp/config
tar xzf /tmp/cf/config.tgz

Effectuer les modifications.

Enregistrer la config a nouveau:

cd /tmp/config
tar czf /tmp/cf/config.tgz *

Replacer la fiche dans l'OpenBrick, puis remettre l'alimentation en route. Le redémarrage est assez long, compter plusieurs minutes avant l'activation de l'accès SSH, et quelques minutes supplémentaires avant le rétablissement de l'accès à Internet.

Problèmes

Saturation de la mémoire

Par défaut, shorewall enregistre *beaucoup* de traces d'activités; ceci consomme toute la mémoire (car le système de fichier est en RAM), et cela finit par bloquer le DHCP. Symptôme intéressant: DHCP accepte des demandes, mais n'y répond pas complètement; du coup, le client DHCP par défaut de Debian attend indéfiniment une réponse valide - j'espère que vous avez appris Control+C à vos clients...

Heureusement il est toujours possible d'obtenir un accès SSH.

Solution: configurer syslog pour envoyer tous ces logs sur une autre machine, dans /etc/syslog.conf:

*.*     @192.168.1.100

Il faut aussi configurer le syslog de ladite machine - le démarrer avec l'option -r.