Utiliser Gitlab Pages comme repository Debian

Les Gitlab Pages (et Github Pages) permettent via un processus de construction d'artefact de publier un site web au travers d'un pipeline.

Un repository Debian étant simplement constitué de fichiers statiques, nous pouvons donc faire un rapprochement entre les pipelines de build et un repository Debian.

Pour réaliser notre repository Debian hébergé sur des gitlab pages nous aurons besoin:

  • Du conteneur docker debian:stretch
  • De GPG pour la signature du repository
  • De reprepro pour créer notre repository
  • D'un repository git hébergé sur un Gitlab

Initialisation du repository

Créer un répertoire sur votre machine et initialisez le lien avec Gitlab:

mkdir debianrepo
cd debianrepo
git init
git remote add origin git@gitlab.com:nerzhul/debianrepo.git

Génération de la clef GPG

Dans un premier temps nous aurons besoin d'une clef GPG pour notre repository. Générez une clef:

gpg --gen-key

On va ensuite exporter la clef publique et la clef privée dans notre repository local:

mkdir repo_meta
gpg --armor --output repo_meta/gpg-public.key --export BDB31B849949AD389C76573EF02015F1E3A69CF2
gpg --export-secret-keys -a BDB31B849949AD389C76573EF02015F1E3A69CF2 > repo_meta/gpg-private.key

Note: exposer la clef privée dans le repository n'est pas recommandé, il est plus judicieux d'utiliser les secret variables de Gitlab pour stocker le contenu de la clef privée. Il s'agit juste de simplifier l'exercice ici

Création du fichier de définition du repository

Créez un fichier repo_distributions dans le répertoire repo_meta. Celui-ci nous servira plus tard, lors de la création du repository. Notez bien que la ligne SignWith contient le fingerprint de la clef GPG précédemment créée

Origin: Debian
Label: Debian
Codename: stretch
Architectures: amd64
Components: main
Description: Apt repository for the posterity
SignWith: BDB31B849949AD389C76573EF02015F1E3A69CF2

Création du pipeline de construction du repository

Le pipeline de repository s'appuie sur le fichier .gitlab-ci.yml de Gitlab. Voici le fichier que nous allons utiliser, nous le détaillerons juste après:

---
image: debian:stretch

stages:
  - package
  - deploy

variables:
  DEBIAN_VERSION: "stretch"
  ETCD_VERSION: 3.2.7
  RUNDECK_VERSION: 2.9.3-1

