Mot-clé - linux

Fil des billets

24avr. 2010

useradd unknown group

gentoo-logo

  1. Contexte :

Il s'agit d'un serveur sous Gentoo Linux hébergeant des milliers de comptes (1520 précisément).

srv1 ~ # equery l sys-apps/shadow
[ Searching for package 'shadow' in all categories among: ]
 * installed packages
[I--] [  ] sys-apps/shadow-4.0.18.2 (0)
  1. Problème :

Lors de la création de nouveau compte :

srv1 ~ # /usr/sbin/useradd -m -d /ftps/XXXX/XX/xx15000 -s /bin/false -gusers -u 15000  xx15000
useradd: unknown group users
  1. Résolution :

Tout d'abord je crée un utilisateur pour l'ajouter manuellement dans le groupe users.

srv1 ~ # /usr/sbin/useradd -m -d /ftps/XXXX/XX/xx15000 -s /bin/false -u 15000  xx15000
srv1 ~ # gpasswd -a xx15000 users
Ajout de l'utilisateur xx15000 au groupe users

Le problème ne viens pas donc du groupe (/etc/group corrompu par exemple).

Je procède ensuite à la mise à jour de shadow vers la dernière version.

sys-apps/shadow-4.1.2.2 [4.0.18.2]

Ayant constaté lors de la mise à jour l'ajout d'une option dans le fichier /etc/login.defs (qui définit la configuration de shadow pour le système), je m'y intéresse.

#MAX_MEMBERS_PER_GROUP   0

Cette option définie le nombre maximum de membres par entrée de groupe.
Lorsque le maximum est atteint, une nouvelle entrée de groupe (ligne) est démarrée dans /etc/group (avec le même nom, même mot de passe et même GID).
Cette fonctionnalité (groupe découpé) permet de limiter la longueur des lignes dans le fichier de groupes.

Je décide donc d'utiliser cette option (avec mes 1520 utilisateurs la ligne correspondant au groupe users fait 10301 caractères).

MAX_MEMBERS_PER_GROUP   150

Je régénère mon fichier /etc/group.

/usr/sbin/grpconv

Le fait de limiter la longueur des lignes à 150 utilisateurs a résolu le problème.

J'ai effectué un test avec une limitation à 25 utilisateurs, un segfault est alors renvoyé à chaque tentative de création d'utilisateur, je pense donc que je serai confronté dans les prochains mois à un nouveau problème Quelles seront les limitations exacte avec /etc/group ?.

15mars 2010

Xen utilisation de l'IPv6 en bridge

Xen_logo.png
Ayant obtenu un bloc IPv6 tout récemment, j'ai tenté de le configurer sur mon Dom0 Xen pensant que le billet Xen bridge IPv6 support suffirait.

Il n'en fut rien, Xen lors de l"initialisation du bridge ne traite aucunement la partie IPv6, j'ai donc développé un petit patch en m'appuyant sur la partie IPv4.

--- /etc/xen/scripts/network-bridge~	2008-06-03 14:50:29.000000000 +0100
+++ /etc/xen/scripts/network-bridge	2010-03-02 18:15:50.000000000 +0100
@@ -103,6 +103,8 @@
 get_ip_info() {
     addr_pfx=`ip addr show dev $1 | egrep '^ *inet ' | sed -e 's/ *inet //' -e "s/$1//"`
     gateway=`ip route show dev $1 | fgrep default | sed 's/default via //'`
+    addr_pfx_6=`ip -6 addr show dev $1 | egrep '^ *inet' | sed -e 's/ *inet6 //' -e "s/$1//" | egrep -E ^2`
+    gateway_6=`ip -6 route show dev $1 | fgrep default | sed 's/default via //' | cut -d' ' -f1`
 }
 
 do_ifup() {
@@ -113,6 +115,18 @@
             ip addr add ${addr_pfx} dev $1
             ip link set dev $1 up
             [ -n "$gateway" ] && ip route add default via ${gateway}
+	fi
+    fi
+}
+
+do_ifup_6() {
+    if [ $1 != "${netdev}" ] || ! ifup $1 ; then
+       	if [ -n "$addr_pfx_6" ] ; then
+      		# use the info from get_ip_info()
+       		ip -6 addr flush $1
+	        ip -6 addr add ${addr_pfx_6} dev $1
+        	ip -6 link set dev $1 up
+            	[ -n "$gateway_6" ] && ip route add default via ${gateway_6}
         fi
     fi
 }
