This site uses cookies! Learn More

Ce site utilise des cookies !

En continuant à utiliser ce site, vous vous engagez à nous permettre de stocker des cookies sur votre ordinateur.

 

Si nous utilisons des cookies et retenons des données anonymes, c’est pour nous aider à mieux gérer notre mesure d’audience, aider nos partenaires commerciaux à nous rémunérer et nos partenaires publicitaires à proposer des annonces qui vous correspondent.

 

Grâce à ces cookies, le forum est en mesure de savoir qui écrit un message et utile pour le système d'authentification.

 

En cliquant sur « J'accepte », vous acceptez l'utilisation par NAS-Forum de cookies publicitaires et de mesure d'audience fine.

Lapin

Membres
  • Compteur de contenus

    560
  • Inscription

  • Dernière visite

  • Jours gagnés

    14

Lapin a gagné pour la dernière fois le 12 mai

Lapin a eu le contenu le plus aimé !

À propos de Lapin

  • Date de naissance 01/02/1975

Contact Methods

  • Website URL
    https://opentx-doc.fr/
  • ICQ
    0

Mon Profil

  • Sex
    Masculin
  • Pays / Ville
    France, Caen
  • Intérêts
    Modélisme, Informatique, Jeux vidéos
  • Mon NAS
    DS916+ / DS411+

Visiteurs récents du profil

4 311 visualisations du profil

Lapin's Achievements

Apprentice

Apprentice (3/14)

  • Conversation Starter Rare
  • Reacting Well Rare
  • First Post Rare
  • Collaborator Rare
  • Posting Machine Rare

Recent Badges

34

