INFO les barques

Installation sme 8 Kernel panic [SME]

Georges Charpenay — 2013-01-20T20:44:55Z

Bien que largement satisfait de la distribution 7 de sme server, et pour continuer à bénéficier des mises à jour de sécurité , il faut se décider, un jour à évoluer sur sme8.

L'ancien système s'installant sans difficultés particulière en raid 1 par la commande sme=raid1, au tout début de l'installation, on serait tenté d'intenter la même commande avec la nouvelle distribution.

Seulement, seulement, il arrive quelquefois que bien que l'installation se passe sans difficultés, le système ne reboote pas entièrement, arrivant sur un kernel panic au moment du chargement du pilote raid (pourtant le bon pilote). J'ai essayé en paramétrant mon bios en raid, même résultat. En installant une carte raid 1, adaptec 1210, linux reconnait bien la carte et prend bien le bon pilote, mais même résultat ! Désespérant !

La solution qui a fonctionné pour moi est très simple. Il suffit de débrancher un des deux disques et faire l'installation sur un seul disque.
Laisser redémarrer le serveur et finir de renseigner les paramètres de base (nom, mot de passe root, domaine, etc...), pour aboutir sur un redémarrage/reconfiguration.

Ensuite, il convient d'aller en admin console et choisir d'ajouter un disque à la grappe. Il voit le deuxième disque comme un disque de spare et l'inclue à la grappe.

Laissez mariner une petite heure, le temps qu'il reconstruise sa grappe, aller voir dans le mail d'admin pour constater que le rebuild est bien terminé et le tour est joué !

Enjoy !

Réinitialisation de l'utilisateur admin (root) mysql [SME]

Georges Charpenay — 2013-01-20T18:36:29Z

Il peut arriver quelquefois d'avoir à réinitialiser l'utilisateur root de mysql sans avoir forcément fait des bêtises.
Par exemple, si vous sauvegardez votre serveur avant de changer de machine, vous installez votre nouveau serveur physique, et restaurez l'intégralité du serveur.

Tout fonctionnera bien, mais on trouvera des anomalies visibles sur la console en fin de boot, et ces anomalies risquent de nous gêner aux prochaines mises à jour système car le serveur ne pourra se connecter à la base sql.

De plus, c'est fortement gênant car vous ne pourrez pas non-plus vous connecter à la base sql en administrateur.

En cherchant sur le net, j'ai trouvé la réponse sur l'excellent site de sme-serveur.

Il suffit de se connecter en ssh et de lancer les commandes suivantes pour que tout rentre dans l'ordre.

cd /var/service/mysqld sv d . expand-template /root/.my.cnf expand-template /var/service/mysqld/set.password /usr/libexec/mysqld --bootstrap --user=mysql --skip-grant-tables < ./set.password sv u .

Uploader des images avec SPIP [SME]

Georges Charpenay — 2012-12-29T19:48:43Z

Depuis la bascule de sites internet spip d'un serveur sme 7 à sme 8, j'ai eu la surprise que tous les sites spip hébergé sur le nouveau serveur ne voulaient pas uploader des documents ou images.

Impossible d'uploader

En cliquant sur le lien, j'ai constaté qu'il manquait une variable à renseigner au niveau du moteur php.

Erreur 6 dossier temporaire

VERIFICATION DE L'ANOMALIE

Pour vérifier cette anomalie, il suffit de créer un fichier phpinfo.php à la racine d'un des sites qui ne fonctionnent pas avec les instructions suivantes :

<?php phpinfo(); ?>

Puis d'appeler ces infos en appelant :
http://votresiteinternet/phpinfo.php

Le site vous retourne alors les valeurs de php chargées et nous voyons que la valeur upload_tmp_dir n'est pas renseignée.

Le problème vient du fait que spip se sert de la configuration apache depuis php.ini et de l'attribut "upload_tmp_dir".

Celui-ci doit être renseigné par un répertoire ayant les droits de lecture et d'écriture.

TESTER UNE SOLUTION/VARIABLE

Il faut donc créer un répertoire pour les upload de spip.

