php 5.2.4

[Baobab]

Bonjour,

Je cherche à mettre à jour php sur ma sme. En effet, j'ai déja php en version 5.1.6 sur ma sme mais cela ne suffit pas à faire tourner joomla 1.7 et rsslounge qui demandent php5.2.4 ou plus. J'ai déja fait un yum update pour voir si des mise à jour de php étaient disponibles mais rien. Malgrés le fait que je n'y croyais pas trop. j'ai quand même essayé de suivre ça : http://smeserver.pialasse.com/index.php/Php_5_mysql_5
Mais toujours rien, ma sme indique qu'elle est à jour.
Je n'ose pas essayer des rpm qui n'ont pas été conçu pour sme.
Faut-il attendre une mise à jour ?

[fleib]

As tu lu ce post?

Il y a quelques pistes qui pourraient t’intéresser.

F

[Baobab]

Merci, je l'avais déja lu, mais en le relisant j'ai trouvé quelque chose d'intéressant :

Serait-ce a cause de la version que vous avez choisi un depot alternatif au depot officiel de CentOS ?

Sous CentosPlus, il s'agit de mysql 5.0 et de php 5.1.
Alors que j'ai besoin de mini php5.2 (actuellement je suis en 5.3. et de mysql 5.5.

En fait, il faut soit que je trouve un paquet de mise à jour vers php5.3, soit il faut que je change de dépot, mais quel dépot dois-je mettre ? Dans le fil, il n'explique pas comment il a eu du php 5.3.8...

[fleib]

Je faisait en effet allusion à ce commentaire là.

Pour ce qui est d'obtenir PHP5.3, je n'ai aucune idée de la marche à suivre...

Peut être qu'en contactant fhs74 directement, tu aurais plus de renseignements.

F

[Baobab]

C'est ce que je pensais faire si je n'ai pas de réponse dans ce post. Mais je vais attendre un peu avant de l'embêter.

Personne n'a d'idée ? ça ne doit pourtant pas être si compliquée ?

[jibe]

Salut,

D'abord, je t'invite si ce n'est pas déjà fait à bien répertorier tes besoins avant de foncer vers une solution prise au hasard. As-tu bien lu ma mise en garde et les solutions alternatives que je propose ? L'une d'elle pourrait peut-être te convenir tout en prenant moins de risques.

Si tu gardes cette solution, je ne comprends pas ton problème avec les dépôts de fhs74 ? Je n'ai pas regardé de près, mais en suivant son lien, il semble qu'il y ait tout ce qu'il faut... Au pire, tu fais un yum localinstall ou (moins conseillé) tu installes directement par la commande rpm...

[EDIT]Je suis quand même surpris que les versions proposées par le repo de CentOS ne conviennent pas... Quand on est un bon développeur, on essaie de garder la compatibilité avec les versions couramment utilisées par les distribs... Perso, je préfère me passer d'une appli web exigeant une version de PHP trop récente plutôt que prendre un risque avec la sécurité.

Une version PHP n'ayant pas encore eu bien le temps de faire ses preuves + une appli développée par quelqu'un qui ne se soucie pas de ce genre de problème = d'énormes risques potentiels !!!

Perso, ce que je développe en PHP ne requière généralement que PHP 4 ! Ça ne m’empêche pas d'honorer les cahiers des charges... Toujours pareil : il s'agit de satisfaire les réels besoins, pas d'utiliser à tout prix les derniers gadgets à la mode !

[bethebeast]

Hello,

[mode HS on]

Perso, ce que je développe en PHP ne requière généralement que PHP 4 !

Je connais justement un développeur qui a été viré parce qu'il développait uniquement en PHP4, son patron, s'en est rendu compte un an après l'avoir embauché...

ça serait pas toi par hasard...?

[mode HS off]

Si ton serveur est en prod :

Plus sérieusement, ma réponse risque ne pas te plaire, c'est normal puisque je ne t'apporte pas de solution concrète.

Mais est ce l'unique but d'un forum d'entre-aide ?

Quand un utilisateur fait fausse route, doit on lui donner la solution ? Non je ne pense pas, et je pense même t'aider en disant cela :

