Différences entre versions de « OpenBrick »
imported>SylvainBeucler m |
imported>SylvainBeucler |
||
(6 versions intermédiaires par le même utilisateur non affichées) | |||
Ligne 32 : | Ligne 32 : | ||
=== Méthode 1: monter la carte dans un lecteur externe === | === Méthode 1: monter la carte dans un lecteur externe === | ||
− | Éteindre par SSH avec 'poweroff' | + | * Éteindre par SSH avec 'poweroff' |
− | Éteindre physiquement (bouton à droite de la face arrière) | + | * É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) | + | * 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) | + | * Brancher la carte dans un lecteur multi-carte (Cliss XXI en possède un) |
− | Monter la carte (automatique dans <code>/media/usbdisk</code> - taper <code>dmesg</code> et chercher le bon <code>/dev/sd*</code> sinon) | + | * Monter la carte (automatique dans <code>/media/usbdisk</code> - taper <code>dmesg</code> et chercher le bon <code>/dev/sd*</code> sinon) |
== Mise à jour proprement dite == | == Mise à jour proprement dite == | ||
En tant que root (pour éviter des problemes de permissions ou de propriétaire), extraire <code>usbdisk/config.tgz</code>: | En tant que root (pour éviter des problemes de permissions ou de propriétaire), extraire <code>usbdisk/config.tgz</code>: | ||
− | + | mkdir /tmp/config | |
− | cd /tmp | + | cd /tmp/config |
− | + | tar xzf /tmp/cf/config.tgz | |
− | tar xzf config.tgz | ||
Effectuer les modifications. | Effectuer les modifications. | ||
Ligne 50 : | Ligne 49 : | ||
Enregistrer la config a nouveau: | Enregistrer la config a nouveau: | ||
cd /tmp/config | cd /tmp/config | ||
− | tar czf | + | 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 == | + | === 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... | 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... | ||
Ligne 65 : | Ligne 62 : | ||
Heureusement il est toujours possible d'obtenir un accès SSH. | Heureusement il est toujours possible d'obtenir un accès SSH. | ||
− | Solution: configurer syslog pour envoyer tous ces logs sur une autre machine: | + | Solution: configurer syslog pour envoyer tous ces logs sur une autre machine, dans <code>/etc/syslog.conf</code>: |
− | + | *.* @192.168.1.100 | |
− | *.* @192.168.1.100 | ||
− | |||
− | Il faut aussi configurer le syslog de ladite machine - le démarrer avec l'option | + | Il faut aussi configurer le syslog de ladite machine - le démarrer avec l'option <code>-r</code>. |
Version actuelle datée du 2 avril 2007 à 09:40
Description
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
- Nexedi introduction to umibuilder: http://www.nexedi.org/workspaces/project/umigumi/introduction_to_umib/view
- http://umigumi.org/: distro generator for (among others) flash disks
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
- taperdmesg
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
.