Sujet fermé
Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5

Problème de connexion à l'admin et à FEU lié à un problème de cache
#1

Citation :#~~~~~ DEBUT BLOC A NE PAS SUPPRIMER ~~~~~
#~ Version du CMS: 2.1.5
#~ Url du site :
#~ Hébergeur / Soft : OVH
#~ Informations Système :
#~ Version de CMSMS™ 2.1.6
#~ Modules installés
#~ AdminSearch 1.0.2
#~ CGEcommerceBase 1.6.2
#~ CGExtensions 1.53.15
#~ CGJobMgr 1.3.4
#~ CGPaymentGatewayBase 1.6.1
#~ CGSimpleSmarty 2.1.5
#~ CGSmartImage 1.21.5
#~ CMSContentManager 1.1.4
#~ CMSMailer 6.2.14
#~ Cart2 1.2.2
#~ CustomContent 1.10
#~ DesignManager 1.1.1
#~ FileManager 1.5.2
#~ FormBuilder 0.8.1.4
#~ FrontEndUsers 2.1.1
#~ JQueryTools 1.3.9
#~ MenuManager 1.50.2
#~ MicroTiny 2.0.3
#~ ModuleManager 2.0.5
#~ NMS 2.12.2
#~ Navigator 1.0.3
#~ News 2.50.6
#~ Orders 1.18.4
#~ PaypalGateway 2.5.2
#~ Products 2.25.3
#~ Search 1.50.2
#~ SelfRegistration 1.9.7
#~ ThemeManager 1.1.8
#~ TinyMCE 3.1.4
#~~~~~ FIN BLOC A NE PAS SUPPRIMER ~~~~~

Bonjour,
Mon problème concerne un site de 23 pages, 185 articles, 990 utilisateurs FEU.
La plupart des articles ne sont accessibles en intégralité qu'aux membres FEU.
Le site est configuré en HTTPS.

Ce site fonctionnait très bien, mais depuis 15 jours le site perd régulièrement les pédales, entre 2 fois par jour à 1 fois tous les 3 jours, vraisemblablement en fonction de l'activité qu'il y a sur le site.
1. Les mots de passe des comptes administrateurs ne sont plus acceptés, ils sont obligés de demander de réinitialiser leur mot de passe pour retrouver l'accès à l'admin.
2. Les utilisateurs FEU ne sont plus reconnus, ils ont un message qui leur dit que leur compte n'existe plus, a expiré ou a été désactivé :
⁃ "Login failed. This probably means that you entered an invalid username or password. But your account may have also expired or been disabled by an administrator. Please double check your login credentials, and if they are correct you may need to contact the site administrator."
3. Des erreurs apparaissent dans le journal d'admin :
⁃ Unable to load template module_db_tpl 'NMS;archivelist_' in 'content:content_en'
⁃ Unable to load template module_db_tpl 'Orders;billingform_' in 'content:content_en'

Pour résoudre tous ces problèmes, il suffit de vider le cache du site dans "Maintenance du système", mais je n'arrive pas à trouver l'origine du problème.
Je n’ai pas détecté de corruption des fichiers du CMS. J'ai appliqué la mise à jour 2.1.6 sur la 2.1.5, mais le problème est revenu rapidement.
J’ai analysé les fichiers de logs du serveur web qui ne révèlent rien d'anormal.
Durant les 10 jours qui ont précédé l'apparition du problème, les administrateurs n'ont fait aucune modification sur le site.
Le jour où ce problème est apparu, il y a simplement eu une mise à jour et la création d'articles.
Je pense à un problème de saturation du cache du CMS. Dans les paramètres globaux, j'ai modifié les "Paramètres du cache serveur", au lieu de 0 (auto), j'ai mis 10 jours, puis 2 jours, mais le problème subsiste.
Auriez-vous des pistes à me donner pour trouver une solution ?
Merci.
#2

Bonjour,

Intéressant ... Il me semble avoir récemment entendu parler d'un problème similaire de cache aléatoire.

Tu utilises le cache Smarty ?

A ta place, je commencerai par remonter le problème sur la page du module FEU : http://dev.cmsmadesimple.org/projects/frontendusers

Sinon, analyser le code php qui mène de la saisie du mot de passe au message d'erreur. Bon courage !
#3

Quelle version de php et apache et plus d’information serveur ?
essayer avec le menu Paramètres globaux/Paramètres Smarty => Activer le cache Smarty Non

