oracle7

@termi Bonjour, Peut-être aussi que tu avais saisi dans le nom du NAS des caractères "exotiques" invisibles qui perturbaient le système UNIX du NAS. Cela arrive souvent lors de C/C. PS : Comme sur tout forum, il est d'usage que les nouveaux membres passent par la rubrique [PRESENTATION] pour faire la leur. Certains ici, y sont sensibles et de plus cela facilite les réponses en fonction du niveau de compétences du membre. Cela dit rassures-toi il n'est pas trop tard pour bien faire ... Cordialement oracle7😉

@kroumi Bonjour, Ce nouvel admin ayant des droits restreints, comme je te l'ai dit précédemment le malveillant potentiel aura la tâche plus compliquée et cela lui prendra plus de temps, temps qu'il n'a pas, donc il se découragera plus vite de poursuivre son action. Sauf si vraiment tes photos par exemple sont telles, qu'elles puissent devenir un moyen de pression sur toi pour obtenir de toi ce qu'il convoiterait. Tu détiens des informations/choses si importantes ? Il faut à mon sens rester raisonnable et au final ce que tu auras mis en place en terme de sécurité sur ton NAS (selon les recommandations ici proposées) peut s'avérer largement suffisant pour les quidams ordinaires que nous sommes. Ce n'est que du bon sens, non ? Oui il faut se protéger mais delà à à devenir parano, pas pour moi en tout cas. Essaies simplement de chiffrer le risque que tu prends pour te rendre compte. Je le répète le risque zéro n'existe pas mais quel prix es-tu prêt à payer pour tout verrouiller ? Cela deviendrait tellement contraignant que tu n'oseras même plus toucher à ton NAS, non ? C'est pas le but ... Bien, tu commences à comprendre la philosophie ... Cordialement oracle7😉

@kroumi Bonjour, Si je peux me permettre, tu te prends la tête pour rien. Pour ton information, le code du fichier .htaccess ne fait ni plus ni moins, que réécrire automatiquement de façon totalement transparente pour toi, l'entête http de toutes les requêtes Web que tu émets, en https comme si tu les émettais toi directement en https. C'est tout. Pour mettre en place cela, c'est on ne peut plus simple et parfaitement décrit dans le TUTO Reserve Proxy, alors pourquoi te priver de cette possibilité qui va de paire avec le bon fonctionnement du reverse proxy ? Je ne comprends pas ... c'est un peu "balo", non ? Là aussi, à mon humble avis, c'est une très mauvaise idée que tu as de ne pas suivre les recommandations de @Fenrir. C'est un expert réseau et sécurité on peut plus reconnu de la communauté et comme tout expert il sait lui, de quoi il parle. Aussi, je ne suis pas sûr que tu mesures bien les conséquences de ton choix, mais libre à toi ... Tu peux toujours faire autrement si tu as les connaissances suffisantes pour ! Oh c'est sûr je te l'accorde, on ne verrouillera jamais complétement les choses, le risque zéro en matière de sécurité n'existe pas, mais on peut a minima faire en faire en sorte de compliquer la tâche des potentiels malveillants et retarder ainsi au maximum leurs actions ce qui aura un effet dissuasif on ne peut plus important et efficace. Et en plus tu gères des données si confidentielles que cela sur ton NAS ? Nota : Enfin, juste une question de bon sens : comment veux-tu qu'un pirate se connecte à ton NAS avec le compte "admin" lorsque celui-ci est désactivé ? Peux-tu m'expliquer STP ? Cordialement oracle7😉

@kroumi Bonjour, Dans l'exemple que t'a donné @maxou56, avec le masque 255.0.0.0 on obtient le maximum d'@IP utilisables pour le sous-réseau 10.0.0.0. Ce qui est plus que conséquent ! Selon la valeur du masque tu adresseras un nombre plus ou moins grand d'@IP. Regardes cet article et tu comprendras mieux si besoin en est. Avec un calculateur de masque tu pourras si tu le souhaites, déterminer le masque adéquat pour restreinte pas exemple la plage d'@IP de ton sous-réseau et ainsi limiter la plage d'@IP utilisables. Cordialement oracle7😉

@kevin67130 Bonjour, Certes mais ce fichier comme je te l'ai déjà dit n'a rien de secret, il n'y a pas d'informations personnelles dedans. L'@IP de ton NAS est une adresse locale INVISIBLE depuis l'extérieur (Internet). Le fichier est OK, pour être cohérent, j'aurai juste mis la dernière ligne de celui-ci "MONITOR ..........................." juste en dessous de la ligne : # -------------------------------------------------------------------------- # MONITOR <system> <powervalue> <username> <password> ("master"|"slave") Tu mets la valeurs que tu veux? moi j'éteints le PC avant le NAS. Cordialement oracle7😉

