Mot-clé - portage

Fil des billets

28fév. 2011

Dell carte raid Perc H200/H700 et sas2ircu

Si vous louez et/ou possédez un serveur Dell R210/R310/R410 munie d'une carte raid Dell Perc H200/H700, voici un petit ebuild (vous pouvez également télécharger manuellement le binaire) pour Gentoo afin de gérer la carte raid depuis linux (sas2ircu).

L'utilisation de cet ebuild ne nécessite pas le chargement de module dans le kernel contrairement aux autres utilitaires testés.

# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/sys-block/sas2ircu/sas2ircu-4.00.00.00.ebuild,v 0.1 2011/02/07 11:47:29 mohamed Exp $

DESCRIPTION="Dell SAS+SATA RAID controller Command Line Interface tool"
HOMEPAGE="http://www-947.ibm.com/support/entry/portal/docdisplay?brandind=5000008&lndocid=MIGR-5084955"
LICENSE="unknow"
SLOT="0"
KEYWORDS="-* amd64 x86 ~x86-fbsd"
IUSE=""
RESTRICT="strip"
DEPEND=""
RDEPEND=""

SRC_URI="http://blog.yacoubi.fr/public/portage/${PN}-${PV}.tar.bz2"

LICENSE_URL="http://www-947.ibm.com/support/entry/portal/docdisplay?brandind=5000008&lndocid=MIGR-5084955"

S="${WORKDIR}"

src_unpack() {
        unpack ${PN}-${PV}.tar.bz2
}

supportedcards() {
        elog "This binary supports should support ALL cards, including, but not"
        elog "limited to the following series:"
        elog ""
        elog "DELL System Perk H200, H700"
	elog "IBM System x3200 M2 (4367, 4368)"
	elog "IBM System x3200 M3 (7327, 7328)"
	elog "IBM System x3250 M2 (4190, 4191, 4194)"
	elog "IBM System x3250 M3 (4251, 4252, 4261)"
	elog "IBM System x3350 (4192, 4193)"
	elog "IBM System x3400 (7973, 7974, 7975, 7976)"
	elog "IBM System x3400 M2 (7836, 7837)"
	elog "IBM System x3455 (7940, 7941)"
	elog "IBM System x3500 (7977)"
	elog "IBM System x3500 M2 (7839)"
	elog "IBM System x3550 (7978, 1913)"
	elog "IBM System x3550 M2 (7946, 4198)"
	elog "IBM System x3650 (7979, 1914)"
	elog "IBM System x3650 M2 (7947, 4199)"
	elog "IBM System x3650 NAS (7979)"
	elog "IBM System x3655 (7985, 7943)"
	elog "IBM System x3755 (8877, 7163)"
	elog "IBM System x3850 M2 (7141, 7144, 7233, 7234)"
	elog "IBM System x3850 X5 (7145, 7146)"
	elog "IBM System x3950 M2 (7141, 7233, 7234)"
	elog "IBM System x3950 X5 (7145)"
}

src_install() {
        into /usr/
        dobin sas2ircu
}



Patch : sas2ircu-4.00.00.00.ebuild
Binaire : sas2ircu-4.00.00.00.tar.bz2

16oct. 2009

suPHP 0.7.1 SecurityException in Application.cpp:511

php_logo.png
Le 17 Septembre 2009, suPHP 0.7.1 a enfin été ajouté au portage Gentoo

* mod_suphp-0.7.1 (17 Sep 2009)
 
  17 Sep 2009; Benedikt B <hollow@gentoo.org>
  -mod_suphp-0.6.2-r3.ebuild, +mod_suphp-0.7.1.ebuild:
  version bump wrt #253537


Rappel de son utilité : suPHP est un outil permettant d'exécuter des scripts PHP avec les autorisations de leurs propriétaires (à l'inverse Mod_PHP exécute les scripts PHP avec l'utilisateur apache). Il se compose d'un module Apache (mod_suphp) et un binaire setuid root (suphp) qui est appelée par le module Apache pour changer l'uid du processus d'exécution de l'interpréteur PHP. Cela garanti donc en cas de hack sur l'un de vos hébergements que le hackeur ne puisse pas modifier au moyen d'un script PHP les hébergements appartenant aux autres comptes.

Devant installer un nouveau serveur, j'ai rapidement été tenté d'essayer cette nouvelle version après avoir bien entendu consulté le Changelog.

Or, à partir de la version 0.7.0, il faut modifier le fichier de configuration (/etc/suphp.conf) et ajouter des guillemets aux directives :

--- /etc/suphp.conf.old    2009-10-16 19:05:13.000000000 +0200
+++ /etc/suphp.conf     2009-10-16 18:38:49.000000000 +0200
@@ -38,10 +38,10 @@
 
 [handlers]
 ;Handler for php-scripts
