FreeBSD: poudriere cross compiling (ARM)

Poudriere permet de réaliser du cross compiling et donc de compiler des cibles d'une autre architecture. Nous allons ici prendre l'exemple d'une architecture amd64 cross-compilant vers ARM6 pour un Raspberry PI 2.

Préparation de la jail poudrière

Tout d'abord on va télécharger une image RPI2 viable depuis le miroir FreeBSD puis la décompresser

fetch http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/11.0/FreeBSD-11.0-RELEASE-arm-armv6-RPI2.img.xz
unxz FreeBSD-11.0-RELEASE-arm-armv6-RPI2.img.xz

On va ensuite la rendre disponible au niveau filesystem grâce à l'utilitaire mdconfig

mdconfig -a -t vnode -f FreeBSD-11.0-RELEASE-arm-armv6-RPI2.img
mount /dev/md0s2a /mnt

On va maintenant supprimer le flag pour le firstboot (inutile ici nous serons dans une jail de build) et créer le répertoire /usr/local/bin pour poudriere

rm /mnt/firstboot
mkdir -p /mnt/usr/local/bin

L'image est maintenant prête on va créer l'archive pour poudriere:

tar -cpf /tmp/FreeBSD-11.0-RELEASE-arm-armv6-RPI2.tar .

Nous pouvons maintenant créer la jail

poudriere jail -c -j 11-arm6 -m tar=/tmp/FreeBSD-11.0-RELEASE-arm-armv6-RPI2.tar -a arm.armv6 -v 11.0-RELEASE

Support de la compilation ARM

Tout d'abord on va avoir besoin de qemu-user-static pour réaliser cette cross compilation. Il a 2 avantages:

  • Il n'a pas de dépendances particulières
  • Le binaire étant statique il va permettre à poudrière de s'éxecuter correctement sans devoir copier des librairies dynamiques supplémentaires dans la jail
pkg install qemu-user-static

Ajoutez maintenant l'émulateur ARM aux interpréteurs utilisables par poudriere

binmiscctl add armv6 --interpreter "/usr/local/bin/qemu-arm-static"
      --magic
      "\x7f\x45\x4c\x46\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00"
      --mask
      "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff"
      --size 20 --set-enabled

Cross-compiling !

L'environnement est prêt, il ne reste plus qu'à lancer la compilation, par exemple de zsh

poudriere bulk -j 11-arm6 -p default shells/zsh
 [00:00:00] ====>> Cross-building ports for arm.armv6 on amd64 requires QEMU
 [00:00:00] ====>> Creating the reference jail... done
 [00:00:00] ====>> Mounting system devices for 11-arm6-default
 [00:00:00] ====>> Mounting ports/packages/distfiles
 [00:00:00] ====>> Using packages from previously failed build
 [00:00:00] ====>> Mounting packages from: /usr/local/poudriere/data/packages/11-arm6-default
 [00:00:00] ====>> Copying /var/db/ports from: /usr/local/etc/poudriere.d/11-arm6-options
 [00:00:00] ====>> Raising MAX_EXECUTION_TIME and NOHANG_TIME for QEMU
 [00:00:00] ====>> Copying latest version of the emulator from: /usr/local/bin/qemu-arm-static
 /etc/resolv.conf -> /usr/local/poudriere/data/.m/11-arm6-default/ref/etc/resolv.conf
 [00:00:00] ====>> Starting jail 11-arm6-default
 [00:00:01] ====>> Logs: /usr/local/poudriere/data/logs/bulk/11-arm6-default/2017-01-13_22h51m51s
 [00:00:01] ====>> Loading MOVED
 [00:00:02] ====>> Calculating ports order and dependencies
 [00:00:32] ====>> Sanity checking the repository
 [00:00:32] ====>> Checking packages for incremental rebuild needed
 [00:00:32] ====>> Deleting stale symlinks
 [00:00:32] ====>> Deleting empty directories
 [00:00:32] ====>> Cleaning the build queue
 [00:00:33] ====>> Recording filesystem state for prepkg... done
 [00:00:33] ====>> Building 36 packages using 2 builders
 [00:00:33] ====>> Starting/Cloning builders
 [00:00:35] ====>> Hit CTRL+t at any time to see build progress and stats
 [00:00:35] ====>> [01][00:00:00] Starting build of ports-mgmt/pkg

Votre jail de cross compilation est maintenant opérationnelle, vous pouvez compiler sur un vrai CPU et ne plus attendre des jours que votre Raspberry PI compile X11.

Gestion de LetsEncrypt sous FreeBSD avec nginx et une jail

