Affichage des articles dont le libellé est FreeBSD. Afficher tous les articles
Affichage des articles dont le libellé est FreeBSD. Afficher tous les articles

dimanche, mars 13, 2011

FreeBSD packages generator

  
Update (8 april 2011): There is a best method detailled here (in french)

Using up-to-date ports on my old workstations became more and more painful (more than 8 hours for compiling the latest LibreOffice).
Then I've decided to use my brand new server (used for generating BSD Router Project images and running BSDRP routing labs using virtualbox) as a FreeBSD packages generator.
But I've faced to a problem with the "make package-recursive" command on FreeBSD:
The port needs to be installed before generating the package! And I didn't want to install useless programs  (xorg, hal, etc…) on my server.
Then I've wrote small ugly script that:

  1. Generate a full new freebsd in a working dir (downloading FreeBSD base, src and lib32 sets).
  2. Update the local port tree
  3. Launch a chrooted portmaster into the working dir for generating the packages.

This script, package_gen.sh, is to be use like that:

Package generator usage:
./package_gen.sh COMMAND [familly/port-name] [build-option]
Where COMMAND can be:
 generate [familly/port-name] [build-option]
 upgrade [port-name] [build-option]
 replace familly/port-name familly/port-name
 delete [familly/port-name]
examples:
./package_gen.sh generate sysutils/tmux                         : Generate tmux package
./package_gen.sh generate editors/vim-lite -DWITHOUT_X11        : Generate vim-lite package without X11 stuffs
./package_gen.sh generate editors/libreoffice LOCALIZED_LANG=fr : Generate french libreoffice
./package_gen.sh upgrade                                        : Upgrade all packages previously generated
./package_gen.sh delete editors/vim-lite                        : Delete vim-lite
 


All generated packages are in /usr/ports/packages.

Once generated or upgraded, I upload them onto a web server using a small lftp script (-f option):


  set ftp:list-options -a
  set cmd:fail-exit true
  debug -o /home/USER/lftp_debug.log 3
  open -p 21 LOGIN:PASS@ftpperso.free.fr
  cd /packages/8.2/amd64/Latest
  lcd /usr/ports/packages/Latest
  mirror -eRL --only-newer --parallel=2 --verbose=4
  cd /packages/8.2/amd64/All
  lcd /usr/ports/packages/All
  mirror -eRL --only-newer --parallel=2 --verbose=4
 quit
 


This lftp script replaces symbolic links found in /usr/ports/packages by the real file.
Now, from my workstations, I can install up-to-date ported software with this command:

env PACKAGESITE=http://gugus69.free.fr/packages/8.2/amd64/Latest/ pkg_add -r openjdk6

You can use this package repository freely. I will try to kept it online (if my ISP accept this uses) and up-to-date.
But here are some information about theses packages:
  • FreeBSD amd64 8.2 only
  • www/firefox-i8n include only french language pack
  • emulators/qemu with kqemu support and GNS3 patch
  • java/jdk16 is compiled with IPv6 enabled


dimanche, octobre 10, 2010

FreeBSD developer summit 2010, Karlsruhe