@@ -245,6 +259,7 @@
     fi
     add_to_bridge2 ${bridge} ${pdev}
     do_ifup ${bridge}
+    do_ifup_6 ${bridge}
 
     if [ ${antispoof} = 'yes' ] ; then
 	antispoofing
@@ -272,6 +287,7 @@
     ip link set ${bridge} name ${tdev}
     ip link set ${pdev} name ${netdev}
     do_ifup ${netdev}
+    do_ifup_6 ${netdev}
 
     brctl delbr ${tdev}
 }



Patch : xen-vif-bridge-ipv6.diff

08mars 2010

Gestion des sessions Magento

magento_logo.jpg
Suite à mon article Centralisation des sessions Magento en cluster présentant l'utilisation de Memcached avec Magento, voici également d'autres façons de gérer les sessions.

  1. Utilisation du mode par défaut :

Lors de l'utilisation de ce mode par défaut, les sessions sont sauvegardées dans le répertoire /home/www/domain.com/var/session. Dans le cadre d'un système clusterisé il serait nécessaire de mutualiser ce répertoire.

Dans le cadre de l'utilisation de Magento sur un serveur en StandAlone, je vous conseil de stocker vos sessions (profitez-en pour vous occuper du cache) en RAM afin d'optimiser au mieux les accès.
Par exemple mon /etc/fstab avec 256Mo alloué pour le cache et 64Mo pour les sessions

tmpfs /home/www/domain.com/var/cache tmpfs size=256M 0 0
tmpfs /home/www/domain.com/var/session tmpfs size=64M 0 0

Attention en cas de redémarrage du serveur le cache et les sessions seront intégralement perdus, il conviendra donc de régénérer le cache depuis l'administration.

  1. Utilisation d'une base de données :

Il vous suffit de choisir l'option appropriée lors de l'étape 3 de l'assistant d'installation : Save session data in Database ou d'effectuer la modification suivante dans app/etc/local.xml.

<session_save><![CDATA[db]]></session_save>

Les sessions devraient à présent apparaître dans la table core_session.

  1. Utilisation de Memcached :

Voir le précèdent billet : Memcached et Magento

01mars 2010

Xen et utilisation du NAT

Xen_logo.png
Un ami ayant eu un besoin urgent de pouvoir gérer des DomU Xen via le NAT et comme la configuration de Xen en NAT ne me plait guère, je me suis alors permis de développer un petit script très simple afin de gérer des règles de routage.

#!/bin/sh
IPTABLES=/sbin/iptables
MORE=/bin/more
GREP=/bin/grep
ECHO=/usr/bin/echo
IP_PUBLIC=XXX.XXX.XXX.XXX
IP_PRIVATE=XXX.XXX.XXX.XXX/XX
 
if ! ${GREP}|> '1' /proc/sys/net/ipv4/ip_forward >/dev/null 2>&1; then
 ${ECHO}|> "1" > /proc/sys/net/ipv4/ip_forward
fi
 
# Routage des requetes sortante DomU
if ! ${IPTABLES}|> -L POSTROUTING -t nat | ${GREP}|> ${IP_PUBLIC}|>  >/dev/null 2>&1; then
	${IPTABLES}|> -A POSTROUTING -t nat -s ${IP_PRIVATE}|> -j SNAT --to ${IP_PUBLIC}|>
fi
 
echo "Rules policy in progress :"
echo "________________________________________________________________________________________________"
${IPTABLES}|> -t nat -L PREROUTING --line-numbers | ${MORE}|> +2
echo "________________________________________________________________________________________________"
echo
echo "Actions :"
echo "+---+-----------------+"
echo "| 1 |    Add Rules    |"
echo "+---+-----------------+"
echo "| 2 |   Delete Rules  |"
echo "+---+-----------------+"
echo "| 3 |    List Rules   |"
echo "+---+-----------------+"
echo -n "  >> "
        read TASK
