Mot-clé - FreeBSD

Fil des billets

jeudi 21 août 2014

Il y a vingt ans ...

Il y a vingt ans, naissait l'arbre des ports chez FreeBSD.

Voic un extrait du commit, fait par jkh@ (Jordan Hubbard)

Commit my new ports make macros. Still not 100% complete yet by any means but fairly usable at this stage.

L'arbre des ports, est la source des binaires.

Une vidéo a été faite pour l'occasion.

Note : Cela fait maintenant deux ans, que j'ai un accès en écriture, et je prends autant de plaisir à maintenir et « porter » de nouveaux logiciels.

samedi 7 juin 2014

Exemples d'utilisation de la fonction sysctlbyname ()

Dans ce billet, nous allons voir comment afficher certaines informations obtenues avec la fonction sysctlbyname(3).

Exemple n°1

/sbin/sysctl vfs.usermount
vfs.usermount: 1

En C, on peut écrire un programme relativement simple (sysctl-01.c), qui va afficher uniquement le résultat.

gcc sysct-01.c -o sysctl-01 -Wall -W -lc
./sysctl-01
1

Exemple n°2

Si l'on souhaite afficher une chaîne de caractères.

/sbin/sysctl kern.ostype
kern.ostype: FreeBSD

Avec le programme sysctl-02.c, on procède de la manière suivante :

gcc sysct-02.c -o sysctl-02 -Wall -W -lc
./sysctl-02
FreeBSD

Exemple n°3

Maintenant, si plusieurs valeurs doivent être affichées.

/sbin/sysctl hw.acpi.supported_sleep_state
hw.acpi.supported_sleep_state: S3 S4 S5

Le programme sysctl-03.c affiche ces informations de cette manière :

gcc sysct-03.c -o sysctl-03 -Wall -W -lc
./sysctl-03
S3
S4
S5

Exemple n°4

Au lieu d'avoir une chaîne de caractères, on a une série d'entiers.

/sbin/sysctl kern.cp_times
kern.cp_times: 889624 1836 116735 3507 4424229

Le programme sysctl-04.c affiche tout ceci, de cette façon :

gcc sysct-04.c -o sysctl-04 -Wall -W -lc
./sysctl-04
Values: 889624 1836 116735 3507 4424229
Max: 4424229

Voilà, on peut désormais s'inspirer de ces exemples, pour apporter des patches aux programmes trop orientés Linux.

mardi 27 mai 2014

Quel est l'équivalent de prctl () pour les BSD avec le langage Vala ?

J'écris ce billet ici, au lieu du wiki, pour qu'il ait plus de visibiliter.

Parfois dans certains projets écris en Vala on trouve ce bout de code :

[...]

[CCode (cheader_filename = "sys/prctl.h", cname = "prctl")]
extern int prctl (int option, string arg2, ulong arg3, ulong arg4, ulong arg5);

[...]

On dénomme ce fragement par C code attribut (ou CCode attribut). Il s'agit d'une particularité de ce langage, pour utiliser directement des fonctions « externes ».

Sous Linux la fonction prctl () permet de nommer un processus (on peut le voir avec top).

Sous les BSD (DragonFly, FreeBSD, NetBSD et OpenBSD) cette fonction n'existe pas. En fait elle s'appelle autrement, setproctitle ().

Or elle n'est pas présente au même endroit dans chacun des BSD.

Sous DragonFly et FreeBSD, on la retrouve dans unistd.h.

[...]

[CCode (cheader_filename = "unistd.h", cname = "setproctitle")]
extern static void setproctitle (string fmt, ...);

[...]

Sous NetBSD et OpenBSD, on la retrouve dans stdlib.h.

[...]

[CCode (cheader_filename = "stdlib.h", cname = "setproctitle")]
extern static void setproctitle (string fmt, ...);

[...]

Voilà, désormais on peut écrire du code « portable ».

mercredi 16 avril 2014

Monitorer un média amovible sous FreeBSD ou DragonFlyBSD

