*BSD embarque sur un memory stick

mips <anti@spam.gov> wrote:

Quelqu'un a-t-il deja essaye de faire tourner un BSD sur un stick usb
en read-only ?

Ben j'ai fait du NetBSD en read-only et du NetBSD sur 40 Mo. J'ai pas
fait les deux à la fois, mais y'a pas de raison que ca ne marche pas.

Pour le read-only, les seuls problèmes etaient qu'ils fallait monter des
ramdisks sur /tmp et /var/tmp (et eventuellement /etc, en union, si on
veut configurer son DNS)

--
Emmanuel Dreyfus
Un bouquin en français sur BSD:
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org

On Tue, 18 May 2004 18:21:00 +0200
manu@netbsd.org (Emmanuel Dreyfus) wrote:

Pour le read-only, les seuls problèmes etaient qu'ils fallait monter
des ramdisks sur /tmp et /var/tmp (et eventuellement /etc, en union,
si on veut configurer son DNS)

Ah, il me semblait que le unionfs c'etait pas encore tres au point.

mips

Pour le read-only, les seuls problèmes etaient qu'ils fallait monter
des ramdisks sur /tmp et /var/tmp (et eventuellement /etc, en union,
si on veut configurer son DNS)
Ah, il me semblait que le unionfs c'etait pas encore tres au point.

Sous tous les OS ? Parce que j'ai réussi a le faire marcher sous
FreeBSD, sans problemes, sauf que mon serveur a commencé à montrer de
gros problemes de stabilité, et j'ai tout desactivé pour arreter les
dégats. C'est beaucoup plus stable (mon uptime est de 15 jours au lieu
de 2), enfin, j'ai l'impression, et je n'ose pas remettre... surtout
que je n'ai pas le temps de faire joujou avec gdb pour ne pas y comprendre
grand chose.

--
Nicolas Le Scouarnec

mips <anti@spam.gov> wrote:

Pour le read-only, les seuls problèmes etaient qu'ils fallait monter
des ramdisks sur /tmp et /var/tmp (et eventuellement /etc, en union,
si on veut configurer son DNS)

Ah, il me semblait que le unionfs c'etait pas encore tres au point.

Non, ca marche bien (enfin sous NetBSD en tout cas): je monte un ramdisk
sur /tmp, je créé /tmp/etc et je le remonte sur /etc.

--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org

Salut,

On Tue, 18 May 2004 14:18:14 +0200, mips <anti@spam.gov> wrote:

Quelqu'un a-t-il deja essaye de faire tourner un BSD sur un stick usb
en read-only ?

Pas fait sur un stick USB, mais fait sur des cartes CF pour un Soekris.

En fait j'aimerais bien faire un systeme minimal qui tiendrait sur 64
ou 128 mo et qui permettrait de faire des diagnostiques reseau, voire
des demos de pf dans le cas d'openbsd. Bien sur tout ceci utiliserait
la memoire vive pour les partitions en ecriture.

J'ai un FreeBSD sur une CF de 32 Mo, avec un joli kernel (IPsec, IPFW...),
sshd, ssh, isakmpd, ping, traceroute, tethereal, dhcpd, dhclient, sftp,
ftp, top, ps, grep, natd, ntpd, tcpdump, ppp, syslogd et j'en passe. Et il
reste encore 6 Mo de libre.

Par contre il est vrai qu'il n'est pas monté read-only (même si ça arrive
quand je reboote sauvagement la boite, même si mon rc s'occupe de ça
maintenant), mais de mémoire la seule conséquence c'est que sshd est un
peu perturbé de ne pas pouvoir changer les droit sur le tty. Ce qui peut
s'arranger en utilisant devfs. Evidemment, il y un ramdisk pour /var qui
est "peuplé" par les scripts de boot.

Une autre alternative est de faire un kernel avec une image de ramdisk
dedans (méthode utilisée pour les floppies d'install), voir du coté de
picoBSD, crunchgen et leurs copains. Moi j'ai pas trop la méthode, mais
bon, ça marche bien aussi.

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

Jacques Caron <jc@imfeurope.com> wrote:

Par contre il est vrai qu'il n'est pas monté read-only (même si ça arrive
quand je reboote sauvagement la boite, même si mon rc s'occupe de ça
maintenant), mais de mémoire la seule conséquence c'est que sshd est un
peu perturbé de ne pas pouvoir changer les droit sur le tty.

Non, j'ai réussi à faire integrer dans OpenSSH un patch pour contourner
ce problème: si les tty sont en mode 600 root/wheel, sshd acceptera une
connexion même si il ne peut pas en modifier les droits (car /dev en
read-only).

Et c'etait justement pour une utilisation de NetBSD sur media read-only.

--
Emmanuel Dreyfus
A lire: 240 pages en français sur l'administration UNIX avec BSD
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org

Le Wed, 19 May 2004 07:49:10 +0200,
Emmanuel Dreyfus <manu@netbsd.org> écrivais:

Jacques Caron <jc@imfeurope.com> wrote:

Par contre il est vrai qu'il n'est pas monté read-only (même si ça arrive
quand je reboote sauvagement la boite, même si mon rc s'occupe de ça
maintenant), mais de mémoire la seule conséquence c'est que sshd est un
peu perturbé de ne pas pouvoir changer les droit sur le tty.

Non, j'ai réussi à faire integrer dans OpenSSH un patch pour contourner
ce problème: si les tty sont en mode 600 root/wheel, sshd acceptera une
connexion même si il ne peut pas en modifier les droits (car /dev en
read-only).

On peut aussi avoir un /dev minimal (/dev/console, /dev/null en
particulier) pour permettre le début de l'amorçage, puis remonter /dev
dans une partition en mémoire (mfs) et faire un MAKEDEV à chaud (et
assez tôt dans le /etc/rc). Des partitions mfs peuvent aussi servir pour
/var et autres...

Testé avec un open 3.3 en read-only sur carte compact flash, ça marche
très bien.

Par contre j'ai essayé avec un mount_union (qui aurait été à priori plus
propre), c'est instable. Sans doute ai-je oublié quelque chose ?