Jibe à raison ! (sauf pour l'histoire du PHP4, mais bon...)

Récapitulons :

- Tu upgrade PHP une première fois, sachant que tous les auteurs de ces how-to dédiés à cette manipulation insistent sur les risques de sécurité/stabilité. Cela peut très bien fonctionner pour certains pendant un certain temps, mais pour d'autres...

- Ensuite, tu veux upgrader une seconde fois

Faut pouvoir imaginer les conséquences sur une SME qui a été conçue pour être la moins bidouillé possible. SME n'est pas une CentOS ou une Debian nue.

Personnellement, je n'utilise SME pour de l'hébergement web qu'avec de rares webapps, et encore... je préfère de loin utiliser un autre serveur dédié pour ça !

Bon, d'un autre côté, si ta SME est une crash test machine, mea-culpa

@+

[unnilennium]

Merci, je l'avais déja lu, mais en le relisant j'ai trouvé quelque chose d'intéressant :

Serait-ce a cause de la version que vous avez choisi un depot alternatif au depot officiel de CentOS ?

Sous CentosPlus, il s'agit de mysql 5.0 et de php 5.1.
Alors que j'ai besoin de mini php5.2 (actuellement je suis en 5.3. et de mysql 5.5.

En fait, il faut soit que je trouve un paquet de mise à jour vers php5.3, soit il faut que je change de dépot, mais quel dépot dois-je mettre ? Dans le fil, il n'explique pas comment il a eu du php 5.3.8...

ben si justement il l'explique la : viewtopic.php?f=19&t=44505&p=280912&hilit=centosplus#p280912

Il fait pointer chez Remi Collet http://rpms.famillecollet.com/ php 5.3.8


SInon il y a aussi ce repo http://www6.atomicorp.com/channels/atom ... i386/RPMS/ php 5.3.8

apres il reste plus que mettre ces depots en format db sme pour yum



ca ressemble a un truc du genre :

Code: Tout sélectionner

/sbin/e-smith/db yum_repositories set dag repository \
Name 'remi' \
BaseURL 'http://rpms.famillecollet.com/enterprise/4/remi/$basearch' \
EnableGroups no \
GPGCheck yes \
GPGKey http://rpms.famillecollet.com/RPM-GPG-KEY-remi \
Visible no \
status disabled

et/ou

Code: Tout sélectionner

/sbin/e-smith/db yum_repositories set dag repository \
Name 'atomicorp' \
BaseURL 'http://www6.atomicorp.com/channels/atomic/centos/4/$basearch' \
EnableGroups no \
GPGCheck yes \
GPGKey https://www.atomicorp.com/RPM-GPG-KEY.art.txt \
Visible no \
status disabled

puis

Code: Tout sélectionner

signal-event yum-modify

enfin une commande yum de mise a jour comme sur le how to de mon site

Attention je mâche le travail mais j'ai pas testé l'installation de ces rpm, et je vous laisse seuls juges du bien fondé d'utiliser ces paquets ou de les compiler vous même pour plus de sécurité.

Sans parler qu’évidemment ces information sont dans un but de test pour voir si cela marche et est faisable mais ne sont pas pour faire sur un serveur en production !

[jibe]

Salut,

Je connais justement un développeur qui a été viré parce qu'il développait uniquement en PHP4, son patron, s'en ai rendu compte un an après l'avoir embauché...

Question (à moitié dans le sujet) : Un bon patron est-il
1 - Un patron qui exige de ses développeurs d'utiliser toujours la toute dernière version de PHP : faut quand même vivre avec son temps, c'est important ! Et puis, le but premier est bien de proposer des développements d'avant-garde. On est une entreprise moderne et dynamique, nous, môssieur !
2 - Un patron qui exige de ses développeurs que le cahier des charges soit scrupuleusement respecté, que si les aspects nécessaires de la sécurité n'y sont pas mentionnés ils soient bien pris en compte malgré tout, et qu'au final l'appli donne entière satisfaction aux utilisateurs ?

Dans le premier cas, le patron que connait bethebeast est un mauvais partron, puisqu'il a mis un an à s'apercevoir que son développeur n'était pas bon !!!

Dans le second cas, un développeur mauvais selon ces critères est repéré très rapidement, que le patron soit bon ou pas d'ailleurs : c'est l'utilisateur qui est juge... Et dans ce second cas, tout le monde se moque bien que l'appli ait été réalisée en PHP 5.4 beta1, en PHP 4, ou en CGI écrites en C ! Tant que l'appli donne toute satisfaction, y compris au niveau sécurité (probablement difficile à obtenir avec PHP 5.4 bêta 1...)

Jibe à raison ! (sauf pour l'histoire du PHP4, mais bon...)

J'ai dit : "ce que je développe en PHP ne requière généralement que PHP 4". Je ne préconise donc pas d'utiliser exclusivement PHP 4 !

Garder, lorsque c'est possible (et ça l'est bien plus souvent qu'on veut nous le faire croire !), une compatibilité avec PHP 4 comporte d'indéniables avantages. Quels en sont donc les inconvénients ? Si les mises à jour de sécurité ont été faites, je ne crois pas qu'il reste de failles connues. Et si cela permet de répondre au cahier des charges, où donc est le problème ?

Il serait temps d'arrêter de jouer les moutons de Panurge et de se fondre dans la pensée unique. Heureusement, les éditeurs de distributions Linux ne cèdent pas à cette mode d'avoir toujours la dernière version, mais s'attachent d'abord à avoir un ensemble cohérent, stable et fiable. Ils ne refusent pas le progrès, ils s'y engagent avec prudence et intelligence. Entre un patron (trop) moderne et l'équipe de dev d'une distribution (même si je ne suis pas toujours d'accord avec ), je n'hésite pas une seconde à qui accorder ma confiance !

Et le résultat est là : toujours aucun cas d'intrusion connu à ce jour sur une SME "out of the box", de nombreux cas connus sur des SME avec version PHP/MySQL modifiée. Ça ne veut pas dire qu'il n'y a aucun problème potentiel avec PHP 4 et faille systématique avec PHP 5, mais les faits sont très significatifs des probabilités de failles de sécurité ! Et donc des choix qui ont été faits, même si on peut effectivement regretter que SME 8 avec PHP 5 tarde tant à sortir en version finale. Mais comme je l'ai souligné, la version bêta actuelle comporte moins de risque que SME 7 + PHP 5... Ce sont les faits concrets et l'expérience de très nombreux utilisateurs de SME qui parlent, pas moi !!!

[Baobab]

Merci pour vos réponses. Mais alors où se trouve le plus gros problème de sécurité ? :

1. Si j'utilise la dernière version de joomla avec php 5.3
2. Si j'utilise la version 1.0.15 de joomla (que par ailleurs j'aimais beaucoup) avec php5, dans la version que j'ai actuellement, intégrée à sme7