Quant on est sous GNU/Linux, il existe udev, très largement utilisé sur ce système d'exploitation (SE), mais lorsque l'on utilise un système BSD, et en particulier FreeBSD il nous est impossible d'utiliser cette bibliothèque. Cependant les développeurs de FreeBSD ont développé un outil similaire devd(8).

Il est accessible via un socket unix.

J'ai voulu voir comment l'utiliser grâce aux systèmes de notifications du noyau kqueue(2)/kevent(2), avec le langage Python.

Je détaille un peu le script, tout d'abord nous allons initialiser un socket (le programme va fonctionner comme un client).

[...]
		s_file = os.path.join("/var", "run", "devd.pipe")

		# Create new socket object
		s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
		s.connect(s_file)

		# Return the socket's file descriptor
		fd = s.fileno()

[...]

fd (file descriptor) est nécessaire pour kevent.

Les fonctions utilisées par kqueue/kevent sous Python sont accessible via le module select. Nous allons uniquement lire les données qui transitent par /var/run/devd.pipe.

Ci-dessous l'initialisation du mécanisme de notification.

[...]
				# Kernel queue object
				kq = select.kqueue()

				# Event to monitor (only attach)
				event = [select.kevent(fd, filter=select.KQ_FILTER_READ, flags=select.KQ_EV_ADD),]

				# Initialize kevent structure (like EV_SET macro in sys/event.h)
				ev_set = kq.control(event, 0, 0)
[...]

Nous pouvons « boucler » pour afficher les résultats quand un périphérique est branché. Un truc magique avec kqueue/kevent on a directement accès à la taille du tampon à lire.

[...]
						for event in events:
								# Display data from socket (event.data is size to read)
								print s.recv(event.data)
[...]

Voici le résultat lorsqu'une clé USB est branchée.

!system=DEVFS subsystem=CDEV type=CREATE cdev=usb/2.2.0
!system=DEVFS subsystem=CDEV type=CREATE cdev=ugen2.2

!system=DEVFS subsystem=CDEV type=CREATE cdev=usb/2.2.1
!system=DEVFS subsystem=CDEV type=CREATE cdev=usb/2.2.2

!system=USB subsystem=DEVICE type=ATTACH ugen=ugen2.2 cdev=ugen2.2 vendor=0x0930
 product=0x653d devclass=0x00 devsubclass=0x00 sernum="0B4085607142DAD4" release
=0x0100 mode=host port=6 parent=ugen2.1
!system=USB subsystem=INTERFACE type=ATTACH ugen=ugen2.2 cdev=ugen2.2 vendor=0x0
930 product=0x653d devclass=0x00 devsubclass=0x00 sernum="0B4085607142DAD4" rele
ase=0x0100 mode=host interface=0 endpoints=2 intclass=0x08 intsubclass=0x06 intp
rotocol=0x50
+umass0 at bus=1 hubaddr=6 port=2 devaddr=2 interface=0 vendor=0x0930 product=0x
653d devclass=0x00 devsubclass=0x00 sernum="0B4085607142DAD4" release=0x0100 mod
e=host intclass=0x08 intsubclass=0x06 intprotocol=0x50  on uhub2

!system=DEVFS subsystem=CDEV type=CREATE cdev=pass2

!system=DEVFS subsystem=CDEV type=CREATE cdev=da0

!system=DEVFS subsystem=CDEV type=CREATE cdev=da0s1

La dernière ligne est intéressante, car c'est le nom de la partition que l'on pourra « monter » sur le système.

jeudi 21 novembre 2013

Two WebKittens dans le « ports tree »

« Two WebKittens » (Midori 0.5.6) est désormais dans l'arbre des ports de FreeBSD. Je viens de committer la mise à jour.