J'ai pensé qu'un répertoire intitulé tmpspip, sous /opt conviendrait.
Je l'ai volontairement placé à cet endroit afin qu'il soit accessible depuis les sites de toutes les ibays et en plus, il pourra, à souhait, être sauvegardé avec le reste du système (voir article inclure répertoire opt dans les sauvegardes smeserveur sur ce même site internet).

Nous nous connecterons donc avec putty et invoquerons les commandes suivantes :

Cd /opt Mkdir tmpspip Chmod 777 tmpspip

Voilà, c'est fait, et à partir de ce moment, on serait tenté d'aller modifier directement le fichier php.ini en ajoutant l'instruction

upload_tmp_dir = /opt/tmpspip

Puis redémarrer le service http avec

/etc/rc7.d/S86httpd-e-smith restart

Pour enfin vite aller dans votre site spip préféré et uploader une image ou un document pour voir que ça fonctionne. .. Et ça fonctionne !
Dans la négative, vous pouvez vérifier la valeur d'upload_tmp_dir avec le fichier phpinfo.php et son appel dans la procédure décrite ci-dessus (au cas où vous auriez fait une faute de frappe par exemple).

On a fini ?, mais non !!!

SOLUTION PERENNE

A cette étape, nous savons que nos modifications vont fonctionner, mais à n'importe quel redémarrage-reconfiguration du serveur, par exemple lors d'une mise à jour, les modifications sont perdues (configuration sme oblige).

Alors, pour rendre ces modifications permanentes, il faut passer par une petite étape, comprendre les templates. (au moins un petit peu comme pour mon cas).

Les templates sont des fragments de tous les fichiers vitaux de votre sme. Php.ini par exemple, est coupé en une multitude de fragments tous stockés dans /etc/e-smith/templates/etc/php.ini/

Au redémarrage du système, ces fragments reconstituent le fichier php.ini d'origine.

Mais pour résoudre notre problème présent dirons-nous, le détail ci-dessous aideront à comprendre le fonctionnement des templates :

– je crée dans les templates personnalisées un répertoire devant accueillir mes propres modifications du fichier php.ini :

mkdir -p /etc/e-smith/templates-custom/etc/php.ini

Je cherche le fragment de fichier qui m'intéresse dans /etc/e-smith/templates/etc/php.ini/

Ici, je constate que le 60FileUploads peut contenir ma variable de répertoire temporaire.

Je copie donc le fragment « origine » (sur lequel je veux faire des modifications ) dans ce répertoire personnalisé (templates-custom)

cp /etc/e-smith/templates/etc/php.ini/60FileUploads /etc/e-smith/templates-custom/etc/php.ini

