-
Compteur de contenus
6648 -
Inscription
-
Dernière visite
-
Jours gagnés
150
Tout ce qui a été posté par .Shad.
-
DNS Server c'est une interface pour BIND, avec des fonctionnalités en moins. Après si tu te sers de DNS Server juste pour une zone locale, autant basculer tes enregistrements sur Adguard qui possède cette fonctionnalité si je ne m'abuse. SWAG c'est prévu pour Docker, Adguard pas forcément, ça c'est à toi de voir, j'aime bien le côté libre de dépendances sur l'hôte avec Docker.
-
Ma suggestion était de mettre juste SWAG, mais rien ne t'empêche de mettre Adguard aussi. DNS Server tu vas avoir du mal c'est un paquet DSM. Ca consomme rien ces applications là, les données ne transiteront pas par le PI non plus. Je disais ça dans le cas où tu ne le gardais pas.
-
Parce que tu essaies d'accéder à un chemin du NAS depuis le conteneur. Lui volume1 etc... il ne connaît pas. Par contre, quand tu as créé le conteneur, tu as lié un dossier du NAS (...tv.m3u) à /etc/xteve, donc c'est ce chemin-là que tu dois utiliser.
-
C'est effectivement une solution, pas idéale selon moi du fait de la double définition, pour le local et à distance. Si tu n'utilises que SWAG comme proxy inversé, tu devras effectivement utiliser deux adresses différentes : https://subdomain.ndd.tld depuis l'extérieur https://subdomain.ndd.tld:4443 en interne C'est là que le macvlan s'illustre, car tu peux utiliser le 443 dans les deux cas, et donc utiliser les mêmes liens. Pour être précis sur les termes, SWAG n'aura pas une IP virtuelle, il aura une IP dans la plage d'attribution du réseau macvlan, qui se trouve en dehors de la plage de ton serveur DHCP (box ou routeur). C'est le NAS qui aura une IP virtuelle, une porte d'entrée par laquelle SWAG et tout autre conteneur sur le réseau macvlan pourra y accéder. Il faudra que ta zone DNS locale fasse effectivement pointer les entrées de proxy inversé vers l'IP de SWAG. Et ta box/routeur devra rediriger 80 et 443 vers l'IP de SWAG également. Tu peux toujours garder le proxy inversé interne dans un premier temps, le temps de s'assurer que tout fonctionne comme tu l'entends. Après, si tu as un Rpi de côté, c'est bien plus simple à gérer en bridge qu'en macvlan sur le NAS. 😉
-
On peut raisonnablement penser que si tu te connectes en 2FA avec un périphérique, tu peux accéder à tous les autres sites nécessitant le même niveau de sécurité, ça ne me choque pas. Sinon dans la partie session, tu peux ajuster la durée du cookie d'authentification, etc... Oui c'est root c'est normal.
-
Oui, c'est un bête fichier, auquel tu essaies par contre d'appliquer des permissions strictes, ça évite d'avoir le mot de passe dans le fichier de configuration directement. Comme pour les autres secrets en fait. 😉
-
Salut, Peux-tu déplacer ce sujet dans la section Docker, et présenter ta demande sous la forme proposée ici :
-
Salut, Chez moi pas de souci : Tu peux : vérifier qu'il n'y a pas une tabulation parasite au niveau du champ password vérifier que le chemin indiqué pour AUTHELIA_NOTIFIER_SMTP_PASSWORD_FILE est le bon dans le fichier compose. vérifier que les droits en lecture sont OK https://www.authelia.com/docs/configuration/session/ A priori c'est au niveau du paramètre samesite que tu règles ça. Par défaut c'est le fonctionnement normal.
-
Le but c'est généralement juste de connaître ton niveau et matos. On a tout ce qu'il nous faut. 😉
-
C'est étrange parce que chez moi dans geoip2.conf j'ai le même contenu. Bref tant mieux si c'est résolu. 😎
-
Dans ce cas-là je n'ai pas de solution à te proposer, peut-être quelqu'un d'autre.
-
Alors dans l'absolu ça peut marcher effectivement, le souci que tu peux rencontrer c'est qu'en faisant ça, littéralement c'est un utilisateur 1027:65536 qui va exécuter Grafana à l'intérieur du conteneur. Si un script ou une commande avait par exemple pour permissions : -rwxr-xr-- root root script.sh Tu serais incapable de l'exécuter. Par contre, Telegraf a été récemment mis à jour pour être exécuté avec un utilisateur non-root, du coup tu peux être certain que l'image va gérer les permissions comme il faut, et que par exemple 1027:65536 sera capable de faire ce qu'il a à faire au sein du conteneur. A ma connaissance, Grafana s'exécute par défaut avec l'utilisateur root.
- 1445 réponses
-
- snmp
- monitoring
-
(et 1 en plus)
Étiqueté avec :
-
Ca je reconnais qu'il y a beaucoup de changements en ce moment + InfluxDB 2.0 qui vise apparemment à se passer de Grafana.
- 1445 réponses
-
- snmp
- monitoring
-
(et 1 en plus)
Étiqueté avec :
-
Il est beaucoup moins risqué de changer le groupe que de modifier les permissions. Les groupes sont utilisables à cet effet sous Linux, la preuve avec le socket graphique utilisé entre autre pour le transcodage Plex/Emby/etc... : ls -l /dev/dri crw------- 1 root root 226, 0 Sep 29 19:09 card0 crw-rw---- 1 root videodriver 226, 128 Sep 29 19:09 renderD128 C'est un changement suite au passage à DSM7, et c'est beaucoup plus logique ainsi. Pour la commande : chown root:nom_du_groupe_docker /var/run/docker.sock Il faut que ton groupe docker, quelque soit son nom, ait accès au dossier partagé docker via la permissions de groupe. Et ajouter l'utilisateur qui fait tourner Telegraf à ce groupe. C'est l'objet de mon message juste avant le tien (la deuxième partie), pour l'instant je reste en 1.20.4 car j'ai les mêmes erreurs. Si tu abandonnes, abandonne pour les bonnes raisons, parce que tu ne t'en sers pas, parce que tu n'oses pas passer sur la version d'InfluxDB, etc... Pas parce que tu n'arrives pas à le faire fonctionner. 😄
- 1445 réponses
-
- snmp
- monitoring
-
(et 1 en plus)
Étiqueté avec :
-
Ah ok, alors à ma connaissance non ça n'existe pas. Ce que tu pourrais peut-être faire c'est avoir par exemple 2 dossiers par utilisateur, un en lecture seule et un en lecture/écriture. Sur celui en lecture seule, pas de quota, celui en lecture/écriture, tu mets le quota voulu. Chaque jour, dans la nuit par exemple, tu fais tourner un script qui déplace les données vers le dossier en lecture seule, ce qui viderait le dossier en lecture/écriture, prêt pour une autre journée d'utilisation. C'est du bricolage hein, mais je pense que tu ne trouveras pas de solution out-of-the-box pour ce que tu souhaites faire.
-
@CHILLY996 Okkkk, j'ai été curieux suite à tes messages, en investiguant dans les commits voici ce que j'ai trouvé : https://github.com/linuxserver/docker-swag/commits/master/root/defaults/geoip2.conf Maxmind est devenu un docker-mod de Linuxserver, et donc par conséquent ce n'est plus actif avec notre configuration actuelle. Du coup, il faut suivre la procédure décrite ici, c'est sensiblement ce qui existait avant, on modifie juste le nom du fichier de configuration : https://github.com/linuxserver/docker-mods/tree/swag-maxmind Ca leur permet aussi d'alléger leurs images et de fonctionner de manière modulaire. Donc : Ajouter le docker-mod dans le fichier compose Remplacer geoip2.conf par maxmind.conf dans nginx.conf Renommer geoip2.conf en maxmind.conf Vérifier que les appels dans les fichiers de configuration des proxy inversés pointent bien vers maxmind.conf et pas geoip2.conf Redémarrer le conteneur J'ai vérifié que ça fonctionnait bien en interdisant l'accès depuis mon pays et j'ai bien l'erreur 403 que je demande.
-
J'aurai du mal à te dire si j'ai créé ou pas ce groupe docker, je n'ai jamais remis à zéro mes NAS donc ça remonte à 2017. Tu peux vérifier via : cat /etc/group | grep docker Autrement, contrairement à @oracle7 et pareillement à @Jeff777, mon conteneur telegraf ne fonctionne pas en 1.21.1, j'ai une panic error runtime, le problème que j'avais trouvé sur Github date d'il y a un an. Je vais essayer de voir de la semaine ce qui cloche, si tu pouvais mettre ton fichier compose @oracle7 pour voir s'il y a des divergences qui pourraient induire cette différence de comportement.
- 1445 réponses
-
- snmp
- monitoring
-
(et 1 en plus)
Étiqueté avec :
-
Le groupe devrait être docker pour le sock, et pas root : J'ai fait un post plus avant sur la manière de résoudre ça :
- 1445 réponses
-
- snmp
- monitoring
-
(et 1 en plus)
Étiqueté avec :
-
Salut, Tous les modèles "+" de la série 20 sont a priori des bons choix. A toi de voir suivant l'espace de stockage dont tu as besoin. Pour la marque des disques durs, classiquement WD et Seagate se partagent le marché dans l'ultra majorité, il n'y a pas vraiment de mauvais choix. Vérifie juste que les disques que tu vas acheter utilisent la technologie CMR et pas SMR (ça se trouve en tapant leur référence sur un moteur de recherche). Réfléchis aussi à une stratégie de sauvegarde, quel type de raid tu veux ou ne veux pas utiliser, etc...
-
Et le dossier monté sur le NAS correspondant à /opt/livebox4/data dans le conteneur a les droits adéquats par rapport à l'utilisateur qui exécute le conteneur ?
- 36 réponses
-
- monitoring
- livebox4
-
(et 1 en plus)
Étiqueté avec :
-
Salut, oui tout à fait, ça peut se configurer par exemple (ce n'est pas le seul moyen) via l'onglet de gestion des utilisateurs : Tu as un onglet "Limite de vitesse". Soit tu crées un groupe auquel tu attribues une limite de vitesse, et les utilisateurs qui en font partie seront de facto limités (réglage par défaut ci-dessus). Soit tu peux utiliser un réglage manuel, lié à l'utilisateur. Attention que les sens de téléchargement sont du point de vue du NAS. Limite de chargement, c'est lorsque les données sortent du NAS, limite de téléchargement inversement.
-
[Résolu] Routeur sécurisé. Synology ou autre chose ?
.Shad. a répondu à un(e) question de declencher dans Questions avant achat
Attention, car suivant les habitations c'est très variable. Par exemple souvent aux US tu verras que les commentaires disent que tout roule, mais ils construisent énormément en bois là-bas. C'est beaucoup plus permissif qu'une dalle en béton. Pour information, chez moi c'est une borne au salon et au 1er, pour desservir le sous-sol et le 2ème étage également. J'ai une UAP-AC-M pour le jardin, environ 50m de profondeur, je capte parfaitement sur les 30-35 premiers mètres. Et prévu pour une utilisation extétieure. Tout est alimenté en PoE, il faut compter environ 4W par borne. -
Hello; bienvenue parmi nous. Je te conseille de séparer ta présentation de ta demande, pour la traçabilité ce sera plus simple. 😉
-
Je trouve ça quand même étrange l'erreur sur l'appel à la fonction map. Est-ce que tu as essayé de retélécharger le fichier geoip2.conf depuis le github de SWAG, pour vérifier qu'un caractère interdit ne s'est pas glissé dans le fichier quelque part. Tu peux utiliser la commande diff sous Linux entre deux fichiers pour comparer leurs différences.