bruno78

@Einsteinium bonjour, j'ai eu cette semaine les renouvellements automatiques des mes 3 domaines : 2 domaines purement dédiés hébergement (des sites wordpress dans des vhost), et en dernier le domaine principal de mon Syno et de tous ses services. Chacun à 2 jours d'intervalle, ça permet de voir plus clair. Résultats : domaine hébergement (www.ndd1.tld1) => renouvellement auto OK, rien à ajouter ! domaine hébergement (www.ndd2.tld2) => echec lors de la première tentative ("forbidden call") je ne touche à rien, ok le lendemain lors de l'essai suivant. PS : c'est tombé en plein pendant l'épisode incendie chez OVH, est-ce que leurs services n'étaient pas un peu perturbés ??? ....) domaine principal de mon Syno, avec tous les services associés renouvellement OK et certificat bien déployé automatiquement sous DSM. A priori on se dit tout va bien ... mais en regardant => c'est toujours l'ancien certificat qui semble être utilisé !! alors qu'il n'apparait plus sous DSM ... ???? Purge du cache navigateur n'y change rien. Le certificat est bien déployé dans DSM : Mais le certificat utilisé est toujours l'ancien ... ??? Et au niveau du Log je ne vous mets que la fin, mais bon c'est OK : [Sun Mar 14 00:41:09 UTC 2021] Generate form POST request [Sun Mar 14 00:41:09 UTC 2021] Upload certificate to the Synology DSM [Sun Mar 14 00:41:09 UTC 2021] POST [Sun Mar 14 00:41:09 UTC 2021] _post_url='http://172.17.0.1:5000/webapi/entry.cgi?api=SYNO.Core.Certificate&method=import&version=1&SynoToken=KscmmODGz6Yiw&_sid=N3WJNnGN0hMgpuc9uopTLqPTsFInzannauvVY9TPyAcbV47DkDXRoGAnxYaeSHiwAwxPWNrTlMs5iPSwnaotbU' [Sun Mar 14 00:41:09 UTC 2021] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Sun Mar 14 00:41:56 UTC 2021] _ret='0' [Sun Mar 14 00:41:56 UTC 2021] http services were restarted [Sun Mar 14 00:41:56 UTC 2021] Success [Sun Mar 14 00:41:56 UTC 2021] Return code: 0 [Sun Mar 14 00:41:56 UTC 2021] _error_level='2' [Sun Mar 14 00:41:56 UTC 2021] _set_level='2' [Sun Mar 14 00:41:56 UTC 2021] The NOTIFY_HOOK is empty, just return. [Sun Mar 14 00:41:56 UTC 2021] ===End cron=== Peut-être dois-je simplement re-importer le certificat à la main ? Cdt, Bruno78

Bonsoir @maxou56 alors si je me penche sur les données des 2 SSD comme tu l'indiques : pour le Cache 1 et pour le cache 2 Or : ces 2 SSD ont toujours été montés ensembles donc la différence de "Power On Hours" = 28h ??!! Si je prends le graffe de température du SSD cache2 que j'avais noté à -1 il "manque" environ 12 heures. Je n'ai pas trouvé d'autre comportement de ce genre sur les 3 derniers mois (je ne garde les stats que 3 mois). Mais pas impossible que ce se soit déjà produit sans que l'on incrimine le SSD .... L'hypothèse d'une panne aléatoire du SSD prend t'elle forme d'après vous ? Merci

@oracle7 d'un côté c'est plutôt bon signe, .... mais du coup ça n'explique pas où est ton problème ....

OK. Je n'ai pas trop de temps ces jours ci, mais je vais regarder.

Bonjour @Denisra76Frog, je n'aime pas trop faire les choses complètement en aveugle, mais je vais jeter un coup d’œil. Peux-tu me donner le lien où l'on parle de cette connexion ? Bruno78