Cette nouvelle version a été retardée notamment à cause de la ré-écriture du gestionnaire de session (il s'appelle désormais tabby), Libunique a été remplacée par GApplication.

Concernant l'intégration dans FreeBSD, j'ai rajouté la possibilité de pouvoir l'installer avec le support de Gtk+3 (Gtk+2 est toujours le choix par défaut).

Le support de WebKit2 est également activé (pour l'instant c'est désactivé, mais quand www/webkit-gtk3 sera mis à jour, on pourra compiler avec ce support).

Je n'ai pas mis le support pour granite, j'ai noté un bug ennuyeux.

Pour connaître toutes les modifications apportées depuis la précédente version, vous pouvez parcourir le ChangeLog.

Lundi 3 décembre 2012

Thunar 1.6.0 sous FreeBSD

Vous souhaitez installer la dernière version de Thunar [1] (1.6.0) sous FreeBSD, et bien réjouissez-vous c'est possible.

Note

[1] Il s'agit du gestionnaire de fichiers sous Xfce.

Lire la suite...

Dimanche 17 juin 2012

Installer FreeBSD, avec mfsBSD [part. 2]

logo FreeBSD

Ce billet est la suite du précédent.

Cette fois-ci, nous allons utilisé une table de partitionnement de type GPT.

Lire la suite...

Installer FreeBSD, avec mfsBSD

logo FreeBSD

Dans ce billet, nous allons voir comment installer FreeBSD avec le live CD mfsBSD.

J'ai choisit la version 8.3.

Lire la suite...

mardi 22 mai 2012

Migration vers FreeBSD 9 enfin terminée

logo FreeBSD

Ce week-end, j'ai décidé de migrer sous la branche releng/9.0 [1] mon laptop. Il fonctionnait auparavant sur la branche releng/8.2 [2].

Il faut dire, que ça me titiller depuis un moment, car je n'étais pas satisfait du partitionnement actuel (absence de répertoire /tmp en RAM), locales toutes en latin9 (je migre de plus en plus vers l'UTF-8). J'en ai profité pour repartir complètement de zéro.

Le partitionnement a bien changé depuis ma dernière installation (à partir d'un CD), qui remonte à la version 6.0. Résultat, au redémarrage l'ordinateur est dans les choux. Je reboote avec le disque d'installation, et recommence l'installation, là l'installateur me sort une erreur, m'indiquant que la partition /dev/ada0p2 est introuvable !!! C'est ma partition racine.

Le lendemain, je recommence, avec cette fois-ci la dernière version de la branche RELENG_7 (7.4). Aucun soucis, car il s'agit de l'ancien installeur (sysinstall). Je migre ensuite vers releng/8.3, je redémarre, l'ordinateur est « planté », j'ai un prompt pour m'aider à booter sur la bonne partition. C'est encore une fois un nouvel échec.

Aujourd'hui, j'ai décidé de prendre le taureau par les cornes, et de tenter une nouvelle installation, et apprivoiser bsdinstall, le nouvel assistant du CD d'installation.

Après avoir sélectionné la bonne disposition du clavier, je suis ensuite passé par le shell, afin de voir l'état du disque dur, avec la commande gpart show (j'ai qu'un seul disque, donc ce n'est pas nécessaire de le mentionner).

En voulant supprimer les précédentes partitions, j'ai obtenu le message d'erreur suivant :

# gpart delete -i 4 ada0
gpart: table 'ada0' is corrupt: Operation not permitted

Après quelques recherches, il faut exécuter le mode recover.

# gpart recover ada0
ada0 recovered

Maintenant la suppression des partitions ne pose plus de problème

[...]
# gpart delete -i 3 ada0
ada0p3 deleted
[...]

J'ai également supprimé la table des partitions MBR. J'ai décidé de migrer sous GPT.

# gpart destroy ada0
ada0 destroyed

# gpart create -s GPT ada0

Une vérification que tout s'est bien passé.

# gpart show
=>       34  195371501  ada0  GPT  (93G)
    	 34  195371501        - free -  (93G)

Création de la partition de boot pour l'entête GPT.

# gpart add -t freebsd-boot -l gpboot -s 512K ada0
ada0p1 added

On installe le bootcode.

# gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 ada0
bootcode written to ada0

Ensuite on passe à la création des partitions.

# gpart add -t freebsd-ufs -l root -s 5G ada0
ada0p2 added
# gpart add -t freebsd-swap -l swap -s 1G ada0
ada0p3 added
# gpart add -t freebsd-ufs -l var -s 3G ada0
ada0p4 added
# gpart add -t freebsd-ufs -l usr -s 62G ada0
ada0p5 added
# gpart add -t freebsd-ufs -l home ada0
ada0p6 added