case ${TASK}|> in
	0)
        	echo "#############"
	        echo "# 28/02/2010 #"
        	echo "#############"
	;;
	1)
		echo "== Add Rules =="
		echo -n "IP Source >> "
			read IPSOURCE
                if ${IPTABLES}|> -t nat -L PREROUTING --line-numbers | ${GREP}|> -w ${IPSOURCE}|> >/dev/null 2>&1; then
                	echo "IP Source is already configured, please remove it before"
			exit
		fi
		echo -n "IP Destination >> "
			read IPDESTINATION
		echo "-------------------------------"
		echo "Apply this Rules, Traffic destined ${IPSOURCE} redirect to ${IPDESTINATION} ? (Y/N)"
		echo -n "  >> "
			read APPLY
		echo
		if ! [ "${APPLY}" = "Y" ]; then
			echo "You have not validated, rules not add"
			exit
		fi
		${IPTABLES}|> -A PREROUTING -t nat -j DNAT -d ${IPSOURCE}|>/32 --to ${IPDESTINATION}|>
		/etc/init.d/iptables save >/dev/null 2>&1
		echo "Success Rules Apply"
	;;
	2)
		echo "== Delete Rules =="
		echo -n "Rules numbers >> "
			read DELRULES
                if ! ${IPTABLES}|> -t nat -L PREROUTING --line-numbers | ${GREP}|> -w ${DELRULES}|> >/dev/null 2>&1; then
			echo "Rules not exist"
			exit
		fi
                echo "Delete this Rules, `${IPTABLES} -t nat -L PREROUTING --line-numbers | ${GREP} -w ${DELRULES} | awk 'BEGIN { FS=" " } { print "Traffic destined to "$6" redirect "$7 }'` ? (Y/N)"
		echo -n "  >> "
                        read APPLY
                echo
                if ! [ "${APPLY}" = "Y" ]; then
                        echo "You have not validated, rules not delete"
                        exit
                fi
		${IPTABLES}|> -t nat -D PREROUTING ${DELRULES}|>
                /etc/init.d/iptables save >/dev/null 2>&1
                echo "Success Rules Apply"
	;;
	3)
		echo "== List Rules =="
		echo "________________________________________________________________________________________________"
		${IPTABLES}|> -t nat -L PREROUTING --line-numbers | ${MORE}|> +2
		echo "________________________________________________________________________________________________"
	;;
	*)
        	echo "---------------------------"
        	echo "Invalid selection"
        	exit
        ;;
esac



Script : xen-nat.sh

25févr. 2010

Xen Allocution memoire superieur à 512Mo

Xen_logo.png
J'ai rencontré un nouveau problème avec l'ensemble du serveur Xen (Dom0/DomU) lors de l'allocution de plus de 512Mo de RAM (1024Mo par exemple).