@kevin67130 Bonjour, C'est évident : commander l'arrêt du PC 3 minutes après avoir reçu l'ordre par le NAS. Cela ne sert à rien de mettre une durée de validité sur le lien vers le fichier que tu transmets, ceux qui te répondent ne sont pas là à attendre chacun de tes posts ! Par ailleurs le "bout" de log que tu joins est parcellaire, il ne donne pas l'information voulue qui elle se trouve justement dans le fichier upsmon.conf. Cordialement oracle7😉

@mery Bonjour, Le logiciel constructeur de ta caméra doit te permettre de définir ce login et le mot de passe associé. C'est ceux là qu'il faut utiliser. D'ailleurs tu as dû aussi utiliser ce logiciel pour rentrer l'@IP de ta caméra sur ton réseau local en remplacement de l'@IP par défaut qui a toutes les chances de ne pas correspondre. En plus c'est aussi le ba a ba de la sécurité pour ces équipements : changer le MdP par défaut et adapter l'@IP. Cordialement oracle7😉

@kevin67130 Bonjour, Une fois WinNUT réinstallé tu devrais avoir quelque chose par exemple comme cela : Ensuite après avoir configuré ton fichier upsmon.conf envoies nous le pour vérifier que tout est bon. Cordialement oracle7😉

@StéphanH Bonjour, C'est peut-être cela la solution : paramétrer un planning d'allumage, en fait d'extinction la nuit. Cela dit, sans lampes IR actives la nuit, l'image résultante risque d'être très sombre voire inexploitable. Il faut faire un compromis, ne rien voir ou voir les évènements de la nuit et éliminer tous les matins les enregistrements de mouvements "parasites". C'est un choix. Cordialement oracle7😉

@StéphanH Bonjour, Regardes si par hasard tu n'aurais pas un paramètre lié à l'Infra Rouge (IR). Par exemple, dans le logiciel constructeur de gestion/paramétrage des caméras chez HIKvision (accessible via un navigateur), on peut désactiver la lampe IR. Foscam étant aussi "une grande marque", il serait étonnant qu'il n'y ait pas aussi ce type de paramétrage. Par ex chez moi c'est dans "Paramètres système/Maintenance" donc par similitude, peut-être que ... Autre piste, regardes aussi si tu ne peux pas paramétrer "les mouvements brefs" i.e. inférieurs à 1 à 2 sec. Sinon, rassures-toi tu n'est pas le seul à avoir des soucis avec les papillons et autres insectes volants, le pire ce sont les araignées qui sont immanquablement attirées par la lampe IR et qui génèrent pléthore de faux évènements de mouvements sur la caméra. Voilà en espérant que cela pourra t'aider. Cordialement oracle7😉

@kroumi Pour compléter les explications précédentes, en général, je dis bien en général car il peut y avoir des exceptions/variantes, les plages d'@IP locales/privées suivantes sont utilisées pour : 10.0.0.0/255.0.0.0 : ce sous-réseau est plutôt utilisé en conjonction d'un réseau VPN (serveur VPN sur le NAS et client VPN sur un périphérique externe). Il devient le réseau local et ton NAS a alors par exemple l'@IP 10.8.0.1 si on utilise le protocole OpenVPN ou 10.2.0.0 si on utilise le protocole L2PT/IPSec. 172.16.0.0/255.240.0.0 : ce sous réseau est utilisé lorsque par exemple on gère des applications en conteneurs sous le logiciel "docker" mais pas que ... 192.168.0.0/255.255.255.0 : ce sous réseau est le plus communément utilisé comme réseau local. Cordialement oracle7😉

@kroumi Bonjour, Pour compléter le propos, la seule solution pour supprimer l’information HSTS du navigateur lors d'une activation par erreur de HSTS sur le NAS, il faut vider le cache HSTS du navigateur, pour réaliser cela : Dans Chrome, taper chrome://net-internals/#hsts Entrer le nom de domaine dans le champ texte de la section "Delete domain security policies" Cliquer sur le bouton Delete Entrer le nom de domaine dans le champ texte de la section "Query HSTS" Cliquer sur le bouton Query La réponse doit être "Not found" (non trouvé) Avec Safari, commencer par fermer le navigateur Effacer le fichier ~/Library/Cookies/HSTS.plist Rouvrir Safari Avec Firefox, fermez tous les onglets Ouvrir le menu de Firefox et cliquer sur Historique / Afficher l’historique. Rechercher la page dont vous voulez supprimer les préférences HSTS Effectuer un clic droit sur une des entrées lui correspondant Choisir Oublier ce site Cordialement oracle7😉

@mery Bonjour, Je ne suis basé sur ton profil et "Trouvé son contenu" et là : pas de présentation. Mais c'est pas grave, saches qu'il est plus facile d'adapter une réponse quand on sait qui on a en face, c'est tout. Sans garantie, essaies ceci : "rtsp://login:password@adresse_ip:554/onvif1" OU "rtsp://login:password@adresse_ip:554/live/ch00_1" Cordialement oracle7😉