-x-httpd-php=php:/usr/lib/php5/bin/php-cgi
-x-httpd-php5=php:/usr/lib/php5/bin/php-cgi
-x-httpd-php4=php:/usr/lib/php4/bin/php-cgi
-x-httpd-phtml=php:/usr/lib/php5/bin/php-cgi
+x-httpd-php="php:/usr/lib/php5/bin/php-cgi"
+x-httpd-php5="php:/usr/lib/php5/bin/php-cgi"
+x-httpd-php4="php:/usr/lib/php4/bin/php-cgi"
+x-httpd-phtml="php:/usr/lib/php5/bin/php-cgi"
 
 ;Handler for CGI-scripts
-x-suphp-cgi=execute:!self
+x-suphp-cgi="execute:!self"

Sans quoi aucun script PHP ne fonctionnera.

SecurityException in Application.cpp:511: Unknown Interpreter: php
Premature end of script headers: setup.php

A présent je me demande pourquoi la compatibilité de l'ancien fichier n'a pas été conservé ?

Une feature révolutionnaire dans la prochaine mouture ?

27mai 2009

dev-util/subversion-1.6.2 Cannot allocate memory

Me voila confronté à une superbe erreur avec ma Gentoo toute neuve :)

/var/tmp/portage/dev-util/subversion-1.6.2/work/subversion-1.6.2/libtool: line 6628: /bin/sed: Cannot allocate memory
libtool: install: warning: `../../subversion/libsvn_subr/libsvn_subr-1.la' has not been installed in `/usr/lib'
libsandbox:  max_envp_len too big!
/var/tmp/portage/dev-util/subversion-1.6.2/work/subversion-1.6.2/libtool: line 6669: /bin/sed: Cannot allocate memory
/usr/bin/install -c  /var/tmp/portage/dev-util/subversion-1.6.2/image//usr/bin/svnadmin
libsandbox:  max_envp_len too big!
/var/tmp/portage/dev-util/subversion-1.6.2/work/subversion-1.6.2/libtool: line 6691: /usr/bin/install: Cannot allocate memory
make: *** [install-bin] Error 126
 * 
 * ERROR: dev-util/subversion-1.6.2 failed.
 * Call stack:
 *               ebuild.sh, line   49:  Called src_install
 *             environment, line 5883:  Called die
 * The specific snippet of code:
 *       emake -j1 DESTDIR="${D}" local-install || die "Installation of core of Subversion failed";
 *  The die message:
 *   Installation of core of Subversion failed

Tout d'abord je vérifie que ma version de sed est bien à jour, mais c'est le cas.

srv1 tmp #  eix sys-apps/sed
[I] sys-apps/sed
     Available versions:  4.1.5-r1 ~4.2 {acl nls static}
     Installed versions:  4.1.5-r1(14:31:27 08/06/08)(nls -static)
     Homepage:            http://sed.sourceforge.net/
     Description:         Super-useful stream editor

Puis l'erreur libsandbox attire mon attention, je me décide de mettre à jour sandbox qui en avait besoin.

srv1 tmp # emerge -av sandbox
 
These are the packages that would be merged, in order:
 
Calculating dependencies... done!
[ebuild     U ] app-misc/pax-utils-0.1.19 [0.1.17] USE="-caps" 76 kB
[ebuild     U ] sys-apps/sandbox-1.6-r2 [1.2.18.1-r2] 300 kB

Et voila le problème est résolu, probablement un oubli dans l'ebuild qu'il me reste à remonter ;)

10avr. 2009

Fixing broken portage installations

J'ennoncais dans mon précédent article l'utilisation d'un portage recovery, permettant de continuer à utiliser la commande en cas de problème.

Le script get_portage_back.sh automatisant la mise en place du portage recovery disponible sur la page officielle Gentoo Manually fixing broken portage installations redirigeant à présent vers une erreur 404, voici la source de ce script :

#!/bin/bash
 
python_version=$(python -c 'import sys; print "%02d%02d" % sys.version_info[:2]')
unpack_dir=/var/tmp/portage-unpack
 
die() {
	echo $@
	exit 1
}
 
case "$python_version" in
	0202)
		portage_version=2.0.51.22
		portage_dir=/usr/lib/portage
		;;
	0203)
		portage_version=2.1.1
		portage_dir=/usr/lib/portage
		;;
	0204|0205)
		portage_version=2.1.4
		portage_dir=${HOME}|>/portage-recover
		;;
	0201|0200)
		die "your python version is too old"
		;;
	*)
		die "unknown python version: $python_version"
		;;
esac
 
echo ">>> Found python version ${python_version}, using portage-${portage_version}"
 
