30mar. 2011

Système de fichier distribué Glusterfs

gluster_logo

Je vais débuter une série d'article qui seront publiées chaque semaine sur la mise en place de Gluster.

Gluster est un logiciel libre de système de fichiers distribué en parallèle (scale-out), capable de monter jusqu'à plusieurs pétaoctets et de gérer plusieurs milliers de clients.

Gluster est un système de fichiers de cluster/réseaux. Gluster est livré avec deux éléments, un serveur et un client.

Le serveur de stockage (ou chaque serveur d'un cluster) fait tourner glusterfsd et les clients utilisent la commande mount ou glusterfs client pour monter les systèmes de fichiers servis, en utilisant FUSE. Les Serveurs sont déployés comme des briques de stockage, chaque serveur exécutant un daemon glusterfsd qui exporte un système de fichier local comme un «volume».
Le processus client glusterfs, se connecte aux serveurs avec un protocole spécifique (implémenté au-dessus de TCP/IP, InfiniBand ou SDP) et regroupe les volumes distants en un unique volume.

gluster

* Évolutivité et performance :


L'architecture scale-out permet d'agréger des ressources en fonction des besoins de capacité et de performance sans interruption. Gluster permet également un rééquilibrer de la charge après ajout ou suppression des serveurs de données. La fonction Gluster Elastic Hash supprime la nécessité d'un serveur de métadonnées et élimine donc un goulot d'étranglement au travers d'une réelle parallélisation des accès aux données. (équilibrage de charge)

* Haute Disponibilité :


Les serveurs peuvent être géré en miroir de type RAID-1. Après une panne matérielle, glusterfs reconstruira automatiquement en tache de fond le volume défaillant. Glusterfs n'utilise pas un format propriétaire pour stocker des fichiers sur le disque des serveurs de données.

* Gluster Elastic Hash :


Plutôt que d'utiliser un serveur de métadonnées, Glusterfs utilise un algorithme de hachage afin de localiser les données dans le pool de stockage. Tous les systèmes de stockage du pool ont donc la possibilité de connaître précisément l'emplacement de n'importe quelle données sans avoir besoin d'interroger un autre serveur du pool.

* Gluster Manager Console :


Gluster offre une interface web (Python, Ruby, PHP) avancée afin de permettre la gestion et l'automatisation des différents serveurs de données.

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

18janv. 2011

World IPv6 Day le 8 Juin 2011

Internet_Society

A l'occasion du World IPv6 Day qui se déroulera le 8 Juin 2011 et afin d'apporter ma très modeste contribution (je ne vais pas me comparer au géant Google, Facebook, Yahoo!, Akamai, Limelight Networks) :

Je m'engage à ce que ce blog soit accessible en IPv6 à la date prévue pour 24h au minimum


Pour rappel et je cite Internet Society


« Le 8 Juin 2011, Google, Facebook, Yahoo!, Akamai, Limelight Networks feront partie des principales organisations qui offriront leur contenu sur IPv6 pour un test de 24 heures. L'objectif de cette journée est de motiver les organisations de toute l'industrie, les fournisseurs de services Internet, les fabricants de matériel, les fournisseurs de systèmes d'exploitation et les entreprises du web, à préparer leurs services pour IPv6 afin d’assurer une transition réussie, alors que les adresses IPv4 s'épuisent. »

Liens :

08janv. 2011

Migration vers Prestashop et référencement

prestashop_logo

C’est quoi la conversion d’URL ?

Imaginez, vous migrez votre site OsCommerce vers la plateforme PrestaShop.

Voici à quoi ressemble l’url du produit sous OsCommerce :

  • http://www.monsite.com/Toyota-Yaris-p-123.html

Et maintenant, sur votre site sous PrestaShop :

  • http://www.monsite.com/123-Toyota-Yaris.html

Et c’est là qu’intervient la conversion d’URL afin de permettre de ne pas perdre l’URL de l'ancienne page.

A quoi ça sert ?

Premièrement, vous l’aurez compris, cela permet de ne pas avoir de page 404 quand un visiteur arrive via une ancienne URL (google, ou bookmark par exemple).

Mais imaginez si vous n’aviez pas fait cela, les moteurs de recherches auraient donc dans leurs « index » des dizaines, centaines ou milliers de pages renvoyant vers une erreur 404.
Hors d'après JohnMu, ingénieur chez Google les erreur 404 permettent aux moteurs de recherche de "nettoyer" leur index, c'est-à-dire de supprimer de leur base toutes les pages périmées, ce qui veut dire que vous allez devoir recommencer tout votre référencement à partir de zéro…

Il existe une technique pour pallier à ce problème, les redirections 301.
Selon RFC2616, les moteurs de recherche devraient remplacer automatiquement l’URL qui fait une redirection 301 par l’adresse destinataire de la redirection et ils devraient sauvegarder cette dernière comme adresse officielle du contenu concerné.
Exactement ce qu’il nous faut :

  • Car Google va comprendre cela, et va mettre à jour son « index ». Il va donc remplacer l’ancienne URL par la nouvelle, et le mieux dans tout cela, c’est qu’il va garder le « PageRank » de la page. Ce qui veut dire que votre page ne perdra pas ou peu de place sur Google lors d’une recherche.
  • Car à chaque fois qu’un visiteur utilisera l’ancienne adresse dans son navigateur (bookmark), le navigateur va automatiquement comprendre que l’url a changé et va donc rediriger le visiteur sur la bonne page.

Dans quels cas j’ai besoin de faire cela ?

Il y a plusieurs dizaines de cas, mais les principaux sont certainement les suivants :

Ca ne permet donc que de rediriger une ancienne page vers une nouvelle ?

Eh bien, NON! Il est même possible de crée une conversion d’URL pour la « beauté » et le « SEO Friendly » de l’url.
En effet, c’est déjà le cas avec l’utilisation des URL Rewrite de PrestaShop, on a la possibilité d’avoir une jolie url avec le nom du produit dedans, plutôt que des caractères bizarres (product.php?id_product=123).

PrestaShop propose donc de base de changer les URL pour vous, mais certaines pages ne bénéficient pas de cette fonctionnalité (c’est la cas de page contact par exemple qui s’appelle « contact-form.php »).
Il est donc possible de créer une redirection/alias qui va dire que l’url « www.monsite.com/Contactez-nous.html » renverra vers la page « www.monsite.com/contact-form.php ».
Dans le cas d’une redirection, le visiteur verra toujours le nom « contact-form.php » dans l’url, mais dans le cas d’un alias (rewrite), le visiteur ne verra que le nom de la nouvelle page.

Mais attention, car si Google voit 2 pages identiques (contact-form.php et Contactez-nous.html) il va passer celles-ci en duplicate content, et Google n’aime pas DU TOUT ça! Il est donc très important dans des cas comme celui-ci de vérifier qu’aucune de vos pages ne renvoie vers l’ancienne url (contact-form.php).

C’est bien beau tout ça, mais comment on fait ?

Avec PrestaShop de base, vous n’avez pas la possibilité de faire cela. Hormis en mettant les mains dans le fichier « .htaccess » et de s’y connaitre, car une erreur et c’est le crash du site.

Pierre-yves a donc développé (sur l’idée de Jeckyl de Mediacom87) un module qui permet de faire cela depuis le panel d'administration Prestashop.

A quoi ca ressemble ?

prestashop_301_1.pngprestashop_301_2.pngprestashop_301_3.png

Ou trouver ce module ?

Vous trouverez le lien en bas de ce billet qui vous permettra de l’acheter à moindre coût.

Acheter le module sur le store de Mediacom87

Pierre-yves se tiens également à votre disposition pour tous développements, installations, maintenances PrestaShop sur-mesure.

26juin 2010

Xen utilisation de l'IPv6 vif-route

Xen_logo.png
Mon bloc IPv6 étant enfin routé correctement, je me suis attelé à la configuration de ce dernier sur le Dom0 et DomU Xen.

Ma configuration Xen étant à l'origine en bridge et disposant d'un bloc routé vers mon serveur, j'ai donc dût basculer ma configuration Xen en mode route. (vif-route)

Bien entendu à l'instar du mode bridge, le mode route n'est pas compatible IPv6 ...
Voici deux patch à appliquer (compatible Xen-4) ainsi qu'un exemple de configuration (Gentoo).

1) Dom0


  • vif-common