@kroumi Bonjour, Pas de soucis, saches que t'a démarche d'analyse, compréhension des notions avant mise en œuvre est à mon sens excellente. Beaucoup d'autres, malheureusement, n'ont pas cette vision des choses. Cela dit, pour le HSTS saches que c'est une option pas du tout recommandée (voir le TUTO ReverseProxy) car c'est le navigateur qui enregistre cette information et il ne laissera plus passer autrement qu'en HTTPS, même si ce dernier est coupé (HSTS coché puis décoché). Si tu veux forcer le https, il vaut mieux passer par le fichier .htaccess via web station comme indiqué dans le TUTO. Cordialement oracle7😉

@mery Bonjour Comme sur tout forum, il est d'usage que les nouveaux membres passent par la rubrique [PRESENTATION] pour faire la leur. Certains ici, y sont sensibles et de plus cela facilite les réponses en fonction du niveau de compétences du membre. Cela dit rassures-toi il n'est pas trop tard pour bien faire ... As-tu regardé ici. Essaies à tout hasard avec l'option [Défini par l'utilisateur] au lieu de [ONVIF]. Cordialement oracle7😉

@kevin67130 Bonjour, ????? décidément j'ai du mal à te suivre .... ton écriture a du mal à traduire ta pensée. As-tu utiliser le logiciel WinNUT (sur Windows) pour piloter ton onduleur ? Si Oui, pour mieux comprendre ce qui se passe, peux-tu faire une copie d'écran de WinNUT? et fournir ton fichier "C:\Program Files (x86)\WinNUT\upsmon.conf" (t'inquietes pas il n'y a rien de secret dans ce fichier !). Cordialement oracle7😉

@kevin67130 Bonjour, Fait la somme en Watt des puissances consommées actuellement (à la vue de ta photo) de chacun de tes équipements branchés sur ton onduleur donne 126 Watt (ce qui est très peu !), donc tu divises ces 126 W par 0,66 et tu obtient l'équivalent en VA soit 190 VA. Compares ces 190 VA à tes 1600 VA de ton onduleur et tu te rendras compte que cela correspond en gros à une barre sur ton indicateur. Donc au final tout est normal !!! Pas la peine de te prendre plus la tête. Là il faut que tu reformules ta phrase car je ne comprends pas du tout ce que tu veux dire 🤔 Cordialement oracle7😉

@kroumi Bonjour, Si je peux me permettre, ton jugement sur le TUTO en question est bien sévère. Un très grand nombre de membres ont mis en œuvre ce TUTO sans aucun problème aussi je le défendrai ici. Au moins lui, a l'avantage d'être complet, ce n'est pas le cas de celui que tu cites. Malheureusement, bon nombre des problèmes rencontrés par certains ont bien souvent pour origine d'autres paramétrages dans DSM qui viennent à l'encontre de la mise en place correcte du reverse proxy (cela passe par du NAT mal fait dans la box/routeur, du changement de ports standards, des ouvertures/fermetures de ports mal appropriées et j'en passe et des meilleures ...). Avant de se jeter sur le TUTO, il faut a minima se renseigner sur les notions mises en oeuvre et parfaitement les assimiler sinon on fait des choses sans en comprendre les tenants et aboutissants et là, c'est la porte grande ouverte vers toute sorte de déboires, déceptions et jugements hâtifs. Cordialement oracle7😉