J-C Etiemble v 2.2.xx
#4

Citation :Cms Version: 2.1.6

Installed Modules
AdminSearch: 1.0.2
CGEcommerceBase: 1.6.2
CGExtensions: 1.53.15
CGJobMgr: 1.3.4
CGPaymentGatewayBase: 1.6.1
CGSimpleSmarty: 2.1.5
CGSmartImage: 1.21.5
CMSContentManager: 1.1.4
CMSMailer: 6.2.14
Cart2: 1.2.2
CustomContent: 1.10
DesignManager: 1.1.1
FileManager: 1.5.2
FormBuilder: 0.8.1.4
FrontEndUsers: 2.1.1
JQueryTools: 1.3.9
MenuManager: 1.50.2
MicroTiny: 2.0.3
ModuleManager: 2.0.5
NMS: 2.12.2
Navigator: 1.0.3
News: 2.50.6
Orders: 1.18.4
PaypalGateway: 2.5.2
Products: 2.25.3
Search: 1.50.2
SelfRegistration: 1.9.7
ThemeManager: 1.1.8
TinyMCE: 3.1.4

Config Information
php_memory_limit:
max_upload_size: 128000000
url_rewriting: mod_rewrite
page_extension:
query_var: page
auto_alias_content: true
locale: fr_FR.utf-8
set_names: true
timezone: Europe/Paris
permissive_smarty: false

Php Information
phpversion: 5.6.25
md5_function: On (Vrai)
json_function: On (Vrai)
gd_version: 2
tempnam_function: On (Vrai)
magic_quotes_runtime: Off (Faux)
E_ALL: 32759
E_STRICT: 2048
E_DEPRECATED: 8192
test_file_timedifference: Aucune différence de date du système trouvée
test_db_timedifference: Aucune différence de date du système trouvée
create_dir_and_file: 1
memory_limit: 512M
max_execution_time: 300
register_globals: Off (Faux)
output_buffering: 4096
disable_functions: _dyuweyrj4, _dyuweyrj4r, dl
open_basedir:
test_remote_url: Valable
file_uploads: On (Vrai)
post_max_size: 64M
upload_max_filesize: 128M
session_save_path: /tmp (0700)
session_use_cookies: On (Vrai)
xml_function: On (Vrai)
xmlreader_class: On (Vrai)
check_ini_set: On (Vrai)
curl: On

Performance Information
allow_browser_cache: Off (Faux)
browser_cache_expiry: 60
php_opcache: On (Vrai)
smarty_cache: Off (Faux)
smarty_compilecheck: Off (Faux)
smarty_cache_udt: Off (Faux)
auto_clear_cache_age: On (Vrai)
Server Information:
Server Software: Apache
Server Api: fpm-fcgi
Server Os: Linux 3.14.79-grsec-hosting-web-3.14 On x86_64
Server Db Type: MySQL (mysqli)
Server Db Version: 5.5.52
Server Db Grants: Impossible de trouver un privilège "GRANT ALL". Cela ne conduit pas nécessairement à des problèmes... Mais si vous avez des problèmes pour installer/retirer des modules ou ajouter/supprimer des éléments de contenu ou pages cela pourrait en être la cause.

Voici ci-dessus les informations complètes du système.
Je n'utilise pas le cache Smarty.
Toutes les pages du site sont "cachables" sauf :
• Les pages d'inscription et de modification des données utilisateurs pour FEU
• La page de résultat du moteur de recherche
• La page "Processus" utilisée par CG Job Processing Manager

C'est vrai que jusqu'à présent je n'ai jamais utilisé la balise Smarty {nocache} dans mes gabarits, est-ce une erreur ?
#5

Ça me rappelle un peu mon problème décrit ici : http://www.cmsmadesimple.fr/forum/viewtopic.php?id=6208 sauf que je n'utilise pas FEU sur ce site.
Le compte admin perd également l'accès, et un vidage de cache remet tout d'aplomb.
J'ai aussi d'autres problèmes aléatoires sur certaines pages, et les paramètres globaux qui sautent uniquement à l'affichage, mais pas dans la base.

Ouik - communication . outils numériques . design graphique
#6

je vois "php_opcache: On"
C'est activé depuis longtemps ?, y aurait-il un rapport ?
Peut être essayer d'afficher les erreurs PHP