@oracle7 bonjour, puis-je faire une suggestion ? As-tu essayer de lancer un "snmpwalk" depuis une console ssh vers un élément de la MIB ? Cela peut permettre de voir des messages d'erreur que l'on ne voit pas sinon. D'abord depuis une console ssh du NAS, puis depuis une console ssh dans le docker lui-même.

ok donc je vais enlever une barette de 8Go et garder la seconde 8Go en service. Merci

@EVOTk et du coup, pour repasser à 8Go, il faut absolument faire du 4Go+4Go, ou une seule barette 8Go est supportée ?

Pour être précis, c'est ça que je recois régulièrement : Or à ce moment là, la mémoire dite "libre" tombe de 495Mo à 211Mo. Mais ce n'est pas comme si il ne restait pas 5.4Go de buffer dans lesquels aller puiser ? J'avoue que je ne comprends pas très bien comment la mémoire est gérée ....

@.Shad. @EVOTk, difficile de pointer du doigt à coup sûr l'origine. J'ai rétabli le cache SSD R/W, et je vais passer de 16 à 8 Go de RAM, pour voir si cela change quelque chose au comportement du NAS. => voir si il y a des dégradations visibles de performance. Le fait est que de temps en temps j'ai une alerte "mémoire insuffisante", alors que loin de là !! Je vais voir si ce message apparait encore avec 8Go de RAM.

@Jeff777 @.Shad. en fait 2 pistes : soit effectivement un pb avec un SSD, soit, et le support Syno m'en a remis une couche, un effet de bord d'avoir 16Go de RAM .... pas officiellement supporté par Syno.

Voila Voila, c'est reconfiguré !! Bon tout semble fonctionner correctement 🙂 Maintenant 2 chantiers : mettre un syslog externe au NAS mettre en docker les hébergements web .... et surveiller le comportement du cache ssd ......

@Jeff777 Le support a débloqué l'installation des paquets Apache en relançant le syslog .... bon, ok ..... N'empêche que mon webstation ne sait toujours pas où il habite, donc je désinstalle et re-installe ... et je refais les maj. pour les vhosts wordpress .... que je vais mettre en container parce qu'à chaque fois qu'il y a un problème ou une maj, les configs modifiées nginx et consort passent à la trappe ..... Il est donc urgent de se rendre indépendant !

