Jump to content

jcaron

Membre+
  • Posts

    998
  • Joined

  • Last visited

Everything posted by jcaron

  1. Sans savoir comment sont calculés $widthmenu2 ou $heightimage1demi, difficule de se prononcer. Note que tu peux débugger ton code sur iPad en connectant ton iPad à un Mac et en utilisant les outils développeur de Safari sur le Mac... Jacques.
  2. Dans ton HTML, le deuxième div suit le premier, il n'est pas "dedans" (tu fermes le premier div avant de commencer le deuxième). Donc forcément aucune de tes règles CSS ne s'applique. Jacques.
  3. Tu ne devrais pas avoir besoin de certificat intermédiaire côté client, à partir du moment où il a été signé avec la clef correspondant à un certificat racine installé. Note bien qu'il y a plusieurs certificats racine Godaddy: - "Go Daddy Class 2 Certification Authority Root Certificate" (ancien), qui apparaît sous le nom "Go Daddy Class 2 Certification Authority" - "Go Daddy Class 2 Certification Authority Root Certificate - G2" (nouveau, qui date de 2009 quand même), qui apparaît sous le nom "Go Daddy Root Certificate Authority - G2" Il est vraisemblable qu'ils aient l'ancien certificat racine et pas le nouveau, ce qui expliquerait que les certificats ne soient pas acceptés automatiquement. Si tu rajoutes le nouveau certificat racine, ça devrait résoudre le problème. Rajouter le certificat intermédiaire résout aussi le problème, mais si jamais ils sortent un nouveau certificat intermédiaire ça ne marchera plus avec des certificats signés avec ce nouveau certificat intermédiaire, alors que ça continuera à marcher si le certificat intermédiaire est toujours signé par le même certificat racine (ce qui devrait être le cas pour un moment, les certificats racine sont embarqués dans les browsers, alors on n'en change pas tous les jours, alors que les certificats intermédiaires ils peuvent les changer quand ils veulent). Si le problème est bien qu'ils ont encore le certificat racine G1 et pas le G2, une autre option consiste à ajouter le "Go Daddy G1 to G2 Cross Certificate" comme certificat intermédiaire côté serveur, ça devrait permettre au browser de reconnaître automatiquement le certificat sans avoir à installer quoi que ce soit (pas testé). Jacques.
  4. Au niveau du serveur, si tu as déjà bien tous les certificats intermédiaires, rien. Mais côté client, c'est le certificat racine qu'il faut installer, pas le certificat intermédiaire. Jacques.
  5. Si le certificat racine n'est pas installé, c'est normal. Ton certificat est signé avec la clef associée au certificat intermédiaire, et le certificat intermédiaire est signé avec le clef associée au certificat racine (il peut y avoir plus de certificats intermédiaires). Un navigateur remonte la chaîne des certificats jusqu'à ce qu'il en trouve un auquel il fait confiance (qui est déjà dans sa liste de certificats de confiance). Si le certificat racine de Goddady n'est pas installé, alors il arrive au bout de la chaîne sans avoir trouvé qui que ce soit à qui il fait confiance, donc il beugle. Il suffit d'installer n'importe lequel des certificats de la chaîne (y compris le certificat lié au domaine) dans les certificats de confiance pour qu'il arrête de beugler. Mais plus haut tu remontes (au certificat racine), plus tu t'assures de la tranquillité pour le jour où il y aura un autre certificat, qui utilise éventuellement des certificats intermédiaires différents, mais la même racine. Dans ton cas, il manque le certificat racine (ou tu as un autre certificat racine de Goddady, ce qui revient au même, pour lui c'est un certificat complètement différent). En installant le certificat racine, tu es tranquille pour un moment. Jacques.
  6. Les certificats intermédiaires tu devrais les ajouter côté serveur, pas côté client. Mais il ne peut fonctionner que si le certificat racine correspondant est déjà sur le client. Note bien qu'il y a plusieurs certificats racine pour Goddady (et bien d'autres), des anciens et des plus récents. Si ça se trouve tu avais l'ancien certificat racine, mais le certificat était signé avec le nouveau? Jacques.
  7. Dans son cas c'est plutôt le certificat racine qu'il faut ajouter. Jacques.
  8. Ah ben non, j'ai dit une bêtise, le certificat racine de Godaddy est bien inclus dans IE, je ne l'avais pas vu tout à l'heure. Donc soit il manque sur la machine du client, soit il y a quelque chose dans la config qui l'empêche de le reconnaître. Tu peux commencer par vérifier que le certificat racine est présent: Outils -> Options Internet -> Contenu -> Certificats -> Autorités de certification racine de confiance (ou quelque chose d'approchant, j'ai un IE en anglais là). De mémoire la liste est mise à jour séparément par Windows Update, il y a peut-être quelque chose à voir de ce côté-là? (si le certificat manque effectivement). Jacques.
  9. Ta hiérarchie de certificats ne remonte pas jusqu'à un certificat racine standard dans IE, donc il te manque (au moins) un certificat intermédiaire. Tu peux trouver la tonne de certificates intermédiaires de Godaddy ici: https://certs.godaddy.com/anonymous/repository.pki NB: tu n'as pas tout flouté sur ta première capture. Jacques.
  10. Il est émis par qui le certificat? Il n'y a pas besoin d'un certificat intermédiaire que tu n'aurais pas inclus? La politique de sécurité d'IE sur la machine du client est-elle standard? Tu as une copie d'écran du message? Histoire de voir si c'est IE qui gueule ou si ça pourrait effectivement être un firewall sur le chemin... Jacques.
  11. Un bot fait la même chose qu'un navigateur normal: il effectue une requête sur une URL, et récupère le contenu renvoyé par le serveur. Donc à moins que tu ne fasses quelque chose de particulier côté serveur qui détecte le bot et réagit différemment, tu vas renvoyer la même chose qu'à n'importe quel utilisateur, donc include compris. Il y a de nombreux outils (y compris dans Google Webmaster Tools) pour voir ce que le robot voit quand il fait la requête... Jacques.
  12. Pourquoi ne pas utiliser un système de ticketing? C'est fait pour ça... Jacques.
  13. En effet, comme je le disais plus haut, l'important c'est que tu aies une URL pour une version du contenu, pas une URL qui sert du contenu différent suivant les circonstances. Il y a plein de choix possibles sur la structure de l'URL. Dans le chemin (www.example.com/AU-en/products), dans le sous-domaine (de.ch.example.com/products), dans une combinaison de domaine et sous-domaine (de.example.ch/products), dans une combinaison de domaine et de chemin (www.example.ch/de/products), etc. Les variations qui utilisent des ccTLDs ont l'avantage que Google devine tout de suite pour quel pays c'est, et que ça met les utilisateurs en confiance. L'inconvénient c'est que certains domaines sont difficiles à obtenir quand on n'est pas établi sur place, que certains coûtent cher, que si ont fait du TLS ça coûte plus cher en certificats, et que ça complique le passage de cookies/sessions. Dans ton cas, ça a aussi l'inconvénient que quand il y a des "régions" plutôt que des pays, c'est plus difficile de faire un mapping exact (mais si tu affiches des prix, il est souvent nécessaire d'avoir une version par pays de toutes façons). La version www.example.com/CC-lang/ a l'avantage d'être la plus simple à mettre en oeuvre. Quand l'utilisateur arrive sur une page sans le CC-lang (normalement uniquement la home), tu fais la détection, et tu l'envoies sur la home qui va bien. Normalement toutes les autres pages indexées vont correspondre directement au bon pays et à la bonne langue. Si l'utilisateur arrive (depuis un moteur, un lien externe...) sur une bonne qui ne correspond pas à ce qui est détecté, tu peux lui présenter le choix d'aller sur la "bonne" page, ou de rester là où il est (et dans ce dernier cas tu mets un cookie ou un flag de session). En dehors de ça, tu n'utilises jamais un cookie ou une session pour décider du contenu affiché (à part les parties réellement dynamiques genre connexion à son compte, panier, etc. évidemment). Pour changer de pays ou de langue, il suffit donc de construire la bonne URL. Là encore, le cas example.com/CC-lang/ est le plus facile, mais les autres cas se gèrent aussi sans trop de problème. Jacques.
  14. Quoi qu'il arrive, c'est une bonne idée, même pour l'utilisateur, que je le laisser choisir le pays. La détection de pays c'est assez fiable, mais ce n'est pas non plus du 100%. Et il y a toujours le cas du gars qui consulte le site alors qu'il est en déplacement à l'étranger mais qui veut voir le site "de chez lui". Donc des liens entre les différentes versions c'est utile, et c'est indispensable pour les robots. Sauf peut-être si tu utilies les <link> qui vont bien, mais je suis loin d'être convaincu que ça suffise. Ce que ton client "impose" c'est ce que je te disais de faire: tu utilises le Accept-Language s'il contient une langue valable pour le pays, sinon tu as une valeur par défaut. Tout ça n'est que très normal et standard, rien d'ingérable là-dedans vu d'ici... Jacques.
  15. A partir du moment où tu fais bien un redirect (i.e. que chaque version pays/langue a une URL différente, tu ne sers pas des pages différentes avec la même URL), et que tu as bien des liens (crawlables) entre les différentes versions, ça ne devrait pas poser de problème. Il commencera par une version, et puis il ira crawler le reste. Tu peux aussi utiliser les <link> qui vont bien pour l'aider. Note que plutôt que de choisir une langue par défaut pour les pays multi-lingues, tu pourrais/devrais te baser sur le Accept-Language (avec évidemment un fallback si la langue n'est pas supportée pour ce pays ou s'il n'y a pas de Accept-Language, comme dans le cas des bots). Jacques.
  16. jcaron

    Count et LEFT JOIN

    Le premier point, c'est qu'il te faut absolument un index sur la colonne id1 de table2 (et plus si affinités...). Ensuite, tu devrais pouvoir simplifier ta requête comme ça: SELECT t1.id1, champ1, champ11, count(*) FROM table1 t1 LEFT JOIN table2 t2 ON (t1.id1=t2.id1) GROUP BY 1,2,3 ORDER BY whatever LIMIT 10 Non? Note qu'un LIMIT sans ORDER BY c'est complètement imprévisible. Jacques.
  17. Le souci, c'est que le problème va se reproduire à la prochaine rotation des logs Apache. Si tu ne peux pas modifier le script qui lance sc_serv, tu as plusieurs options: 1. Tu déplaces sc_serv a un autre endroit. Tu mets à la place un script qui ferme les FDs qui vont bien et qui lance le "vrai" sc_serv en lui passant les mêmes arguments etc. 2. Tu modifies le script qui fait la rotation des logs Apache. Tu ajoutes un -k à gzip (comme ça le fichier n'est pas effacé par gzip), puis tu tronques le fichier avant de l'effacer. Le fichier continuera à être ouvert par sc_serv, mais au moins il n'occupera pas tout plein de place pour rien. Ceci dit, tu devrais faire remonter le problème aux fournisseurs du script qui lance sc_serv, c'est un vrai bug... Jacques.
  18. Ils n'ont plus de père, ils ont été détachés. Ce qui signifie qu'ils ont probablement été lancés par un processus Apache (les FDs ouverts sont une bonne indication), mais qu'ils sont maintenant indépendants, donc tu devrais pouvoir relancer Apache sans te poser de questions. Le problème, c'est que le processus qui les lance hérite des FDs d'Apache (en particulier access.log et error.log), et les passe à sc_serv, qui les garde ouverts alors qu'au moins access.log il ne s'en sert pas (error.log est lié à STDERR, donc il peut potentiellement envoyer des choses dessus). Comme sc_serv ne les a pas ouverts, il n'a aucune idée de leur existence, et il ne peut pas les fermer, même si tu demandes une rotation des fichiers de logs. Bref, pour libérer l'espace occupé à l'heure actuelle par ces fichiers, pas d'autre solution que de tuer les sc_serv (et de les relancer je ne sais pas trop comment). Pour éviter que le problème ne se reproduise à l'avenir, il faudrait modifier le script qui lance sc_serv pour qu'il ferme ces fichiers avant de le lancer. Jacques.
  19. Ce ne sont pas les colonnes que je pensais, ps aux ne donne pas le PPID. ps axl te donnera ça (3e colonne normalement). Et il est possible que chaque processus ait un père différent. Jacques.
  20. Ce n'est pas la bonne méthode pour savoir si c'est Apache qui l'a lancé. Il faut regarder qui est le processus père (2448), éventuellement récursivement, pour savoir d'où il vient. Ceci dit, le fait qu'il ait un fichier de config qui semble créé à la volée est une indication qu'il est peut-être lancé par Apache, mais le fait qu'il semble tourner depuis 2012 et qu'il ait accumulé autant de runtime me paraît très suspect pour un processus lancé par Apache... Jacques.
  21. Evidemment, dans la liste tu as beaucoup de fichiers qui sont listés plusieurs fois (parce qu'ils sont ouverts par plusieurs processus). Mais il y a qui ont été ouverts plusieurs fois par différents processus... Pour Apache, oui, un apachectl graceful devrait faire l'affaire. Ca va prendre un petit moment parce qu'il ne coupe personne mais attend tranquillement que chaque processus ait fini son boulot, mais à la fin, tu ne devrais plus avoir aucun fichier effacé ouvert. Kill envoie un signal à un processus. Par défaut c'est SIGTERM, mais tu peux préciser n'importe quel signal soit par son numéro, soit par son nom. Donc kill -HUP pid ça veut dire "envoie SIGHUP à pid". Tu es sûr que sc_serv est lancé par Apache? D'après la doc, sc_serv est normalement plutôt un processus indépendant. Et d'après la doc, tu peux lui envoyer un SIGHUP pour faire la rotation des fichiers, mais le souci c'est qu'il la fait lui-même, alors qu'il semble être configuré pour utiliser les mêmes fichiers qu'Apache, ce qui va faire des choses pour le moins étranges, avec Apache qui va probablement continuer à écrire dans un fichier qui a été renommé entre temps... Ce serait probablement une bonne idée que de lui faire utiliser des fichiers de logs séparés, mais sans en savoir plus sur le setup complet, difficile de s'avancer plus que ça. Jacques.
  22. Ah ouaip fstat c'est BSD-esque, désolé. Il semblerait que côté Linux ce soit plutôt lsof (ou éventuelle pfile ou pfiles?). Jacques.
  23. Pas besoin de relancer la machine, juste les processus correspondants. Ce n'est pas Windows :-) Pour trouver le processus fautif, tu peux essayer avec fstat. Il liste tous les fichiers qui sont ouverts par tous les processus, et il y a une colonne qui contient la date (au moins dans la version FreeBSD, je suppose que c'est pareil sur ta distribution). Par exemple chez moi: fstat | sort -rn +7 Donne les plus gros fichiers ouverts. En recoupant avec ce qu'il y a effectivement sur disque, tu dois pouvoir trouver le processus qui a un fichier ouvert mais non visible. Il ne reste alors plus qu'à relancer ce processus (ou à lui signaler qu'il doit fermer/rouvrir le fichier correspondant). Jacques.
  24. Si tu as effacé un log archivé ça ne devrait pas poser de problème. Mais si tu as effacé des fichiers de logs encore actifs, ils continuent à prendre de la place, voire à grandir. Il suffit de signaler aux processus correspondants qu'il y a eu "log rotation" pour qu'ils ferment les fichiers et en rouvrent de nouveaux, et la place correspondante va être libérée. C'est souvent faisable via un kill -HUP sur le process, mais ça varie d'un programme à l'autre. Dans le pire des cas, un restart du process correspondant fait l'affaire. A l'avenir, outre la méthode ci-dessus, une méthode efficace pour regagner de la place sur des logs en cours d'utilisation c'est de les tronquer (:>nomdufichier) plutôt que les supprimer. Jacques.
×
×
  • Create New...