Mot-clefs : Sysadmin

Utilisation de yum shell pour migrer de php-mysql vers php-mysqlnd

Par Guillaume Kulakowski, le mercredi 08 mai 2013 - 17:28 | Catégories : Sysadmin

Avec l'arrivée imminante de php 5.5, version qui verra disparaitre la librairie php-mysql, il est grand temps d'entamer une migration vers mysqlnd. Voici donc le mode opératoire pour effectuer ce changement en utilisant yum shell & le dépôt remi sur ma RHEL6.

Pourquoi yum shell ? Car il n'est pas possible de passer par un simple yum install :

root@kalach ~> yum install php-mysqlnd
Loaded plugins: changelog, downloadonly, presto, product-id, rhnplugin
This system is receiving updates from RHN Classic or RHN Satellite.
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package php-mysqlnd.x86_64 0:5.4.14-1.el6.remi will be installed
--> Processing Conflict: php-mysql-5.4.14-1.el6.remi.x86_64 conflicts php-mysqlnd
--> Finished Dependency Resolution
Error: php-mysql conflicts with php-mysqlnd-5.4.14-1.el6.remi.x86_64
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

En effet php-mysqlnd et php-mysql rentrent en conflit...

Alors essayons de désinstaller php-mysql :

root@kalach ~> yum remove php-mysql
Loaded plugins: changelog, downloadonly, presto, product-id, rhnplugin
This system is receiving updates from RHN Classic or RHN Satellite.
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package php-mysql.x86_64 0:5.4.14-1.el6.remi will be erased
--> Processing Dependency: php-mysql for package: php-pluf-1.0-3.gitb1fed2e.el6.remi.noarch
--> Processing Dependency: php-mysql for package: phpMyAdmin-3.5.8.1-1.el6.remi.noarch
--> Processing Dependency: php-mysql for package: cacti-0.8.8a-2.el6.noarch
--> Running transaction check
---> Package cacti.noarch 0:0.8.8a-2.el6 will be erased
---> Package php-pluf.noarch 0:1.0-3.gitb1fed2e.el6.remi will be erased
--> Processing Dependency: php-pluf >= 1.0-3 for package: indefero-1.3.3-1.el6.noarch
---> Package phpMyAdmin.noarch 0:3.5.8.1-1.el6.remi will be erased
--> Running transaction check
---> Package indefero.noarch 0:1.3.3-1.el6 will be erased
--> Finished Dependency Resolution
 
Dependencies Resolved
 
=======================================================================================================
 Package         Arch        Version                          Repository                          Size
=======================================================================================================
Removing:
 php-mysql       x86_64      5.4.14-1.el6.remi                @remi                              449 k
Removing for dependencies:
 cacti           noarch      0.8.8a-2.el6                     @epel                              5.4 M
 indefero        noarch      1.3.3-1.el6                      @/indefero-1.3.3-1.el6.noarch      3.4 M
 php-pluf        noarch      1.0-3.gitb1fed2e.el6.remi        @remi                              1.2 M
 phpMyAdmin      noarch      3.5.8.1-1.el6.remi               @remi                               22 M
 
Transaction Summary
=======================================================================================================
Remove        5 Package(s)
 
Installed size: 33 M
Is this ok [y/N]:

Trop de dépendances !

La solution : yum shell :

root@kalach ~> yum shell                                     13:37
Loaded plugins: changelog, downloadonly, presto, product-id, rhnplugin
This system is receiving updates from RHN Classic or RHN Satellite.
Setting up Yum Shell
> install php-mysqlnd
Setting up Install Process
> remove php-mysql
Setting up Remove Process
> run
--> Running transaction check
---> Package php-mysql.x86_64 0:5.4.14-1.el6.remi will be erased
---> Package php-mysqlnd.x86_64 0:5.4.14-1.el6.remi will be installed
--> Finished Dependency Resolution

================================================================================
 Package            Arch          Version                    Repository    Size
================================================================================
Installing:
 php-mysqlnd        x86_64        5.4.14-1.el6.remi          remi         260 k
Removing:
 php-mysql          x86_64        5.4.14-1.el6.remi          @remi        449 k