[Edit] un rapport (peut être) avec No admins can login, front end gone a bit wrong too sur le forum En

J-C Etiemble v 2.2.xx
#7

jce76350 a écrit :[Edit] un rapport (peut être) avec No admins can login, front end gone a bit wrong too sur le forum En
Ah oui ça ressemble furieusement à nos problèmes, j'ai l'impression. Ouf, on n'est pas tout seul, et en plus c'est un des membres de l'équipe.

Bon, cela dit la seule solution semble de vider le cache via ftp… mouais.

Ouik - communication . outils numériques . design graphique
#8

Passe un mot sur le forum EN pour dire qu'il n'est pas seul Wink

J-C Etiemble v 2.2.xx
#9

jce76350 a écrit :je vois "php_opcache: On"
C'est activé depuis longtemps ?, y aurait-il un rapport ?

Oui, depuis toujours, c'est un cache au niveau d'OVH (PHP-FPM) pour d’accélérer les réponses PHP, il apporte des performances jusqu’à 7 fois plus rapides.
Je le désactive en période de développement et le réactive quand le site est en production. Je n'ai jamais eu de problème avec ce cache qui donne de bons résultats avec gtmetrix.com.

jce76350 a écrit :Peut être essayer d'afficher les erreurs PHP

Merci pour ce rappel.

jce76350 a écrit :un rapport (peut être) avec No admins can login, front end gone a bit wrong too sur le forum En

Merci pour ce lien.
#10

Ouik a écrit :Ça me rappelle un peu mon problème sauf que je n'utilise pas FEU sur ce site.
Le compte admin perd également l'accès, et un vidage de cache remet tout d'aplomb.
J'ai aussi d'autres problèmes aléatoires sur certaines pages, et les paramètres globaux qui sautent uniquement à l'affichage, mais pas dans la base.

Oui, j'ai le même problème que toi pour 2 autres gros sites qui sont encore sous CMSMS 1.12.x.
Un de 80 pages et 120 évènements de calendrier.
Un de 360 pages et 34 évènements de calendrier.
Ils n'ont pas FEU, mais utilisent CGSmartImage et les admins ne perdent pas l'accès, mais un bout d'un certain temps les blocs de contenus globaux ne sont plus exécutés.
Vider le cache remet tout dans l'ordre.
Pour l'instant, je n'ai pas parlé de ces 2 cas, j'attends de les passer sous CMSMS 2.x.
Je n'ai pas de problème avec d'autres sites CMSMS qui ont moins de contenu.
#11

jce76350 a écrit :Passe un mot sur le forum EN pour dire qu'il n'est pas seul Wink

C'est fait. Mon message est en attente de validation par un modérateur.
#12

Je vais faire de même.

Ouik - communication . outils numériques . design graphique
#13

J'ai à peu près le même souci, après je ne suis pas encore un pro de l'utilisation de CMS mais je vais essayer de vider le cache comme vous le dites et ferait un retour. Bonne continuation à tous
#14

J'ai modifié mon gabarit principal (Core:Tongueage) il y a une semaine et pour l'instant ce problème ne s'est pas reproduit.

Mon gabarit principal comprend un haut de page avec un lien intitulé "Se connecter" qui permet de s'authentifier à FrontEndUsers. Lorsqu'un utilisateur FEU est connecté, le lien est renommé avec le prénom et le nom de l'utilisateur.

Ma modification a consisté à ajouter une balise {nocache} autour de cet appel Smarty, ce qui donne :
{nocache}{if feu_smarty::get_current_userid()}{feu_smarty::get_user_property('prenom')} {feu_smarty::get_user_property('nom')}{else}Se connecter{/if}{/nocache}

Je vais attendre encore un peu avant de confirmer que mon problème est résolu.
#15