package:etcd:
  stage: package
  before_script:
    - find etcd -type d -exec chmod 755 {} \;
    - find etcd -type f -not -name postinst -exec chmod 644 {} \;
    - find etcd -type f -name postinst -exec chmod 755 {} \;
    - mkdir -p build/ dist/
    - apt-get -qy update > /dev/null
    - apt-get -qyy install wget > /dev/null
  script:
    - sed -i 's/%%ETCD_VERSION%%/'${ETCD_VERSION}'/g' etcd/DEBIAN/control
    - mkdir -p etcd/usr/bin/
    - cd build/
    - wget https://github.com/coreos/etcd/releases/download/v${ETCD_VERSION}/etcd-v${ETCD_VERSION}-linux-amd64.tar.gz
    - tar xzf etcd-v${ETCD_VERSION}-linux-amd64.tar.gz
    - cp etcd-v${ETCD_VERSION}-linux-amd64/etcd etcd-v${ETCD_VERSION}-linux-amd64/etcdctl ../etcd/usr/bin/
    - cd ..
    - dpkg-deb -b etcd/
    - mv etcd.deb dist/
  artifacts:
    when: on_success
    expire_in: 1 week
    paths:
      - dist/*

package:rundeck:
  stage: package
  before_script:
    - apt-get -qy update > /dev/null
    - apt-get -qyy install wget > /dev/null
    - mkdir dist/
  script:
    - cd dist/
    - wget http://dl.bintray.com/rundeck/rundeck-deb/rundeck-${RUNDECK_VERSION}-GA.deb
  artifacts:
    when: on_success
    expire_in: 1 week
    paths:
      - dist/*

pages:
  stage: deploy
  only:
    - master
  dependencies:
    - package:etcd
    - package:rundeck
  before_script:
    - apt-get -qy update > /dev/null
    - apt-get -qyy install reprepro > /dev/null
    - gpg --import repo_meta/gpg-private.key
  script:
    - mkdir -p public/conf
    - cp repo_meta/repo_distributions public/conf/distributions
    - cp repo_meta/gpg-public.key public/repo.key
    - cd public
    - reprepro includedeb ${DEBIAN_VERSION} ../dist/*.deb
  artifacts:
    when: on_success
    expire_in: 1 year
    paths:
      - public

Notre pipeline se décompose en 2 phases:

  • Construction des paquets du repository
  • Création et déploiement du repository

La phase de déploiement nécessite de connaître les paquets Debian construits. Par convention les paquets Debian construits seront placés dans le répertoire dist/ qui sera transféré à la phase de déploiement des Gitlab Pages.

Nous avons ici 2 paquets différents, Etcd et Rundeck qui sont 2 outils libres. Le premier ne fournit pas de paquet Debian, le second oui.

Création des paquets

Commençons par Rundeck, le plus simple.

package:rundeck:
  stage: package
  before_script:
    - apt-get -qy update > /dev/null
    - apt-get -qyy install wget > /dev/null
    - mkdir dist/
  script:
    - cd dist/
    - wget http://dl.bintray.com/rundeck/rundeck-deb/rundeck-${RUNDECK_VERSION}-GA.deb
  artifacts:
    when: on_success
    expire_in: 1 week
    paths:
      - dist/*

Dans la section __before_script__, nous mettons ce qui ne concerne pas le build, ici l'installation de wget pour télécharger le paquet.

Nous nous plaçons ensuite dans le répertoire dist et téléchargeons la version de Rundeck spécifiée dans les variables du CI, plus haut.

Les artefacts intermédiaires sont ensuite sauvegardés pour 1 semaine. Pour rappel on peut télécharger les artefacts depuis l'interface de Gitlab sur chaque pipeline.

Passons maintenant au paquet etcd:

package:etcd:
  stage: package
  before_script:
    - find etcd -type d -exec chmod 755 {} \;
    - find etcd -type f -not -name postinst -exec chmod 644 {} \;
    - find etcd -type f -name postinst -exec chmod 755 {} \;
    - mkdir -p build/ dist/
    - apt-get -qy update > /dev/null
    - apt-get -qyy install wget > /dev/null
  script:
    - sed -i 's/%%ETCD_VERSION%%/'${ETCD_VERSION}'/g' etcd/DEBIAN/control
    - mkdir -p etcd/usr/bin/
    - cd build/
    - wget https://github.com/coreos/etcd/releases/download/v${ETCD_VERSION}/etcd-v${ETCD_VERSION}-linux-amd64.tar.gz
    - tar xzf etcd-v${ETCD_VERSION}-linux-amd64.tar.gz
    - cp etcd-v${ETCD_VERSION}-linux-amd64/etcd etcd-v${ETCD_VERSION}-linux-amd64/etcdctl ../etcd/usr/bin/
    - cd ..
    - dpkg-deb -b etcd/
    - mv etcd.deb dist/
  artifacts:
    when: on_success
    expire_in: 1 week
    paths:
      - dist/*

Pour etcd nous construisons un paquet Debian depuis des binaires fournis par les développeurs. Le répertoire etcd contient l'arborescence minimale du paquet, à savoir la configuration, l'unit system et les fichiers control et postinst de Debian.

Dans l'étape __before_script__ nous avons également besoin de wget, mais également de corriger les permissions sur le répertoire etcd du repository, le Gitlab CI changeant les droits sur les fichiers. Je n'ai pas réussi à comprendre pourquoi, celles-ci sont correctes dans git.

L'étape de build se décompose ensuite de la manière suivante:

  • On modifie le fichier control du paquet afin de spécifier la version du paquet etcd
  • On télécharge l'archive etcd du release concerné, qu'on extrait
  • On copie les binaires nous intéressant dans le paquet dans /usr/bin
  • On construit le paquet avec dpkg-deb
  • On bouge le paquet dans le répertoire dist

Enfin, tout comme pour Rundeck, on archive l'artefact.

Création du repository Debian et publication

Notre dernière tâche consiste à créer le repository Debian pour l'exposer via les Gitlab Pages

pages:
  stage: deploy
  only:
    - master
  dependencies:
    - package:etcd
    - package:rundeck
  before_script:
    - apt-get -qy update > /dev/null
    - apt-get -qyy install reprepro > /dev/null
    - gpg --import repo_meta/gpg-private.key
  script:
    - mkdir -p public/conf
    - cp repo_meta/repo_distributions public/conf/distributions
    - cp repo_meta/gpg-public.key public/repo.key
    - cd public
    - reprepro includedeb ${DEBIAN_VERSION} ../dist/*.deb
  artifacts:
    when: on_success
    expire_in: 1 year
    paths:
      - public

L'étape du pipeline doit obligatoirement se nommer pages par convention de Gitlab et le livrable du repository doit se situer dans le répertoire public.

Nous ajoutons nos deux étapes de construction de paquets en dépendances, afin d'avoir les artefacts à disposition pour cette étape, puis nous installons reprepro qui va nous permettre de construire un repository Debian facilement, et nous importons la clef GPG privées dans le trousseau du conteneur de build.

La construction du repository se fait ensuite de la manière suivante:

  • Copie du fichier repo_meta/repo_distributions vers public/conf/distributions, utilisé par reprepro pour construire le repository
  • Copie de la clef GPG publique vers public/repo.key afin de la distribuer à nos clients
  • En se positionnant dans le répertoire public, inclusion de l'ensemble des fichiers deb du répertoire dist/ dans le repository

Enfin nous archivons le repository pour une durée de 1 an, afin d'assurer sa pérennité dans le temps.

Vous pouvez maintenant commiter et pousser tous les changements

Résultat

Allez maintenant sur votre repository Gitlab dans la section pipelines, vous devriez avoir un résultat similaire:

Vous savez désormais construire une repository Debian en ajoutant dynamiquement des paquets construits à partir d'un pipeline Gitlab. Je vous invite à consulter le repository ayant servi de PoC puis de référence pour cet article:

Apache: obtenir l’IP source depuis un en-tête conditionel dans les logs

Dans le cadre d'un environnement web haute disponibilité il y a généralement des répartiteurs de charge HTTP comme HAproxy ou des reverse proxies comme Apache ou Nginx en frontal qui vont s'occuper de répartir la charge et/ou filtrer une partie des requêtes pour ménager les serveurs d'application de backend.

Le principal problème rencontré dans ce type d'architecture est que, généralement, le service web de frontend va masquer l'IP source du client, réduisant la tracabilité de celui-ci sur les backends. Nous allons ici partir du principe que le service web de frontend retransmet l'IP au backend via un en-tête HTTP nommé X-Real-IP.

L'astuce que nous allons voir ici permet d'afficher l'adresse IP du client via l'en-tête X-Real-IP si celui-ci existe, auquel cas l'adresse IP source.

Dans un premier temps nous allons définir 2 LogFormat, _completerealip et complete, chacun ayant un paramétrage sur le champ 1 différent:

LogFormat "%{X-Real-IP}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" \"%{Host}i\" %D" complete_realip
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" \"%{Host}i\" %D" complete

Dans un second temps, nous allons nous servir du module _modsetenvif afin de vérifier l'existence de l'en-tête:

SetEnvIf X-Real-IP ^.+$ real_ip_exists

Enfin on définit une condition sur l'environnement afin de basculer le log d'un mode à l'autre suivant la requête entrante:

CustomLog /var/log/apache/myapp_access.log complete_realip env=real_ip_exists
CustomLog /var/log/apache/myapp_access.log complete env=!real_ip_exists

Conclusion

Votre serveur Apache va désormais basculer l'IP présentée dans ses logs dynamiquement en fonction de la présence ou non de l'en-tête X-Real-IP.

Note: Si vous utilisez un haproxy en frontend, la configuration à ajouter à vos backend haproxy est la suivante:

http-request set-header X-Real-IP %[src]

Linux: Ajout de CPU à chaud

Sur un système Linux récent (noyau > 2.6.24) il est possible de changer le nombre de CPU de la machines à chaud, qu'on soit en machine virtuelle ou physique. Pour vérifier l'état d'activation d'un CPU, il suffit d'afficher le fichier concernant le CPU mentionné

cat /sys/devices/system/cpu/cpu2/online

Si online est à 1 le CPU est activé et si c'est à 0 il est désactivé Pour cela il suffit de s'interfacer avec le sous système /sys pour changer l'état actif/inactif du CPU en poussant 0 ou 1 dans le champ online

echo 1 > /sys/devices/system/cpu/cpu2/online

Pour activer tous les CPU d'un coup, faîtes une boucle:

cd /sys/devices/system/cpu/
for F in cpu* ; do echo 1 > "$F/online"; done

A des fins de tests vous pouvez également désactiver des CPU en spécifiant 0 au lieu de 1, la seule limitation étant que le cpu0 n'est pas désactivable.

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/

Linux: Ajout de RAM à chaud

Sur les systèmes Linux récents, il est possible d'ajouter de la RAM à chaud si votre Linux est sur une système de virtualisation. Suivant les outils utilisés et le système de virtualisation vous pouvez avoir 2 cas:

  • Lorsque vous ajoutez de la RAM à chaud le système virtualisé la prend en compte directement (virtualisation avec KVM par exemple, ou VMWare + openvm-tools récents)
  • Lorsque vous ajoutez de la RAM à chaud le système ne la prend pas en compte mais le système de virtualisation oui.

Dans le second cas, si votre distribution est assez récente (Debian 7 et 8 par exemple), vous pouvez lancer une action manuelle afin d'activer les nouveaux espaces mémoires de la machine:

cd /sys/devices/system/memory
for F in memory* ; do
  if [ $(cat "$F/state") != "online" ]; then
    echo "online" > "$F/state";
  fi;
done

Si cela fonctionne vous n'aurez pas d'erreur à l'écran comme quoi l'argument est invalide. Auquel cas, votre système Linux est trop ancien et vous devrez le redémarrer.

Recompiler un paquet officiel sous ArchLinux

Archlinux est une distribution en rolling release très intéressante, réservée à des utilisateurs plus avertis que la normale, le processus d'installation étant manuel (et bien documenté).

Une des fonctionnalités intéressantes d'Archlinux est la possibilité de pouvoir recompiler certains paquets afin d'optimiser les performances de la machine en optimisant le code binaire généré, en ajoutant, retirant des options de compilation ou encore en optimisant les flags passés au compilateur.

Initialisation

Afin de pouvoir bénéficier de ce système de build, installez le paquet abs (Archlinux Build System)

sudo pacman -S abs

Si vous souhaitez utiliser la branche testing, il va falloir reconfigurer ABS pour lui dire de synchroniser ces repositories. Editez le fichier /etc/abs.conf et activez le repository testing en retirant les point d'exclamation.

Ainsi:

REPOS=(core extra community multilib !testing !community-testing !multilib-testing !staging !community-staging !gnome-unstable !kde-unstable

Deviendra:

REPOS=(core extra community multilib testing community-testing multilib-testing !staging !community-staging !gnome-unstable !kde-unstable)

Lancez maintenant la commande abs en root afin de télécharger les définitions de paquets.

sudo abs

Cette commande va télécharger les définitions de paquets dans /var/abs//

Recompiler un paquet

Admettons qu'on souhaite recompiler mesa, la pile graphique libre sous Linux.

On copie le répertoire /var/abs/extra/mesa dans ~/mesa-custom puis on entre dedans

cp -R /var/abs/extra/mesa ~/mesa-custom
cd ~/mesa-custom

Si vous souhaitez modifier les options à passer au compilateur, éditez la ligne CFLAGS et CXXFLAGS dans le fichier /etc/makepkg.conf (attention toutes les options ne sont pas identiques entre Clang et GCC).

Si vous souhaitez changer les options de compilation du programme, éditez le fichier PKGBUILD présent dans le répertoire.

Construisez maintenant le paquet.

makepkg -s

Enfin installez votre nouveau paquet !

sudo pacman -U mesa-10.6.0-1-x86_64.pkg.tar.xz

Conclusion

Vous savez désormais comment recompiler certains paquets sur un Archlinux à base d'un repository, et ainsi optimiser les performances de vos programmes.

Source

https://wiki.archlinux.org/index.php/Arch_Build_System

Debian: packager le JAVA Oracle

Dans un environnement de production JAVA sous Linux les mainteneurs d'applications lourdes, web ou non, seront amenés à faire le choix entre OpenJDK et Oracle-JDK

L'OpenJDK a l'avantage d'être libre et open source, il peut être recompilé pour améliorer sensiblement les performances du code java au moyen d'optimisations compilateur GCC pour l'adapter au processeur de vos machines, néanmoins on le fait rarement sous Debian.

Le JDK Oracle a le mérite d'être plus performant sur certains points et certaines structures/entreprises le préfèreront pour des raisons de confiance, de support ou encore de grapiller quelques performmances par rapport à un OpenJDK non compilé.

Sous Debian on ne retrouve pas nativement le JDK Oracle dans les repositories, il faut passer alors par le système d'installation par .tar.gz ou binaire d'Oracle, qui n'offre pas une intégration Debian suffisante.

Pour résoudre cette dernière problématique, il existe un outil dans le repository main de Debian qui s'appelle JavaPackage. Cet outil permet à partir d'un .tar.gz Oracle de créer une archive .deb et d'ajouter l'intégration Debian au sein du paquet (update-alternatives, liens symboliques...).

Pour l'installer rien de plus simple:

apt-get install java-package

Et pour l'utiliser, téléchargez l'archive sur le site d'Oracle puis tapez la commande suivante:

make-jpkg jdk-7u60-linux-x64.tar.gz

Ensuite il vous suffit de l'installer simplement avec dpkg:

dpkg -i oracle-jdk_7.0.60_amd64.deb

Si vous disposez d'un repository local avec vos propres paquets, plus qu'à l'intégrer avec par exemple reprepro.

Source

https://wiki.debian.org/JavaPackage

Impression vers mail (via lpd)

Je vous propose ici une méthode sous Linux permettant de créer une imprimante virtuelle qui va envoyer l'impression en pièce jointe par mail. On utilisera ici le bon vieux service lpd

Configuration

Pour configurer cette imprimante il convient de modifier le fichier /etc/printcap.local et d'ajouter l'entrée suivante:

VirtualMailPrinter:\
    :ml#0:\
    :mx#0:\
    :sd=/var/spool/lpd/VirtualMailPrinter:\
    :sh:\
    :lp=/dev/null:\
    :if=/usr/local/bin/copy_lpd_to_mail.py:
  • ml: nombre minimum de caractères pour imprimer
  • mx: taille maximale du job
  • sd: spooler
  • sh: S'il faut supprimer les en-têtes
  • lp: sortie d'impression (ici nulle part)
  • if: filtre avant impression. C'est lui qui va capturer le contenu pour l'envoyer par mail

On redémarre ensuite le service lpd. Celui-ci va lire les entrées dans /etc/printcap.local et les ajouter dans /etc/printcap.

On va ensuite créer le script python (v2.7) /usr/local/bin/copy_lpd_to_mail.py qui va se charger de lire l'entrée standard (stdin), écrire le contenu dans un fichier temporaire puis le joint par mail avant de l'envoyer à la personne configurée.

Le choix de python est dû au fait que bash ne gère pas correctement la lecture de stdin pour des fichiers dans un format non textuel. Si votre interpréteur python n'est pas celui ci-dessous, changez le également.

#! /usr/local/bin/python2.7
import sys, os
import smtplib
import mimetypes
from email.mime.base import MIMEBase
from email import encoders
from email.mime.multipart import MIMEMultipart

# Params
tmpfileName = '/tmp/mail.tmp'
mailDest = "destination@example.org"
mailSrc = "lpd@myserver.example.org"

# Write stdin (printer) to file
f = open(tmpfileName, 'w')
for line in sys.stdin:
        f.write(line)
f.close()

# Create E-mail
outer = MIMEMultipart()
outer['Subject'] = 'Impression To Mail'
outer['To'] = mailDest
outer['From'] = mailSrc
outer.preamble = 'You will not see this in a MIME-aware mail reader.\n'

# Read our file and join it to mail
ctype, encoding = mimetypes.guess_type(tmpfileName)
if ctype is None or encoding is not None:
        # No guess could be made, or the file is encoded (compressed), so
        # use a generic bag-of-bits type.
        ctype = 'application/octet-stream'

maintype, subtype = ctype.split('/', 1)

fp = open(tmpfileName, 'rb')
msg = MIMEBase(maintype, subtype)
msg.set_payload(fp.read())
fp.close()
encoders.encode_base64(msg)
msg.add_header('Content-Disposition', 'attachment', filename="export_lpd.txt")
outer.attach(msg)
composed = outer.as_string()

# Send the mail
s = smtplib.SMTP('localhost')
s.sendmail(mailSrc, mailDest, composed)
s.quit()

Créer son propre paquet Debian

Dans le cas de logiciels maisons ou propriétaires, il peut être utile d'avoir son propre repository et ses propres paquets Debian maison afin de déployer rapidement un logiciel.

Nous allons voir ici comment créer un paquet Debian.

Création de l'arborescence

Un paquet Debian s'architecture de manière simple. Il s'agit d'un répertoire contenant les fichiers tels qu'ils seraient vus à partir de la racine. A cela on rajoute un répertoire DEBIAN contenant les fichiers de configuration du paquet (options, scripts de pré-install, post-install...).

On créée ici un paquet mypackage qui devra déployer le binaire /usr/bin/mycustomsoft.

mkdir -p /tmp/mypackage /tmp/mypackage/DEBIAN /tmp/mypackage/usr/bin/

Copie des fichiers à déployer

Une fois l'arborescence créée, on copie les fichiers que l'on souhaite déployer dans notre répertoire dédié au paquet. Attention à bien conserver les droits

cp -p /usr/bin/mycustomsoft /tmp/mypackage/usr/bin/

Configuration du paquet

Pour finir on va créer un fichier dans le répertoire DEBIAN nommé control qui contiendra des informations administratives sur le paquet.

Package: mypackage
Version: 1.0
Section: base
Architecture: amd64
Depends: linux-headers libboost-dev
Conflicts: firefox
Maintainer: Gerard Toki <gtoki@unix-experience.fr>
Description: Paquet custom

Vous pourrez spécifier ici le nom du paquet, sa version, ses dépendances, éventuellement les paquets avec lequel il est en conflit, une description et un mainteneur.

La liste est non exhaustive, bien entendu.

Construction du paquet

Pour terminer on construit le paquet avec la commande dpkg-deb.

dpkg-deb --build mypackage

Conclusion

Vous savez maintenant comment créer un paquet Debian très simple. Il est possible de rajouter des options et scripts avant et après l'installation (redémarrage de service, configuration automatisée...

Sources

http://alp.developpez.com/tutoriels/debian/creer-paquet/

https://www.debian.org/doc/debian-policy/ch-relationships.html

VI: raccourcis essentiels

VI est un éditeur de texte très puissant. Il est intégré de base dans toutes les distributions Linux et BSD

Pour certains il s'agit d'un éditeur compliqué réservé aux barbus. Pour d'autres c'est l'éditeur de choix.

Vous trouverez ci-dessous les raccourcis essentiels de VI classés par thématique.

Edition

i : insertion, permet d'éditer la ligne à partir du caractère courant

I : active l'insertion au début de la ligne courante

a : append, active l'édition à partir du caractère suivant

A : active l'édition à partir de la fin de la ligne courante

o : ajoute une ligne vide en dessous et active l'édition

O : ajoute une ligne vide au dessus et active l'édition

Echap : désactive l'édition

Couper/Copier/Coller

dd : coupe la ligne en cours (et la supprime)

dXd : coupe X lignes à partir de la ligne courante

d$ : coupe la fin de ligne à partir du caractère courant

x : coupe le caractère courant

MAJ+S : coupe la ligne en cours et active l'insertion

yy : copie la ligne courante

yXy : copie X lignes à partir de la ligne courante

p : colle les lignes coupées/copiées

Déplacements

:X : se déplacer à la ligne X du fichier

:$ : se déplacer à la fin du fichier

:0 : se déplacer au début du fichier

w : se déplacer au mot suivant

b : se déplacer au mot précédent

$ : se déplacer à la fin de la ligne courante

0 : se déplacer au début de la ligne courante

j : se déplacer à la ligne suivante

k : se déplacer à la ligne précédente

Recherche/Substitution

/ : recherche le patern dans le fichier (début → fin)

/ : répète la recherche précédente

? : comme / mais de la fin → début

:%s///g : remplace le patern dans l'ensemble du fichier par replace

:%s : répète la substitution précédente

Enregistrer/Quitter

:q : quitter vi

:q! : quitter vi sans enregistrer

:w : enregistrer le fichier

:wq / 😡 : enregistrer le fichier et quitter

:wq! / :x! : forcer l'enregistrement et quitter

Inclassables

u : défaire (undo)

. : répéter l'action précédente

[Serveur Dédié]OpenVPN

Dans cette article nous allons mettre en oeuvre un serveur OpenVPN en nous servant de l’article suivant.

Je ne commenterai que les modifications que j’ai faites par rapport à cet article sur le serveur ainsi que le client.

Serveur

J’ai copié le dossier easy-rsa dans /etc/openvpn qui été présent pour ne pas jongler entre différents répertoires concernant la configuration et l’utilisation de OpenVPN.

J’ai noter une différence dans le fichier vars avec la possibilité d’indiquer nativement des informations relatifs a son utilisation au sein d’un annuaire LDAP et l’utilisation de carte à puce via PKCS. Continuer à lire

Shibboleth (IdP): installation et retour d’expérience

Shibboleth est un système de fédération d'identités. Il permet d'authentifier des utilisateurs faisant partie d'établissements/entreprises différentes sur des applications mutualisées.

Peu présent et utile dans le secteur privé, Shibboleth est une référence en terme d'authentification dans le secteur public, au sein du ministère de l'enseignement supérieur et de la recherche. Renater, fournisseur d'accès à Internet réservé aux établissement d'enseignement supérieur et de recherche, est l'un des organismes qui l'utilise le plus.

Shibboleth est composé de plusieurs briques, notamment le Service Provider (SP, fournisseur de services) et dans notre cas le fournisseur d'identité (Identity Provider, IdP)

Installation

Pré-requis

Avant de pouvoir installer et utiliser shibboleth, il vous faudra installer JDK 6 et Tomcat 7.

Si vous utilisez Debian tapez simplement:

apt-get install openjdk-6-jdk tomcat7

Si vous utilisez FreeBSD, compilez le port www/tomcat

cd /usr/ports/www/tomcat7
make install clean

ou installez le package depuis votre repo pkgng préféré

pkg install tomcat

Installation de Shibboleth

Téléchargement de l'archive

On télécharge tout d'abord le dernier Shibboleth puis on l'extrait

wget http://shibboleth.net/downloads/identity-provider/latest/shibboleth-identityprovider-2.4.0-bin.tar.gz
tar xvzf shibboleth-identityprovider-2.4.0-bin.tar.gz

Configuration de la variable JAVA_HOME

Pour pouvoir installer Shibboleth nous allons avoir besoin de spécifier la variable d'environnement JAVA_HOME.

Pour Debian, tapez la commande suivante:

export JAVA_HOME="/usr/lib/jvm/java-6-openjdk-amd64/jre"

Pour FreeBSD:

  • si vous utilisez csh:
setenv JAVA_HOME "/usr/local/openjdk6/jre/"
  • si vous utilisez sh, bash ou encore zsh:
export JAVA_HOME="/usr/local/openjdk6/jre/"

Lancement de l'installeur

Pour finir nous lançons l'installation:

cd shibboleth-identityprovider-2.4.0
./install.sh

Lors de l'installation le chemin d'installation, le nom du serveur (adresse DNS du CAS/SSO) et un mot de passe vous seront demandés:

Where should the Shibboleth Identity Provider software be installed? [/opt/shibboleth-idp]
What is the fully qualified hostname of the Shibboleth Identity Provider server? [idp.example.org]
A keystore is about to be generated for you. Please enter a password that will be used to protect it.

Une fois l'installation terminée, on copie le fichier WAR de l'application java dans le répertoire d'applications tomcat.

Pour Debian:

cp /opt/shibboleth-idp/war/idp.war /usr/share/tomcat7/webapps/

Pour FreeBSD:

cp /opt/shibboleth-idp/war/idp.war /usr/local/apache-tomcat-7.0/webapps/

Il faut ensuite changer les droits des répertoires de logs et de méta-données.

Pour Debian:

chown -R tomcat7 /opt/shibboleth-idp/logs
chown -R tomcat7 /opt/shibboleth-idp/metadata

Pour FreeBSD:

chown -R www /opt/shibboleth-idp/logs
chown -R www /opt/shibboleth-idp/metadata

Pour finir, on va ajouter quelques librairies JAVA à tomcat afin que Shibboleth fonctionne correctement. Vous trouverez ces fichiers dans le répertoire où vous avez extrait l'installeur de Shibboleth.

Pour Debian:

cp endorsed/*.jar /usr/share/tomcat7/endorsed/

Pour FreeBSD:

cp endorsed/*.jar /usr/local/apache-tomcat-7.0/endorsed/

Lancement du service

On peut désormais lancer Tomcat.

Sous Debian:

service tomcat7 start

Sous FreeBSD:

service tomcat start

Pour vérifier que tout fonctionne, connectez vous à l'adresse http://idp.example.org:8080/idp/profile/Status. Si la page affiche ok c'est que l'application est correctement déployée.

Enfin, vérifiez que le portail SSO de Shibboleth fonctionne en allant à l'URL http://idp.example.org:8080/idp/Authn/UserPassword

Designer le SSO

Le premier axe d'amélioration est la personnalisation du design du SSO. Pour cela c'est très simple, il suffit d'aller dans le répertoire webapps/idp/ de votre tomcat et de personnaliser les fichiers login.jsp et login.css, correspondant à la page de login. Vous n'avez pas besoin de redémarrer tomcat à chaque modification, à contrario des fichiers de configuration de Shibboleth.

Conclusion

Nous avons ici fait la partie la plus simple, à savoir l'installation de Shibboleth. Le plus compliqué reste la configuration de l'IdP lui-même. Vous trouverez dans les sources ci-dessous la documentation Renater, extrêmement complète permettant de comprendre les différents éléments à configurer pour Shibboleth (partez de la partie 4)

J'ai également essayé d'installer Shibboleth avec Jetty 8 (Shibboleth ne supporte que Jetty >= 7) mais je n'ai pas réussi, ni sur Debian, ni sur FreeBSD. Jetty nécessite d'intégrer des fichiers de configuration supplémentaires et des librairies Tomcat pour faire fonctionner Shibboleth, il reste donc plus pertinent d'utiliser Tomcat 7.

Par ailleurs, j'ai fortement apprécié le déploiement sur cette version de Tomcat 7. J'utilise peu Tomcat et ma précédente expérience avec Tomcat 6 n'avait pas été convaincante.

Même si vous n'utilisez pas la fédération d'identité, Shibboleth peut très bien être utilisé en tant que serveur CAS/SSO (dans mon cas il est branché sur 2 OpenLDAP). Si vous suivez la documentation Renater vous devriez sans problème arriver à faire fonctionner cette partie et pouvoir commencer à l'intégrer sur vos services web.

Sources

https://wiki.shibboleth.net/confluence/display/SHIB2/IdPInstall https://www.switch.ch/aai/docs/shibboleth/SWITCH/latest/idp/deployment/#shibboleth-idp-configuration https://services.renater.fr/federation/docs/installation/idp_decembre2012