Au final cela donne ça :

# gpart show
=>       34  195371501  ada0  GPT  (93G)
         34       1024     1  freebsd-boot  (512k)
       1058   10485760     2  freebsd-ufs  (5.0G)
   10486818    2097152     3  freebsd-swap  (1.0G)
   12583970    6291456     4  freebsd-ufs  (3.0G)
   18875426  130023424     5  freebsd-ufs  (62G)
  148898850   46472685     6  freebsd-ufs  (22G)

En quittant le shell on retrouve l'assistant pour continuer l'installation.

À la fin, je suis retourné sous le shell (on est directement dans le chroot de notre nouveau système) pour modifier le fichier /etc/fstab et /etc/rc.conf.

Notes

[1] Afin de pouvoir utiliser la dernière version Xorg.

[2] La fin du support des mises à jour de sécurité approchant à grand pas.

samedi 21 avril 2012

ACPI et FreeBSD

logo du système d'exploitation, FreeBSD

En ce moment, je travaille sur l'intégration de la prochaine version stable (4.10) de Xfce sous FreeBSD.

Un des composants, xfce4-session gère l'hibernation et le suspend to RAM (mise en veille). J'ai donc voulu voir, comment cela été pris en charge par FreeBSD.

L'essais a été effectué sur :

olivier@bornem:~ $ uname -rsp                                   
FreeBSD 8.2-RELEASE-p3 i386
olivier@bornem:~ $ 

État des lieux

Il faut savoir, que par défaut l'ACPI est déjà activé [1]. Cependant on doit rechercher les informations concernant les différentes méthodes de mise en veille.

olivier@bornem:~ $ sysctl -a | grep acpi.supported                  
hw.acpi.supported_sleep_state: S3 S4 S5
olivier@bornem:~ $ 

Sur cet ordinateur, on peut voir que trois états (sleep states) sont « pris en charge » par le système.

On peut également voir, si le BIOS est capable de le gérer.

olivier@bornem:~ $ sysctl -a | grep acpi.s4bios                     
hw.acpi.s4bios: 0
olivier@bornem:~ $ 

Dans mon cas, la valeur est à zéro, donc mon BIOS n'a pas ce support.

On peut tester les différents états (il faut être root) avec l'utilitaire acpiconf.

root@bornem:~ # acpiconf -s 3 

L'état S4 (correspondant à l'hibernation) est équivalent à S5, j'en déduis donc que je ne pourrais pas utiliser cette fonctionnalité.

L'état S3 (suspend to RAM) est pleinement fonctionnel.

Intégration avec le gestionnaire de bureau

xfce4-session possède une dépendance, UPower [2], responsable de la gestion de la consommation (en autre).

Pour pouvoir l'employer, il faut autoriser certaines opérations, grâce notamment à polkit.

On va tout d'abord rechercher les actions possibles concernant UPower.

olivier@bornem:~ $ pkaction | grep upower                           
org.freedesktop.upower.hibernate
org.freedesktop.upower.qos.cancel-request
org.freedesktop.upower.qos.request-latency
org.freedesktop.upower.qos.request-latency-persistent
org.freedesktop.upower.qos.set-minimum-latency
org.freedesktop.upower.suspend
olivier@bornem:~ $ 

J'ai uniquement besoin du support de suspend, j'en profite donc pour créer un fichier .pkla (l'extension est primordiale) situé dans /usr/local/etc/polkit-1/localauthority/50-local.d/.

Voici son contenu :

root@bornem:~ # cat /usr/local/etc/polkit-1/localauthority/50-local.d/org.freedesktop.upower.pkla 
[Suspend]
Identity=unix-group:users
Action=org.freedesktop.upower.suspend
ResultAny=yes
ResultInactive=yes
ResultActive=yes
root@bornem:~ # 

Tous les utilisateurs appartenant au groupe users sont autorisés à mettre en veille (en RAM) le système.

Notes

[1] Si l'on démarre avec les paramètres prédéfinis.

[2] Cette bibliothèque n'est pas fonctionnelle sous tous les BSD

- page 2 de 3 -