Si l'instruction n'est pas dans un fragment d'origine, je peux en créer un en prenant un numéro de fragment n'existant pas (le numéro correspondant à la position où il se trouvera dans le fichier destination (le cas présent, le fichier php.ini)

– je modifie le fichier copié (ou mon propre fragment), dans templates-custom.

cd /etc/e-smith/templates-custom/etc/php.ini nano 60FileUploads

– j'ajoute la ligne (pour le cas présent) :

upload_tmp_dir = /opt/tmpspip

– je quitte nano en sauvegardant le tout.

Si j'avais alors souhaité mon propre template sans modifier le template système, j'aurais tout simplement créé un fichier sous /etc/e-smith/templates-custom/etc/php.ini/ que j'aurais appelé, par exemple 61RepUpload (je suis libre du nom que je veux utiliser).

J'éditerais ce fichier :

Nano 61RepUpload

et j'aurais ajouté la ligne dans ce fichier :

upload_tmp_dir = /opt/tmpspip

Nota : Sachant que le fichier commence par 61, ses instructions seront interprétées immédiatement après 60FileUploads.

– Il suffit ensuite de valider le fragment et reconstruire le php.ini :

expand-template /etc/php.ini

Puis de redémarrer le serveur http

/etc/rc7.d/S86httpd-e-smith restart

Notez qu'une reconfiguration-redémarrage du serveur depuis la console d'administration aura le même effet.

Voilà, c'est fini, la modification sera prise en compte par le serveur aux redémarrages...

ANNULATION

En cas d'erreur, on peut bien sûr faire machine arrière

Pour annuler une modification, il suffit tout simplement de supprimer le fragment de fichier créé ou copié dans templates custom, suivi des commandes suivantes

expand-template /etc/php.ini /etc/rc7.d/S86httpd-e-smith restart

Vers SME 9

Au delà de toutes ces manipulations, le blocage des upload_tmp-dir peut persister.
Nous trouvons le coupable dans les messages

Aug 26 22:10:05 goupil httpd : PHP Warning : Unknown : open_basedir restriction in effect. File(/tmp) is not within the allowed path(s) : (/home/e-smith/files/ibays/) in Unknown on line 0 Aug 26 22:10:05 goupil httpd : PHP Warning : File upload error - unable to create a temporary file in Unknown on line 0

En fait c'est le openbasedir qui bloque, c'est en quelque sorte
une prison qui empêche les applications php de sortir des répertoires
par défaut que on leur a attribué. Il faut donc personnaliser l'ebay contenant le site internet pour qu'elle puisse aller écrire dans le répertoire temporaire.

L'explication estici
et la commande est, par exemple :

db accounts setprop <mon_ibay> PHPBaseDir /home/e-smith/files/ibays/<mon_ibay>/:/tmp/ signal-event ibay-modify

Et tout rentre dans l'ordre, comme par magie.

J'invite d'ailleurs à installer l'excellente contrib de Stéphane de Labrusse (que je remercie encore de m'avoir personnellement guidé pour le coup)
Il s'agit de smeserver-webhosting, qui ne fonctionne qu'à partir de la sme 9.

yum --enablerepo=smecontribs install smeserver-webhosting signal-event post-upgrade; signal-event reboot

Vous trouverez la procédure complète d'installation de webhostingici.
Ainsi, vous trouverez tout sur l'interface d'administration de votre serveur. N'est-ce pas une contribution royale ???

Quand le serveur ne veut plus se mettre à jour... [SME]

Georges Charpenay — 2012-04-07T10:32:35Z

Eh oui, nul n'est infaillible, et encore moins l'informatique !

J'ai rencontré récemment un problème de mise à jour du serveur :

Cannot find a valid baseurl for repo : base
Error : Cannot find a valid baseurl for repo : base

Gênant, et puisqu'il s'agit d'un serveur de production, on ne peut, à mon sens, laisser perdurer une telle situation au risque de s'exposer à plus ou moins long terme, à des attaques du net ou des dysfonctionnement du serveur.

J'ai recherché longuement sur le net une solution pour mettre d'aplomb les repository. Après plusieurs manipulations en console infructueuses (yum.conf et les fichiers de repository), je me suis dit qu'il doit bien exister quelque-chose dans l'interface pour reparamétrer correctement les sites de mises à jour. Et en fait, la solution est très simple.

Il faut aller tout simplement dans l'interface server-manager et choisir le menu de mise à jour logicielle (à gauche), puis le bouton "modifier les paramètres de mise à jour.

Dans ces options de mises à jour, je n'ai choisi que les repository stables, à savoir :

– CentOS - os
– CentOS - updates
– SME Server Addons
– SME Server Contribs
– SME Server - os
– SME Server - updates

NE PAS activer SME Server - updates testing qui contient des logiciels en test bêta !

A partir de là, les fichiers d'update se mettent à jour correctement et tout est reparti correctement.

Vive Centos ! et vive le libre !

Vider le cache du proxy squid [SME]

Georges Charpenay — 2011-05-05T16:44:40Z

Si vous passez par un proxy, pour ne citer squid utilisé dans la distribution de sme-server et constatez des lenteurs d'affichage de pages web sur votre browser préféré. Testez d'abord un autre browser et si ces lenteurs sont répétées mais aussi aléatoires en utilisant plusieurs browsers, il peut arriver que le cache de votre proxy soit plein.

Cela n'empêche pas le système de fonctionner, mais peut ralentir l'accès internet, de par le nombre de pages stockées en local. Si le cache est trop grand, on obtient l'effet inverse que celui recherché en matières de performances.