@Jeff777 merci pour ton retour, pour le moment je laisse le support Syno prendre la main dessus et regarder (c'est encours). C'est le but même de la Beta, voir si il y a du grain à moudre ou pas. Je ne suis pas à 1 heure prêt (heureusement) et à partir du moment où je n'ai pas perdu de données ... bah ça va déjà mieux . J'avais déjà eu quelque chose de similaire, il avait fallu désinstaller complètement Webstation (incl. les paquets Apache et en ne conservant pas les paramètres), reinstaller et reconfigurer les vhost ... 1 petite heure de boulot. Si ils trouvent le pourquoi du comment de la non réparation des paquets Apache, je vous tiens au courant.

Les paquets qui me donnent du mal, et qui sont vraisemblablement la cause des problèmes WebStation, sont les 2 paquets Apache, qui refusent de se réparer !

@Mic13710 oui tout à fait. D'où un œil constant sur les sauvegardes :-). En l’occurrence, même si il a bien redémarré (à Webstation prêt !) je crains plutôt sur ce coup là une petite défaillance matérielle sur l'un des 2 caches SSD NVME. A surveiller de très prêt.

Bon, après reset au bouton POWER (meme le support me le conseillait comme seule solution), retour à la vie : A priori pas de perte de données, mais vérifications à venir. Par contre reverse proxy, webstation, .... c'est n'importe quoi ... Les journaux systèmes ont été rincés. Par contre les logs des dockers confirment qu'il était bien vivant ... J'ai du travail de vérification pour la journée... Cdt, bruno78

Bon ben quand faut y aller ... PS : courage pour ceux qui sont sur OVH STBG ....

bonjour @.Shad., non, malheureusement plus accès à rien, ni via DSM ni via ssh. Le plus étonnant c'est qu'il y a toujours une certaine activité, certains dockers répondent (dont telegraf !). Le bouton de reset n'est pas pris en compte, il y a de l'activité sur les HDD, le cpu tourne, pas de saturation mémoire . Pas de led d'anomalie .... Et précisemment, comme il y a de l'activité, un arrêt brutal ne me tente pas trop car risque élevé de corruption. Le seul point positif, c'est que j'ai des sauvegardes .... Pour le support, je n'ai pas grand chose à leur fournir du coup .... ( à l'avenir, j'archiverai les logs en dehors du NAS ....)

Suite : NAS invisible depuis le synology assistant connection au DSM désormais impossible bouton arrière RESET inoperant pourtant un certain nombre de services fonctionnent semble t'il !! J'attends un peu avant un arrêt brutal , voir si vous avez des suggestions, mais moi j'ai fait le tour de ce que je pouvais faire "proprement"

par ailleurs, les 2 SSD ont disparu la surveillance des disques : avant : maintenant :

Bonjour, tout allait plutôt bien dans le meilleur des mondes, jusqu'à ce matin. Le DS918 sous DSM7 semble avoir eu des vapeurs cette nuit. A la connexion, le bureau est réinitialisé, comme neuf !. Les applis sont là mais ne répondent pas forcement. Connexion ssh impossible. Bien que l'écran soit vide, les dockers semblent continuer à tourner (dixit grafana), même si pas forcement accessibles depuis le réseau. Si on regarde Active Insight, il n'y a plus de données remontées depuis cette nuit. La je suis un peu perdu ... Merci pour les pistes que vous pourriez me donner. PS : j'ai un doute sur l'état du cache SSD ..... pb matériel ? Cdt, Bruno78 Côté gestionnaire de stockage, ce n'est pas encourageant : Quant au monitoring grafana, il me donne ceci pour les températures de disques, ce qui me laisse entrevoir une panne matérielle sur l'un des caches SSD ? bruno78

Bonsoir @Denisra76Frog, Bienvenue parmi nous. content de voir que je ne suis pas seul sur Influxv2 ! Je suis en train d'essayer d'y convertir tous mes dashboards. Et certains posent plus de problèmes que d'autres .... (j'ai entre autres des problèmes avec les variables dans les dashboards !) Pour la 4G je ne sais pas ... Si l'API ne dit rien, .... . Et comme je n'ai qu'une Révolution, donc sans 4G ... N'hésites pas à faire un tour par la case présentation 🙂 Bruno78

@Jeff777 oui je me souviens bien de ta problématique. 2 solutions pour utiliser directement le python : soit un container sur mesure (que tu as déjà testé mais tu veux garder la possibilité de mise à jour), soit se passer de docker et utiliser directement le Python du DSM , sachant que sur DSM7 le python est intégré de base, mais il faudra quand même rajouter des modules spécifiques .... je ne sais pas alors ce qui se passera lors d'une mise à jour DSM ? Pour le moment je suis reparti sur une solution docker et image personnalisée (et je butte sur un stupide problème de crontab dans le container .... mais ce n'est pas le sujet). Si je n'y arrive pas ou si trop contraignant, j'essaierai quand même la solution d'utiliser le python du DSM.

@.Shad. effectivement, ce sont les 2 axes repérés. Je me suis d'abord dit : "on peut se passer de grafana". Presque .. il manque des fonctionnalités de customisation des graphes, plugins, .... . Mais c'est vrai que cela fait hésiter. Si ils font un effort de ce côté là, on devrait pouvoir se passer de Grafana. Mais si on a d'autres sources (Loki par exemple), je ne sais pas comment influxdb2 va le gérer ... ou pas. Et il y a les "tasks". mais là je n'ai pas regardé du tout. Pour l'instant je galère (mais ce n'est pas avec Influxdb) avec le dashboard Freebox, que j'ai essaie de faire passer directement du Python vers Influxdb, sans passer par telegraf ....