Réputation sur la communauté

  1. Je ne sais pas trop. En tout cas à forcer de faire des stop/start depuis l'app Docker dans le DSM Synology, cela a fini par fonctionner.
  2. Maintenant que tu le dis, de mémoire. cela a bien fonctionné sur le 1er (celui qui a fonctionné du 1er coup). Par contre, je crois avoir eu un comportement étrange sur le 2ème (celui qui a eu du mal se lancer). Il se pourrait bien que j'ai du changé le MDP depuis le GUI et qu'après redémarrage il affiche enfin les containers.
  3. Oui, je te confirme qu'il a fallu que je change le mot de passe.
  4. @MilesTEG1 Lorsque j'ai mis à jour vers la 2.13.0 sur les 2 NAS du boulot (même modèle, même version), j'ai eu le même problème que toi sur l'un des 2 NAS. C'était franchement étonnant de ne pas avoir le même comportement sur les 2. Après un (ou 2, je ne me souvien plus) stop/start sur le NAS concerné, l'interface est revenue. Avec la mise à jour 2.13.1, pas de souci. Cela a fonctionné du 1er coup sur les deux.
  5. Que ce soit long, c'est normal. Pour te donner une idée, j'ai fait un synchro de 4To entre 2NAS en local par Ethernet 1GB. Cela a mis 28h. Les synchro d'après ne durent que quelques minutes. Si un fichier est modifié pendant la synchro elle sera prise en compte lors de la prochaine synchro. Il y a un système de snapshoot sous Linux. Cela permet de figer un état précis le temps que la tâche en cours soit terminée.
  6. Oui, oui bien sûr. C'est normal en utilisant rsync.
  7. Très bonne remarque. Dans ma cas, la destination est un NAS DSM6. Donc, tout roule.
  8. Bon, pour ceux qui aurait le même problème que moi un jour, la solution est simple. Il ne faut pas utiliser le "rsync" de base. Il faut utiliser HyperBackup et choisir "Copie rsync (monoversion)". Cette option ne sauvegarde que la dernière version et ne compresse rien. L'avantage est que la sauvegarder est lisible directement. Pratique si la destination n'est pas un NAS Synology. En cochant la case "Activer la sauvegarde des métadonnées", cela fait parfaitement le boulot.
  9. Bonjour à tous, J'espère être dans le bon sous-forum. Je n'ai pas trouvé de topic dédié à rsync. Voilà mon problème bien pénible. J'ai 2 NAS. Mon vieux DS411+ (ressuscité après un changement de ventilo sur le CPU) sert de destination pour la sauvegarde local de mon 916+. HyperBackup est utilisé pour quasiment toutes mes tâches sauf pour certains dossiers (gros fichier de backup de plusieurs Go). J'ai créé, 4 tâches de synchro. Tout va bien pour les 3 premières, mais pour la 4ème j'ai un souci récurrent très très agaçant. La 1ère synchro fonctionne, mais les suivantes plantent systématiquement car rsync change les droits d'accès sur le dossier de destination sur mon DS411+. A chaque fois, je me prend une erreur "Sync error code 53". J'ai suivi cette procédure → How to fix Shared Folder Sync error code 53 Cela corrige le problème pour la prochaine syncho, mais ensuite le problème revient le jour d'après. C'est extrêmement agaçant et je n'ai pas trouvé de solution. Pour info, j'ai créé un utilisateur "rsync_back" avec les droits Admin sur mon DS411+. Et, bien évidemment, c'est l'utilisateur utilisé pour le test de connexion lors de la création de la tâche sur le DS916+. Bref, je suis un peu désespéré sur ce coup-là....
  10. Bonjour à tous, J'ai longtemps attendu pour passer de DSM6 à DSM7 car j'utilisais le package officiel SVN pour mes petits projets. Pour franchir le pas, il a fallu que je passe sur une solution SVN tournant sous Docker étant donné que le package officiel SVN Server n'est plus disponible sous DSM7. Donc, si votre NAS fonctionne avec Docker, voici un package qui fonctionne parfaitement (et qui est même mieux que l'ancien package officiel). → https://hub.docker.com/r/clamy54/svn-svnadmin Il y a même un tuto en Français expliquant la procédure à suivre ici: → https://www.be-root.com/2021/11/25/synology-et-serveur-svn/ Depuis la rédaction du tuto, le conteneur a un peu évolué. La variable TZ est maintenant prise en charge, et Python2 (via une variable d'environnement) ou Python3 (par défaut) sont nativement disponibles pour ceux utilisant des hooks. Bref, je recommande vivement ! C'est une solution parfaite. Comme point de départ, voici mon fichier de config docker compose. Mes hooks fonctionnent avec des scripts Python2. J'ai remappé le port HTTP sur le port 8082 et le port HTTPS sur le port 8083 version: "2.1" services: svnadmin : image: clamy54/svn-svnadmin:latest container_name: svnadmin environment: - TZ=Europe/Paris - DEFAULT_PYTHON=2 volumes: - /volume1/docker/svnadmin/hooks:/var/hooks - /volume1/docker/svnadmin/svn:/var/svn - /volume1/docker/svnadmin/apache2/keys:/etc/apache2/keys - /volume1/docker/svnadmin/apache2/dav_svn:/etc/apache2/dav_svn ports: - 8082:80 - 8083:443 restart: unless-stopped Une fois le transfert de votre(vos) repo(s) effectué et le conteneur lancé, vous pourrez accéder à l'interface SVNAdmin ici → http://IP_DE_VOTRE_NAS:8082 Depuis cette interface vous pourrez alors tout gérer, créer les utilisateurs autorisés à accéder à votre(vos) repo(s) SVN, créer de nouveau repo, gérer les groupes, les permissions d'accès, etc... Elle est pas belle la vie ?!?
  11. J'ai pas mal "joué" avec Portainer hier soir. Effectivement, c'est super méga pratique une fois passé l'apprentissage de l'interface. Interface qui est très jolie et rapide, mais pas super "user friendly". En plus, c'est super léger à faire tourner. Merci d'avoir insisté. Finalement je l'adopte sans réserve. De plus, j'ai découvert que le bouton "stack" permettait de lancer 2 conteneurs (ou plus) dans une seule config liée. Dans ce cas "l'empilement" prend tout son sens. Et cela simplifie les mises à jour. La mise à jour d'un conteneur est un vrai régal. Un bouton à cliquer, un inter à commuter et c'est fait ! Pour l’accès à distance, je n'ai pas encore décidé ce que je voulais faire. Je pense que je n'ai pas intérêt à exposer Portainer sur le Web. Au pire, je peux toujours me connecter sur l'interface DSM si j'ai besoin de faire une manip basic à distance. Si je partais sur une solution simple (https DSM Proxy Reverse) avec un mot de passe super fort et un identifiant administrateur autre que les classiques admin/root, je ne pense pas prendre de gros risques. OK, je n'aurais pas de 2FA, mais faut déjà qu'un éventuel hacker arrive à choper mon nom de DNS, mon identifiant admin et le bon port avant de pouvoir tenter de craquer mon mot de passe. A moins que l'interface Web Portainer soit une passoire sensible à des attaques (ex: backdoor)... Mais dans cette hypothèse là, seule une connexion VPN serait fiable. Tout autre solution se heurterait au même problème.
  12. Lapin

    [TUTO] Docker : Introduction

    Encore merci pour tes bons conseils. Comme tu as dû le lire dans l'autre topic, j'ai commencé à tester Portainer. Je ne vais pas polluer ce topic.
  13. Je regarde un peu Portainer. Finalement, c'est vraiment simple à installer et cela permet d'utiliser des fichiers YAML directement depuis un GUI. Et ça, c'est vraiment tip-top une fois que l'on a compris. Par contre, il va falloir que je potasse quelques vidéos, car je trouve l'interface assez complexe et pas très ergonomie. PS: dans ton tuto, le lien de l'image n'est plus correct. Maintenant c'est : portainer/portainer-ce Sinon, j'ai pas encore sécurisé le tout. Je me demande si un Proxy reverse avec un mot de passe très complexe (j'utilise BitWarden) est suffisant.... D'un autre côté, je ne suis pas sûr d'avoir besoin d'accéder à Portainer depuis l'interface WAN. Je me tâte.
  14. Lapin

    [TUTO] Docker : Introduction

    Un grand merci pour toutes ces explications. Je viens de me rendre compte/comprendre que le GUI docker sous DSM n'était qu'un wrapper graphique. Mais que, derrière, ce sont bien les "vraies" commandes Linux qui sont exécutées. Donc, qu'un conteneur soit créé par le GUI DSM, par SSH, par composer ou par Portainer, cela reste un setup Linux qui va résister à toutes mises à jour. J'ai tout bon ? C'est bien plus clair dans ma tête maintenant. Merci. NB: j'ai juste paraphrasé ce que tu m'as expliqué. C'est pour être sûr à 100% que j'ai bien compris. Concernant Portainer, j'ai déjà regardé. J'ai même testé leur site de demo. Et j'avoue que j'étais complètement perdu. J'ai trouvé qu'il y avait trop de boutons pour un usage aussi basic que le mien. Mais bon, il n'y a que les imbéciles qui ne changent pas d'avis. Je vais lire ton tuto avec beaucoup d'attention.
  15. Lapin

    [TUTO] Docker : Introduction

    C'est bien la moindre des choses !! J'ai un petit site consacré à un firmware de radio (pour le modélisme) et je sais que les remerciements est le carburant minimum pour rester motiver à faire de nouveaux tutos. Oui, je confirme. Et cela parait normal. Je ne voie pas comment il pourrait avoir toutes les infos sans accéder au socket Docker. Merci pour la confirmation. Cela correspond bien à mes tests sur l'installation de mon domicile. Merci ! Sur ce point là, j'aurais 2 questions: 1- Est-ce qu'un conteneur monté par SSH résiste à une mise à jour DSM ? Ou seul, les conteneurs faire par le GUI Synology sont immunes aux mises à jour ? 2- En passant par Docker-compose, cela à rendu visible le conteneur sous le GUI Synology. Du coup, je peux tout faire: start/stop/ouvrir un terminal/afficher le log. Donc, pourquoi faire une tâche supplémentaire pour arrêter le conteneur DIUN ? Y aurait-il une subtilité qui m'aurait échappée ? Ça, c'est moche. En clair, seules les notifs "natives" à la couche Docker Syno sont remontées. J'avais espoir qu'il soit possible de remonter des push à travers la couche "Docker Synology". J'ai vu qu'il y avait des histoire de MetaData, mais là cela me dépasse pour l'instant. Dans tous les cas, j'ai hâte de lire tes tutos sur Docker Compose. Je suis sûr que cela va être fort instructif. Je trouve que tu arrives à super bien vulgariser des sujets complexes pour les non-initiés.