Classement

Bonjour, Le topic originel https://www.nas-forum.com/forum/topic/37274-fichier-host-1fichier-host-file-1fichier/ n'étant plus mis à jour par son auteur @Souli, il m'a été demandé de créer un nouveau topic pour retrouver plus facilement l'information. J'ai l'intention de maintenir ce fichier host si certains rencontrent des bugs, donc n'hésitez pas à me poser des questions. Si je ne répond pas sur le forum je suis aussi disponible par email, et mon email est indiqué sur mon compte github. L'ensemble du code est donc disponible sur un repo github : https://github.com/Gizmo091/synology_1fichier_hosting Lient de téléchargement du module premium + access ( utilisant la clé d'api ) 2025-10-07 - 4.6.0 : https://github.com/Gizmo091/synology_1fichier_hosting/raw/refs/heads/main/OneFichierCom(4.6.0).host Changelogs : - 4.6.0 : L’URL du fichier "verify" sur 1fichier, utilisée pour vérifier le bon fonctionnement de la connexion, est récupérée depuis le dépôt GitHub. Comme je n’ai plus de compte premium, cette URL est susceptible de changer régulièrement. - 4.5.0 : Mise en place d'un coutournement lorsque la recuperation du nom du fichier par l'api est impossible - 4.4.0 : Suppression du controle du certificats SSL sur les appels à l'API - 4.3.0 : Définition du nom du fichier de destination dans les informations retournées au DL Station ( evite par exemple les _ indésirables ) - 4.2.0 : Prise en compte des liens avec un token de téléchargement : exemple : https://a-6.1fichier.com/p1058755667 - 4.1.0 : Le endpoint Account : Show n'est plus utilisé pour valider que la clé d'API peut être utilisée , on test plutot sur un fichier dont on connait l'existance (fichier sur mon compte) - 4.0.7 : Code rendu compatible à partir de php 5.6 pour être pleinement rétrocompatible. - 4.0.7 : Code rendu compatible à partir de php 5.6 pour être pleinement rétrocompatible. - 4.0.6 : Correction d'un problème si pas de paramètre passé à la place de l'username et correction d'un problème avec les logs - 4.0.5 : Le code est maintenant compatible php7 (des fonctionnements de php8 avait été inclus auparavant) - 4.0.4 : Ajout de la possibilité d'envoyer les logs sur un serveur externe (pour aider au debug) - 4.0.2 : Ajout de logs pour debugger - 4.0.1 : Utilisation du password pour l'apikey et non l'username - 4.0.0 : Attention, version utilisant l'API donc reservé au premium/access Problèmes connus : - [Corrigé depuis la 4.1.0] Le fait de verifier les identifants retourne parfois une erreur, si vous êtes sur de votre clé d'api, ignorez cette erreur. L'API de 1fichier peut parfois être capricieuse et leur politique de controle des requetes faites à l'API est un peut trop restrictive. L'API retourne alors une erreur de flood meme avec très peu de requete. - Conflit avec alldrebrid : La version 4.3.0 ( et peut être d'autre) du host de alldebrid fait echouter le chargement des fichiers host des autres provider. ( je ne sais pas pourquoi mais je l'ai constaté ). - Verification du login : Depuis le 10 octobre 2025, je n’ai plus de compte premium. Par conséquent, je dois régulièrement télécharger un fichier sur 1fichier et mettre à jour le lien dans le dépôt GitHub pour que la vérification des identifiants fonctionne. Une erreur peut survenir lors de la vérification, mais si vous êtes sûr de votre clé API, les téléchargements ne devraient pas être affectés. Support : Soit sur le forum, soit sur Discord : gizmo091 Informations : - Ce fichier host se configure de la facon suivante : nom d'utilisateur : ce que vous voulez ( mais il ne faut pas que ce soit vide), peut contenir des variables de configurations password : votre apikey , récupérable sur le site de 1fichier : https://1fichier.com/console/params.pl section API Key. Notez la bien car elle ne sera plus visible par la suite, il faudra alors la desactivé et en générer une nouvelle si vous devez la saisir à nouveau. Configurations addionnelles : Le champ username/nom d'utilisateur peut donc contenir un ou plusieur configuration. Elle doivent être saisies de la façon suivante : <parametre1>=<valeur_param1>;<parametre2>=<valeur_param2>;... Paramètres disponibles : - local_log : activable en ajoutant local_log=1 dans le champ username Les fichiers de logs seront écrits dans le répertoire /tmp/1fichier_dot_com , un fichier sera créer par téléchargement avec l'id du lien ( exemple : lien = https://1fichier.com/?kitiwlyogv8uozsnfi&af=3108529, fichier de log = /tmp/1fichier_dot_com/kitiwlyogv8uozsnfi.log ) , si par d'identifiant dans le fichier sera /tmp/1fichier_dot_com/default.log Exemple avec local_log d'activé : - remote_log : activable en ajoutant remote_log=<serveur_de_log> dans le champ username. Les logs seront envoyé au serveur passé en paramètres via des requetes cURL. Vous pouvez heberger votre propre serveur de log en utilisant le code se trouvant dans le repertoire remote_log du repository git, ou alors vous pouvez utiliser mon serveur : https://vedie.fr/remote_log/log.php et vous pouvez consulter les logs ici : https://vedie.fr/remote_log/read.php Exemple avec remote_log d'activé : Hashtags : hostfile, host file, onefichier