tarball="portage-${portage_version}.tar.bz2"
mypath=$(readlink -f $0)
[ -z "${DISTDIR}" ] && DISTDIR=${mypath%/*/*}
mkdir -p "$portage_dir" "$unpack_dir"
 
[ -d "$DISTDIR" ] || DISTDIR=/var/tmp
 
wget -O "${DISTDIR}/${tarball}" "http://distfiles.gentoo.org/distfiles/${tarball}"
 
tar xfj "${DISTDIR}/${tarball}" -C "$unpack_dir" 
unpack_dir=${unpack_dir}|>/portage-${portage_version}|>
 
cp -r "${unpack_dir}"/{pym,bin} "${portage_dir}/"
if [ ! -e /etc/make.globals ]; then
	echo ">>> Restoring /etc/make.globals"
	cp "${unpack_dir}/cnf/make.globals" /etc
fi
 
if [ -e "${unpack_dir}/cnf/sets.conf" -a ! -e /usr/share/portage/config/sets.conf ]; then
	echo ">>> Restoring /usr/share/portage/config/sets.conf"
	mkdir -p /usr/share/portage/config/
	cp -r "${unpack_dir}/cnf/sets.conf" /usr/share/portage/config/
fi
 
echo ">>> Testing if rescue portage works and trying to remerge portage"
export PYTHONPATH="${portage_dir}/pym" 
export PATH="${portage_dir}/bin:${PATH}"
emerge --version > /dev/null && emerge --oneshot portage
if [ "$?" -ne 0 ]; then
	echo "!!! Portage was not remerged correctly"
fi
if [ "${portage_dir}" != /usr/lib/portage ]; then
	echo ">>> The rescue portage has been installed in \$HOME/portage-recover. You can access it"
	echo "    with the following command:"
	echo "    PYTHONPATH=${portage_dir}/pym PATH="${portage_dir}|>/bin:\$PATH" emerge"
	echo "    Of course you can also remove that directory if you've sucessfully remerged portage"
	echo "    and don't need the rescue version anymore."
fi
echo ">>> Cleaning up"
rm -rf "$(dirname ${unpack_dir})"



Script : get_portage_back.sh

10avr. 2009

Emerge IOError: [Errno 21] Is a directory [sys-apps/portage]

J'ai procédé à un upgrade apparemment sans problème de sys-apps/portage-2.1.4.5 vers sys-apps/portage-2.1.6.7.

Finalement au bout de quelques jours j'ai eu besoin d'installer et de mettre à jour un paquet et c'est là que tout ce complique, la fameuse erreur IOError: [Errno 21] Is a directory est apparu.

raga ~ # emerge -av tcpdump
 
These are the packages that would be merged, in order:
 
Calculating dependencies
Traceback (most recent call last):
File "/usr/bin/emerge", line 40, in <module>
retval = _emerge.emerge_main()
File "//usr/lib/portage/pym/_emerge/__init__.py", line 14670, in emerge_main
myopts, myaction, myfiles, spinner)
File "//usr/lib/portage/pym/_emerge/__init__.py", line 13587, in action_build
mydepgraph = depgraph(settings, trees, myopts, myparams, spinner)
File "//usr/lib/portage/pym/_emerge/__init__.py", line 4373, in __init__
pkg_cache=self._pkg_cache)
File "//usr/lib/portage/pym/_emerge/__init__.py", line 1074, in __init__
real_dbapi.flush_cache()
File "//usr/lib/portage/pym/portage/dbapi/vartree.py", line 368, in flush_cache
self._owners.populate() # index any unindexed contents
File "//usr/lib/portage/pym/portage/dbapi/vartree.py", line 748, in populate
self._populate()
File "//usr/lib/portage/pym/portage/dbapi/vartree.py", line 774, in _populate
owners_cache.add(cpv)
File "//usr/lib/portage/pym/portage/dbapi/vartree.py", line 698, in add
contents = self._vardb._dblink(cpv).getcontents()
File "//usr/lib/portage/pym/portage/dbapi/vartree.py", line 1162, in getcontents
myc = open(contents_file,"r")
IOError: [Errno 21] Is a directory

Cette erreur ne donnant rien de concret sur les moteurs de recherches, je me suis tourné vers le chan officiel Gentoo, un problème de compilation avec python a été évoqué, néanmoins je reste sceptique à cette hypothèse, en effet le portage recover en version 2.1.4.5 fonctionne parfaitement. Cependant en l'utilisant je reste limité à l'utilisation de paquet dans la branche EAPI=1.

Je me suis donc intéressé de plus près au fameux dossier /var/db/pkg contenant toutes les informations sur les paquets installés nécessaires à portage. Après suppression de ce dossier (un backup a été effectué), emerge a l'air de fonctionner néanmoins je ne valide pas l'installation du paquet.

En procédant par élimination (d'où l'intérêt du backup), je remonte jusqu'au dossier /var/db/pkg/sys-libs/timezone-data-2006a, après suppression de ce dernier et une réinstallation de sys-libs/timezone-data-2009b, tout fonctionne parfaitement.