Transaction Summary
================================================================================
Install       1 Package(s)
Remove        1 Package(s)

Total download size: 260 k
Is this ok [y/N]: y
Downloading Packages:
Setting up and reading Presto delta metadata
Processing delta metadata
Package(s) data still to download: 260 k
php-mysqlnd-5.4.14-1.el6.remi.x86_64.rpm                 | 260 kB     00:00     
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing : php-mysqlnd-5.4.14-1.el6.remi.x86_64                         1/2 
  Erasing    : php-mysql-5.4.14-1.el6.remi.x86_64                           2/2 
  Verifying  : php-mysqlnd-5.4.14-1.el6.remi.x86_64                                                                                                                                                         1/2 
  Verifying  : php-mysql-5.4.14-1.el6.remi.x86_64                                                                                                                                                           2/2 

Removed:
  php-mysql.x86_64 0:5.4.14-1.el6.remi                                                                                                                                                                          

Installed:
  php-mysqlnd.x86_64 0:5.4.14-1.el6.remi                                                                                                                                                                        

Finished Transaction
> exit
Leaving Shell

Et voila, bien sûr on peut utiliser yum shell pour d'autres opérations.

ownCloud : mon cloud à moi (Dropbox like & killer !)

Par Guillaume Kulakowski, le jeudi 06 sept 2012 - 20:54 | Catégories : Sysadmin

Cela fait maintenant un certain temps que je me sers de Dropbox pour synchroniser les données de mes différents postes mais également pour pouvoir accéder à ces informations de partout. Bref pour mettre mes données dans les nuages.

Le problème de Dropbox c'est qu'une fois mes 10Go passés, la solution devient payante (normale me direz-vous c'est un service qu'on consomme il est normal de la payer). L'autre problème, plus grave, est que les données ne sont pas cryptées et c'est plutôt dérangeant lorsqu'un problème survient.

Donc j'ai un peu regardé ce qui s'offrait à moi comme Dropbox like et DropBox killer.

Les concurrents : Box, Drive, SkyDrive et Hubic

Box, Drive et SkyDrive ont des prix équivalents à DropBox. hubiC quant à lui offre plusieurs avantages :

Français : mes données restent donc en France et sont donc soumises aux lois françaises,
Prix compétitifs,
Possibilité de monter du WebDAV et de faire des cryptages avec encfs. Après il faut juste s'accrocher.

J'ai un peu testé hubiC mais le client mal intégré à l'OS et les performances d'un montage WebDAV m'ont vite découragé.

Mon cloud à moi : ownCloud

Comme je possède un serveur, je me suis donc dit que je pouvais héberger mon cloud à moi :

SparkleShare : très prometteur, mais GIT est-il un moteur de stockage adéquate pour des fichiers binaires (MP3, photos, etc.) ? AMHA, la réponse est non !
Syncany : prometteur sur le papier, mais je ne bosse pas sur le papier ;-).

Bref, je me suis alors tourné vers OwnCloud qui est une sorte de DropBox mais hébergé chez soit :

Client Linux / Mac / Windows,
Interface web,
WebDAV,
Cryptage,
Versioning,
Partage,
etc.

Cependant, l'outil n'est pas encore exempte de problèmes. Par exemple, l'interface web est très lente, des améliorations devraient arriver avec la version 4.5 et un système de cron.

Loutil possède une feuille de route claire, la version 4.5 est actuellement en beta, les fonctionnalités à venir sont alléchantes :

Intégration au sein de Fedora 18,
Synchronisation de vos bookmarks Firefox,
Montage Dropbox et Drive
etc.

Sortie d'Indefero 1.3.2 et disponibilité des RPMs

Par Guillaume Kulakowski, le jeudi 10 mai 2012 - 10:43 | Catégories : Sysadmin, Indefero, RPM