Bonjour à tous, Nous allons voir dans ce tutoriel comment mettre en place rapidement un certificat Let's Encrypt avec la méthode acme.sh en utilisant l'api Ovh en Docker, si vous êtes rapide, en 10 minutes c'est en place. Pourquoi en docker ? Car je suis contre la pollution du DSM, des corruptions par update, mais aussi par simplicité et rapidité. 1) On commence par la création de clé d'api chez ovh : https://api.ovh.com/createToken/?GET=/domain/zone/mydomain.com/*&POST=/domain/zone/mydomain.com/*&PUT=/domain/zone/mydomain.com/*&GET=/domain/zone/mydomain.com&DELETE=/domain/zone/mydomain.com/record/* On remplit donc le formulaire, pour "Validity" (1) on choisit "Unlimited", pour "Rights" (2) on remplace dans les champs "mydomain.com" par le vôtre et dans "Restricted IPs" (3), on rajoute son IP afin qu'en cas de vol des clés, elles ne puissent être exploitées et votre domaine détourné. (NB : Si vous n'avez pas une IP fixe, on passe ce dernier point) On garde les clés retournées en résultat sous la main pour la suite. 2) Passons maintenant au docker : A) On commence par la création d'un dossier "Acme" dans le dossier docker. B) La création du fichier de config : On crée avec l'éditeur de texte du DSM (Codage UTF-8) le fichier "account.conf" à la racine de notre dossier "Acme" contenant : LOG_FILE="/acme.sh/acme.sh.log" LOG_LEVEL=1 AUTO_UPGRADE='1' #NO_TIMESTAMP=1 USER_PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' SAVED_OVH_AK='XXXXXXX' SAVED_OVH_AS='XXXXXXX' SAVED_OVH_CK='XXXXXXX' DEFAULT_ACME_SERVER='https://acme-v02.api.letsencrypt.org/directory' On remplace dedans le contenu des 3 variables "SAVED_OVH_**" par nos clés obtenues précédemment par OVH. C) La création du docker : On va mettre un petit peu de code pour la création du docker et son actualisation journalière via le gestionnaire de tâche... Panneau de configuration / Planificateur de tâches / Créer / Tâche planifiée / Script défini par l'utilisateur Utilisateur : Root On programme pour une exécution par jour la nuit (5h c'est bien) Exécuter la commande : docker pull neilpang/acme.sh:latest docker stop Acme docker rm Acme docker image prune -f docker volume ls -qf dangling=true | xargs -r docker volume rm docker run -d --cpu-shares=10 --memory=134217728 --name=Acme -v /volume1/docker/Acme:/acme.sh:rw --restart unless-stopped neilpang/acme.sh:latest daemon On exécute manuellement la tâche une première fois pour la création du docker. C Bis) Le docker-compose.yml : version: "2.1" services: acme: cpu_shares: 10 mem_limit: 128M container_name: Acme network_mode: bridge labels: - com.centurylinklabs.watchtower.enable=true volumes: - /volume1/docker/Acme:/acme.sh:rw restart: unless-stopped image: neilpang/acme.sh:latest command: daemon D) Création du certificat : Avec le planificateur de tâche en exécution unique (cf point 2C) ou en ssh (root) en remplaçant "mydomain.com" : docker exec Acme sh -c "acme.sh --issue --keylength 4096 -d 'mydomain.com' -d '*.mydomain.com' --dns dns_ovh" Il n'y a rien à détailler pour expliquer cette commande, le keylenght peut être, on double la valeur par défaut qui est aujourd'hui considérée comme faible à 2048. /!\ Renouvellement automatique du certificat sans action de votre part 3) Installation des certificats : A) Importation manuel : Vos certificats seront disponibles directement dans filestation "docker/Acme/votredomaine" et ce qui nous intéresse dedans : Certificat : mydomain.com.cer Clé privée : mydomain.com.key Certificat intermédiaire : ca.cer On va maintenant faire leur import manuellement, dans "Panneau de configuration/Sécurité/Certificat". En cas d'import manuel, vous pouvez activer la notification mail, mais cette action se réalise toujours 1 mois avant expiration : https://github.com/acmesh-official/acme.sh/wiki/notify B) Déploiement automatique : NB : Faire un premier déploiement manuel avant le déploiement automatique, afin de bien le mettre par défaut et supprimer celui de synology par défaut. 1) Création d'un compte que l'on rajoutera dans le groupe admin, on lui mettra aucun acces à tous les dossiers et refuser à toutes les applications, on active pas la double authentification qui sera inutile. 2) On ré édite notre fichier "account.conf" créé au point 2B, on y rajoute : SAVED_SYNO_Scheme='http' SAVED_SYNO_Hostname='172.17.0.1' SAVED_SYNO_Port='5000' SAVED_SYNO_Username='nom utilisateur' SAVED_SYNO_Password='le password' SAVED_SYNO_DID='' SAVED_SYNO_Certificate='description du certificat mise dans le DSM' 3) Ensuite une fois les modifications faites, avec le planificateur de tâche en exécution unique (Cf point 2C) ou en ssh (root) : docker exec Acme sh -c "acme.sh --deploy -d 'mydomain.com' --deploy-hook synology_dsm" Guide officiel : https://github.com/acmesh-official/acme.sh/wiki/Synology-NAS-Guide Pour d'autres API que ovh : https://github.com/acmesh-official/acme.sh/wiki/dnsapi 😉