LetsEncypt est une autorité de certification utilisant une API basée sur des appels HTTP et un client côté serveur qui va générer des tokens lus par les serveurs LetsEncrypt. Nous allons ici voir une architecture LetsEncrypt typique dans laquelle nous allons utiliser le client acme-client d'OpenBSD disponible dans les ports et les packages FreeBSD.

Installation

Dans un premier temps installez le client sur votre machine hôte (et pas votre jail web):

pkg install acme-client

Configuration de nginx

Nous allons maintenant configurer nginx afin de pouvoir interagir avec l'API letsencrypt. Créez tout d'abord le répertoire suivant dans votre jail avec l'utilisateur et le groupe nobody

mkdir /usr/local/www/.well-known && chown nobody:nobody /usr/local/www/.well-known

Ensuite configurez vos virtual hosts afin de faire pointer les appels vers /.well-known dans ce répertoire:

server {
        listen 80;
        server_name www.unix-experience.fr;
        location /.well-known {
            alias /usr/local/www/.well-known;
        }
        location / {
            return 301 https://www.unix-experience.fr$request_uri;
        }
        add_header X-Frame-Options "DENY";
        add_header Strict-Transport-Security "max-age=86400; preload";
}

Note: nous ajoutons ici le support du protocole HSTS avec un TTL d'1 journée spécifiant aux navigateurs que le site supporte SSL et qu'il faudrait passer dessus. Vous pouvez sans souci faire pointer plusieurs de vos virtual hosts dans ce même répertoire.

Configuration du client LetsEncrypt

Retournez maintenant sur votre hôte et créez le fichier /usr/local/etc/acme/domains.txt puis ajoutez y un domaine par ligne:

www.unix-experience.fr
ftp.unix-experience.fr