Le problème vient de se reproduire :-(
Il n'y a eu aucune activité de la part des administrateurs aujourd'hui.
À 10h08, un utilisateur FEU s'est connecté normalement.
À 10h50, "CGJobMgr" a déclenché l'action "PING: No jobs found (pings at least every 2 hours)"
À 10h55, "Automated Task Succeeded" a déclenché l'action "PruneAdminlogTask"
À 10h56, les utilisateurs FEU ne pouvaient plus se connecter, ils avaient l'erreur :
Login failed. This probably means that you entered an invalid username or password. But your account may have also expired or been disabled by an administrator. Please double check your login credentials, and if they are correct you may need to contact the site administrator.

Ensuite, pour me reconnecter en Admin, mon mot de passe n'est plus accepté, je suis obligé d'utiliser la fonction de réinitialisation du mot de passe.
Dès que je suis reconnecté en Admin et que je vide le cache du site dans "Maintenance du système", tout rentre dans l'ordre.
#16

Je viens de regarder dans le journal de l'administration, j'ai des messages d'erreur du type "An error has occurred Unable to load template module_db_tpl 'Gallery;' in 'content:content_en'" juste après la même action automatique que tu mentionnes :
Citation :"Automated Task Succeeded" a déclenché l'action "PruneAdminlogTask"
Puis même problème de connexion à l'admin.
En vidant le cache via ftp, tout redevient normal.

On devrait peut-être ouvrir un bug sur la forge non ?

Ouik - communication . outils numériques . design graphique
#17

J'ai relancé sur le fil du forum .org.

Ouik - communication . outils numériques . design graphique
#18

Avant d'ouvrir un bug sur la forge, j'aimerais trouver une raison qui expliquerait l'apparition de ce problème.
Je vais surveiller mon site encore un peu.
Actuellement, je pense à un problème lié à la taille du journal d'administration car :
1. Calguy dit que "PruneAdminlogTask" est une tâche qui passe régulièrement pour empêcher au journal d'administration d'être trop gros (cf. forum.cmsmadesimple.org/viewtopic.php?p=304434#p304434)
2. Mon site a une conservation des logs d'admin réglée à 3 mois et le journal tient en ce moment sur 88 pages.
#19

Bon, ça devient très fréquent maintenant (tous les 1-2 jours).

Toujours le même enchainement entre la tâche auto et les erreurs qui viennent ensuite et l'accès impossible à l'admin sans vidage de cache.

Ouik - communication . outils numériques . design graphique
#20

Bonjour Ouik,

Je constate que sur mon site que la tâche "PruneAdminlogTask" est exécutée tous les jours (environ toutes les 24h et 20min). Dans ce cycle, cette tâche est toujours suivie de la tâche "ClearCacheTask". Dans ces cas-là, le problème n'apparaît pas.
Mais certains jours, en plus de ce cycle, "PruneAdminlogTask" est exécutée seule et c'est là que le problème apparaît.
Peux-tu confirmer le même déroulement dans l'apparition du problème sur ton site ?
Merci.
#21

Je vais regarder et te tiens au courant.

Sinon pour info j'ai discuté sur IRC avec des membres du staff, et ils sont sur le problème, mais ils ont du mal à comprendre précisément de quoi ça provient, ça semble dépendant du serveur (un paramétrage ?). Du coup tout renseignement utile côté configuration du serveur peut aider.

Et pour info également, il semblerait que désactiver le vidage de cache automatique (c'est à dire le mettre sur 0) éviterait le problème. Je l'ai fait sur mon site, et je le suis avec attention pour voir si ça se reproduit ou non.

Ouik - communication . outils numériques . design graphique
#22

Alors je viens de regarder : chez moi l'enchainement n'est pas systématique. Et parfois il est inversé (ClearCacheTask en premier) et ça ne pose pas de problème. Par contre à chaque fois que ça s'est déclaré, il y avait PruneAdminlogTask non suivi de ClearCacheTask.

Ouik - communication . outils numériques . design graphique
#23

Merci pour ce retour.
Je doute que désactiver le cache automatique résolve le problème, car le cache de mon site était justement réglé sur 0 quand le problème est arrivé.
#24

Ah ? Tu es bien sûr ? C'est ce que m'a conseillé un des dévs pourtant. Mais bon vu qu'ils ne savent pas trop d'où ça vient…

Ouik - communication . outils numériques . design graphique
#25

Oui, je l'ai précisé dans l'avant-dernière phrase de mon premier post :
cyrcle a écrit :Je pense à un problème de saturation du cache du CMS. Dans les paramètres globaux, j'ai modifié les "Paramètres du cache serveur", au lieu de 0 (auto), j'ai mis 10 jours, puis 2 jours, mais le problème subsiste.
À l'époque, je pensais que la valeur "0" correspondait à "auto" alors ça semble plutôt correspondre à "jamais", mais mon site était bien configuré sur "0" quand c'est arrivé.
Sujet fermé


Atteindre :


Utilisateur(s) parcourant ce sujet : 5 visiteur(s)