Bonjour, Quelqu'un aurait-il un lien pour télécharger un fichier host (download station) pour le site Updloady.io s'il vous plait ? Ou un tuto sur comment en créer un ? J'ai vu sur Google qu'il y avait un topic à ce sujet sur le forum mais je n'y ai pas accès : https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://www.nas-forum.com/forum/topic/81968-fichier-host-pour-uploadyio/%3Fdo%3DfindComment%26comment%3D1319513384&ved=2ahUKEwiKuK_mrpWLAxXZ3AIHHQ3lJ0gQFnoECAcQAQ&usg=AOvVaw1KQ-cOebOdNKcHwwUFaVT8 Merci d'avance

Refonte du tutoriel pour la V6, amélioration du fichier compose et mise à jour des impressions d'écran.

Importante mise à jour qui vient de sortir : MàJ faites sur DS220+ et DS218+.

Bonjour, Je viens de voir que dsm 7.3 est en vue. Ce sera la dernière mise à jour pour mon DS 218+ 😞

Autre solution : en IPv6, chaque NAS a sa propre adresse IP publique, et est donc adressable sans souci, sur tous les ports.

Salut @.Shad., Le problème avec les serveurs DNS c'est que leur hiérarchie n'est pas respectée. Le client peut faire appel à n'importe quel serveur de la liste. Si le DHCP distribue plusieurs IP DNS, il vaut mieux que ces serveurs résolvent les requêtes de la même manière. Je suis plutôt pour une deuxième instance pi-hole (ce que j'ai), ou bien à la limite passer par le serveur DNS du NAS avec une zone correctement paramétrée. Surtout pas d'autres serveurs externes qui sont incapables de résoudre les adresses locales.

Hello, j'ai aussi fait la migration il y a quelques semaines et ça s'est très bien passé. Je vais essayer de trouver le temps de mettre à jour le tutoriel, je devrais retrouver des disponibilités à partir de fin juin...

cd /volume1/@appdata Un simple cd / est plus efficace.

Il y a aussi Domoticz que j'utilise sur un Rasp PI4. A mon avis, que ce soit home assistant, jeedom ou domoticz ou d'autres, mieux vaut ne pas solliciter le NAS pour ces applications qui sont en général nativement adaptées et parfaitement intégrées sur des plateformes type Rasp.