--- vif-common.sh~      2010-04-07 18:12:04.000000000 +0200
+++ vif-common.sh       2010-06-26 23:08:38.000000000 +0200
@@ -14,7 +14,7 @@
 # License along with this library; if not, write to the Free Software
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 #
-
+# IPv6 Patched by Timeuhmeuh
 
 dir=$(dirname "$0")
 . "$dir/xen-hotplug-common.sh"
@@ -135,6 +135,17 @@
   ip addr show "$1" | awk "/^.*inet.*$1\$/{print \$2}" | sed -n '1 s,/.*,,p'
 }
 
+##
+# ip6_of interface
+#
+# Print the IPv6 address currently in use at the given interface, or nothing if
+# the interface is not up.
+#
+ip6_of()
+{
+        ip -6 addr show dev "$1" scope global | awk -F'[ |/]' '/inet6 (([0-9a-f]+:*)+)/ { print $6 } ' | awk '/::/ {print $1}'
+}
+
 
 ##
 # dom0_ip
@@ -156,3 +167,38 @@
   fi
   echo "$result"
 }
+
+##
+# dom0_ip6
+#
+# Print the IPv6 address of the interface in dom0 through which we are routing.
+# This is the IPv6 address on the interface specified as "netdev" as a parameter
+# to these scripts, or eth0 by default.  This function will call fatal if no
+# such interface could be found.
#
+dom0_ip6()
+{
+    local nd=${netdev:-eth0}
+    local result=$(ip6_of "$nd")
+    if [ -z "$result" ]; then
+        echo ""
+    else
+        echo "$result"
+    fi
+}
+
+##
+# is_ip6
+#
+# Verifing IPv6 address
+#
+is_ipv6()
+{
+case "$1" in
+    *:*:*)
+        echo "yes"
+        ;;
+    *)
+        echo ""
+esac
+}
  • vif-route
