Introduction
Distcc est très pratique voir indispensable sur des systèmes comme Gentoo. Distcc permet de faire de la compilation distribuée. C’est a dire que nous allons repartir les taches de compilations sur plusieurs machines afin d’alleger la peine de nos pauvres becanes 
Prérequis
Pour que Distcc fonctionne bien nous aurons besoin des memes versions de GCC partout.
Distcc est capable de faire de la crosscompilation mais on ne verra pas ce point ici.
Installation et configuration
Pour le monitoring on utilisera le USE gtk
emerge -av distcc
Si les machines utilisant distcc sont 10.0.0.1 et 10.0.0.2 La configuration suivante s’applique sur la machine 10.0.0.1 dans /etc/distcc/hosts
10.0.0.2 localhost
On fera l’inverse sur l’autre machine
Dans le make.conf il faut dire à portage d’utiliser distcc:
DISTCC_HOSTS="10.0.0.2 localhost"
# on indique d'utiliser distcc, ici nous utilisons deja ccache donc on le met avant
FEATURES="ccache distcc"
Ne pas oublier de mettre à jour le l’option -j pour GCC sur le paramètre MAKEOPTS.
On lance le service maintenant et pour les prochains boot.
/etc/init.d/distcc start && rc-update add distcc default
Voila c’est fini \o/
Pour avoir un gain de temps vraiment reel il faut aussi utiliser ccache.
Voila ce que donne une compilation vue avec distccmon-gui, l’outil de monitoring livré avec distcc:
Related Posts:
Je me suis retrouvé sur Gentoo hardened avec quelque chose d’un peu gênant… les logs de vixie-cron dans le /var/log/message, le /var/log/debug et le /var/log/cron.log. Sympa, mais un poil redondant. Cela ne concerne que Gentoo hardened qui dispose d’un fichier de conf spécifique pour syslog-ng.
Pour que cron logue seulement dans son ficher, il suffit d’exclure les logs cron des fichiers debug et message:
filter f_messages { level(info..warn)
and not facility(auth, authpriv, mail, news, cron); };
destination messages { file(“/var/log/messages”); };
log { source(src); filter(f_messages); destination(messages); };
Même punition pour le fichier de debug.
Related Posts:
Ci dessous, un bloc note sur l’utilisation de XFS.
- Vérification du Filesystem
Pour verifier la consistence du Systeme de fichier, on utilise conjointement deux programmes xfs_check et xfs_repair.
xfs_check /dev/device
xfs_repair -n /dev/device
xfs_repair -n fait un test un peu plus complet que xfs_check
- Réparation du Filesystem
Pour réparer des inconsitences du FS on pourra utiliser xfs_repair et ceci toujours sur un device démonté
xfs_repair /dev/device
- Fragmentation
Au bout de quelques années d’utilisation il se peut qu’un système de fichiers se fragmente un peu, surtout si la partition est presque pleine et qu’il y a des mouvements de fichiers réguliers.
XFS intègre des outils pour défragmenter ses partitions à chaud.
Cet outil magique se trouve dans le package xfsdump dans lequel on trouvera aussi les outils de backup et restore.
emerge -av xfsdump
Nous allons ensuite verifier le taux de fractionnement de notre partition.
xfs_db -r /dev/hda1
xfs_db> frag
actual 452654, ideal 450929, fragmentation factor 0.38%
xfs_db>
Visiblement L’utilisation de Gentoo en ~x86 sur mon portable pendant plusieurs années n’a pas fait suffisament souffir XFS
Dans le cas ou nous aurions besoin de défragmenter on pourra utiliser la commande suivante:
xfs_fsr -v /dev/hda1
Related Posts:
Packaging Gentoo
Portage et le système d’ebuild de Gentoo sont des outils très puissants et flexibles, mais un peu obscur à utiliser au départ pour qui veut faire son package. Voyons comment s’y prendre.
Première étape, il faut définir un overlay si ce n’est déjà fait. Pour rappel, l’overlay consiste en un dossier parallèle au dossier /usr/portage qui constitue en fait une extension de la base de données des paquets. Il est alors possible de rajouter ses propres paquets dans cet overlay, pour notamment y mettre des ebuilds de version de test ou tout simplement de logiciel non encore présent dans Portage.
Création de l’overlay
Rien de plus simple :
On créé un répertoire pour stocker l’overlay.
mkdir /usr/local/portage
Ensuite il suffit d’éditer le fichier /etc/make.conf et d’y ajouter cette ligne.
PORTDIR_OVERLAY="/usr/local/portage"
Voila, l’overlay est défini.
Création d’un ebuild
Avant toute chose, il faut savoir que votre ebuild doit avoir un nom précis, et être dans un dossier précis (on rapelle que l’overlay doit avoir la même structure que Portage).
Votre ebuild doit donc être dans un de ces dossiers (que vous créerez dans le dossier de l’overlay pour l’occasion si ce n’est déjà fait) :
app-accessibility
app-admin
app-antivirus
app-arch
app-backup
app-benchmarks
app-cdr
app-crypt
app-dicts
app-doc
app-editors
app-emacs
app-emulation
app-forensics
app-i18n
app-laptop
app-misc
app-mobilephone
app-office
app-pda
app-portage
app-shells
app-text
app-vim
app-xemacs
dev-ada
dev-cpp
dev-db
dev-dotnet
dev-embedded
dev-games
dev-haskell
dev-java
dev-lang
dev-libs
dev-lisp
dev-ml
dev-perl
dev-php
dev-php4
dev-php5
dev-python
dev-ruby
dev-scheme
dev-tcltk
dev-tex
dev-tinyos
dev-util
games-action
games-arcade
games-board
games-emulation
games-engines
games-fps
games-kids
games-misc
games-mud
games-puzzle
games-roguelike
games-rpg
games-server
games-simulation
games-sports
games-strategy
games-util
gnome-base
gnome-extra
gnustep-apps
gnustep-base
gnustep-libs
kde-base
kde-misc
mail-client
mail-filter
mail-mta
media-fonts
media-gfx
media-libs
media-plugins
media-radio
media-sound
media-tv
media-video
net-analyzer
net-dialup
net-dns
net-firewall
net-fs
net-ftp
net-im
net-irc
net-libs
net-mail
net-misc
net-nds
net-news
net-nntp
net-p2p
net-print
net-proxy
net-wireless
net-www
net-zope
perl-core
rox-base
rox-extra
sci-astronomy
sci-biology
sci-calculators
sci-chemistry
sci-electronics
sci-geosciences
sci-libs
sci-mathematics
sci-misc
sci-visualization
sys-apps
sys-auth
sys-block
sys-boot
sys-cluster
sys-devel
sys-fs
sys-kernel
sys-libs
sys-power
sys-process
www-apache
www-apps
www-client
www-misc
www-servers
x11-apps
x11-base
x11-drivers
x11-libs
x11-misc
x11-plugins
x11-proto
x11-terms
x11-themes
x11-wm
xfce-base
xfce-extra
L’ebuild basique : il télécharge, décompresse, configure, compile et installe une archive de source.
L’ebuild est nommé de la manière suivante : nom_du_soft-version.ebuild et est stocké dans /usr/local/portage/dossier-correspondant-au-type-de-l’application (voir juste au dessus)/nom_du_soft/
N’oubliez pas de créer aussi le répertoire /usr/local/portage/app-portage/clean-distfiles/files qui sert à stocker tous les digest
Décortiquons l’ebuild d’aMule 2.1.0 par exemple. Il s’appelle logiquement amule-2.1.0-r1.ebuild.
L’entête standard
# Copyright 1999-2006 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/net-p2p/amule/amule-2.1.0-r1.ebuild,v 1.1 2006/01/13 11:18:44 mkay Exp $
L’ebuild va utiliser des fonctions des ces classes
inherit eutils flag-o-matic wxwidgets
Définition de quelques variables par praticité. Emerge définit un certains nombre de variables lui même, comme par exemple ${PV} qui donne directement la version du paquets selon le nom de l’ebuild. Pratique pour mettre à jour un paquet juste en renommant l’ebuild.
MY_P=${P/m/M}
S=${WORKDIR}/${MY_P}
Le description du paquet.
DESCRIPTION="aMule, the all-platform eMule p2p client"
La homepage du paquet.
HOMEPAGE="http://www.amule.org/"
L’url de téléchargement. On remarque l’utilisation de variable, ce qui rend l’ebuild plus “dynamique”.
SRC_URI="mirror://sourceforge/${PN}/${MY_P}.tar.bz2"
La licence du soft.
LICENSE="GPL-2"
Le slot d’installation. Cela permet d’installer parallèlement plusieurs versions du même paquets (surtout utiliser pour certaines librairies, ou pour les kernel).
SLOT="0"
Les keywords du paquets.
KEYWORDS="~alpha ~amd64 ~ppc ~ppc64 ~sparc ~x86"
Définit les flags USE auquels l’ebuild peut réagir.
IUSE="amuled debug gtk nls remote stats unicode"
Définition des dépendances du paquets.
aMule dépend donc de wxGTK, de zlib et ce, inconditionnellement. Par contre, il dépend de gd si le flag USE “stats” est utilisé. De même pour libpng avec le flag USE “remote”. Pour finir, aMule ne peut pas être installé en même temps que xmule (provoquera une erreur “ebuild blocked by another”.
DEPEND=">=x11-libs/wxGTK-2.6.0
>=sys-libs/zlib-1.2.1
stats? ( >=media-libs/gd-2.0.26 )
remote? ( >=media-libs/libpng-1.2.0 )
!net-p2p/xmule"
L’étape de configuration. Elle est utilisée pour vérifier que les paramètres ne comporte pas d’erreur. La fonction “use” est utilisé pour savoir un flag USE est défini ou non.
pkg_setup() {
export WX_GTK_VER="2.6"
if ! use gtk && ! use remote && ! use amuled; then
eerror ""
eerror "You have to specify at least one of gtk, remote or amuled"
eerror "USE flag to build amule."
eerror ""
die "Invalid USE flag set"
fi
if use unicode && use gtk; then
einfo "wxGTK with gtk2 and unicode support will be used"
need-wxwidgets unicode
elif use gtk; then
einfo "wxGTK with gtk2 support will be used"
need-wxwidgets gtk2
elif use unicode; then
einfo "wxGTK with unicode and without X support will be used"
need-wxwidgets base-unicode
else
einfo "wxGTK without X support will be used"
need-wxwidgets base
fi
if use stats && ! use gtk; then
einfo "Note: You would need both the gtk and stats USE flags"
einfo "to compile aMule Statistics GUI."
einfo "I will now compile console versions only."
fi
if use stats && ! built_with_use media-libs/gd jpeg; then
die "media-libs/gd should be compiled with the jpeg use flag when you have the stats use flag set"
fi
}
L’étape de configuration/compilation. De même que pour pkg_setup, on utilise la fonction “use” pour configurer dynamiquement les sources. Classiquement, on définit une variable locale (ici myconf) à laquelle on rajoute des arguments selon les flags USE utilisés. Pour configurer le paquet, on n’utilise pas directement ./configure, mais plutôt la fonction econf et pour compiler non pas make mais emake.
src_compile() {
local myconf=""
if use gtk ; then
use stats && myconf="${myconf}
--enable-wxcas
--enable-alc"
use remote && myconf="${myconf}
--enable-amule-gui"
else
myconf="
--disable-monolithic
--disable-amule-gui
--disable-wxcas
--disable-alc"
fi
econf \
--with-wx-config=${WX_CONFIG} \
--with-wxbase-config=${WX_CONFIG} \
--enable-amulecmd \
`use_enable debug` \
`use_enable !debug optimize` \
`use_enable amuled amule-daemon` \
`use_enable nls` \
`use_enable remote webserver` \
`use_enable stats cas` \
`use_enable stats alcc` \
${myconf} || die
# we filter ssp until bug #74457 is closed to build on hardened
if has_hardened; then
filter-flags -fstack-protector -fstack-protector-all
fi
emake -j1 || die
}
L’étape d’installation des sources, utilisée notamment si des manipulations sont à faire après la compilation (ici par exemple, la création de nouveaux groupes ou d’utilisateurs).
src_install() {
make DESTDIR=${D} install || die
if use amuled || use remote; then
if ! id p2p >/dev/null; then
enewgroup p2p
enewuser p2p -1 -1 /home/p2p p2p
fi
fi
if use amuled; then
insinto /etc/conf.d; newins ${FILESDIR}/amuled.confd amuled
exeinto /etc/init.d; newexe ${FILESDIR}/amuled.initd amuled
fi
if use remote; then
insinto /etc/conf.d; newins ${FILESDIR}/amuleweb.confd amuleweb
exeinto /etc/init.d; newexe ${FILESDIR}/amuleweb.initd amuleweb
fi
}
Comme on a pu le voir, certaines fonctions sont à la dispositions de l’utilisateur dans les ebuilds. Les plus courantes :
- use : permet de vérifier la présence d’un flag USE.
- einfo : affiche un message d’information.
- eerror : affiche un message d’erreur et stoppe.
- econf : configure les sources.
- emake : compile les sources.
Une fois l’ebuild créé, il doit être placé dans le bon répertoire. Ensuite, il faut créer le digest : ebuild chemin_vers_l’ebuild digest
Une fois ceci fait sans erreur, votre paquet est près à être emergé.
- Plus d’infos ?
Pour avoir plus d’informations sur la création d’ebuilds Gentoo, vous pouvez allez directement consulter la page de référence du handbook gentoo. Vous y retrouverez tout ce qui a été dit ici, mais aussi la liste complète des variables et des fonctions définies par emerge.
Related Posts:
Un autre tip tiré de (bientôt) feu le wiki
merci trap
On le sait, Portage est très bien mais le souci reste quand même la lenteur relative de emerge –sync. Une astuce pour gagner un peu de temps consiste à désactiver la régénération du cache à la fin du processus.
Marche à suivre:
Elle est très simple. Tout d’abord :
echo "portdbapi.auxdbmodule = cache.metadata_overlay.database" >> /etc/portage/modules
Rajouter ensuite FEATURES="-metadata-transfer dans le fichier /etc/make.conf.
Et pour finir, on peut supprimer l’ancien cache :
rm -rf /var/cache/edb/dep/*
Conclusion :
Voilà 5 minutes (voire plus) de gagnées pour la mise à jour. Alors la grande question reste pourquoi cela n’est pas le comportement par défaut de Portage ? Portage n’est pas encore capable de détecter si un eclass a été modifié entre temps et donc s’il faut régénerer le cache ou pas. Si vous ne faites aucune modification d’eclass (ce qui est assez probablement le cas), cette méthode ne pose aucun souci.
