[spip-dev] Installation de spip (version de dev) sur Mac OS X

Dev
1

Coucou,

Je découvre à l'instant Mac OS X. Premier sentiment : c'est très beau. Je
tente quelques installations pour s'amuser un peu... les indications
données récemment sur cette liste ne marchent plus (certains liens sont en
404). Voici donc mon parcours, si ça peut aider les prochains...

Apache 2
http://www.macupdate.com/download.php/Apache-2.0.39-MacOSX.tar.gz
S'installe d'un clic

PHP 4.2.2
http://www.macupdate.com/download.php/PHP-4.2.2-Apache2-MacOSX.tar.gz
S'installe d'un deuxième clic

mettre <? phpinfo(); ?> dans le fichier /usr/local/apache2/htdocs/info.php
et le voir à l'adresse http://localhost/info.php: super !

MySQL
http://www.entropy.ch/software/macosx/mysql/
le package s'installe facilement, mais ensuite il faut un peu configurer,
suivre la doc qui indique les manips à faire dans le Terminal.

Penser à installer mysql dans les éléments au démarrage grâce au
package suivant :
http://www2.entropy.ch/download/mysql-startupitem.pkg.tar.gz

Ensuite redémarrer et vérifier, via http://localhost/info.php que tout a
bien redémarré avec l'ordinateur...

Renommer le fichier info.php3, vérifier qu'il... n'est pas compris par le
serveur, et aller éditer /usr/local/apache2/conf/httpd.conf: ajouter sous
la ligne
    AddType application/x-httpd-php .php
une ligne
    AddType application/x-httpd-php .php3
et modifier la ligne
    DirectoryIndex index.php3 index.php index.html

Redémarrer apache2 (/usr/local/apache2/bin/apachectl stop / puis ... start)

Créer le compte mysql pour le site: il faut aller dans le Terminal
mysql -uroot -p
    (taper mot de passe root mysql)

create database spip1;
GRANT usage on spip1.* to caroline@localhost IDENTIFIED BY 'toto';
GRANT ALL PRIVILEGES on spip1.* to caroline@localhost;
exit

Installer SPIP (base 'spip1', login mysql 'caroline', pass' toto').

            * * *

C'est bon... ou presque : je rencontre de gros problèmes avec les cookies
spip_session et spip_admin, qui ne sont pas acceptés/effacés à coup sûr
par le brouteur : probablement un truc que le serveur ne fait pas comme
d'habitude... une "feature" de php4.2.2 ou d'apache2 ? Une gestion plus
stricte de la RFC qui débouche sur un bug de SPIP ? Un bug de MacOS X ?
Aucune idée à ce stade...

Toujours est-il que les symptomes sont étranges : impossible de se loger du
premier coup mais la deuxième fois ça passe ; impossible de "se connecter
sous un autre identifiant" (opération censée supprimer spip_admin)...

-- Fil

2

Coucou,

Je découvre à l'instant Mac OS X. Premier sentiment : c'est très beau. Je
tente quelques installations pour s'amuser un peu... les indications
données récemment sur cette liste ne marchent plus (certains liens sont en
404). Voici donc mon parcours, si ça peut aider les prochains...

Bienvenue au club ! :wink:

Apparemment tu utilises Mail.app avec ses problèmes d'encodages :wink:
Personnellement, je me régale avec mon localhost Apache.

Vivement Jaguar pour plus de réactivité !

Steph

3

Yo,

Tes accents ne passent absolument pas....

Pour MacOS X, il y a www.mosx.net, je ne sais pas si ça peut servir.

C'est bon... ou presque : je rencontre de gros problèmes avec les

A mon avis il vaut mieux prendre Apache 1.3.x, Apache 2 n'est pas
stable.

a+

Antoine.

4

Fil wrote:

C'est bon... ou presque : je rencontre de gros problèmes avec les cookies
spip_session et spip_admin, qui ne sont pas acceptés/effacés à coup sûr
par le brouteur : probablement un truc que le serveur ne fait pas comme
d'habitude... une "feature" de php4.2.2 ou d'apache2 ? Une gestion plus
stricte de la RFC qui débouche sur un bug de SPIP ? Un bug de MacOS X ?
Aucune idée à ce stade...

Toujours est-il que les symptomes sont étranges : impossible de se loger du
premier coup mais la deuxième fois ça passe ; impossible de "se connecter
sous un autre identifiant" (opération censée supprimer spip_admin)...

J'ai le même problème avec opera 6.02 sous linux et spip 1.4d6.
Mon opera est configurer pour me demander l'autorisation quand un site m'envoie un cookie. Mais même si je répond "accepter", la première fois ça ne passe pas. Et lorsque je me connecte la deuxième fois, j'ai un message comme quoi "une autre connection est en cours, voulez vous la supprimer ?".

On dirait que le message d'echec d'identification est envoyé immédiatement, sans attendre ma réponse (j'accepte le cookie), mais qu'après spip tient quand même compte de ma réponse, même s'il ne l'affiche pas (d'où l'autre connection en cours, et oui je me deconnecte comme il faut).

Je ne sais pas si ça peut vous aider, ou si ça a un rapport.

Et merci pour spip, ce projet est génial ! (le passage de la 1.3.2 à la 1.4 est impressionnant de nouveautés)

Fanf

5

C'est bon... ou presque : je rencontre de gros problèmes avec les cookies
spip_session et spip_admin, qui ne sont pas acceptés/effacés à coup sûr
par le brouteur : probablement un truc que le serveur ne fait pas comme
d'habitude... une "feature" de php4.2.2 ou d'apache2 ? Une gestion plus
stricte de la RFC qui débouche sur un bug de SPIP ? Un bug de MacOS X ?
Aucune idée à ce stade...

Qu'entends tu par les cookies effacés ?
Lorsque je me logue une première fois, je me déconnecte, je relance explozer
il ne me reste plus qu'à saisir mon pass.
X.1.5/Apache 1.3.x

impossible de "se connecter
sous un autre identifiant" (opération censée supprimer spip_admin)...

Pour ma part, cela foncionne à la seule nuance, que l'ancien log apparaisse
dans "actuellement en ligne".

Steph

6

@ Steph <listes@visual-concept.net> :

Apparemment tu utilises Mail.app avec ses problèmes d'encodages :wink:

Non, je fais un ssh sur rezo.net oÃu se trouve toujours mon mail, mais j'ai
du mal a trouver les reglages qui rendraienit ca ndolore quetion accents.
Mais on est vraimenthors-sujet la... passons la discussion en prive...

Personnellement, je me régale avec mon localhost Apache.

Pas de probleme de cookie avec spip 1.4dx ?

Vivement Jaguar pour plus de réactivité !

C'est quoi ?

Tes accents ne passent absolument pas....

toi aussi tu as vu :wink:

Pour MacOS X, il y a www.mosx.net, je ne sais pas si ça peut servir.

Non, leurs liens sont 404

A mon avis il vaut mieux prendre Apache 1.3.x, Apache 2 n'est pas
stable.

Pour tester, rien ne vaut les versions ultra avancees. S'il y a un bug
de spip avec apache2 autant s'en rendre compte maintenant :wink:

-- Fil

7

@ Steph <listes@visual-concept.net> :

Qu'entends tu par les cookies effacés ?

Quand spip envoie la commande
    setcookie('spip_admin', $spip_admin, time()-24*3600)

le client devrait effacer le cookie spip_admin de sa memoire

Lorsque je me logue une première fois, je me déconnecte, je relance explozer
il ne me reste plus qu'à saisir mon pass.

Oui, justement c'est la que tu peux choisir [se connecter sous un autre
identifiant ] et que chez moi ca ne marche pas.

X.1.5/Apache 1.3.x