J'utilise joomla parce-que j'ai besoin de créer un site complet rapidement, qui disparaitra sans doute au bout d'un an ou deux. Si j'avais eu le temps j'aurais codé moi-même.

[unnilennium]

le problème de sécurité est d'utiliser joomla. C'est un des CMS avec DUPRAL les plus utilisés et sur lesquels on toruve le plus de failles de sécurité. Leur succé fait que le pool de dev est immense et les controles de securité moins systématiques dans le code.

le mieux est de ne pas utiliser de CMS, mais si tu n'as pas le choix je t'orienterais plus vers ZIKULA ( suite de postnuke) qui a toujours mis une priorité sur la sécurité. Je ne dit pas qu'il n'y a pas de failles dedans, juste potentiellement moins.

Il faut bien évidemment faire les mises à jour, surveiller les failles decouvertes et limiter les plugins non verifiés.

JP

[jibe]

Salut,

+1 unnilennium !

j'ai besoin de créer un site complet rapidement

C'est un peu bref comme cahier des charges ! Difficile de te conseiller utilement ! Je suppose que Joomla a été choisi parce que c'est un des CMS les plus connus, non en fonction d'une adéquation au cahier des charges... La panurgie n'est pas la meilleure démarche en matière de sécurité

Ne connaissant pas tes besoins, on peut supposer que WordPress pourrait te convenir également. N'ayant jamais eu à choisir un CMS, je ne me suis pas penché sur le problème, mais WordPress a été choisi pour le portail du futur phénIXUS. Quand on considère que Bruno n'a généralement confiance qu'en ce qu'il code lui-même, on peut s'imaginer que WordPress est aussi très bien sécurisé.

Reste que, comme le dit unnilennium, il faut éviter les plugins dont on n'est pas sûr.

[bethebeast]

Merci pour vos réponses. Mais alors où se trouve le plus gros problème de sécurité ? :

1. Si j'utilise la dernière version de joomla avec php 5.3
2. Si j'utilise la version 1.0.15 de joomla (que par ailleurs j'aimais beaucoup) avec php5, dans la version que j'ai actuellement, intégrée à sme7

J'utilise joomla parce-que j'ai besoin de créer un site complet rapidement, qui disparaitra sans doute au bout d'un an ou deux. Si j'avais eu le temps j'aurais codé moi-même.

Très bonne question !

Je comprends très bien ton scepticisme, mais il faut également comprendre que l'on a le choix entre le pire, et le moins pire

