Aller au contenu

Fredje_B

Membres
  • Compteur de contenus

    46
  • Inscription

  • Dernière visite

À propos de Fredje_B

Visiteurs récents du profil

Le bloc de visiteurs récents est désactivé et il n’est pas visible pour les autres utilisateurs.

Fredje_B's Achievements

Newbie

Newbie (1/14)

  • Week One Done
  • One Month Later
  • One Year In

Recent Badges

2

Réputation sur la communauté

  1. Par curiosité, puis je demander pour quel usage tu comptes améliorer les performances avec un cache SSD? Ayant moi même installé cela sur mon NAS, je ne remarque aucune différence de performance! Il n'y a que dans le cas ou plusieurs utilisateurs veulent lire/écrire sur les mêmes fichiers que cela apportera quelque chose...
  2. De mon coté, je n'arrive même pas à avoir le USB actif...j'ai installé les différents paquets mais il ne voit pas le contrôleur. Je pensais que c'était à cause de la Machine Virtuelle qui utilisait (et donc bloquait) le contrôleur USB, je l'ai dont désactivé sur la MV mais rien n'y fait. Je lance les commandes suivantes et obtient les messages suivant : service bluetooth start [ ok ] Starting bluetooth: bluetoothd. service bluetooth status [FAIL] bluetooth is not running ... failed! rfkill list Can't open RFKILL control device: No such file or directory Une idée pour me dépanner?
  3. J'ai pas mal chipoté avec les paramètres de MariaDB et le seul qui à un impact significatif est : innodb_flush_log_at_trx_commit = 2 à la place de 0. Je suis passé de 15s à 5s au benchmark! Par contre ca risque de flinguer l'intégrité de la DB en cas de crash pendant des opérations d'écritures...ce qui n'est pas anodin! Après je fait des backups journalier et j'ai un UPS qui permet de stopper sagement le système en cas de panne électrique. Voici ce que dit la doc sur ce paramètre : The default setting of 1 is required for full ACID compliance. Logs are written and flushed to disk at each transaction commit. With a setting of 0, logs are written and flushed to disk once per second. Transactions for which logs have not been flushed can be lost in a crash. With a setting of 2, logs are written after each transaction commit and flushed to disk once per second. Transactions for which logs have not been flushed can be lost in a crash. Par contre, j'ai aussi le problème de mémoire à 0% et même des processus qui ont été tué par le système par manque de mémoire : Aucune idée d'où ca vient surtout que la machine est fraichement installée et rien n'a été ajouté à Jeedom --> config complètement vanilla autrement dit!
  4. A voir car je me souviens qu'en étant passé de Docker à l'époque vers Virtual Machine que mes scénarios pour allumer et éteindre les lampes étaient beaucoup plus réactif, le jour et le nuit même. Je me souviens aussi qu'il y avait quelques paramètres à changer au niveau de MariDB pour gagner pas mal de temps, je vais replonger là-dedans demain. Au niveau du cache Redis, j'avais déjà essayé dans le temps sans jamais avoir su si ca apportait vraiment quelque chose...c'était du temps ou le benchmark Jeedom n'existait pas encore...
  5. Tout fonctionne parfaitement...j'ai fait un test de performance et c'est pire que ce que je ne le pensais...de 7s au benchmark Jeedom sur Virtual Machine, je passe à 15s sur Docker...je m'attendais à quelques secondes de différence mais pas au double! Je pense que je vais rester sur Virtual Machine pour les temps de réaction de Jeedom Je vais quand même voir pour optimiser le conteneur MariaDB qui est le gros goulot d'étranglement et voir pour mettre le cache dans un containeur Redis pour voir si ca améliore les choses...
  6. Dans le dépit des choses, j'ai repris cette option d'un précédents posts...le principal est que ca marche maintenant 😉 Merci pour ton aide, top!
  7. j'ai ca dans le fichier : nameserver 192.168.1.10 # PiHole options ndots:0 Oh purée, en relisant ce message, je m'aperçois de l'erreur...mon pi-hole est sur le 192.168.0.10! Je m'en vais changer cela
  8. Pas moyen d'accéder aux sites extérieure depuis le conteneur de Jeedom ce qui fait que je n'arrive pas à lancer les 3 commandes puisqu'il n'y a aucune résolution DNS...une idée pour me dépanner? Je suis connecté au serveur pi-hole depuis mon PC et la résolution DNS fonctionne bien....
  9. Bon pour la mise en oeuvre, ca sera pour demain matin quand la petite famille dort encore car ma box ne me permet pas de gérer le DHCP, je vais renseigner mon routeur local en DMZ de ma box et configurer le DHCP sur mon routeur local...ce qui signifie une interruption du réseau pendant quelques minutes et en ces temps de confinement, toute la famille est occupée sur internet à l'instant. Je ne voudrai pas que ca soit eux qui me tue à la place du virus... J'ai deux question (@bruno78) : J'ai déjà pas mal de serveurs configuré en adresse fixe mais dans la plage 0 à 99...je voudrai donc faire l'inverse de toi et déclarer la plage DHCP de 100 à 255 et garder mes serveurs sur la plage 0 à 99. Y a t'il un problème potentiel à cette approche? Je n'ai pas trop compris l'astuce du script au redémarrage du NAS...à quoi cela sert il exactement? Et surtout pourquoi y a t'il cette ligne dans ce script vu que tu n'as aucun serveur sur l'adresse 248 : "ip route add 192.168.1.248/29 dev bridgemacvlan"? Merci d'avance pour toute aide. Frederic
  10. Merci Bruno78 pour ce tutoriel très interessant! Ca me donne envie de faire passer mon Jeedom à nouveau sur un Docker plutôt que la Machine Virtuelle qui reste lourde pour le système. Le pire c'est que j'ai déjà un pi-hole en macvlan qui tourne et n'ai jamais pensé à y inclure Jeedom! Je vais tenter la manoeuvre et faire une vérification des performances de Jeedom...si il n'y a pas trop de perte (je ne m'attend pas à un gain), je convertirai certainement tout vers Docker.
  11. @PPJP : J'avoue que j'ai été un peu perdu au fil des threads entre le dernier script qui semblait fonctionner uniquement sur le NAS et cette version hybride qui cherche à fonctionner aussi bien sur les NAS que sur les Routeurs Synology. De ce que j'avais compris au sujet du script hybride, c'est que la partie NAS est systématiquement testée par vos soins et ce sont les forumeurs qui testent la partie Routeur. Cette version est pleine de commande écho pour débugger les différentes étapes (ce qui en passant, n'est pas plus mal pour consulter le log) mais de ce que je comprend, les blocages et autres commandes non reconnues ne s'appliquent pas à la partie NAS, elle me semble donc opérationnelle. C'est en tout cas ce que je peux constater chez moi grâce à la création du log (un grand merci au passage, je n'ai pas eu le réflexe du mode commande en ligne pour la création du log dans l'interface et suis un peu gêné maintenant d'avoir demandé cela 😞) Si ca ne vous dérange pas, je vais suivre les réponses de ce post ainsi que les mises à jour du script...tout en essayant de ne donner que des retours utiles si jamais je constate un problème à l'exécution du script (pour l'instant, encore une fois, cela tourne nickel sur mon NAS).
  12. Merci PPJP et Superthx pour ce merveilleux travail! Je viens de faire tourner le script sur mon NAS, la premiere fois en ssh et ensuite via le planificateur de tâches. 1er run, résultat : Error: no such table: Tmp IP dans table Tmp: Demarrage du script ./blacklisttest.sh version v0.5.1: Wed Oct 23 20:36:54 CEST 2019 Script implanté dans NAS Horodatage du blocage des IP: 1571855814 29223 IP téléchargées depuis le site lists.blocklist.de 9774 IP téléchargées depuis le site mariushosting.com Traitement d'une liste de 38472 adresses IP deblocage_ip maj_ip_connues maj_ip_connues_p1 maj_ip_connues_p2 insertion_nouvelles_ip data pour nouvelles IP import_nouvelles_ip insertion_nouvelles_ip_nas Le blocage de 0 IP a été prolongé 38472 nouvelles IP ont été ajoutées La liste de blocage mise à jour va bloquer 38472 IP Fin du script exécuté en 409 secondes Exécution en 10s ensuite via le planificateur de tâches, les dates ont bien été mises à jour et toujours le même nombre d'IP. Je n'ai par contre pas de retour via le planificateur de tâches...j'ai bien un fichier aniop.txt dans le répertoire où est installé le script mais seul une phrase comme quoi le script à été lancé est indiquée. J'ai demandé à ce que le résultat soit envoyé par email mais je n'en ai reçu aucun. Je vais garder à l'oeil le résultat dans la liste des sites bloqués plutôt que de me baser sur un mail. Merci encore une fois!
  13. Salut, J'ai été aussi dans la même situation que toi, mort du 1815+ et rachat d'un nouveau modèle...il suffit de mettre les disques dans le nouveau et de le démarrer...aucun soucis à se faire. L'ordre des disques n'importe même pas! Frederic
  14. Il n’y a rien de spécial a faire si ce n’est de mettre tout tes disques dans les nouvelles baies. L’ordre n’a meme pas d’importance!
  15. Merci pour le partage...c'est une fonctionnalité que je cherchais depuis un certain temps. Par contre, la méthode que tu décris ne fonctionne pas chez moi...j'obtiens une erreur au lancement de lighttpd qui me dit qu'il ne sais pas faire le mapping avec le port indiqué. J'ai suivis ce tuto (en Anglais) et ca fonctionne parfaitement! http://tonylawrence.com/posts/unix/synology/free-your-synology-ports/
×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.