X.1.5 aussi, mais apache2, ca doit donc venir d'apache2

> impossible de "se connecter
> sous un autre identifiant" (opération censée supprimer spip_admin)...
Pour ma part, cela foncionne à la seule nuance, que l'ancien log apparaisse
dans "actuellement en ligne".

Ca c'est normal (ou a ranger dans la categorie "bug de spip" si on veut).
Quand on se deconnecte la trace "actuellement en ligne" n'est pas supprimee.

-- Fil

8

@ Steph <listes@visual-concept.net> :

Personnellement, je me régale avec mon localhost Apache.

Moi aussi, pour apprendre et développer SPIP, c'est génial

Pas de probleme de cookie avec spip 1.4dx ?

Vivement Jaguar pour plus de réactivité !

C'est quoi ?

Le nom de développement de la version 10.2 qui sort le 24 août. Plus
réactive, plus rapide, bref, plus mieux ...

Sinon, le fait de se délogger qui ne met pas à jour la liste des connectés,
c'est quand même un peu déroutant, non ?

9

Qu'entends tu par les cookies effacés ?

Quand spip envoie la commande
  setcookie('spip_admin', $spip_admin, time()-24*3600)
le client devrait effacer le cookie spip_admin de sa memoire

A quel moment, le cookie devrait être effacé ?
Lors de la déconnexion et/ou au bout de 24h ?
Dans le cas de la deconnexion, le cookie garde une trace du login.
Dans le cas des 24h, il faut se reloguer complètement (de mémoire).

Lorsque je me logue une première fois, je me déconnecte, je relance explozer
il ne me reste plus qu'à saisir mon pass.

Oui, justement c'est la que tu peux choisir [se connecter sous un autre
identifiant ] et que chez moi ca ne marche pas.

Confirmation que cela fonctionne sans problèmes chez moi (IE5.2) sur la
release ainsi que la CVS.

Steph

10

@ Steph <listes@visual-concept.net> :

>> Qu'entends tu par les cookies effacés ?
>
> Quand spip envoie la commande
> setcookie('spip_admin', $spip_admin, time()-24*3600)
> le client devrait effacer le cookie spip_admin de sa memoire

A quel moment, le cookie devrait être effacé ?

Quand tu demandes "[choisir un autre identifiant]", la page login.php3
t'envoie vers spip_cookie.php3 qui invoque la commande citée ci-dessus. Le
navigateur devrait effacer son cookie à ce moment là.

Dans le cas de la deconnexion, le cookie garde une trace du login.

Oui. C'est justement cette trace qui ne s'efface pas dans mon cas quand je
clique sur le lien censé l'effacer. Il faudrait voir tous les entêtes
renvoyés par le serveur et vérifier s'ils sont corrects, mais je ne vois pas
trop comment faire (quelle est la requête http qui va bien, cookie inclus --
(si vous voulez tester en direct, il faudra que j'ouvre le serveur sur
l'extérieur...))?

Confirmation que cela fonctionne sans problèmes chez moi (IE5.2) sur la
release ainsi que la CVS.

Merci.

PS: pour les accents je n'ai pas de soucis si j'utilise MacSSH au lieu de
    Terminal, mais c'est une application "Classic", dommage.

-- Fil

11

@ Roustoubi <roustoubi@mac.com> :

Sinon, le fait de se délogger qui ne met pas à jour la liste des connectés,
c'est quand même un peu déroutant, non ?

C'était une décision prise à l'époque : j'étais plutôt contre, je crois me
rappeler. C'est un peu perturbant, c'est vrai ("me suis-je mal délogé ?"),
dans le cas où l'on se dé/reconnecte en changeant d'identifiant..

-- Fil

12

Pour tester, rien ne vaut les versions ultra avancees. S'il y a un bug
de spip avec apache2 autant s'en rendre compte maintenant :wink:

Et s'il y a un bug d'Apache2 avec HTTP, ce n'est pas à nous de nous
faire chier avec.

13

Pour tester, rien ne vaut les versions ultra avancees. S'il y a un bug
de spip avec apache2 autant s'en rendre compte maintenant :wink:

Et s'il y a un bug d'Apache2 avec HTTP, ce n'est pas à nous de nous
faire chier avec.

Y a des bugs PHP aussi :

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9483
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10061

14

@ Fil <fil@rezo.net> :

Quand spip envoie la commande
    setcookie('spip_admin', $spip_admin, time()-24*3600)

le client devrait effacer le cookie spip_admin de sa memoire

OK, voici une piste ; je ne suis pas le seul à avoir ce problème, c'est bien
une question d'apache2-php-cookies ; je ne sdais pas si ce sera réglé par
des modifs dans apache2, php ou dans la gestion des cookies sur les applis,
ce serait pas mal de trouver de l'info là-dessus avant de sortir la 1.4.

1) http://www.siteexperts.com/forums/viewConverse.asp?d_id=9704

"redirecting to another page poses problems. Technically, the redirect will
happen first, nad the browser will disregard the cookie handling."

2) http://www.apachelabs.org/httpd-users/200112.mbox/<0B0BB62E3235D411889B000629EE12882436C9@WLM>