Une autre astuce bien pratique: la possibilité de générer, automatiquement,
par les sources, des image système amorçables (en dérivant la génération du
cdromXY.fs) et contenant à peu près tout ce que l'on souhaite avec un
simple Makefile d'une dizaine de lignes (+ une liste pour crunchgen) ; le
tout sans sans rien modifier ni ajouter dans /usr/src.
C'est très propre et agréable pour les mise à jour. Vive BSD ;)

En revanche je m'interroge sur la façon dont le bootloader d'open (un
brin psychorigide) peut encaisser l'amorçage sur clef usb. Avec syslinux
+ memdisk j'arrive à amorcer (sur ce media) linux + freebsd (en dual
boot!), mais pas moyen de lancer un open (même avec l'amorçeur dernier
cri de 3.5). Bref je saisi l'occasion pour demander conseil sur le sujet.
Si quelqu'un à une idée sur la façon de faire coopérer syslinux/memdisk et
open (et netb aussi) j'adorerai en savoir plus.

Ah, il me semblait que le unionfs c'etait pas encore tres au point.

Sous tous les OS ? Parce que j'ai réussi a le faire marcher sous
FreeBSD, sans problemes, sauf que mon serveur a commencé à montrer de
gros problemes de stabilité, et j'ai tout desactivé pour arreter les
dégats. C'est beaucoup plus stable (mon uptime est de 15 jours au lieu
de 2), enfin, j'ai l'impression, et je n'ose pas remettre... surtout
que je n'ai pas le temps de faire joujou avec gdb pour ne pas y comprendre
grand chose.

Unionfs en général pose des problèmes car il casse tous les postulats
que l'on peut faire sur les algorithmes de système de fichiers (pas de
cycles, par exemple). Au fil du temps et en fonction de la compétence et
du temps consacré par les gens qui se penchent sur le problème, les gros
problèmes disparaissent, mais il en reste toujours un ou deux bien
cachés.

A l'heure actuelle, on peut raisonnablement considérer qu'un unionfs
dont un seul des systèmes de fichiers considérés est monté avec accès en
écriture, est stable.

Le seul exemple de montage de type union vraiment stable, à ma
connaissance, est le TVFS d'OS/2, qui en plus du système d'union dispose
également de la notion de priorité des montages, afin de mieux répartir
les opérations d'écriture. Malheureusement, le code n'est pas public ;
j'ai eu une longue discussion avec son auteur à propos des algorithmes
utilisés, et effectivement, il est assez difficile de penser à tout,
tout en conservant des performances acceptables.

Benjamin Pineau <ben@zouh.org-nospam.com> wrote:

On peut aussi avoir un /dev minimal (/dev/console, /dev/null en
particulier) pour permettre le début de l'amorçage, puis remonter /dev
dans une partition en mémoire (mfs) et faire un MAKEDEV à chaud (et
assez tôt dans le /etc/rc). Des partitions mfs peuvent aussi servir pour
/var et autres...

Ben en fait le problème ne se pose que sur OpenBSD: Sous FreeBSD il y a
un devfs, et sous NetBSD, si /dev/console est absent, init créé un
ramdisk avec les devices dedans, monté sur /dev

Testé avec un open 3.3 en read-only sur carte compact flash, ça marche
très bien.
Par contre j'ai essayé avec un mount_union (qui aurait été à priori plus
propre), c'est instable. Sans doute ai-je oublié quelque chose ?

Ben ecoute, chez moi ca marche très bien (NetBSD 1.6.2)

En revanche je m'interroge sur la façon dont le bootloader d'open (un
brin psychorigide) peut encaisser l'amorçage sur clef usb. Avec syslinux
+ memdisk j'arrive à amorcer (sur ce media) linux + freebsd (en dual
boot!), mais pas moyen de lancer un open (même avec l'amorçeur dernier
cri de 3.5). Bref je saisi l'occasion pour demander conseil sur le sujet.
Si quelqu'un à une idée sur la façon de faire coopérer syslinux/memdisk et
open (et netb aussi) j'adorerai en savoir plus.

Ben une clé USB, c'est vu comme un disque ATAPI, non? Donc avec un MBR
et tout le toutim, on est dans les sentiers battus...

--
Emmanuel Dreyfus
Un bouquin en français sur BSD:
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org

Ben une clé USB, c'est vu comme un disque ATAPI, non? Donc avec un
MBR et tout le toutim, on est dans les sentiers battus...

C'est vu comme un disque scsi :

Ça tombe bien, ATAPI c'est grosso modo SCSI-over-ATA ...