La forge Indefero, utilisée sur projects.llaumgui.com (entre autre, car on s'en sert également sur Fedora-Fr et à mon travail) est sortie hier en version 1.3.2.

L'occasion pour moi de mettre à jour les RPMs disponibles sur mon dépôts et également de rappeler la review Request au bon souvenir des approbateurs potentiels.

Pour mettre à jour votre forge, rien de plus simple :

Mise à jour du RPM :

yum --enablerepo=llaumgui update indefero

Mise à jour de la configuration (/etc/indefero/idf.php).
Mise à jour de la base :

root@stetson /usr/share/indefero> php /usr/share/php/pluf/migrate.php --conf=/etc/indefero/idf.php -a -d -u
PHP include path: .:/usr/share/pear:/usr/share/php:/usr/share/php/pluf
Migrate  to version latest
18 18DownloadMD5 up
19 19WikiPageAssocs up
20 20AddWikiResources up
21 21WikiPageRevisionName up
22 22ProjectTagRelationTable up
23 23ProjectActivity up
24 24CurrentProjectActivity up

Effacement du cache :

rm -f /tmp/Pluf_*

Voila.

Ma forge (projects.llaumgui.com) sous Indefero 1.3

Par Guillaume Kulakowski, le mardi 01 mai 2012 - 14:05 | Catégories : Sysadmin

Cela va faire bientôt une semaine que ma forge tourne sans problème sous Indefero 1.3. J'en ai également profité pour mettre à jour la forge au boulot, car nous avions atteint un nombre de projets critique et la nouvelle page d'accueil introduite avec la version 1.3 nous permet maintenant de retrouver rapidement nos projets en fonction des technologies, des clients, etc.

Malheureusement la 1.3 comportant quelques bugs (notamment pour les utilisateurs de PostgreSQL, et une dépendance à Pluf) j'ai bien mis à jour le SPEC, mais je n'ai pas encore releasé les RPMs sur mon dépôt et pense pour cela attendre la 1.3.1 qui ne devrait tarder.

CSSLint et Sniffer Zeta Components dans le dépôt llaumgui

Par Guillaume Kulakowski, le dimanche 20 nov 2011 - 10:59 | Catégories : CSSLint, Intégration continue, Jenkins, Sysadmin, RPM

En ce moment, professionnellement je travaille beaucoup avec Jenkins, qui nous permet de monter en qualité dans le code mais également en maintenabilité. J'en suis tellement fan que je suis entrain de me monter une plateforme d'intégration continue personnelle sur mon serveur (sujet d'un prochain billet à venir).

Comme il manque encore quelques outils en RPM, j'ai packagé CSSLint pour Fedora 14/15/16 et RHEL 5/6. Vous pouvez donc trouver cet utilitaire au sein du dépôt llaumgui, package pour lequel j'ai également ouvert une review request.

Au niveau des eZ Components que je package pour Fedora et EPEL, il manquait le standard pour php Code Sniffer. C'est chose faite avec l'arrivée de PHP_CodeSniffer_Standards_Zeta dans le dépôt llaumgui.

Mise en place et exploitation de Memcached

Par Guillaume Kulakowski, le mercredi 20 juil 2011 - 08:27 | Catégories : Cacti, IPB, Mediawiki, Memcached, Scénario-PaintBall, Sysadmin, Dotclear, Indefero

Afin de réduire au maximum les appels à la base de données, ainsi que les traitements résultant de l'exploitation des requêtes, les CMS, Wikis, forums et autre blogs utilisent au maximum des systèmes de cache. Le plus souvent les fichiers sont stockés directement sur le système de fichier, mais il existe des alternatives de stockage telles que les système de mémoire cache distribuée dont Memcached en est un excellent représentant.

Bien que pour le moment je ne possède qu'un seul serveur pour Scenario-Paintball et que je n'ai pas besoin de distribuer mon cache ou mes sessions, l'utilisation d'un stockage en RAM apporte un gain de performance par rapport à un stockage sur disque dont les accès (I/O) sont généralement plus lents.

Pourquoi Memcached en plus d'APC

Certaines applications comme IPB proposent de stocker leur cache applicatif au sein d'APC.

En mon sens (mais peut-être suis je un puriste) APC est un cache d'opcode et non un cache applicatif. De plus, il n'est pas distribué et dans le cas d'une application répartie sur plusieurs serveurs, on pourrait rencontrer des versions de cache différentes.

Pour du cache applicatif, je pense qu'il vaut mieux utiliser un cache distribué et donc (par exemple) Memcached.

Installation de Memcached et des extensions pour php et Python

Pour installer Memcached et les extensions pour Python et php, rien de plus simple : Just Yum It !

yum install memcached.x86_64 python-memcached.noarch php-pecl-memcached.x86_64 perl-Cache-Memcached.noarch

Monitorer Memcached

Pour monitorer Memcached, j'ai trouvé sur la toile un memcahce.php dans le même style que l'APC.php permettant de monitorer APC.

J'ai également mis en place un template pour Cacti, également trouvé sur le web, pour monitorer Memcached au sein de mon instance Cacti.

Configuration des différentes applications en place sur mon serveur

Indefero est compatible avec Memcached et il existe une documentation pour ça.
MediaWiki est compatible avec Memcached et il existe une documentation pour ça.
Invision Power Bord est compatible, entre autres, avec Memcached et il existe une documentation pour ça.
Il existe un plugin pour permettre à Dotclear d'utiliser Memcached.
Pour ce qui est des sessions, j'ai appliqué la configuration suivante :

;;;;;;;;;;;;;;;
;  Memcached  ;
;;;;;;;;;;;;;;;
;  Use memcache as a session handler
session.save_handler=memcached
;  Defines a comma separated list of server urls to use for session storage
session.save_path="localhost:11211"

Rajouter un disque (SSD) dans un groupe de volumes LVM

Par Guillaume Kulakowski, le dimanche 16 jan 2011 - 11:11 | Catégories : LVM, SSD, Sysadmin

Je viens de profiter des soldes pour muscler une fois de plus ma station de travail. enterprise passe donc à 8Go de RAM mais surtout possède à présent 64Go de disque SSD en SATA III. L'occasion pour moi de faire un article sur comment rajouter un disque dans un groupe de volumes et comment y déplacer les partitions qui vont bien.

Remarques :

Je possède 2 groupes de volumes : VG00 et VG01, dans cette article VG01 ne rentre pas en compte. Je l'ignore donc volontairement.
J'utilise system-config-lvm pour illustrer mes propos. Bien évidement vous pouvez passer par gparted et system-config-lvm pour faire tout ce que je décris ici, mais c'est quand même moins sport et puis le jour où vous administrerez un serveur j'espère que vous n'aurez pas ces GUI sous la main !
Merci à Remi Collet pour ses conseils sur le LVM et pour son article LVM c'est quand même bien qui m'a servi de base.
Pour ceux qui ne connaissent que Windows, ils vont avoir un choc : avec LVM on peut déplacer une partition d'un disque dur vers un autre à chaud et cela même si la partition est la partition système !

Préambule

Ma carte mère gère le SATA III, j'ai donc choisi un disque SSD SATA III de la marque Crucial. Lors du premier boot, je n'ai pas trouvé mon nouveau disque. Pour cela j'ai du passer l'option "Marvell Controller" de IDE vers AHCI, si vous rencontrez le même problème je vous invite à lire le mode d'emploi de votre carte mère.

Partitionnement du disque

Maintenant que le disque dur est visible il faut le partitionner. La Commande fdisk -l me retourne moult informations mais surtout m'indique que mon disque se prénomme /dev/sda. Je vais donc le partitionner en 2 :

512Mo pour le /boot,
le reste pour mon LVM.

Il est possible de faire ceci avec parted ou même gparted, je me le suis fait à l'ancienne (fdisk) :

root@enterprise ~> fdisk /dev/sda
Le périphérique ne contient pas une table de partitions DOS ou Sun, SGI, OSF valide
Création d'une nouvelle étiquette DOS avec id de disque 0x51d8c6f2.
Les modifications restent en mémoire jusqu'à ce que vous les écriviez.
Après quoi, bien sûr, le contenu précédent sera irrécupérable.
 
AVERTISSEMENT: fanion 0x0000 non valide dans la table de partitions 4, sera corrigé par w(écriture)
 
Commande (m pour l'aide): m
Commande d'action
   a   bascule le fanion d'amorce
   b   éditer l'étiquette BSD du disque
   c   basculer le fanion de compatibilité DOS
   d   supprimer la partition
   l   lister les types de partitions connues
   m   afficher ce menu
   n   ajouter une nouvelle partition
   o   créer une nouvelle table vide de partitions DOS
   p   afficher la table de partitions
   q   quitter sans enregistrer les changements
   s   créer une nouvelle étiquette vide pour disque de type Sun
   t   modifier l'id de système de fichiers d'une partition
   u   modifier les unités d'affichage/saisie
   v   vérifier la table de partitions
   w   écrire la table sur le disque et quitter
   x   fonctions avancées (pour experts seulement)
 
Commande (m pour l'aide): n
Commande d'action
   e   étendue
   p   partition primaire (1-4)
p
Numéro de partition (1-4, par défaut 1): 
Premier secteur (2048-125045423, par défaut 2048): 
Utilisation de la valeur par défaut 2048
Dernier secteur, +secteurs or +taille{K,M,G} (2048-125045423, par défaut 125045423): +512M
 
Commande (m pour l'aide): n
Commande d'action
   e   étendue
   p   partition primaire (1-4)
p
Numéro de partition (1-4, par défaut 2): 
Utilisation de la valeur par défaut 2
Premier secteur (1050624-125045423, par défaut 1050624): 
Utilisation de la valeur par défaut 1050624
Dernier secteur, +secteurs or +taille{K,M,G} (1050624-125045423, par défaut 125045423): 
Utilisation de la valeur par défaut 125045423
 
Commande (m pour l'aide): w
La table de partitions a été altérée!
 
Appel de ioctl() pour relire la table de partitions.
Synchronisation des disques.

A ce moment j'ai donc 1 groupe de volume (VG00) étalé sur 1 volume physique (/dev/sdb2) :

La prochaine étape sera donc de rajouter mon disque SSD à VG00.

Création du volume physique et affectation au groupe de volumes VG00

Nous allons créer un volume physique à partir de /dev/sda2 et le rajouter au groupe VG00 :

root@enterprise ~> pvcreate /dev/sda2
  Physical volume "/dev/sda2" successfully created

root@enterprise ~> vgextend VG00 /dev/sda2
  Volume group "VG00" successfully extended

A cette instant j'ai 1 groupe de volumes (VG00) réparti sur 2 volumes physique (/dev/sda2, /dev/sdb2) :

Déplacement des partitions systèmes sur le nouveau PV

Le SSD c'est bien mais c'est cher ! Comptez environs 120€ pour 64Go. A ce prix là on ne peut pas avoir un PC 100% SSD. Nous allons donc déplacer sur le SSD les partitions systèmes qui doivent être les plus rapides :

Le système (LV_root),
le swap (LV_swap),
le tmp (LV_tmp),

root@enterprise ~> pvmove -v -n LV_root /dev/sdb2 /dev/sda2
    Finding volume group "VG00"
    Archiving volume group "VG00" metadata (seqno 37).
    Creating logical volume pvmove0
    Moving 640 extents of logical volume VG00/LV_root
    Found volume group "VG00"
    activation/volume_list configuration setting not defined, checking only host tags for VG00/LV_root
    Updating volume group metadata
    Found volume group "VG00"
    Found volume group "VG00"
    Suspending VG00-LV_root (253:2) with device flush
    Found volume group "VG00"
    activation/volume_list configuration setting not defined, checking only host tags for VG00/pvmove0
    Creating VG00-pvmove0
    Loading VG00-pvmove0 table (253:7)
    Resuming VG00-pvmove0 (253:7)
    Found volume group "VG00"
    Loading VG00-pvmove0 table (253:7)
    Suppressed VG00-pvmove0 identical table reload.
    Loading VG00-LV_root table (253:2)
    Resuming VG00-LV_root (253:2)
    Creating volume group backup "/etc/lvm/backup/VG00" (seqno 38).
    Checking progress before waiting every 15 seconds
  /dev/sdb2: Moved: 0,2%
  /dev/sdb2: Moved: 4,8%
  /dev/sdb2: Moved: 9,2%
  /dev/sdb2: Moved: 13,9%
  /dev/sdb2: Moved: 18,1%
  /dev/sdb2: Moved: 22,7%
  /dev/sdb2: Moved: 27,3%
  /dev/sdb2: Moved: 31,7%
  /dev/sdb2: Moved: 36,1%
  /dev/sdb2: Moved: 40,5%
  /dev/sdb2: Moved: 45,0%
  /dev/sdb2: Moved: 49,4%
  /dev/sdb2: Moved: 53,6%
  /dev/sdb2: Moved: 58,3%
  /dev/sdb2: Moved: 62,5%
  /dev/sdb2: Moved: 66,4%
  /dev/sdb2: Moved: 70,8%
  /dev/sdb2: Moved: 75,3%
  /dev/sdb2: Moved: 79,7%
  /dev/sdb2: Moved: 83,6%
  /dev/sdb2: Moved: 88,3%
  /dev/sdb2: Moved: 92,7%
  /dev/sdb2: Moved: 96,6%
  /dev/sdb2: Moved: 100,0%
    Found volume group "VG00"
    Found volume group "VG00"
    Loading VG00-LV_root table (253:2)
    Suspending VG00-LV_root (253:2) with device flush
    Suspending VG00-pvmove0 (253:7) with device flush
    Found volume group "VG00"
    Found volume group "VG00"
    Found volume group "VG00"
    Resuming VG00-pvmove0 (253:7)
    Found volume group "VG00"
    Resuming VG00-LV_root (253:2)
    Found volume group "VG00"
    Removing VG00-pvmove0 (253:7)
    Found volume group "VG00"
    Removing temporary pvmove LV
    Writing out final volume group after pvmove
    Creating volume group backup "/etc/lvm/backup/VG00" (seqno 40).

root@enterprise ~> pvmove -v -n LV_swap /dev/sdb2 /dev/sda2
    Finding volume group "VG00"
    Archiving volume group "VG00" metadata (seqno 40).
    Creating logical volume pvmove0
    Moving 64 extents of logical volume VG00/LV_swap
    Found volume group "VG00"
    activation/volume_list configuration setting not defined, checking only host tags for VG00/LV_swap
    Updating volume group metadata
    Found volume group "VG00"
    Found volume group "VG00"
    Suspending VG00-LV_swap (253:6) with device flush
    Found volume group "VG00"
    activation/volume_list configuration setting not defined, checking only host tags for VG00/pvmove0
    Creating VG00-pvmove0
    Loading VG00-pvmove0 table (253:7)
    Resuming VG00-pvmove0 (253:7)
    Found volume group "VG00"
    Loading VG00-pvmove0 table (253:7)
    Suppressed VG00-pvmove0 identical table reload.
    Loading VG00-LV_swap table (253:6)
    Resuming VG00-LV_swap (253:6)
    Creating volume group backup "/etc/lvm/backup/VG00" (seqno 41).
    Checking progress before waiting every 15 seconds
  /dev/sdb2: Moved: 0,0%
  /dev/sdb2: Moved: 43,8%
  /dev/sdb2: Moved: 87,5%
  /dev/sdb2: Moved: 100,0%
    Found volume group "VG00"
    Found volume group "VG00"
    Loading VG00-LV_swap table (253:6)
    Suspending VG00-LV_swap (253:6) with device flush
    Suspending VG00-pvmove0 (253:7) with device flush
    Found volume group "VG00"
    Found volume group "VG00"
    Found volume group "VG00"
    Resuming VG00-pvmove0 (253:7)
    Found volume group "VG00"
    Resuming VG00-LV_swap (253:6)
    Found volume group "VG00"
    Removing VG00-pvmove0 (253:7)
    Found volume group "VG00"
    Removing temporary pvmove LV
    Writing out final volume group after pvmove
    Creating volume group backup "/etc/lvm/backup/VG00" (seqno 43).

root@enterprise ~> pvmove -v -n LV_tmp /dev/sdb2 /dev/sda2
    Finding volume group "VG00"
    Archiving volume group "VG00" metadata (seqno 43).
    Creating logical volume pvmove0
    Moving 64 extents of logical volume VG00/LV_tmp
    Found volume group "VG00"
    activation/volume_list configuration setting not defined, checking only host tags for VG00/LV_tmp
    Updating volume group metadata
    Found volume group "VG00"
    Found volume group "VG00"
    Suspending VG00-LV_tmp (253:5) with device flush
    Found volume group "VG00"
    activation/volume_list configuration setting not defined, checking only host tags for VG00/pvmove0
    Creating VG00-pvmove0
    Loading VG00-pvmove0 table (253:7)
    Resuming VG00-pvmove0 (253:7)
    Found volume group "VG00"
    Loading VG00-pvmove0 table (253:7)
    Suppressed VG00-pvmove0 identical table reload.
    Loading VG00-LV_tmp table (253:5)
    Resuming VG00-LV_tmp (253:5)
    Creating volume group backup "/etc/lvm/backup/VG00" (seqno 44).
    Checking progress before waiting every 15 seconds
  /dev/sdb2: Moved: 0,0%
  /dev/sdb2: Moved: 40,6%
  /dev/sdb2: Moved: 84,4%
  /dev/sdb2: Moved: 100,0%
    Found volume group "VG00"
    Found volume group "VG00"
    Loading VG00-LV_tmp table (253:5)
    Suspending VG00-LV_tmp (253:5) with device flush
    Suspending VG00-pvmove0 (253:7) with device flush
    Found volume group "VG00"
    Found volume group "VG00"
    Found volume group "VG00"
    Resuming VG00-pvmove0 (253:7)
    Found volume group "VG00"
    Resuming VG00-LV_tmp (253:5)
    Found volume group "VG00"
    Removing VG00-pvmove0 (253:7)
    Found volume group "VG00"
    Removing temporary pvmove LV
    Writing out final volume group after pvmove
    Creating volume group backup "/etc/lvm/backup/VG00" (seqno 46).

Maintnant j'ai donc 2 PV, l'un avec mes partitions de stockage (le disque dur), l'autre avec les partitions systèmes (le SSD) :

Déplacer le boot sur le SSD

Maintenant nous allons déplacer la dernière partition qui n'est pas un LVM puisque c'est le /boot en ext4, pour ça j'utilise la méthode de Remi :

root@enterprise ~> mke2fs -j -T ext4 -L boot /dev/sda1
root@enterprise ~> mount /dev/sda1 /mnt/tmp
root@enterprise ~> tar cf - -C /boot . | tar xvf - -C /mnt/tmp
root@enterprise ~> umount /mnt/tmp
root@enterprise ~> umount /boot

Ensuite il faut aller modifier le /etc/fstab en mettant à jour le UUID que vous trouverez avec :

root@enterprise ~> ll /dev/disk/by-uuid
total 0
lrwxrwxrwx 1 root root 10 16 janv. 10:55 10bd9879-81cc-4813-a0a7-4bb33c1a7c5f -> ../../sda1
lrwxrwxrwx 1 root root 10 15 janv. 20:17 128e5cbc-7a29-463a-8710-a2de40b74084 -> ../../dm-1
lrwxrwxrwx 1 root root 10 15 janv. 20:36 240b9e30-190e-48a6-9fcf-0d1edd85d801 -> ../../dm-2
lrwxrwxrwx 1 root root 10 15 janv. 20:40 848181fa-38fd-40e1-87b6-501ac68686fc -> ../../dm-6
lrwxrwxrwx 1 root root 10 15 janv. 20:17 86e1bee2-32d7-4103-b2f8-c654110d5a75 -> ../../dm-4
lrwxrwxrwx 1 root root 10 15 janv. 20:27 b166653c-e4ed-4481-a2b9-81162209696a -> ../../sdb1
lrwxrwxrwx 1 root root 10 15 janv. 20:41 b9665501-2d21-4f0a-af94-cd15ae238d3a -> ../../dm-5
lrwxrwxrwx 1 root root 10 15 janv. 20:17 d776dc2a-174f-46e5-99ca-084caed2da7e -> ../../dm-0
lrwxrwxrwx 1 root root 10 15 janv. 20:17 f6481e9e-a8c5-400c-a35d-4204f4a015d9 -> ../../dm-3

Pour terminer on monte le nouveau boot et on fait un grub-install

root@enterprise ~> mount /booot
root@enterprise ~> grub-install /dev/sda --recheck

Ensuite on récupère l'ancien boot (/dev/sdb1) et on le rajoute à VG00 :

root@enterprise ~> pvcreate /dev/sdb1
  Physical volume "/dev/sdb1" successfully created

root@enterprise ~> vgextend VG00 /dev/sdb1
  Volume group "VG00" successfully extended

Ce qui nous donne à la fin :

Trac, authentification à FluxBB au traver de mod_auth_mysql

Par Guillaume Kulakowski, le mardi 05 mai 2009 - 08:15 | Catégories : Sysadmin

L'une des façons les plus rapides de faire une authentification sur le net est de passer par un fichier htaccess et un htpasswd. C'est à dire mettre dans un fichier le login et le mot de passe (crypté). Le problème c'est que si cette solution permet de mettre facilement et rapidement un contenu derrière une protection par authentification, elle est cependant guerre poussée et évolutive.

Nous allons donc voir comment modifier notre htaccess (ou encore mieux, notre vHost) pour aller chercher l'information dans une base de données via le module apache mod_auth_mysql. Nous verrons cela au travers d'un exemples : l'identification sur un Trac via les identifiants d'un FluxBB.

Trac et l'identification

Trac n'offre pas de zone membre à proprement parlé. Toute personne qui s'identifie à Trac voit son compte automatiquement crée. Il en résulte qu'on peu donc affecter des droits à un compte qui n'a pas encore était crée. Mais alors comment s'authentifier ? C'est justement là la force de Trac : on peut s'identifier par la méthode que l'on souhaite. Dans un premier temps j'étais passé par un htpasswd mais à présent je désire m'authentifier avec l'identifiant et le mot de passe d'un forum FluxBB.

Prérequis

Évidement il vous faudra un Trac et un FluxBB installés et configurés. Il vous faudra aussi, bien évidement, mod_auth_mysql (yum install mod_auth_mysql). Histoire de faire un cliché avant/après, voici la configuration de mon Trac avant la manipulation :

<Location />

    SetHandler mod_python

    PythonHandler trac.web.modpython_frontend

    PythonOption TracEnv /home/llaumgui/public_html/trac.llaumgui.com/www/

    PythonOption TracUriRoot /

    # "/tmp" should be some writable temporary directory

    SetEnv PYTHON_EGG_CACHE /tmp

    # "trac" can be any string, but must be the same for all

    # Trac instances on the same Apache install

    PythonInterpreter trac

</Location>



<Location /login>

     AuthType Basic

     AuthName "Connection sur les dev de LLaumgui"

     AuthUserFile /home/llaumgui/public_html/trac.llaumgui.com/trac.htpasswd

     Require valid-user

</Location>

On y remarque que l'identification se fait au travers du fichier /home/llaumgui/public_html/trac.llaumgui.com/trac.htpasswd.

Connexion

On va maintenant passer à une identification MySQL :

Order deny,allow

Deny from all

AuthName "Veuillez saisir votre nom d'utilisateur et votre mot de passe Dotclear"

AuthType Basic

require valid-user

Satisfy Any



AuthMySQLAuthoritative On

AuthMySQLEnable On



# On se connecte à la base mon_fluxbb du serveur localhost

# Bien sûr l'idéal est qu'apache n'est accès à mon_fluxbb qu'en lecture.

AuthMySQLHost localhost

AuthMySQLUser apache

AuthMySQLPassword mon_mot_de_passe

AuthMySQLDB mon_fluxbb



# La table contenant la liste des utilisateur dans FluxBB est la table fluxbb_user

# Le login correspond à username et le mot de passe à password

# Dans FluxBB, les mots de passe sont crypté en sha1

AuthMySQLUserTable fluxbb_user

AuthMySQLNameField username

AuthMySQLPasswordField password

AuthMySQLNoPasswd Off

AuthMySQLPwEncryption sha1

On constate que le choix des méthodes d'encryptages est limité à crypt, scrambled, md5, aes et sha1. Il n'est donc malheureusement pas possible de connecter un Trac avec un Dotclear. En effet, pour le cryptage des mots de passe, Dotclear passe par crypt::hmac.

mod_auth_mysql permet aussi des requêtes plus complexes avec des jointures sur d'autres tables et des clauses where, pour plus d'information, la documentation devrait vous aider.

Fedora-Fr - Communauté francophone Fedora - Linux

Blogueurs

Projets

Planétarium

A propos

Liens utiles