gentoo

Distcc sur gentoo

Posted by jc on October 18, 2008
Linux / No Comments

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:

distcc-mon

Tags: ,

syslog-ng, gentoo hardened et cron :)

Posted by jc on October 06, 2008
Linux / No Comments

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.

Tags:

XFS mon amour :)

Posted by jc on September 12, 2008
Linux / No Comments

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

Tags: ,

Packaging Gentoo

Posted by jc on August 30, 2008
Linux / No Comments

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.

Tags: ,

emerge –sync, ne pas regénérer le cache

Posted by jc on August 24, 2008
Linux / No Comments

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.

Tags: ,