Je viens de terminer mon premier FreeBSD developer summit que j'ai vraiment adoré.
La dernière conférence BSD à laquelle j'ai participé était la BSDCan 2007 et je n'avais pas participé au dev summit (d'ailleurs je ne savais même pas que ca existait à cette époque).
Mais qu'est ce qu'un dev summit exactement ?
Il s'agit d'une rencontre se déroulant sur 2 jours juste avant l'EuroBSDCon qui permet de rencontrer physiquement la majorité des personnes qui contribuent au projet FreeBSD (seul les contributeurs et quelques invités y participent).
Chacune des 2 journées du dev summit se décomposent en 3 parties:

  • Le matin, dans le grand amphi: Les personnes présentent l'état de leurs travaux (environ 10 minutes de présentation et 5 minutes de questions).
  • L'après midi a lieu différents ateliers sur des thèmes spécifiques.
  • Le soir: Le resto on l'on essaye de discuter d'autre chose que de «geekerie» (mais c'est très très dur vus le profil de la population présente ).

Le nombre de personne qui viennent de loin pour ces quelques jours (US et Japon en particulier) est impressionnant. On y rencontre bien sur pas mal de personne travaillant pour iXsystems (Warner Losh, Dru Lavigne, Kris Moore, Alexander Motin).

Voici quelques sujets abordés le matin:

  • ringmap : Une autre approche différente de «zero_copy» permettant d'éviter toute recopie interne d'un paquet lors de son traitement. Cette techno à été mise au point pour la capture de paquet à haut débit, mais elle va être très intéressante concernant les améliorations de performance de routage.
  • VPS: C'était LA présentation que j'attendais. Voir des VPS FreeBSD changer de serveur hôte sans impact sur les clients c'est très beaux, tellement que ca fait presque pleurer. Et surout on va pouvoir bientôt leur en foutre pleins sur la gueule à virtuozzo!!!
  • Amélioration de NanoBSD: Synthèse des différents problèmes que j'ai rencontré avec nanoBSD et les solutions proposées
  • FreeNAS: Warner Losh a présenté l'état actuel de la récupération du projet par iXsystems.
  • FreeBSD Virtualbox Image for Port Mainteners, basée sur FreeBSD -current elle inclue une tinder box pré-configurée pour pour valider ses ports FreeBSD (7,8,-current)… Il va falloir que je test ce truc.
  • La documentation: Comment simplifier la contribution à la doc ?
  • PC-BSD: Les utilisateurs de PC-BSD, par leurs usages différents remontent pas mal de bug non détecté par les admins systèmes de FreeBSD. Comment améliorer la synergie entre PC-BSD et FreeBSD ?
  • Et pleins d'autres sujets: la gestion des ports, des trucs concernant le noyau dont je ne comprends rien, etc… La liste est sur le wiki.


Au sujet les ateliers de l'après-midi, par exemple celui sur FreeNAS, on profite de la présence dans la même pièce de plusieurs personnes clés:

  • Warner Losh, qui récupère la responsabilité du projet chez iXsystems
  • Martin Matuska qui contribue à l'import ZFS dans FreeBSD
  • Alexander Motin qui développe entre autre le système CAM ATA… entre autre

Pour discuter «performance, tunning» et autre. Bref le résultat est «vivement FreeNAS 8 car le support du ZFS dans FreeBSD 7 n'est pas terrible du tout» (que soit au niveau des perfs et même de la stabilité).

J'ai aussi profité de la présence de Kris Moore (PC-BSD) pour qu'il me montre sa version de travail du futur PC-BSD (qui supportera plusieurs gestionnaires de bureau comme Gnome et LXDE4 et ne reste plus limité à KDE). Il lui reste à finir l'homogénéisation des différents thèmes et menu. Cela à l'air vraiment prometteur (résultats dans 1 ou 2 mois).

Conclusion: Je vais essayer de me refaire inviter pour celui de l'année prochaine. Car même pour un petit contributeur le dev summit permet d'échanger énormément en seulement 2 jours !
Le seul problème est que les journées se terminent tard (1h du matin), ce qui ne m'a pas laissé le temps d'aller visiter Karlsruhe :-(

jeudi, août 19, 2010

Réparation des bibliothèques manquantes

Suite à la mise à jour d'une bibliothèque critique sur mon FreeBSD (mise à jour de devel/icu4 qui est passé de 4.3 vers 4.4) et d'une erreur de ma part lors de l'étape de mise à jour:
Je me suis retrouvé avec un FreeBSD dont la base était pleinement fonctionnelle (merci à la séparation de la base et des ports) mais dont la grosse majoritée des applications ne voulaient plus démarrer (dont gnome).
En effet, les applications recherchaient les bibliothèques libicu*.so.43 qui n'existaient plus car remplacées par libicu*.so.44.
Pour retrouver rapidement un système fonctionnel, j'ai en premier lieu ajouté les correspondances «anciennes libs <=> nouvelles libs» dans le fichier /etc/libmap.conf:


libicule.so.43          libicule.so.44
libicui18n.so.43        libicui18n.so.44
libicudata.so.43        libicudata.so.44
libicuuc.so.43          libicuuc.so.44
libicutu.so.43          libicutu.so.44
libiculx.so.43          libiculx.so.44
libicuio.so.43          libicuio.so.44

Ce «bidouillage» ma permis de retrouver un système fonctionnel très rapidement, mais ca ne me plaisait pas d'avoir un système «pas si propre que ça».
Je me suis donc attelé à la rédaction d'un script shell qui
  1. Parcours l'ensemble des dossiers /usr/local/bin, /usr/local/sbin et /usr/local/lib à la recherche de fichier lié à des bibliothèques manquantes
  2. Puis retrouve le port correspondant à ces fichiers (pkg_info)
  3. Puis enfin recompile/réinstalle ces ports (portmaster)
Tout contents de moi, je suis aller le proposer sur #freebsd-fr, pour découvrir que je venais de ré-inventer la roue :-(
Ce script existe déjà en zsh (Reconstruire les paquets cassés) et il existe un port en ruby (sysutils/libchk).
Mais comme la version de mon script:
  1. Est en sh (et donc ni dépendante de zsh ni de ruby… qui sont des ports potentiellement «cassés» au moment ou vous avez besoin de ce script)
  2. Que c'est moi qui l'ai fait tout seul comme un grand, et que ca m'embête de le jeter après les heures (oui c'est très très chiant le sh) passé dessus
Je mes suis décidé à le publier quand même:

#!/bin/sh
# Found file with missing libs, and recompile the related breaked ports
set -e
dirs="/usr/local/lib /usr/local/libexec /usr/local/bin /usr/local/sbin"

portnames_tmp=""
for dir in ${dirs}; do
    for filename in `find -L ${dir} -type f`; do
    if file ${filename} | grep -q ELF; then
        if ldd ${filename} 2>&1 | grep -q "not found"; then
            portnames_tmp=${portnames_tmp}" "`pkg_info -qoW ${filename}`
        fi
    fi
    done
done

if [ "${portnames_tmp}" = "" ];then
    echo "No missing lib found"
    exit 0
fi

# Filtering duplicate name in $portnames_tmp
portnames=`for port in ${portnames_tmp}; do  echo $port; done |  sort -u | xargs echo`

echo "Detecting missing library for theses ports:"
echo ${portnames}

echo "Start upgrading them…"
portmaster -B ${portnames}

PS (1): le port devel/icu4 étant buggué (il oublie d'installer la bibliothèque libicutest.so.44), à chaque lancement de ce script, il détectera que devel/icu4 à une bibliothèque manquante et voudra donc le ré-installer :-)
PS (2): Ne pas oublier de faire le ménage dans /etc/libmap.conf après avoir corrigé vos problèmes.

lundi, août 02, 2010

Compilation des ports et proxy HTTP authentifié

Ayant la possibilité de tester un serveur SunFire V480R au bureau, j'en ai profité pour lui installer un FreeBSD 8.1.
Si l'installation n'a posée aucun problème à par la prise en main de l'OpenBoot PROM (OBP pour les intimes), la déclaration du proxy HTTP authentifié qui ma pris plus de temps que prévus.
En effet, il est assez simple de le déclarer le proxy par les commandes suivantes (a adapter dans votre cas):

setenv HTTP_PROXY "10.0.0.10:8080"
setenv HTTP_PROXY_AUTH "basic:*:login:password"
setenv http_proxy 'http://login:password@10.0.0.10:8080/'

On peux désormais faire du «portsnap fetch extract», etc…:

[olivier@sparc64]~>fetch http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/book.html
book.html                                     100% of 5595 kB  370 kBps 00m00s
[olivier@sparc64]~>


Par, contre cela ne suffit pas pour permettre le téléchargement des sources des ports: Le proxy est bien utilisé, mais il ne s'authentifie pas tous seul:

[root@sparc64]/usr/ports/www/shellinabox#make extract
===>  Vulnerability check disabled, database not found
===>  License accepted by the user
=> shellinabox-2.10.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch from http://shellinabox.googlecode.com/files/.
fetch: http://shellinabox.googlecode.com/files/shellinabox-2.10.tar.gz: Proxy Authentication Required


Avant de s'énerver et de remplacer le FreeBSD par un Ubuntu Server :-) faisons un petit tour du coté des barbus français (freebsd-fr@freenode)… C'était la bonne méthode, car le grand bapt@ était présent et ma fait une réponse aux petits ognons:

echo "FETCH_ARGS=-pRr" >> /etc/make.conf

Et cela à résolus mon problème:

[root@sparc64]/usr/ports/www/shellinabox#make extract
===>  Vulnerability check disabled, database not found
===>  License accepted by the user
=> shellinabox-2.10.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch from http://shellinabox.googlecode.com/files/.
shellinabox-2.10.tar.gz                       100% of  501 kB 1087 kBps
===>  Extracting for shellinabox-2.10
=> MD5 Checksum OK for shellinabox-2.10.tar.gz.
=> SHA256 Checksum OK for shellinabox-2.10.tar.gz.

On peux même déclarer le proxy dans le fichier make.conf (mais éviter de déclarer votre proxy partout, car en cas de changement cela fait plusieurs fichiers à modifier et votre mot de passe qui traine partout):

echo "FETCH_ENV=http_proxy='http://login:password@10.0.0.10:8080/'" >> /etc/make.conf

dimanche, juillet 25, 2010

make installworld: «touch: not found» lors d'une mise à jour à distance

FreeBSD 8.1-Release étant de sortie, j'en ai profité pour mettre à jour mon kimsufi 250G.
Si la procédure de mise à jour à distance est en général assez risquée pour un changement de version majeure, elle ne ma jamais posée de problème pour un changement de version mineure.
Sauf que cette fois-ci, le «make installworld» se termine mal par le message d'erreur «touch: not found».

La FAQ officielle explique que ce problème est lié un problème d'horloge qui fait que les dates des fichiers à installer sont incorrect suite au redémarrage en mode «single user». La FAQ conseil d'utiliser la  commande «adjkerntz -i» pour résoudre ce problème. Cette proposition n'est pas adaptée à mon cas car je ne redémarre pas en mode single user.
    Un autre utilisateur, barryp, indique que ce problème est du au fichier /usr/src/sys/conf/newvers.sh qui n'a pas la bonne date et qu'un simple «touch» sur ce fichier pour le mettre à la bonne date résous le problème… Pas chance, cela ne résous pas mon problème :-(
     
    La bonne réponse m'a été donné sur le site de so14k: Il faut utiliser la commande «make installworld PATH=$PATH» pour ne plus avoir ce problème de «touch: not found».

    lundi, juillet 12, 2010

    Installation de FreeBSD «headless» (utilisation du port console comme clavier/écran)

    Je souhaitai installer FreeBSD sur une «vieille» unité centrale qui n'avait plus d'écran: Il me fallait utiliser le port série comme console principale.
    Ce n'est pas très compliqué: Il suffit de modifier l'image ISO de FreeBSD pour forcer l'usage du port série.
    Une fois téléchargé l'image, on la monte (l'ensemble des exemples utilisent tcsh comme shell):

    set MD=`mdconfig -a -t vnode -f FreeBSD-8.1-RC2-amd64-disc1.iso`
    mount -t cd9660 /dev/$MD /mnt/

    Vous obtenez une image montée en lecture seule (normal pour un ISO)… Ne reste plus qu'à la modifier et re-générer un fichier ISO.
    Pour cela, on peux vous conseiller de recopier l'intégralité de l'image disque et ensuite de modifier votre copie comme ceci:

    mkdir /tmp/isotmp
    cd /mnt
    tar cf - * | ( cd /tmp/isotmp; tar xfp - )

    Mais comme cette méthode est lente et consomme de la place sur votre disque, voici une méthode plus intelligente utilisant unionfs:

    mkdir /tmp/isotmp
    mount -t unionfs -o noatime /tmp/isotmp/ /mnt/

    Désormais le point de montage original (/mnt) est accessible en écriture :-)
    Modifions le boot/loader.conf pour forcer l'usage du port série:
    J'utilise une vitesse de 38400 baud pour que ca ne soit pas trop désagréable.
    Attention à l'utilisation de unionfs qui ne gère pas la fusion du contenus de deux fichiers identiques, il faut utiliser une copie pour ne pas écraser l'ancien:

    cat /mnt/boot/loader.conf > /mnt/boot/loader.conf.new
    echo 'comconsole_speed="38400"' >> /mnt/boot/loader.conf.new
    echo 'console="comconsole"' >> /mnt/boot/loader.conf.new
    echo 'boot_serial="-h"' >> /mnt/boot/loader.conf.new
    mv /mnt/boot/loader.conf.new /mnt/boot/loader.conf

    Ne reste plus qu'a régénérer une ISO:

    cd /mnt
    mkisofs -R -no-emul-boot -b boot/cdboot -o /tmp/FreeBSD-8.1-headless-.iso .

    Puis à démonter (2 fois) votre image, détruire le md et effacer votre dossier temporaire:

    cd /
    umount /mnt
    umount /mnt
    mdconfig -d -u $MD
    rm -rf /tmp/isotmp

    Mais ne partez pas si vite ! Il reste juste un tout petit détail qui a son importance…
    Une fois l'installation de FreeBSD terminé, et avant de re-démarrer:

    N'oubliez pas de modifier le /etc/ttys en lui déclarant l'usage du port série!
    Dans sysinstall: configure system ttys.
    Il va ouvrir le fichier /etc/ttys dans un éditeur de texte, il faut remplacer la ligne suivante:

    # Serial terminals
    # The 'dialup' keyword identifies dialin lines to login, fingerd etc.
    ttyu0   "/usr/libexec/getty std.9600"   dialup  off secure

    Par ceci:

    # Serial terminals
    # The 'dialup' keyword identifies dialin lines to login, fingerd etc.
    ttyu0   "/usr/libexec/getty std.38400"   vt100  on secure

    Personnellement, avant de graver le CD, je vérifie la procédure par l'excellentissime[1] qemu:

    qemu-img create fbsd-test.img 4G
    kldload kqemu.ko
    kldload aio.ko
    qemu-system-x86_64 -kernel-kqemu -nographic -cdrom FreeBSD-8.1-headless.iso -hda fbsd-test.img -boot d
    qemu-system-x86_64 -kernel-kqemu -nographic -hda fbsd-test.img

    Article original m'ayant fortement inspiré: FreeBSD Headless install
    [1] Essayez d'en faire autant en si peux de lignes de commande avec VirtualBox !

    vendredi, juillet 09, 2010

    Utilisation de nanoBSD sur un WRAP de PC-Engines

    Après avoir passé 2 jours à chercher pourquoi BSDRP (NanoBSD basé sur FreeBSD 8.1-RC2) ne voulais pas démarrer sur mon PC-Engines WRAP.1E-2, voici la liste des pré-requis à respecter…

    Coté WRAP:
    1. Version du BIOS en 1.11
    2. BIOS configuré en mode CHS (et non pas LBA)
    Coté NanoBSD:
      1. Compiler un noyaux i386 avec la ligne "options CPU_GEODE" dans le fichier de configuration
      2. L'image nanoBSD doit utiliser comme console le port série par défaut (cust_comconsole) à la vitesse de 38400 baud si possible (pour respecter la vitesse par défaut du WRAP).
      3. L'image nanoBSD doit absolument utiliser une géométrie disque de 255H 63S/T. Par exemple en utilisant «UsbDevice generic-hdd 256» pour une image finale de 256Mo.
      4. Le bootloader doit être paramétré en mode nopacket, car le mode «packet» par défaut n'est pas compatible avec le BIOS du WRAP

        Si votre séquence de démarrage reste bloqué à l'affichage de nombreux «###» comme ceci:

        PC Engines WRAP.1C/1D/1E v1.11
        640 KB Base Memory
        130048 KB Extended Memory

        01F0 Master 848A SanDisk SDCFB-512                      
        Phys C/H/S 993/16/63 Log C/H/S 993/16/63

        1  FreeBSD
        2  FreeBSD
         
        F6 PXE
        Boot:  1 #############################################################################################################

        Re-vérifiez les point 3 et 4 de vos images nanoBSD.
        Par exemple, une fois la carte flash insérée dans le lecteur CF de votre poste de travail (sous FreeBSD), utilisez la commande «boot0cfg -v /dev/device» pour vérifier le mode:




        [root@d630]#boot0cfg -v /dev/da1
        #   flag     start chs   type       end chs       offset         size
        1   0x80      0:  1: 1   0xa5    111: 63:32           32       229344
        2   0x00    112:  1: 1   0xa5    223: 63:32       229408       229344
        3   0x00    224:  0: 1   0xa5    233: 63:32       458752        20480
        4   0x00    234:  0: 1   0xa5    243: 63:32       479232        20480

        version=2.0  drive=0x80  mask=0x3  ticks=182  bell=# (0x23)
        options=nopacket,update,nosetdrv
        volume serial ID 9090-9090
        default_selection=F1 (Slice 1)

        Puis vérifier que la géométrie de votre image :

        [root@d630]#fdisk /dev/da1
        ******* Working on device /dev/da1 *******
        parameters extracted from in-core disklabel are:
        cylinders=62 heads=255 sectors/track=63 (16065 blks/cyl)

        parameters to be used for BIOS calculations are:
        cylinders=62 heads=255 sectors/track=63 (16065 blks/cyl)

        (etc…)


        mardi, juin 30, 2009

        Rencontres Mondiales du Logiciel Libre 2009

        Je participerai aux Rencontres Mondiales du Logiciel Libre (RMLL) cette année car elles se déroulent sur Nantes.
        En plus de faire une présentation de FreeNAS, je serais présent sur le stand FreeBSD (sur le village associatif) toute la semaine.
        J'en profiterai pour récupérer la substantifique moelle des gurus présents, et passer dire bonjour aux utilisateurs de clavier bépo sur leur stand.

        vendredi, mars 13, 2009

        Utilisation du client DHCP FreeBSD sur une interface bridge

        Je souhaite utiliser mon PC portable dans 2 environnements différents:
        1. À la maison, ou j'utilise l'interface Ethernet native (bge0)
        2. Au bureau, ou j'insère mon portable entre mon PC bureautique et la prise murale: Connexion au PC bureautique par câble croisé sur une carte Ethernet PCMCIA (xl0) et un câble droit entre la prise murale et sur l'interface Ethernet native (bge0). Le FreeBSD réalisant un pont entre ces deux cartes réseaux.
        Et comme je ne veux pas modifier la configuration du PC à chaque fois, je souhait obtenir cette configuration «générique» dans mon /etc/rc.conf :


        cloned_interfaces="bridge0"

        ifconfig_bridge0="addm bge0 addm xl0 DHCP"

        ifconfig_bge0="up"

        ifconfig_xl0="up"
        Le problème est qu'avec cette configuration, mon interface bridge0 refuse de lancer le client DHCP!
        En effet, le client DHCP nécessite de recevoir un «link state events», ce que ne fait pas l'interface virtuelle bridge0.
        Ce problème ce résous en utilisant le mode «synchronous client» par l'utilisation du mot clé SYNCDHCP à la place de DHCP.
        Et voici au final, la configuration fonctionnelle:

        cloned_interfaces="bridge0"

        ifconfig_bridge0="addm bge0 addm xl0 SYNCDHCP"

        ifconfig_bge0="up"

        ifconfig_xl0="up"


        mercredi, février 11, 2009

        Problème avec pkg_delete (ou make deinstall) qui genère un Segmentation fault

        Je viens de tomber sur un problème avec mon tout nouveau FreeBSD 7.1: certains ports refusent de se mettre à jour car leur désinstallation ne fonctionne pas.
        En effet, pkg_delete génère un Segmentation fault (core dumped).
        Heureusement que le problème est assez facile à résoudre:
        1. Éditez le fichier /var/db/pkg/nom-du-logiciel-qui-bug/+CONTENTS
        2. Recherchez la ligne qui commence par «@pkgdep» mais qui ne contiens aucun nom de paquet à la suite
        3. Supprimez cette ligne
        Et voila! Ce mauvais fichier +CONTENTS ne devrais plus faire planter pkg_delete!

        Vous pouvez trouver plus d'info sur ce post.