Cela peut être vérifié en affichant les journaux systèmes dans votre interface d'administration.. et si vous trouvez un message qui ressemble à celà :

squid[8473] : WARNING : Disk space over limit : 180016 KB > 102400 KB, c'est bien que votre proxy est plus que plein et qu'il convient de faire un peu de ménage pour optimiser le tout.

Pour cela, en ayant ouvert une console ssh, lancez les commandes suivantes :

cd /var/spool/squid service squid stop rm -fr /var/spool/squid/* service squid start

En fait, on se place sur le répertoire du cache, on arrête le service squid, on supprime les fichiers du cache, on redémarre le service....

Le tour est joué ! Votre cache est propre et va se reconstituer petit à petit.

Nota : Si toutefois le service squid ne se désactive pas correctement, vous pouvez utiliser l'interface admin pour arrêter et redémarrer les services proxy. Prenez toutefois la précaution de désactiver le proxy, le cas échéant dans votre explorateur car vous perdrez la main sur l'interface admin, quitte à le réactiver immédiatement après.

On peut vérifier que tout s'est bien passé en allant consulter à nouveau le fichier messages à travers la console web qui doit vous afficher des informations ressemblant à celà :

Ready to serve requests. squid[15637]: Done reading /var/spool/squid swaplog (0 entries) squid[15637]: Finished rebuilding storage from disk. squid[15637]: 0 Entries scanned squid[15637]: 0 Invalid entries. squid[15637]: 0 With invalid flags. squid[15637]: 0 Objects loaded. squid[15637]: 0 Objects expired. squid[15637]: 0 Objects cancelled. squid[15637]: 0 Duplicate URLs purged. squid[15637]: 0 Swapfile clashes avoided. squid[15637]: Took 0.3 seconds ( 0.0 objects/sec). squid[15637]: Beginning Validation Procedure squid[15637]: Completed Validation Procedure squid[15637]: Validated 0 Entries squid[15637]: store_swap_size = 0k

Mais rien ne vous empêche, dans la foulée, à ajouter cette procédure dans le cron pour qu'elle s'exécute régulièrement, par exemple, une fois par semaine.

Inclure le répertoire "opt" dans les sauvegardes sme [SME]

Georges Charpenay — 2009-01-06T13:15:44Z

Ajouter des répertoires et des fichiers à la liste des inclusions de sauvegarde

Ah, le répertoire /opt, il contient des fichiers vitaux quand vous installez par exemple un egroupware et il est donc nécessaire, à mon sens, de ne pas oublier de le sauvegarder...

Avertissement : Le panneau d'e-smith est conçu pour être utilisé comme parade à un sinistre de sauvegarde totale et de restauration pour votre sme server.

En tant que tel, il repose sur la bonne gestion des répertoires qui sont inclus dans la sauvegarde.

Il ne donc faut pas supprimer l'un des répertoires par défaut de 40Go-en (qui est la sauvegarde système par défaut) car ils sont tous essentiels pour le succès de la pleine restauration de votre sauvegarde à une réinstallation propre de votre système SME.

Vous pouvez donc de façon sûre ajouter des répertoires à la sauvegarde sme, / opt, comme indiqué, mais il faut voir ces inclusions supplémentaires de sauvegarde comme un élément supplémentaire de sauvegarde.

Sachant que la sauvegarde par défaut n'inclue pas /opt, il faut, pour ajouter /opt à la liste d'inclusion de sauvegarde, créer un fragment de template personnalisé et ajouter /opt à la liste.

C'est la seule façon de faire en étant sur qu'une nouvelle mise à jour de sme ne modifie ou n'écrase pas les instructions supplémentaires à exécuter dans la sauvegarde pour ne pas oublier /opt.

Création du template personnalisé pour ajouter les fichiers et répertoires

mkdir -p /etc/e-smith/templates-custom/etc/dar/DailyBackup.dcf nano /etc/e-smith/templates-custom/etc/dar/DailyBackup.dcf/41go-into

Et ajouter dans le fichier la ligne suivante :

--go-into opt

Si nous voulons inclure d'autres répertoires, par exemple /var/lib/mysql/, pour récupérer "en dur", toutes les bases mysql, il faut ajouter dans ce fichier, la ligne suivante :

--go-into var/lib/mysql/

Cette dernière précaution est ultime (et double), car les sauvegardes de sme incluent automatiquement un dump de chaque base mysql dans /home/e-smith/db/mysql/.

Ensuite, il faut développer le template :

expand-template /etc/dar/DailyBackup.dcf

Voilà, dès la prochaine sauvegarde effectuée, vous pourrez vérifier que le répertoire /opt a bien été pris en compte en lançant depuis la console serveur la vérification de la sauvegarde.

Coté restauration : Il faut ne restaurer entièrement votre sauvegarde que sur une nouvelle installation propre, ce qui ne vous dispensera pas d'installer ultérieurement toutes les contributions et modifications particulière que vous avez installées.

Il serait avisé, pour une vérification ultime, de réinstaller un serveur complet (formatage), puis une restauration de la sauvegarde. C'est le meilleur moyen de vous assurer que votre sauvegarde fonctionne bien !

Une petite heure de perdue, mais tellement salvatrice !

L'idéal, si vous avez un serveur en production, est d'avoir une vieille machine en plus, destinée à cet effet. Elle vous servira également pour tester toutes les procédures d'installation de plugins ou logiciels divers...

Enfin, il faut bien télécharger la version 7.4 de sme server pour la réinstallation car la sauvegarde/ restauration à partir de fichier .dar n'est implémentée qu'à partir de cette version.

Désinstaller un paquet avec yum [SME]

Georges Charpenay — 2008-11-04T20:41:30Z

Il m'est arrivé, lors d'une installation infructueuse d'egroupware, suivi de sa désinstallation, de ne plus pouvoir réinstaller egroupware parce que le système "connaissait" le paquet d'egroupware.

Une réinstallation d'egroupware, que ce soit par rpm -ivh smeserver-egroupware-1.4.004-1.noarch.rpm, ou que ce soit par yum localinstall smeserver-egroupware-1.4.004-1.noarch.rpm aboutissait par le message "paquet déjà installé", pas de modif système.

Il faut donc supprimer le paquet de la base système, pour pouvoir le réinstaller (ou exécuter le script d'installation dans sa totalité).

Il s'agit d'abord, pour supprimer le paquet, de connaître son intitulé exact dans la base système.

Pour celà, en mode console, vous avez la commande yum info
, mais vu que le système va vous dérouler des centaines de paquets et que le buffer de l'écran ne vas pas tellement loin, au niveau des lignes historiées, il y a fort peu de chance que vous trouviez le paquet concerné.

Usons alors de la redirection système :

yum info>liste

Après l'éxécution de cette commande, vous avez un fichier "liste" qui contient l'intégralité des paquets installés.

nano liste

.. qui vous permet ensuite d'ouvrir l'éditeur de texte du fichier "liste"

"touche ctrl+w", et tapez le nom du paquet recherché... ici egroupware..., puis touche entrée.

Ouf, le paquet s'appelle smeserver-egroupware.

"touche ctrl+x" pour quitter l'éditeur.

Il ne vous reste plus qu'à le désinstaller avec la commande :

yum remove smeserver-egroupware

et le tour est joué.

Vous pouvez ensuite recommencer l'installation et tout baigne...

Réinstallation de linux sme server 7.3 et restauration [SME]

Georges Charpenay — 2008-05-15T20:21:28Z

Comment j'ai fait pour tout transporter sur une nouvelle machine quand la sauvegarde de linux ne fonctionne pas (sauvegarde réseau à travers l'interface système qui ... ne veut pas se restaurer sur une nouvelle machine).

Avant tout, et c'est évident, faire une sauvegarde par le réseau de votre machine de production. Cette sauvegarde produit un fichier intitulé "smeserver". Copier ce fichier sur une clé usb sans changer le nom du fichier.

Je précise "sur une clé usb", en effet, et nous verrons plus tard que de la copier sur un cd ou DVD ne fonctionne pas toujours ultérieurement, notamment si la nouvelle machine est équipée d'un disque et d'une carte scsi.

Ensuite, pour le nouveau serveur, il vaut mieux prendre une nouvelle machine que la machine qui héberge votre sme-serveur. C'est évident, surtout si vous avez une machine en production. Ainsi, nous sommes à l'abri des ruptures de services pendant l'installation, surtout si on se heurte à des imprévus lors de l'installation.

Sur la nouvelle machine, installer linux sme d'après l'image d'installation de la version que vous souhaitez installer et que vous aurez téléchargé sur le net. Pour mon cas, c'est la 7.3.

Au redémarrage de la nouvelle machine, choisir l'option de restaurer un backup, et plug & play aidant, votre clé est reconnue. (l'image gravée sur un cd n'a pas fonctionné).

Au redémarrage, en mode console, entrer en admin et choisir une adresse IP différente du serveur de production (car les deux machines sont sur le même réseau et on a un conflit d'adresse IP - le serveur de production étant resté allumé, il continue à fonctionner normalement).

Lancer un redémarrage (et reconfiguration) du nouveau serveur.

A partir de ce moment, vous pouvez débrancher l'écran du nouveau serveur et mettre son clavier de côté car vous n'en avez plus besoin.

Prendre ensuite un pc du réseau et se connecter sur la console d'administration du nouveau serveur en ayant préalablement paramétré votre firefox pour prendre en première langue l'anglais, pour aller chercher les mises à jour réseau. Menu Configuration/sofware installer .Attention : il est prudent d'en sélectionner une partie à la fois et pas la totalité pour éviter les time-outs de votre navigateur. 10 ou 15 items de mise à jour suffisent à chaque opération.

Les menus sont en anglais, mais sont toujours fonctionnels. Finissez de valider la dernière mise à jour, et lancez une reconfiguration du serveur, puis, une fois le redémarrage effectué, reconnectez vous (en anglais) pour finir toutes les mises à jour.

En effet, sur un autre article de ce site, je vous avais averti de la mise à jour "défectueuse" du 19 avril 2008, cela veut dire que si, par malchance, vous arriviez sur "erreur 500 internal server error", pas la peine de prendre des mouchoirs pour pleurer : dans votre navigateur, configurer la langue par défaut "anglais" et reconnectez vous immédiatement sur la console d'administration. (ah ! UTF8, quand tu nous tiens...!).

Une fois toutes les mises à jour effectuées, rebasculez votre explorateur en français par défaut, et vous devriez retrouver vos petits à la prochaine connexion à la console d'administration.

Si vous voulez installer plus tard egroupware 1.4 (qui demande php5), la première solution est d'upgrader le système sous php5, cela marche, mais comporte des risques (car nous ne sommes pas sûrs que les mises à jours système fonctionneront toutes sous php5 - les mises à jours actuelles, du moins celles en version 7.3 sont toujours en php4). La deuxième solution que j'ai adoptée pour l'instant, en attendant la mise à jour de l'os en php5, est de bien laisser le système en php4, puis d'installer egroupware 1.4 à partir de la contrib suivante (qui fonctionne correctement). Installation egroupware 1.4 sur sme 7.3 (merci à l'auteur).

Installer toutes les contribs supplémentaires que vous aviez installées.

Après tout celà, tout devrait fonctionner, néanmoins une petite visite sur le journal journaux système, messages, depuis la console d'administration permet de vérifier si tout démarre normalement.

Upgrade php4 et mysql sur sme [SME]

Georges Charpenay — 2008-05-05T19:38:05Z

ATTENTION :

J'ai utilisé la méthode ci-dessous pour upgrader mysql et php5, elle fonctionne, cependant vous arrivez à l'erreur 500 avec impossibilité d'accéder au server-manager. Elle a l'avantage de faire prendre de l'avance au système en terme de performances, mais elle lie le système à php5 et nous ne sommes pas à l'abri de ce genre de problème.

Je la publie quand même et je modifierai cet article dès que je l'aurais corrigé Si quelqu'un connait la suite, merci de contribuer en répondant à cet article.

J'ai trouvé cependant une autre alternative qui permet de conserver le php4 pour le système et d'installer en parallèle PHP5 qu'on lancera indépendamment pour les applications de votre choix qui le requièrent. Ce qui permet d'avoir de laisser aux mises à jour le choix de basculer au niveau système sur php5 dès que les applicatifs système la réclameront, c'est à dire par les mises à jour système. Ce qui permet de travailler en php5 sans toucher la configuration système. Je vais la tester très vite et je publierais un article dès qu'elle sera fonctionnelle.

METHODE : TOUT EN PHP5 (OS COMPRIS)

Pour upgrader mysql et php, par exemple pour installer egroupware 14, qui demande du php5, il faut utiliser yum pour effectuer la mise à jour.

Mais avant certaines dépendances liées à PHP4 doivents être supprimées, comme par exemple eaccelerator.

rpm -e - -nodeps smeserver-eaccelerator

(attention, ce site est fait sous spip et les deux tirets "- -" avant "nodeps" sont contigus, se suivent -mauvais formatage de spip à l'édition-)

Si le paquet n'est pas installé, vous pouvez passer à la suite, mais s'il a été trouvé et désinstallé, il faut aller, par précaution, détruire le dossier
/var/cache/ eaccelerator .

Idem ensuite pour PostGreSQL pour pouvoir le réinstaller proprement après PHP5.

rpm -e postgresql
Ainsi que ses dépendances si elles n'ont pas été supprimée :
rpm -e postgresql-python
rpm -e postgresql-server
rpm -e postgresql-contrib
rpm -e postgresql-libs
rpm -e postgresql-devel
rpm -e postgresql-jdbc
rpm -e postgresql-libs
rpm -e php-pgsql

Ensuite on peut procéder à l'installation de PHP5 :

yum - -enablerepo=centosplus update php

(attention, ce site est fait sous spip et les deux tirets "- -" avant "enablerepo" sont contigus, se suivent -mauvais formatage de spip à l'édition")

Pour MySQL5 :

yum - -enablerepo=centosplus update mysql

On finit l'install et on redémarre ensuite le serveur avec :

signal-event post-upgrade ; signal-event reboot

Pour qu'Apache puisse prendre en compte les modifications, il faut, dans le fichier /etc/httpd/conf/httpd.conf remplacer la ligne,
LoadModule php4_module modules/libphp4.so
par
LoadModule php5_module modules/libphp5.so

En principe, il s'agit d'une simple vérification, pour ma part, la ligne a été modifiée directement dans les templates et httpd.conf a été regénéré.

Puis on relance Apache : httpd -k restart

PHP 5 est alors installé.

Reste plus qu'à installer Postgresql...
Pour finir dans les mises à jour, vous pouvez toujours installer phpmyadmin 2.11 (au préalable yum remove —ancien paquet de phpmyadmin—)

Impossible d'accéder au panel admin après mise à jour [SME]

Georges Charpenay — 2008-04-27T16:19:03Z

Après la mise à jour du 19 avril 2008, Gasp, impossible d'accéder au panel admin.

Plusieurs jours de galère pour trouver une solution. D'autant plus que le mail ne fonctionnait plus correctement car la mise à jour ne s'est pas terminée.. Erreur 500. Cerise sur le gâteau, votre mail ne fonctionne plus, les mails refusent de partir. La totale quoi !

Sur ce domaine, j'ai lu plein d'expériences, de déboires, plein de contribs, Utf8, langue, page de code, accents et tout le bins..

J'ai fait maint tests sur des serveurs de test et..

Finalement, la solution est toute simple.

Vous mettez votre firefox en anglais, accédez à votre panel, (cool, cette fois, ça marche), et vous en profitez pour faire les mises à jour restantes.

Surtout, n'insistez pas et repassez pas votre firefox en français car vous allez désorganiser votre panel (pas mal de rubriques repasseront en unknown).

Il faut simplement en profiter pour faire les mises à jour restantes, reboot et reconfig, tout rentre dans l'ordre. Et vous pouvez remettre la langue de Voltaire par défaut sur votre firefox... Vous devriez retrouver vos petits...

Si cette bidouille vous a dépanné, n'hésitez pas à répondre à cet article...