etiennegaloup Posté(e) le 25 août 2004 Partager Posté(e) le 25 août 2004 Bonjour à tous, et oui toujours avec ma compilation php. Je pensais à avoir réussi et c t trop y croire. Je possède une Woody Stable. J'ai téléchargé les sources de php4-4.1.2. Je les recompile pour réintégrer pdflib et postgresql. Tout marche excepté pdflib et une fonction postgresql. Du coup, je télécharge les sources du paquet php-4.3.8. Je les compile. J'utilise les même paramètres, il n'y a que celui de pdflib qui change. Et là PDFLib marche, postgresql marche ausi nickel mais maintenant les valeurs des variables ne peuvent plus se transmettre de page en page. Donc c un peu chiant quand même.... Si quelqu'un a une idée, ça m'interesse. Ciao Lien vers le commentaire Partager sur d’autres sites More sharing options...
tuXXX Posté(e) le 25 août 2004 Partager Posté(e) le 25 août 2004 ouais, c'est normal... c'est une config de apache...je sais plus laquelle... en fait, ça ne transmet pas tout seul les paramètres, il faut utiliser $_GET["nom_variable"] C'est ce qu'il faut faire...donc évite de configurer apache pour faire l'inverse...nouvelles normes... Donc apprends à programmer avec ça... Lien vers le commentaire Partager sur d’autres sites More sharing options...
theocrite Posté(e) le 25 août 2004 Partager Posté(e) le 25 août 2004 Je crois que c'est register_global qui est désactivé par défaut depuis php4 pour des raisons de sécurité. Dans httpd.conf tu peut mettre cette option à on, mais comme le dit tuxx, il est préférable d'utiliser POST et GET Lien vers le commentaire Partager sur d’autres sites More sharing options...
etiennegaloup Posté(e) le 27 août 2004 Auteur Partager Posté(e) le 27 août 2004 Salut, merci pour vos infos, J'ai développé mon appli sur une mandrake et je n'utilisais ni $_POST ni $_GET et ça fonctionnait. J'avais essayé avec une version antérieur, celle de php4-4.1.2 et là ça fonctionnait à merveille aussi. Quand j'utilisais une version php4-4.3.3 ou php4-4.3.8, plus moyen de transmettre des variables de pages en pages... Je pensais alors que ça venait de la version de mon apache.... Sinon j'ai trouvé un début de solution. J'ai mis php4-4.1.2 et mis une version antérieur de PDFLib, le problème c que ma fonction postgresql pg_num_rows que j'utilise quand même pas mal de fois n'est valide qu'à partir de la 4.2.0... Ouh là là, je suis un peu perdu avec toutes ces versions.... Ciao, Etienne Lien vers le commentaire Partager sur d’autres sites More sharing options...
etiennegaloup Posté(e) le 27 août 2004 Auteur Partager Posté(e) le 27 août 2004 Salut à tous, Ok merci, ça marche, j'avais quand même pas mal galéré. J'essaie de me débrouiller par moi-même mais ce n'est pas toujours gagné... Merci encore... Ca m'aide pas mal... A plus , par contre le register_globals, il est dans php.ini.... Lien vers le commentaire Partager sur d’autres sites More sharing options...
Sandeman Posté(e) le 27 août 2004 Partager Posté(e) le 27 août 2004 je pense que ton problème est que tu veux utiliser des applications fonctionnant sur une version plus avancée des serveurs (apache, postgres) que ne l'est ton système. Le problème est donc en amont : - soit quand tu as développé tes applis, l'environnement de recette n'était pas conforme à l'environnement de production (puisque trop avancé) - soit l'environnement de production doit être upgradé ... une machine de prod en sarge, à l'heure actuelle, ne me choque absolument pas, j'en ai plusieurs et non des moindres. (pis le serveur de BDD + MySQL + PHP qui archive en base 15 Go de logs par mois, il est en sid, et se porte très bien) Lien vers le commentaire Partager sur d’autres sites More sharing options...
etiennegaloup Posté(e) le 27 août 2004 Auteur Partager Posté(e) le 27 août 2004 Ouais t'as raison Sandeman, je vais y réfléchir. Bon là avec la solution de theocrite et tuxx, ça fonctionne, mais c pas génial car j'ai récupéré les sources du php4-4.3.3, je les ai compilé puis installé. Le plus propre aurait été d'installer un .deb Mais pour ça j'aurais peut-etre du passer en sarge. Le truc c que c un serveur, et j'ai toujours lu que pour les serveurs, fallait rester en stable... Merci pour les conseils, j'en prend bonne note. Ciao Lien vers le commentaire Partager sur d’autres sites More sharing options...
Poulpatine Posté(e) le 27 août 2004 Partager Posté(e) le 27 août 2004 ouais mais debian c bien ;-D alors, même le plus unstable des debian sera plus stable que le plus stable des Windows ( je pousse un peu là je sais ) Lien vers le commentaire Partager sur d’autres sites More sharing options...
-rem- Posté(e) le 27 août 2004 Partager Posté(e) le 27 août 2004 Le truc c que c un serveur, et j'ai toujours lu que pour les serveurs, fallait rester en stable... Oui tout le monde dit ca, et tout le monde fait ca, j'avoue qu'a part Sandeman, je ne connais aucun utilisateur experimente qui fait tourner un serveur en testing. De meme pour le raid 0 qui est generalement du raid 10 ou 50 ( certes bcp plus couteux ). Enfin, bref, le sujet n'est pas la, mais sachez que la sarge deviendra stable tres bientot maintenant, dans moins d'un mois.... Et on peut se dire qu'elle est presque stable. "presque". même le plus unstable des debian sera plus stable que le plus stable des Windows oui, et c'est meme bien plus stable qu'une distribution axée plus grand public, car le systeme est bcp plus robustes, et nettement plus "propre" au niveau config, et y a pas 60 daemons qui se lancent au demarrage. Debian non stable, ca veut juste dire que les paquets ne sont pas sur sur, qu'ils comportent ptet encore des bugs ou failles de securite et que c'est en cours de recherche de bugs. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Poulpatine Posté(e) le 27 août 2004 Partager Posté(e) le 27 août 2004 oui, et c'est meme bien plus stable qu'une distribution axée plus grand public, car le systeme est bcp plus robustes, et nettement plus "propre" au niveau config, et y a pas 60 daemons qui se lancent au demarrage. Debian non stable, ca veut juste dire que les paquets ne sont pas sur sur, qu'ils comportent ptet encore des bugs ou failles de securite et que c'est en cours de recherche de bugs. ah, bon, j'avais raison alors ? lol je pensais qu'une unstable c'était l'anarchie, genre windows 95a =) finalement, chez microsoft l'ordre c'est alpha => beta => gold => unstable ? ;-) ( troll inside ) Ps : désolé pour le HS, promis, j'arrete =) Lien vers le commentaire Partager sur d’autres sites More sharing options...
tuXXX Posté(e) le 27 août 2004 Partager Posté(e) le 27 août 2004 Ben oui, debian unstable est (malgré son nom) très stable !!! Dans une optique serveur, elle est peut-être "unstable", mais pour une utilisation courante, elle est parfaite !!! Lien vers le commentaire Partager sur d’autres sites More sharing options...
Poulpatine Posté(e) le 27 août 2004 Partager Posté(e) le 27 août 2004 oky, merci pour les précisions =) Lien vers le commentaire Partager sur d’autres sites More sharing options...
-rem- Posté(e) le 27 août 2004 Partager Posté(e) le 27 août 2004 Dans une optique serveur, elle est peut-être "unstable", mais pour une utilisation courante, elle est parfaite !!! ben le gros souci c'est les failles de securites possibles, un instabilite parfois, et des fois des incompatibilites, ou genre la connerie avec le reiserfs que j'ai poste en debut de semaine...mais pour qq'un qui connait pas trop, sur une workstation, je dirais que c'est assez proche de gentoo. EDT : Bon faut qu'on arrete ce gros hors sujet la.... Lien vers le commentaire Partager sur d’autres sites More sharing options...
Sandeman Posté(e) le 27 août 2004 Partager Posté(e) le 27 août 2004 Ben oui, debian unstable est (malgré son nom) très stable !!!Dans une optique serveur, elle est peut-être "unstable", mais pour une utilisation courante, elle est parfaite !!! C'est en fait ce que je me dis depuis ~3 ans, qu'une Debian unstable n'est pas facteur de gros risque. Cela dit, pour rassurer Remy je ne suis pas kamikaze : j'ai un "envrionnement de recette" : je teste dessus un dist-upgrade AVANT de le faire en réel ... Lien vers le commentaire Partager sur d’autres sites More sharing options...
-rem- Posté(e) le 27 août 2004 Partager Posté(e) le 27 août 2004 oui sandeman, pour les bugs, mais pour les failles de securite recherchees par l'equipe securite de debian stable, tu passes a travers et laisse en production des paquets potentiellement critiques. Lien vers le commentaire Partager sur d’autres sites More sharing options...
theocrite Posté(e) le 27 août 2004 Partager Posté(e) le 27 août 2004 Peut être que je me trompe, mais il me semble que même s'il est écrit "la branche testing n'est pas complètement testée et n'est pas officiellement maintenue par l'équipe de sécurité Debian", elle l'est quand même suivie par cette équipe, dans une moindre mesure et officieusement. Enfin perso, je ne mettrais pas de serveur en testing. (Même si je suis obligé de faire du backport, parce que php4.1 sur un serveur en prod ) Pour info, le serveur de Sandeman, c'est un truc important, ou un serveur pas très critique ? par contre le register_globals, il est dans php.ini....Arrg Bien sûr que c'est dans le php.ini, rien à voir avec apache. Quand j'ai écrit httpd.conf, je pensais php.ini.:s/http.conf/php.ini/g Toutes mes excuses. passer en sarge [...] pour les serveurs, fallait rester en stable... Ce ne sera plus incompatible le 15 septembre + retard prévu Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Archivé
Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.