3) There is a history of PHP-4 and Apache2 in the last few months directly
affecting other PHP-cookie-based software and those issues directly relating
to how and where cookies are used, read and written. Those issues have been
repaired in other software packages by rewriting the cookie sections. For
information see: http://forums.mercuryboard.com/index.php?a=topic&t=697
(on n'apprend rien)

-- Fil

15

Y a des bugs PHP aussi :

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9483
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10061

OK.

-- Fil

16

C'est aussi mon avis : je n'ai pas compris grand chose aux récentes
discussions sur la sécurité parce que c'est bien trop compliqué pour moi,
mais si on me conseille d'un côté de me déconnecter proprement en quittant
l'interface, que ça n'est pas répercuté dans la liste des connectés et que
par un recoupement quelconque je m'en rend compte, je me pose des questions.

Une question toute bête d'ailleurs (c'est tout moi ça), quel est l'intérêt
d'avoir une liste des connectés si ça ne reflète pas qui sont réellement les
connectés ? Ou plutôt, prenons le problème à l'envers : quel est l'intérêt
d'avoir quelqu'un qui n'est pas (ou plus) connecté dans la liste des
connectés ? Si c'est une façon de simplifier le code ou qq chose comme ça,
je comprends, mais sinon, je vois pas

Any comments ?

17

Oui, mais le savoir permettra de répondre aux questions... C'est plus un
bon point de hotliner que de dev, c'est vrai.

Et rien n'empêche de faire tourner 2 instances, une avec apache 1.3, et
une avec apache 2.0 MaxOS est bien foutu pour ça.... quite à le faire à
la main.

18

mais si on me conseille d'un côté de me déconnecter proprement en quittant
l'interface, que ça n'est pas répercuté dans la liste des connectés et que
par un recoupement quelconque je m'en rend compte, je me pose des questions.

Oui, tu as raison : je vais modifier ça.

Une question toute bête d'ailleurs (c'est tout moi ça), quel est l'intérêt
d'avoir une liste des connectés si ça ne reflète pas qui sont réellement les
connectés ? Ou plutôt, prenons le problème à l'envers : quel est l'intérêt
d'avoir quelqu'un qui n'est pas (ou plus) connecté dans la liste des
connectés ?

La notion de connexion (sur la durée) n'existe pas en http : on ne sait
jamais si le client a fermé son n avigateur ou pas. On a donc décidé qu'un
"connecté" est quelqu'un qui a fait un hit dans l'espace privé depuis moins
de 5 minutes. Mais c'est vrai qu'avec le bouton "déconnecter" on sait, il
faut donc traiter cette info sous peine d'incohérence.

-- Fil