Par défaut, un paquet WoL n'est diffusé que sur le segment réseau de l'émetteur. Dans le cas présent, le smartphone n'émet ce paquet que sur le réseau 192.168.68.0/24 (broadcast à destination de 192.168.68.255 ou 255.255.255.255). Le paquet ne peut donc pas parvenir au NAS situé sur un autre segment (192.168.1.0/24). Il est très peu probable que le routeur Mesh propose un proxy WoL pour propager la diffusion du paquet sur les autres segments qui y sont connectés. La solution la plus simple est de connecter le NAS derrière le routeur mesh (attention au changement d'adressage IP). La solution la plus propre est de configurer un unique segment réseau en configurant les appareils réseau du réseau mesh en points d'accès Wi-Fi.

Bonjour, Je n'ai pas tout compris...

Re-bonjour, J'ai trouvé ma réponse : mon mot de passe contient des caractères spéciaux dont la saisie est mal interprétée dans drive client ubuntu. En saisissant le mot de passe dans un éditeur quelconque, puis en le copiant dans le mot de passe de la connexion drive client, Ö miracle, ca fonctionne. bien à vous

Attention toutefois, dans le tuto donné par @firlin, la résistance est à 100ohm. Il faut remplacer cette valeur par 300ohm environ pour limiter le courant dans le transistor (voir ce fil de discussion)

@Sun880 Tu es mal placé pour faire le malin... De plus tu as posté dans une autre rubrique la même question à 2 reprises. Je te laisse une semaine de vacances pour t'approprier le fonctionnement du forum

Tout est vendu !

Click droit sur la touche Windows et lancer l'application Terminal suffit. Puis faire la commande : K.I.S.S.

Donne-moi un seul cas d'usage où un débit >1Gbps sur internet est nécessaire sur ton NAS.

J'ai repris la configuration de sécurité : et cela a visiblement corrigé mon problème...

J'ouvre de nouveau ce sujet pour vous donner des nouvelles. Apple a reconnu un souci avec la gestion des codes OTP sur des machines ayant le même suffixe DNS (ce qui est le cas si l'on utilise plusieurs NAS dont le nom est fournir par le DDNS de Synology). Ce problème est inexistant avec les clé d'accès. J'attends des nouvelles la semaine prochaine… A suivre ...

