Yacoubi Mohamed

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

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 :

• Migration d’un OsCommerce vers PrestaShop
• Migration d’un PowerBoutique vers PrestaShop
• Migration d’un VitueMart vers PrestaShop
• Migration d’un PrestaShop vers PrestaShop (et oui… même dans ce cas)
• Changement du rewrite d’une catégorie, d’un produit ou d’un cms (si on change le nom/rewrite sous PrestaShop, alors l’url de la page change… et donc on perd le référencement de celle-ci).
• …

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 ?

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.

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

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

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.