Yacoubi Mohamed

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 ?.

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

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

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

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