- soit on bidouille le système, ce qui peut créer des failles connues ou inconnues. On peut ouvrir une porte, ou plusieurs sans même s'en rendre compte, et là, ça peut être très dangereux !

- soit on laisse le système tel qu'il est, et on installe une webapp à risque.

Pour le dernier choix, je vais prendre un exemple concret :

Imaginons que j'ai un hébergement mutualisé chez un prestataire quelconque.

J'installe une webapp très populaire et très utilisé (ce n'est pas une fatalité hein !), un lamer découvre une faille dans mon site, et décide de l'exploiter.

Que va t'il se passer ?

Il peut très bien s'attaquer à d'autres sites sur le même serveur, ou lancer une attaque plus conséquente.

En règle générale, et chez tout prestataire qui se respecte, ce type de tentative est rapidement détectée.

Moralité, si le serveur est bien verrouillé, possède les outils nécessaires et a un bon sysadmin, on peut contrer les attaques.

Et comme l'a souligné Jibe :

Et le résultat est là : toujours aucun cas d'intrusion connu à ce jour sur une SME "out of the box", de nombreux cas connus sur des SME avec version PHP/MySQL modifiée. Ça ne veut pas dire qu'il n'y a aucun problème potentiel avec PHP 4 et faille systématique avec PHP 5, mais les faits sont très significatifs des probabilités de failles de sécurité !

Bref, faut quand même trouver une solution. On ne peut pas rester campé sur cette position sans essayer de trouver/donner une solution qui puisse convenir.

Donc si tu décide quand même de te lancer dans l'aventure de modification, tu le fera en connaissance de cause.

Si tu change d'avis, essaie de nous décrire ton/tes besoin(s) et ton architecture, on avisera par la suite

Bon dimanche.

@+

[Baobab]

En complément :
Ce qu'il va me falloir c'est un site type "site vitrine", donc très simple, que je dois avoir monté avant la fin de la semaine prochaine, mais ce site aura sans doute une durée de vie limitée puisqu'il sera sans doute supprimé au bout de 2ans(je sais que ça n'influe pas pour autant sur l'aspect "sécurité").
Ce que je n'ai pas dit non plus, c'est pour cela que j'ai besoin d'un CMS, c'est qu'il faudrait que plusieurs personnes (n'ayant pas de compétences en informatique) puisse l'éditer.
Et je dois donc installer ceci en très peu de temps.
Si je me suis tourné vers joomla c'est que je le connaissait déja auparavant et que j'aime bien sont fonctionnement pour le style(templates). Après je suis ouvert à tout, du moment que je n'ai pas à mettre le nez dans une doc de 200pages si il y a quelque chose qui cloche, parce que naturellement, je n'ai pas le temps pour ça.

[jibe]

Salut,

Bribes par bribes, on va peut-être finir par comprendre tes besoins !

Le problème me semble assez simple à résoudre : tout est question de priorités !

Si ta priorité est d'aller vite sans te casser la tête, tu peux peut-être utiliser joomla que tu connais déjà. Mais il va falloir upgrader PHP/MySQL sur ta SME, opération à risque et au résultat incertain (combien de jours perdus pour savoir comment faire + installer puis t'apercevoir qu'il faut trouver une autre solution). Et dans ce cas, tu ajoutes à un CMS déjà réputé pour ses multiples failles de sécurité de gros risques d'en créer de nouvelles au niveau SME... Tout ça pour qu'une fois mis en place, ton site soit défacé et que ta SME finisse par servir de relais pour de la propagande terroriste et à héberger un site pédophile...

Autre solution : utiliser SME8. Déjà bien meilleur, mais reste le risque joomla...

Troisième solution : installer ZIKULA que te conseille unnilennium ou WordPress vers lequel je t'orientais... Certes, si tu ne connais pas, tu auras de la doc à lire et un apprentissage à faire ! Mais au moins, tu partiras sur une solution sûre ! Je ne connais pas ZIKULA et ne t'en dirai donc rien, mais WordPress a bonne réputation côté administration ! J'ai créé quelques pages sur le WordPress du futur phénIXUS sans aucun problème, j'ai dû perdre moins de 5mn pour trouver comment faire ! Bon, c'est un cas un peu spécial : il ne s'agissait que de faire l’équivalent d'autres pages déjà existantes. C'est certes beaucoup plus facile ! Mais bon, si tu compares avec le temps que tu passe(rai)s à mettre en place une "mauvaise" solution...