Bonjour à tous, Après une installation réussi hier soir de Bitwarden, je viens vous proposer un petit tuto pour l'installer. Tout d'abord, Bitwarden, qu'es ce que c'est ? Bitwarden est une application Open Source développer en C# et MSSQL (j'y reviendrais) qui permet de gérer ses mots de passe à la manière de 1Password, Lastpast, Keepass. Des extensions sont disponibles pour tout les navigateurs et iOS/Android. Vous aller me dire tout ça c'est bien joli mais quel intérêt ? L’intérêt, c'est qu'il est possible de s'auto héberger et donc d'avoir son propre gestionnaire de mot de passe à la maison sans passer par des serveurs bien plus exposé sur internet. Vous êtes toujours partant ? En premier lieu, quelque pré-requis : - Disposer d'un NAS sous architecture x86 (Intel) tout simplement car l'installation est réalisé avec Docker - Disposer de pas mal de RAM, l'application exécute une instance Microsoft SQL Server (très) gourmande en RAM (environ 700Mo, une version Ruby beaucoup plus légère existe mais c'est une adaptation et non une vrai branche) - Ne pas avoir peur de faire un peu de ligne de commande ? Vous êtes toujours là ? Allons y vous aller voir c'est très simple. Merci @InfoYANN pour avoir refait toute le tuto avec les dernières version de Bitwarden ! ***************************************************** Créer un dossier "bitwarden" dans le dossier "docker" dans FileStation. Créer un sous domaine pour votre instance bitwarden et faites en sorte que le certificat SSL de Let's Encrypt soit fonctionnel (rien à faire pour les certificats wildcard). Aller sur le site de Bitwarden afin d'obtenir un ID : https://bitwarden.com/host Entrer une adresse mail valide et copier : ID d'installation : xxxxxxxxxxxxxxxxxxxxxxxxxxxxx Clé d'installation : xxxxxxxxxxxxxxx Maintenant connecter vous en SSH (voir mon tuto si vous ne savez pas faire). Rendez-vous ici : cd /volumeX/docker/bitwarden Nous allons maintenant récupérer le script d'installation et le mettre dans le dossier bitwarden fraichement créé : curl -s -o bitwarden.sh https://raw.githubusercontent.com/bitwarden/core/master/scripts/bitwarden.sh&& sudo chmod u+x bitwarden.sh Puis on lance l'installation : ./bitwarden.sh install Pendant l'installation, nous allons devoir répondre à quelques questions (moins qu'auparavant) : *Les lignes en rouge seront les messages du système au fur et à mesure de l'installation ! (!) Enter the domain name for your Bitwarden instance (ex. bitwarden.company.com): sousdomaine.domaine.tld (!) Do you want to use Let's Encrypt to generate a free SSL certificate? (y/n): n (!) Enter your installation id (get at https://bitwarden.com/host): xxxxxxxxxxxxxx (!) Enter your installation key: xxxxxxxxxxxxx (!) Do you have a SSL certificate to use? (y/n): y !!!!!!!!!! NOTE !!!!!!!!!! Make sure 'certificate.crt' and 'private.key' are provided in the appropriate directory before running 'start' (see docs for info). (!) Is this a trusted SSL certificate (requires ca.crt, see docs)? (y/n): y Installation complete If you need to make additional configuration changes, you can modify the settings in `./bwdata/config.yml` and then run: `./bitwarden.sh rebuild` or `./bitwarden.sh update` Next steps, run: `./bitwarden.sh start` and then `./bitwarden.sh updatedb` Rendez-vous dans FileStation mais ne fermez pas votre fenêtre SSH. Nous allons renommer et copier les fichiers du certificat SSL dans le bon dossier : Renommer le fichier "privkey.pem" avec comme nom "private.key" puis le copier dans /volumeX/docker/bitwarden/bwdata/ssl/votredomaine/ ce qui donnera comme résultat : /volumeX/docker/bitwarden/bwdata/ssl/votredomaine/private.key Renommer le fichier "cert.pem" avec comme nom "certificate.crt" puis le copier dans /volumeX/docker/bitwarden/bwdata/ssl/votredomaine/ ce qui donnera comme résultat : /volumeX/docker/bitwarden/bwdata/ssl/votredomaine/certificate.crt Renommer le fichier "chain.pem" avec comme nom "ca.crt" puis le copier dans /volumeX/docker/bitwarden/bwdata/ssl/votredomaine/ ce qui donnera comme résultat : /volumeX/docker/bitwarden/bwdata/ssl/votredomaine/ca.crt Nous allons maintenant créer les dossiers qui seront manquants pour la suite de l'installation : /volumeX/docker/bitwarden/bwdata/logs /volumeX/docker/bitwarden/bwdata/logs/admin /volumeX/docker/bitwarden/bwdata/logs/api /volumeX/docker/bitwarden/bwdata/logs/icons /volumeX/docker/bitwarden/bwdata/logs/identity /volumeX/docker/bitwarden/bwdata/logs/mssql /volumeX/docker/bitwarden/bwdata/logs/nginx /volumeX/docker/bitwarden/bwdata/logs/notifications /volumeX/docker/bitwarden/bwdata/logs/events /volumeX/docker/bitwarden/bwdata/core /volumeX/docker/bitwarden/bwdata/core/attachments /volumeX/docker/bitwarden/bwdata/mssql /volumeX/docker/bitwarden/bwdata/mssql/data /volumeX/docker/bitwarden/bwdata/mssql/backups Nous allons éditer le fichier "global.override.env" qui se trouve dans "/volumex/docker/bitwarden/bwdata/env" afin de configurer le serveur SMTP pour que Bitwarden puisse envoyer les notifications. On va en profiter pour inscrire notre adresse mail pour la partie admin 😉 Il faut maintenant finir de configurer manuellement le fichier "config.yml" qui se trouve dans "/volumex/docker/bitwarden/bwdata" : Par défaut, les ports sont 80 et 443 mais en général, ils sont déjà utilisés sur DSM alors on va en mettre d'autres. Pour ma part, j'ai choisi le port 81 et 444. On retourne dans notre fenêtre SSH et on lance ensuite ces commandes une par une : ./bitwarden.sh update ./bitwarden.sh updatedb ./bitwarden.sh start Si ces commandes ne fonctionnent pas, faites d'abord : ./bitwarden.sh rebuild Vous pouvez maintenant accéder à votre instance Bitwarden via votre domaine : le port. Source : http://www.synology-forum.de/showthread.html?90435-Bitwarden-auf-der-Synology-(Docker)/page5 En complément, dans le dossier env (éditable via vi pour les plus aguerris) vous pouvez paramétrer le SMTP (pour l'envoi des mails) et bloquer les inscriptions supplémentaires sur votre serveur ci nécessaire.