Bonjour, @pierre1331 et @brunaliax Comme sur tout forum, il est d'usage que les nouveaux membres passent par la rubrique [PRESENTATION] pour faire la leur. Certains ici, y sont sensibles et de plus cela facilite les réponses en fonction du niveau de compétences du membre. Cela dit rassurez-vous il n'est pas trop tard pour bien faire ... @brunaliax Ne te serais-tu pas trompé en saisissant l'@MAC de tes caméras et inversé les choses lors de la création du bail statique DHCP ? De plus, via le logiciel constructeur de tes caméras, sont-elles bien déclarées en DCHP automatique ? @pierre1331 Ta caméra fonctionne certainement comme beaucoup d'autres, soit en 100 Mbits, aussi le port de ta bbox (malgré qu'il soit Gbits) s'adapte à ce périphérique et le signale en clignotant ou s'allumant en fixe orange. C'est donc normal ! Pas de voyant orange allumé lorsque le port fonctionne en Gbits avec des périphériques eux mêmes en Gbits. Cordialement oracle7😉

@TuringFan Bonjour, Si j'étais toi (en supposant que tes 3 clés OVH sont bien sauvegardées) : AVANT toutes choses ! Vérifier qu'il n'y a pas d'usage de caractères "exotiques" dans les identifiants et MdP sinon à corriger impérativement. Pas la peine de réinstaller acme.sh. Faire éventuellement un update et sauf si vraiment tu as un doute, alors désinstalles (cf google) et réinstalles acme.sh selon le TUTO. Nettoyer avec le script et l'option "-c" (acme.sh doit être opérationnel). Supprimer dans DSM le certificat et toutes les anciennes instances de celui-ci après avoir sauvegarder les fichiers "*.pem" correspondants pour le cas où. Supprimer aussi les répertoires "ndd.tld" et "Acme_renew" dans "/volume1/Certs". On conserve les répertoires "/volume1/Certs" et "/volume1/Scripts". Reprendre le processus au début sauf la partie chez OVH (§ 3.1 uniquement) MAIS ne pas omettre l'exportation des variables d'environnement (à tous les niveaux du processus !). Si certaines actions semblent avoir déjà été faites dans les tentatives précédentes, bien s'assurer qu'elles sont conformes aux attendus. Voilà j'espère ne rien avoir oublié. Cela peut paraître radical mais après, cela devrait le faire normalement si tu es très attentif à tes actions. Prends ton temps et assures-toi de chaque action avant de passer à la suivante. Si besoin lis et relis le TUTO... Je ne peux te dire mieux. Cordialement oracle7😉

@TuringFan Bonjour, Il y a un retour à la ligne en trop. Vérifies ce répertoire. Pas ce caractères "exotiques" dans les identifiants et MdP ainsi que les noms de fichiers : UNIX n'aime pas du tout ... Lors de ta dernière tentative le certificat avait été renouvelé (voir le premier log où je m'était "planté") donc la prochaine date de renouvellement annoncée est normale et il est normal qu'il te dise "Inutile de renouveler le certificat". Toutefois, le processus de cette tentative qui avait renouvelé le certificat, ayant avortée avant la fin, certaines opérations de déploiement n'ont pas été prise en compte et ton NAS indique certainement toujours la date de l'ancien certificat. Attention aussi au nombre de tentatives de renouvellement déjà effectuées pour la présente semaine ! Le max autorisé est de 5, au delà tu seras bloqué pour une semaine par LetsEncript. Donc utilises l'option "-f" avec parcimonie ... Cordialement oracle7😉 @TuringFan Bonjour Le script Python ne modifie pas le fichier account.conf, il ne fait que le lire par contre seul acme.sh lui le modifie. D'où ton erreur est franchement bizarre ... A moins que @bruno78 n'ai une idée ? Cordialement oracle7😉

@TuringFan Bonjour, Commence par vérifier que tu n'utilises pas de caractères "exotiques" dans ton Id et MdP. Regardes le contenu du fichier "/volume1/Certs/ndd.tld/ndd.tld.conf" et vérifie la cohérence des données. Tu devrais avoir notamment ces lignes : SAVED_SYNO_DID n'est présente que si tu as activé la double authentification SAVED_SYNO_Certificate ici est un exemple Tout cela couplé aux autres définitions de variables d'environnement contenues dans le fichier "/usr/local/share/acme.sh/account.conf" dont il te faut vérifier la cohérence. Cordialement oracle7😉

@TuringFan Bonjour Une fois connecté SSH sous root tu tapes simplement "python3 /volume1/Scripts/acme_renew.py -c ndd.tld" pour effectuer un nettoyage. Cordialement oracle7😉

@TuringFan Bonjour, Tu as dû relancer le processus à un moment ou un autre, je ne vois que cela comme explication en première approche. Normalement oui mais au cas où sauvegarde la clé. Normalement, ta connexion SSH avec PuTTY doit se faire avec le vrai 'root' et pas autre chose sinon tu auras d'autres problèmes. C'est expliqué dans le TUTO et cela été un des premiers problèmes découverts avec celui-ci. Cordialement oracle7😉

@TuringFan Bonjour Sauf erreur de ma part, à la vue du log acmelog, tu as mis le doigt dessus, le message est clair. Donc ton problème semble venir du fait que dans le processus de création du certificat, tu as dû omettre d'exporter la variable d'environnement OVH_CK (voir §3.2 du TUTO) : $ export OVH_CK="votre consumer key" Regardes dans le fichier "/usr/local/share/acme.sh/account.conf" où elle est normalement sauvegardée par le système, tu devrais avoir une ligne du type : où 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' est la clé 'Consumer Key' que tu as générée au § 3.1 du TUTO et que tu as normalement sauvegardée précieusement par ailleurs sur ton PC/Mac. S'il cette ligne n'existe pas, alors ajoutes là au fichier account.conf (attentionà la syntaxe : "simples cotes" et pas de guillemets !) et enregistres le fichier. Relances alors la procédure de renouvellement. Cordialement oracle7😉