--- vif-route~	2010-04-07 18:12:04.000000000 +0200
+++ vif-route	2010-06-26 23:12:45.000000000 +0200
@@ -18,17 +18,24 @@
 # Read from the store:
 # ip      list of IP networks for the vif, space-separated (default given in
 #         this script).
+#
+# IPv6 Patched by Timeuhmeuh - http://blog.yacoubi.fr
 #============================================================================
 
 dir=$(dirname "$0")
 . "$dir/vif-common.sh"
 
 main_ip=$(dom0_ip)
+main_ip6=$(dom0_ip6)
 
 case "$command" in
     online)
+	log info "[vif-route] online request, ip ${ip} with main_ip ${main_ip} and main_ip6 ${main_ip6} for $vif."
         ifconfig ${vif} ${main_ip} netmask 255.255.255.255 up
-        echo 1 >/proc/sys/net/ipv4/conf/${vif}/proxy_arp
+	if [ ! -z "${main_ip6}" ]; then
+		ip -6 addr add ${main_ip6} dev ${vif}
+	fi
+	echo 1 >/proc/sys/net/ipv4/conf/${vif}/proxy_arp
         ipcmd='add'
         cmdprefix=''
         ;;
@@ -43,7 +50,16 @@
     # If we've been given a list of IP addresses, then add routes from dom0 to
     # the guest using those addresses.
     for addr in ${ip} ; do
-      ${cmdprefix} ip route ${ipcmd} ${addr} dev ${vif} src ${main_ip}
+	result=$(is_ipv6 "${addr}")
+	if [ -z "${result}" ] ; then
+		result=`${cmdprefix} ip route ${ipcmd} ${addr} dev ${vif} src ${main_ip} 2>&1`
+		log info "[vif-route] Result: ${result}"
+	else
+		log info "[vif-route] Adding IPv6 address ${addr} with src ${main_ip6} for $vif."
+	      result=`${cmdprefix} ip -6 route ${ipcmd} ${addr} dev ${vif} src ${main_ip6} 2>&1`
+		log info "[vif-route] Result: ${result}"
+	fi
+#      ${cmdprefix} ip route ${ipcmd} ${addr} dev ${vif} src ${main_ip}
     done 
 fi
  • /etc/conf.d/net
config_eth0=( "192.168.0.1/24" "2001:758:f00:340:192:168:0:12/64" "2001:758:5312::/48" )
  • /etc/xen/domU
vif = [ 'ip=2001:758:5312::2 192.168.0.10' ]

2) Dom0


  • /etc/conf.d/net
config_eth0=( "192.168.0.2/24" "2001:758:5312::2/48" )
routes_eth0=( "default gw 192.168.0.1" "default via 2001:758:5312::" )

Patch :


Lien utile : xen-and-routed-ipv6

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

15mar. 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

08mar. 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

01mar. 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év. 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.

- page 2 de 5 -