Le serveur sur lequel était alloué autant de mémoire vive crashé au démarrage. (ce qui est gênant lorsqu'on décide que Dom0 doit avoir plus de mémoire)

Ce bug n'est bien entendu pas présent lors de l'utilisation de HVM (Hardware-Assisted Virtual Machine) mais uniquement en paravirtualisation.

Dans le cas où ce bug se produit, il suffit simplement de désactiver l'option suivante dans le kernel et de le recompiler :

Processor type and features  --->
[ ] Allocate 3rd-level pagetables from highmem

L'option Allocate 3rd-level pagetables from highmem , permet de placer les structures de données du gestionnaire de mémoire virtuelle en mémoire haute. Ces structures ayant une taille proportionnelle à la quantité de mémoire effectivement installée, cette option permet d'éviter qu'elles ne saturent la mémoire basse.

01janv. 2010

Optimisation de Magento avec la réplication Mysql

magento_logo.jpg
Pour les utilisateurs d'une réplication mysql et de Magento, il faut savoir que tout a été prévu par Magento afin d'optimiser le traitement des requêtes Mysql avec un serveur dédiée à la lecture, et un second à l'écriture.

Voici pour les développeurs la syntaxe à adopter :

       <resources>
            <db>
                <table_prefix><![CDATA[]]></table_prefix>
            </db>
            <default_setup>
                <connection>
                        <host><![CDATA[Mysql_Write:port]]></host>
                        <username><![CDATA[user]]></username>
                        <password><![CDATA[password]]></password>
                        <dbname><![CDATA[bdd_name]]></dbname>
                    <active>1</active>
                </connection>
            </default_setup>
            <default_read>
                <connection>
                        <host><![CDATA[Mysql_ReadOnly:port]]></host>
                        <username><![CDATA[user]]></username>
                        <password><![CDATA[password]]></password>
                        <dbname><![CDATA[bdd_name]]></dbname>
                    <active>1</active>
                </connection>
            </default_read>
        </resources>

Bien entendu, il ne faut pas oublier que je préconise un serveur Mysql dédié au rôle de Read Only, donc une réplication avec des paramètres avancés du type Replicate_Wild_Ignore_Table afin d'éviter une action du type Je me suis trompé de serveur lors de l'insertion et la réplication Mysql sur le serveur RO est donc en erreur

Lien :

Magento Performance Group

23déc. 2009

Attaque DOS PHP < 5.2.12 suite

php_logo.png
Une petite mise à jour du ticket précédent Attaque DOS PHP < 5.3.1

Le 17 Décembre 2009, l'équipe de PHP a releasé PHP-5.2.12 qui corrige également cette vulnérabilité.

Version 5.2.12
17-December-2009

    * Security Fixes
          o Added "max_file_uploads" INI directive, which can be set to limit the number of file uploads per-request to 20 by default, to prevent possible DOS via temporary file exhaustion. (Ilia)


Le changelog de PHP est disponible : PHP-5.3 Changelog

11déc. 2009

Attaque DOS PHP < 5.3.1

php_logo.png
Cela fait quelques jours que je voulait ajouter un nouveau billet sur cette faille.

Récemment, une faille a été découverte sur toutes les versions de PHP inférieures à 5.3.1.
Cette faille permet une attaque de type DOS (Denial Of Service), la faille consiste à envoyer via une requête POST plusieurs milliers de fichiers sur le serveur jusqu'à saturer ce dernier.


D'après ce rapport que je vous invite vivement à consulter, chaque système réagit différemment.

Pour l'heure 2 solutions existent afin de palier au problème :

  • Désactiver la directive file_uploads dans le php.ini si vous n'en avez pas besoin (file_uploads = Off)
  • Mettre à jour PHP vers 5.3.1. Une nouvelle directive "max_file_uploads" fait son apparition avec une valeur par défaut de 20 (max_file_uploads = 20)

Le changelog de PHP est disponible : PHP-5.3 Changelog

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 ?

15sept. 2009

Xen bridge IPv6 support

Xen_logo.png
A chaque mise à jour de Xen je me retrouve confronté à un bug causé par le support IPv6 compilé dans le kernel.
Ce petit bug est présent depuis près d'une année il sera peut être un jour corrigé, en attendant voici le patch à utiliser (ça m'évitera d'avoir à le rechercher la prochaine fois)

--- /etc/xen/scripts/network-bridge~	2008-06-03 14:50:29.000000000 +0100
+++ /etc/xen/scripts/network-bridge	2008-06-03 14:50:29.000000000 +0100
@@ -90,7 +90,7 @@
 tdev=tmpbridge
 
 get_ip_info() {
-    addr_pfx=`ip addr show dev $1 | egrep '^ *inet' | sed -e 's/ *inet //' -e "s/$1//"`
+    addr_pfx=`ip addr show dev $1 | egrep '^ *inet ' | sed -e 's/ *inet //' -e "s/$1//"`
     gateway=`ip route show dev $1 | fgrep default | sed 's/default via //'`
 }



Patch : xen-vif-bridge-ipv6-225715.diff
Lien : Gentoo Bug 225715

- page 2 de 4 -