Créez ensuite le script ci-dessous (basé sur le script présent dans le même répertoire sous forme d'exemple) dans /usr/local/etc/acme/acme-client.sh

#!/bin/sh -e
WEBJAIL="web"
BASEDIR="/usr/local/etc/acme"
SSLDIR="/usr/local/etc/ssl/acme"
DOMAINSFILE="${BASEDIR}/domains.txt"
CHALLENGEDIR="/jails/${WEBJAIL}/usr/local/www/.well-known/acme-challenge"

[ ! -d "${SSLDIR}/private" ] && mkdir -pm700 "${SSLDIR}/private"

cat "${DOMAINSFILE}" | while read domain line ; do
   CERTSDIR="${SSLDIR}/${domain}"
   [ ! -d "${CERTSDIR}" ] && mkdir -pm755 "${CERTSDIR}"
   set +e # RC=2 when time to expire > 30 days
   acme-client -b -C "${CHALLENGEDIR}" \
               -k "${SSLDIR}/private/${domain}.pem" \
               -c "${CERTSDIR}" \
               -n -N -v \
               ${domain} ${line}
   RC=$?
   set -e
   [ $RC -ne 0 -a $RC -ne 2 ] && exit $RC
done

Ce script lit les domaines présents dans le fichier domains.txt puis il va s'occuper de créer vos clefs privées et de les faire signer par LetsEncrypt, en se basant sur le répertoire .well-known présent dans votre jail. Une fois ce script exécuté, si tout s'est passé correctement vous trouverez votre clef privée dans le répertoire /usr/local/etc/ssl/acme/private/example.org et votre clef publique et les chaînes de certificats dans le répertoire /usr/local/etc/ssl/acme/example.org. Ces répertoires sont situés sur votre hôte et non dans votre jail web. Pour déployer les scripts un script d'exemple est présent dans le répertoire /usr/local/etc/**acme, mais nous allons légèrement le modifier. Créez le fichier /usr/local/etc/acme/deploy.sh**:

#!/bin/sh

set -e

BASEDIR="/usr/local/etc/acme"
DOMAINSFILE="${BASEDIR}/domains.txt"
LEDIR="/usr/local/etc/ssl/acme"
JAILSDIR="/jails"
TARGETS="web"
cat "${DOMAINSFILE}" | while read domain line ; do
    for jail in ${TARGETS}; do
        targetdir="${JAILSDIR}/${jail}/etc/ssl"
        # Check if the certificate has changed
        [[ -z "`diff -rq ${LEDIR}/${domain}/fullchain.pem ${targetdir}/certs/${domain}.pem`" ]] && continue
        cp -L "${LEDIR}/private/${domain}.pem"   "${targetdir}/private/${domain}.pem"
        cp -L "${LEDIR}/${domain}/fullchain.pem" "${targetdir}/certs/${domain}.pem"
        chmod 400 "${targetdir}/private/${domain}.pem"
        chmod 644 "${targetdir}/certs/${domain}.pem"
        # Restart/-load relevant services
        [[ "${jail}" = "web" ]] && jexec ${jail} service nginx restart
    done
done

Ce script va copier tous les certificats associés à vos dernières négociations LetsEncrypt et va les déployer dans votre jail web puis redémarrer nginx.

Renouvellement automatique

Pour finir il ne reste plus qu'à configurer le cron ajouté par le paquet acme-client afin de configurer la tâche hebdomadaire. Pour se faire, éditez le fichier /usr/local/etc/periodic.conf et ajoutez les entrées suivantes:

# letsencrypt
weekly_acme_client_enable="YES"
weekly_acme_client_user="nobody"
weekly_acme_client_deployscript="/usr/local/etc/acme/deploy.sh"

Cela va vous permettre d'activer le cron, et de lancer le déploiement automatiquement toutes les semaines.

Conclusion

Vous pouvez désormais faire des demandes de certificats LetsEncrypt facilement et les renouveler automatiquement via un cron fourni par acme-client.

Installer et utiliser powerline sur Archlinux et FreeBSD

Powerline est un excellent module qui peut se greffer sur votre shell favori, sur vim et sur tmux. Il permet d'ajouter une couche dynamique intéressante sur les outils précédents en ajoutant de la colorisation et des états à votre shell, tmux ou vim. vim powerline

Installation

Sur votre Archlinux installez les paquets suivants:

pacman -S powerline powerline-vim powerline-fonts

Note: si votre Archlinux est un serveur (ce que je ne recommande pas), n'installez pas les fonts Sur FreeBSD installez les paquets suivants:

pkg install py27-powerline-status powerline-fonts py27-psutils

Note: si votre FreeBSD utilise une version de python par défaut différence, par exemple Python 3.5, changez les noms de paquets par py35-powerline-status et py35-psutils. Si votre FreeBSD est un serveur vous n'avez pas besoin des fonts.

Intégration tmux

tmux est un excellent remplaçant au vénérable screen. Il supporte très bien powerline. Pour activer le support powerline dans tmux, éditez le fichier tmux.conf(~/.tmux.conf pour votre utilisateur uniquement, en global: /etc/tmux.conf sous Linux, /usr/local/etc/tmux.conf sous FreeBSD) et ajoutez la ligne suivante.

Archlinux

source /usr/lib/python3.6/site-packages/powerline/bindings/tmux/powerline.conf

FreeBSD

source /usr/local/lib/python2.7/site-packages/powerline/bindings/tmux/powerline.conf

Note: la version de Python est peut être à changer dans ce chemin, sous FreeBSD cela dépend de la version de Python par défaut sur votre repository, sous Archlinux il se peut que cela devienne Python 3.6 ou plus lorsqu'il sortira. Lancez maintenant un nouveau tmux ou lancez la commande suivante dans un nouveau tmux (après avoir appuyé sur CTRL+B)

:source-file

Résultat:tmux powerlineIntégration ZSH

Pour intégrer powerline sur ZSH il vous faudra simplement sourcer powerline dans le fichier ~/.zshrc de l'utilisateur concerné Sous Archlinux

source /usr/lib/python3.6/site-packages/powerline/bindings/zsh/powerline.zsh

Sous FreeBSD

source /usr/local/lib/python2.7/site-packages/powerline/bindings/zsh/powerline.zsh

Résultat sur un shell local:

powerline-zsh-local

Intégration BASH

Pour bash c'est la même chose, sourcez powerline dans le fichier ~/.bashrc de votre utilisateur: Sous Archlinux:

source /usr/lib/python3.6/site-packages/powerline/bindings/bash/powerline.sh

Sous FreeBSD:

source /usr/local/lib/python2.7/site-packages/powerline/bindings/bash/powerline.sh

Résultat sur un shell distant, en SSH:powerline-bash-ssh

Intégration VIM

Enfin il nous reste à l'implémenter dans vim éditez le fichier ~/.vimrc si vous souhaitez l'activer pour votre utilisateur ou /etc/vim/vimrc (/usr/local/etc/vim/vimrc sous FreeBSD) si vous souhaitez les modifications en global. Ajoutez les lignes suivantes:

set laststatus=2
set t_Co=256

Si vous utilisez un vim compilé pour Python 3, ajoutez la ligne suivante:

let g:powerline_pycmd="py3"

Enfin, uniquement sous FreeBSD vous devrez ajouter la ligne suivante dans votre vimrc:

set rtp+=/usr/local/lib/python2.7/site-packages/powerline/bindings/vim/

Installer sonatype/nexus sous FreeBSD

Sonatype/Nexus est un logiciel écrit en JAVA permettant d'offrir une puissance interface de gestion à vos développeurs JAVA pour gérer leurs repositories au format Maven. Sonatype fournit des packages permettant d'installer une version embarquée de nexus utilisant Jetty pour Linux, Solaris, Windows et Mac OSX, mais pas FreeBSD. Il n'est pas non plus disponible dans l'arbre de ports.

Préparation de l'OS

Nous allons utiliser la couche d'emulation Linux 32bits afin de pouvoir lancer le wrapper linux de nexus, en espérant une version native FreeBSD un jour. Dans un premier temps on charge le module de compatibilité linux et on l'active au démarrage

kldload linux
sysrc linux_enable=YES

Puis on déclare utiliser un kernel 2.6.32

sysctl compat.linux.osrelease=2.6.32
echo "compat.linux.osrelease=2.6.32" > /etc/sysctl.conf

Enfin on installe le port de compatiblité centos6

cd /usr/ports/emulator/linux_base-c6
make install

ou encore au format binaire

pkg install linux_base-c6

Téléchargement et extraction

Téléchargez la dernière version de nexus présente ici.

fetch http://download.sonatype.com/nexus/oss/nexus-2.11.1-01-bundle.tar.gz

On va maintenant créer le répertoire d'installation de nexus

mkdir -p /usr/local/sonatype /usr/local/sonatype-work

Et enfin on extrait l'archive

tar xvzf nexus-2.11.1-01-bundle.tar.gz -C /usr/local/sonatype

Droits

Afin de lancer proprement nexus, nous allons utiliser l'utilisateur www et le groupe www. On applique les droits sur les répertoires dans lesquels nexus a besoin d'écrire

chown -R www:www /usr/local/sonatype/nexus-2.11.1-01/logs
chown -R www:www /usr/local/sonatype/nexus-2.11.1-01/tmp
chown -R www:www /usr/local/sonatype/sonatype-work

Tricher avec le lanceur

On va faire croire au lanceur que notre version de FreeBSD est en fait un Linux 32 bits afin de pouvoir utiliser le wrapper et la couche d'émulation Linux 32 bits.

ln -s /usr/local/sonatype/nexus-2.11.1-01/bin/jsw/linux-x86-32/ /usr/local/sonatype/nexus-2.11.1-01/bin/jsw/freebsd-x86_64

Enfin on créer un fichier de PID qu'on va attribuer à l'utilisateur www /usr/local/sonatype/nexus-2.11.1-01/bin/../bin/jsw/freebsd-x86-64/nexus.pid

touch /usr/local/sonatype/nexus-2.11.1-01/bin/../bin/jsw/freebsd-x86-64/nexus.pid
chown www:www /usr/local/sonatype/nexus-2.11.1-01/bin/../bin/jsw/freebsd-x86-64/nexus.pid

Lanceur FreeBSD

Pour finir on créée un fichier de démarrage /usr/local/etc/rc.d/nexusd

#!/bin/sh
#

# PROVIDE: nexusd
# REQUIRE: LOGIN
# BEFORE:  securelevel
# KEYWORD: shutdown

# Add the following lines to /etc/rc.conf to enable `nexusd':
#
# nexusd_enable="YES"
#

. /etc/rc.subr

name="nexusd"
rcvar=nexusd_enable

command="/usr/local/sonatype/nexus-2.11.1-01/bin/nexus"
mypidfile="/usr/local/sonatype/nexus-2.11.1-01/bin/jsw/freebsd-x86-64/nexus.pid"
nexusd_user="www"

start_precmd="nexus_precmd"
start_arg=$1

# read configuration and set defaults
load_rc_config "$name"
: ${nexusd_enable="NO"}

nexus_precmd()
{
    touch $mypidfile
    chown $nexusd_user $mypidfile
}

if [ "$start_arg" = "quietstart" ]; then
    start_arg="start"
fi

command_args="$start_arg"
run_rc_command "$start_arg"

On lui attribue les droits d'exécution et on peut désormais lancer nexus

chmod +x /usr/local/etc/rc.d/nexusd
sysrc nexusd_enable=YES
service nexusd start

Conclusion

Vous pouvez désormais installer nexus sur vos serveurs FreeBSD. L'installation n'est pas triviale mais cela a le mérite de fonctionner.

Créer son serveur minetest sous FreeBSD

Minetest est un clone libre de Minecraft rédigé en C++ utilisant le moteur Irrlicht. Il dispose d'une partie cliente et d'une partie serveur.

La partie serveur de Minetest utilise des fichiers et une base SQLite pour héberger ses données (notamment la carte).

Installation

L'installation du serveur minetest se fait en deux temps, il faut installer d'une part le moteur Minetest (APIs, fonctionnalités...) et d'autre part la partie intelligente du jeu. Les options par défaut des packages FreeBSD officiels ne sont pas satisfaisantes pour faire un serveur, nous utiliserons les ports.

Dans un premier temps installez le port games/minetest avec les options suivantes:

Minetest options

cd /usr/ports/games/minetest/
make install

Puis installez le port games/minetest_game (à vous de choisir si vous voulez la documentation ou non)

cd /usr/ports/games/minetest_game/
make install

Configuration

La configuration du serveur Minetest s'effectue au niveau du fichier /usr/local/etc/minetest.conf.

Changez tout d'abord le nom d'utilisateur du superutilisateur du serveur. C'est lui qui pourra donner les droits à d'autres utilisateurs. Une fois en jeu n'oubliez pas de changer son mot de passe via le menu dédié !

name = superminetest

On va ensuite changer quelques options administratives, le nom du serveur, son adresse, l'URL web et le message de connexion

server_name = Minetest UnixExperience (FR)
server_address = minetest.unix-experience.fr
server_url = http://mintest.unix-experience.fr
motd = Welcome to UnixExperience Minetest Server

Passons maintenant à la configuration réseau. Vous pouvez changer le port et optionellement l'adresse d'écoute, si vous disposez de plusieurs interfaces réseau (autrement le serveur écoute sur toutes les interfaces). Vous pouvez également modifier la limite de joueurs connectés.

port = 30000
bind_address = 8.8.9.34
max_users = 100

Si vous souhaitez que votre serveur s'annonce sur la liste de serveurs publique, spécifiez l'option suivante:

server_announce = 1

Passons maintenant à la configuration du mode de jeu du serveur.

L'option creative_mode permet d'active le mode créatif. Si elle est à false, vous serez en mode survie.

Vous pouvez également activer/désactiver les dommages et le JcJ.

creative_mode = false
enable_damage = true
enable_pvp = false

Le cycle jour/nuit et saisons est personnalisable, il suffit de faire varier les options time_speed et year_days:

time_speed = 72
year_days = 365

Pour savoir comment calculer la durée réelle en secondes d'une journée en jeu voici la formule:

1 jour en jeu = 86400/time_speed secondes

Enfin, si vous souhaitez rendre votre serveur un peu plus autonome, vous pouvez donner des droits par défaut à vos joueurs (ici: interagir, casser, aller vite et voler)

default_privs = interact, shout, fast, fly

Modding

Le modding permet d'ajouter des fonctionnalités à vos serveurs Minetest. L'avantage de Minetest par rapport à Minecraft est la possibilité quasi infinie de modder côté serveur, permettant aux clients de bénéficier d'un ensemble de fonctionnalités très larges et de textures et modèles personnalisés sans rien installer sur le client.

Pour installer un mod, extrayez le dans le répertoire /usr/local/share/minetest/games/minetest_game/mods puis activez le en ajoutant la ligne suivante dans le fichier world.mt de votre monde présent par défaut dans /var/db/minetest/world (remplacez homedecor_modpack par le nom du répertoire extrait)

load_mod_homedecor_modpack = true

Conclusion

Vous savez désormais comment installer et configurer un serveur minetest avec des mods sous FreeBSD, il est temps de terraformer !

Compiler une application Android avec Jenkins sous FreeBSD

Jenkins est un outil d'intégration continue permettant de compiler et valider des applications. Il s'intègre avec diverses applications, que ce soit JAVA, C/C++ ou bien d'autres langages. Nous allons ici étudier la compilation d'une application Android sous FreeBSD, celle-ci nécessitant un peu de tuning.

Prérequis

Installez tout d'abord les paquets jenkins, gradle, apache-ant et linux_base-c6 et bash

pkg install jenkins gradle linux_base-c6 bash apache-ant

Configuration du système

Créez ensuite un lien symbolique pour bash dans /bin

ln -s /usr/local/bin/bash /bin/bash

Configuration du SDK Android

Téléchargez ensuite le SDK Android ici et extrayez le dans /usr/local

cd /usr/local
tar xvzf android-sdk_r24.0.2-linux.tgz

Lancez la commande suivante afin de visualiser les SDK dont vous avez besoin:

/usr/local/android-sdk-linux/tools/android list sdk -u

Puis téléchargez les composants qui vous intéressent (ici toutes les API de Android 4.0 à 5.0)

/usr/local/android-sdk-linux/tools/android update sdk --filter 1,2,4,5,6,7,8,9,10,11,34,35,36,37,38,39,40,41,42 -u

Téléchargez maintenant les outils de compilation Android, puisque le SDK Android ne reconnait pas encore FreeBSD et copiez les dans le répertoire dédié du SDK (changez la version dans le répertoire final par celle que vous avez)

https://dl-ssl.google.com/android/repository/build-tools_r21.1-linux.zip
unzip build-tools_r21.1-linux.zip
cp -R android-5.0/* /usr/local/android-sdk-linux/build-tools/21.1.2/

Enfin changez les droits sur le SDK Android afin d'autoriser jenkins à utiliser tous les outils.

chown -R jenkins:jenkins /usr/local/android-sdk-linux

Configuration de Jenkins

Lancez maintenant le service Jenkins et connectez vous à l'URL http://jenkins.instance:8180

service jenkins start

Créez ensuite un nouveau projet en mode FreeStyle, configurez votre repository source et les options de compilation suivantes: Jenkins AndroidCelles ci vont configurer le fichier local.properties pour gradle, mettre à jour le projet si nécessaire puis appeler ANT afin d'effectuer le build android.

Conclusion

Vous pouvez désormais compiler vos applications Android avec FreeBSD. Veuillez noter que la configuration reste très proche sous Linux, à l'exception de la couche émulation.

Sources

https://wiki.jenkins-ci.org/display/JENKINS/Building+an+Android+app+and+test+project http://zewaren.net/site/?q=node/125

Fail2ban sous FreeBSD

Fail2ban est un outil en python très pratique qui va inspecter vos logs de connexion afin de bannir des adresses IP au niveau de votre pare-feu. Si l'intégration au niveau de Linux se fait facilement, sous FreeBSD elle nécessite un petit peu plus de modifications. Nous allons ici intégrer fail2ban avec Packet Filter sous FreeBSD.

Installation

Installez tout d'abord le package/port py27-fail2ban

pkg install py27-fail2ban

ou

cd /usr/ports/security/py-fail2ban
make install

Configuration

Nous ne configurerons pas ici la base de PF, nous considérerons que vous avez déjà un Packet Filter opérationnel. On va dans un premier temps configurer votre Packet Filter afin de créer un conteneur d'adresses bloquées. En haut de votre fichier /etc/pf.conf créez une table persistante (elle ne sera pas effacée à chaque rechargement des règles PF)

table <banssh> persist

Créez ensuite une règle de blocage précédant votre règle d'autorisation fail2ban block in quick inet proto tcp from to self port ssh pass in quick inet proto tcp to self port ssh On va maintenant créer un filtre fail2ban associé à SSH et le binder sur PF. Créez le fichier /usr/local/etc/fail2ban/jail.d/ssh-pf.conf et associez lui le contenu suivant.

[ssh-pf]
enabled  = true
filter   = sshd
action   = pf
logpath  = /var/log/auth.log
findtime  = 600
maxretry = 3
bantime  = 86400

On créée ici un filtre sur le démon sshd qui va effectuer l'action pf. On bannit ici pour une durée d'une journée (86400 secondes) Modifiez ensuite le fichier /usr/local/etc/fail2ban/action.d/pf.conf en éditant la ligne tablename

tablename = banssh

Enfin activez et lancez le service fail2ban

sysrc fail2ban_enable=YES
service fail2ban start

Vérifier les IP bloquées

Pour vérifier les adresses IP bloquées, interrogez la table PF de la manière suivante

pfctl -t banssh -T show

[Serveur Dédié] Nginx – Owncloud

Introduction

Nous revoilà avec un nouvel article consacré à l’auto-hébergement via un serveur dédié.

Dans cette article nous allons voir plus en détail le déploiement du serveur web Nginx avec sa configuration, nous finirons par l’installation d’Owncloud. Nous utilisons dans cet article un serveur FREEBSD 9.2.

http://nginx.org/nginx.gif 

Owncloud est un logiciel open-source offrant des services de stockages, partages de fichiers et applications diverses comme un service Sync pour navigateur Firefox.Owncloud est une solution à la fois public et privé de part ces possibilités d’intégrations dans un annuaire LDAP ou Active Directory. Continuer à lire

[Serveur Dédié] Serveur Mail

Introduction

Dans cette article nous allons voir la mise en place d’un serveur mail utilisant OpenSMTPD comme service SMTP et Dovecot en tant que service IMAP ainsi que Roundcube comme webmail.

OpenSMTPD a été vu dans un précédent article.

Dovecot est un service permettant la mise en place de serveur imap ou pop3. Dovecot a été vu sur ce site sur ce lien.

Nous allons présenter la configuration de OpenSMTPD ainsi que celle de Dovecot puis nous détaillerons les modifications qui on été nécessaires au fonctionnement des deux services ainsi que son utilisation d’un point de vue utilisateur via le déploiement de Roundcube sur un serveur web Nginx hébergé  par FreeBSD 9.2. Continuer à lire

Postfix: support natif de SPF

La vérification SPF permet de s'assurer que le MTA distant a bien le droit d'émettre pour un nom de domaine donné.

SPF se base sur un enregistrement TXT à la racine du domaine émetteur définissant des autorisations d'émissions comme par exemple autoriser certaines IP à émettre et interdire les autres, autoriser les MX à émettre, refuser tous les serveurs, etc.. Vous trouverez plus d'informations sur SPF sur www.openspf.org

Mise en place avec Postfix

Dans beaucoup d'articles, comme ceux d'Ubuntu, de HowtoForge ou de quelques autres articles bien rankés sur Google vous verrez l'utilisation d'un appel PERL ou Python postfix-policyd-spf.

Si vous êtes utilisateur de FreeBSD ou que vous compilez vous-même vos programmes, vous n'avez plus besoin d'utiliser ces appels PERL qui peuvent s'avérer assez lourds sur une machine sollicitée. Il existe un patch pour Postfix, inclus dans le port FreeBSD, et peut être dans d'autres systèmes packagés, permettant d'activer une fonctionnalité native permettant de faire les vérifications SPF, évitant donc l'appel à un programme externe, qui plus est en PERL ou en Python et offrant donc un gain non négligeable de ressources processeur et mémoire.

Ce patch est fourni par libspf2.org, vous le trouverez ici.

Si vous effectuez une compilation via les ports FreeBSD ou Poudrière, il suffit de cocher l'option suivante:

Postfix SPF optionUne fois cette option activée, il suffira d'ajouter l'option reject_spf_invalid_sender dans l'option smtpd_recipient_restrictions de Postfix afin de vérifier l'enregistrement SPF associé à un domaine. Postfix s'occupera de faire les vérifications et de rejeter le mail si la politique SPF du domaine le demande.

Liens utiles

http://www.openspf.org/SPF_Record_Syntax

FreeBSD 9.2 est sorti

FreeBSD 9.2 est sorti le 30 septembre 2013.

Ce release fait suite à la version LTS 9.1 de FreeBSD et embarque un ensemble de nouveautés très intéressantes:

  • Mise à jour du driver e1000, amélioration de performances
  • Intégration de virtio dans le kernel GENERIC (x86 et amd64), permettant d'utiliser les drivers dédiés à KVM et améliorant les performances
  • Ajout du support de la commande TRIM pour les SSD
  • Ajout du support de la compression LZ4 sur les volumes ZFS, bien plus performante que LZO
  • Suppression du driver firewire du kernel GENERIC
  • Amélioration des temps de démarrage, notamment au niveau du bootloader
  • Le bootloader a été mis à jour avec un nouveau logo aux couleurs de FreeBSD
  • Amélioration des performances I/O via les unmapped I/O

freebsd9.2-bootVous trouverez l'ensemble des notes concernant ce release ici.

Pour mettre à jour votre système, il suffit de procéder de la manière suivante:

freebsd-update fetch
freebsd-update -r 9.2-RELEASE upgrade
freebsd-update install
reboot
freebsd-update install

Si vous notez des dysfonctionnement sur certains ports, n'hésitez pas à les recompiler/réinstaller. Il est recommandé d'utiliser portmaster afin de recompiler tous les ports pour cette nouvelle version de FreeBSD.

portmaster -a

Benchmark comparatif: PostGreSQL 9.1

Suite à une volonté de tester l'arbre de dports de DragonFlyBSD, et voulant voir ce que vallaient les performances de PostGreSQL sur DragonFlyBSD j'ai décidé de monter un rapide benchmark de performances afin de comparer plusieurs systèmes ayant une version de PostGreSQL commune. J'ai choisi pour ces raisons PostGreSQL 9.1.

Lors de mon benchmark sous Linux (Debian), je me suis retrouvé confronté à des statistiques étonnantes en terme de performances, de ce fait, j'ai décidé de voir ce que vallait une Redhat, j'ai donc pris Centos 6.4.

Les tests ont été effectués sur les plateformes suivantes:

  • DragonFlyBSD 3.4.1 (système de fichiers Hammer)
  • FreeBSD 9.1-p3 (système de fichiers UFS2+J)
  • FreeBSD 9.1-p3 (système de fichiers ZFS v28)
  • Debian 7: Wheezy (système de fichiers ext4)
  • Centos 6.4 (système de fichiers ext4)

En terme de hardware, le test a été effectué sur un système de virtualisation de type KVM (libvirt) avec 24GBit de mémoire et un processeur Phenom x6 1055T

qemu 1.4.1-3
libvirt 1.0.5-4

Chaque machine virtuelle possède les caractéristiques suivantes:

  • 50Go de disque (virtio pour tous les OS sauf FreeBSD)
  • 12Go de mémoire
  • 4 coeurs de processeur

Passons maintenant au benchmark. La commande utilisée est la suivante: pgbench -T 60 -cX -jX Concrètement, nous demandons à l'utilitaire pgbench de faire un test de 60 secondes sur la base de données, en utilisant X clients et X threads (1 client par thread). Chacune des bases de données est configurée par défaut, avec un support de 300 connexions simultannées.

Première partie: test sur disque virtuel

Le premier graphique représentera le nombre de transations sur la durée, le second par secondes. PGBench1 PGBench2

Le test de performances est surprenant. Nous avons en tête DragonFlyBSD qui surpasse tous les autres systèmes, suivi par FreeBSD. Les performances de DragonFlyBSD sont exceptionnelles, et dépassent de plus de 25% celles de FreeBSD lors de la montée en charge et de près de 200% les Linux.

Loin derrière, avec des performances 2 à 3 fois moindres, nous avons les deux Linux (Debian et Centos) qui plafonnent à près de 7000 transactions sur la durée sans vraiment les dépasser, et peu importe le nombre de clients. Cette courbe est particulièrement étonnante, d'une uniformité sans faille. Seul Debian ne réussit pas à passer le test entièrement en n'arrivant pas à gérer plus de 100 connexions sans devoir à toucher d'autres paramètres.

En fait, cette valeur de 7000 s'explique par l'option barrier du système de fichiers ext4. L'option protège le système de fichiers de la corruption des données en cas de panne matérielle (reboot inopiné...), et bride complètement les performances de PostgreSQL. Dans un second test nous avons ajouté l'option nobarrier/barrier=0 au système de fichiers (via /etc/fstab).

Notez que cette option est risquée, si un redémarrage dû à un problème d'alimentation survient, les fichiers en cours d'écriture sur le disque, voir l'ensemble du système de fichiers peuvent être corrompus. Ne l'utilisez que si vous possédez un contrôleur RAID matériel (Raid 1/5/6) avec une batterie.

Enfin, bon dernier, notre FreeBSD avec ZFS peine à rattraper les Linux. Peut être est-ce dû à la virtualisation ? Ou bien à la conception du système de fichiers lui-même ?

Seconde partie: test sur disque physique

Afin de vérifier nos résultats, il a été décidé de réaliser le même benchmark sur disque Physique. J'ai retenu uniquement les performances avec optimisations, hormis pour ZFS, qui devait avoir un point de comparaison en terme de performances sur disque physique (gérant la couche blocks). Centos a également été écartés n'offrant que peu de différences par rapport à Debian (un peu moins performant). Cette première courbe montre le nombre de transactions totales sur 1 minute: benchpostgrereal1 Cette seconde capture définit le nombre de transactions par secondes traitées: benchpostgrereal2 Etonnament DragonFlyBSD a des performances quasiment identiques à celles sur disque virtuel, ce qui pourrait signifier que les drivers virtio sont très performants et au point. Debian reste aussi performant en virtuel qu'en physique, et plafone à 50K transactions par minute. Les deux points qu'on pourra remarquer sont:

  • Les performances d'UFS (options async et noatime activées), qui doublent voire triplent avec l'optimisation, mais nécessitent les mêmes précautions que le nobarrier de ext4
  • ZFS multiplie par 10-15 ses performances en activant les optimisations sync=disabled et atime=off, surpassant nettement tout autre système de fichier et offrant des performances défiant toute concurrence. De plus l'option sync=disabled est moins dangeureuse que les options de débridages des autres systèmes de fichiers, bien que peu recommandée pour une base de données nécessitant un maximum de fiabilité en cas de panne.

ZFS est donc le leader sur ce benchmark physique, une fois débridé. En virtuel peut-être atteint-il les mêmes performances ?

Conclusion

Vous retrouverez les données complètes du benchmark dans le lien suivant: Benchmarks - PostGreSQL

En conclusion, si vous deviez choisir un système pour vos bases de données PostGreSQL, orientez vous sur un BSD sans hésiter, que ce soit un FreeBSD (UFS) ou un DragonFlyBSD (Hammer) si vous ne possédez pas de contrôleur raid matériel autrement choississez un Linux avec ext4 et nobarrier, ou encore un FreeBSD avec UFS avec async et noatime.

ZFS sur FreeBSD avec les options sync=disabled et atime=off est très tentant (n'oublions pas que NetApp est un FreeBSD avec ZFS), et devra nécessiter le raccordement des disques directements sur la carte mère sans passer par le contrôleur RAID

Merci à Emmanuel Florac et Axel Perrier pour leurs précisions sur l'option nobarrier