seb773

Bonjour, J'ai mis en place "ghcr.io/analogj/scrutiny:latest", le conteneur fonctionne correctement mais les infos ne sont jamais rafraichies. J'ai mis en environment: COLLECTOR_CRON_SCHEDULE=30 12 * * * Pensant que cela programme un rafraichissement automatique quotidien à 12h30 mais c'est apparemment pas le cas. J'ai aussi créé un fichier de config "scrutiny.yaml" pour avoir des notifactions par mail comme ci-dessous: version: 1 # note, usernames and passwords containing special characters will need to be urlencoded. # if your username is: "myname@example.com" and your password is "124@34$1" # your shoutrrr url will look like: "smtp://myname%40example%2Ecom:124%4034%241@ms.my.domain.com:587" notify: urls: - "smtp://alias%40domain%2Ecom:psw@domain.com:587/?fromAddress=alias@domain.com&toAddresses=alias@domain.com" Comme je ne reçois aucun mail, je pense donc que les notifications ne fonctionne pas non plus Quelqu'un a t'il une idée d'où peut venir ces problèmes svp ? Merci

Si ca peut aider voici ci-dessous les logs: 2024/03/30 22:08:38.566 [PXE] ========================================================== 2024/03/30 22:08:38.566 [PXE] ########################################################## 2024/03/30 22:08:38.567 [PXE] ##################### IVENTOY RUN ######################## 2024/03/30 22:08:38.567 [PXE] ########################################################## 2024/03/30 22:08:38.567 [PXE] ========================================================== 2024/03/30 22:08:38.587 [PXE] ##################### IVENTOY [Linux 64] ################ 2024/03/30 22:08:38.587 [PXE] system cpu core number: 4 2024/03/30 22:08:38.587 [PXE] Module <Log> init start ... 2024/03/30 22:08:38.587 [PXE] Module <Log> init OK ... 2024/03/30 22:08:38.587 [PXE] Module <Plat> init start ... 2024/03/30 22:08:38.587 [UTIL] Old system max open files: [1048576 1048576] 2024/03/30 22:08:38.587 [UTIL] New system max open files: [32768 32768] 2024/03/30 22:08:38.587 [PXE] Module <Plat> init OK ... 2024/03/30 22:08:38.587 [PXE] Module <Cfg> init start ... 2024/03/30 22:08:38.587 [PXE] Module <Cfg> init OK ... 2024/03/30 22:08:38.587 [PXE] Module <MAC> init start ... 2024/03/30 22:08:38.587 [PXE] mac addr db init ... 2024/03/30 22:08:38.587 [PXE] Invalid mac db size 0 2024/03/30 22:08:38.587 [PXE] Module <MAC> init OK ... 2024/03/30 22:08:38.587 [PXE] Module <Tarfs> init start ... 2024/03/30 22:08:38.587 [PXE] dat file too small 2024/03/30 22:08:38.587 [PXE] Failed to extract iventoy.dat file. 2024/03/30 22:08:38.587 [PXE] Module <Tarfs> init FAILED ... 2024/03/30 22:08:38.587 [PXE] Module <Tarfs> exit ... 2024/03/30 22:08:38.587 [PXE] Module <MAC> exit ... 2024/03/30 22:08:38.587 [PXE] Module <Cfg> exit ... 2024/03/30 22:08:38.587 [PXE] Module <Plat> exit ... 2024/03/30 22:08:38.587 [PXE] Module <Log> exit ... 2024/03/30 22:08:38.587 [LOG] iVentoy log exit ... Comme on peut voir il y'a des "failed" mais je ne vois pas la raison

Merci pour l'information, du coup le problème n'est pas là. Par hasard quelqu'un aurait il réussi à utiliser iventoy en docker sur son synology ?

Bonjour, Je me permets de relancer le sujet concernant la demande initiale sur "iventoy". J'ai aussi créé le même conteneur avec le docker compose original et celui démarre sans problème mais impossible d'avoir accès à l'interface web http://ipnas:26000 Comme il est précisé "This does not work with rootless Docker. The container must be run as root." Est-ce que le fait de mettre "privileged: true" dans le yaml exécute le container en root ? Merci

J'ai trouvé, en fait c'est tout bête. Il a juste fallu une synchro NTP du NAS.

Bonjour, Sur la page admin de vaultwarden dans diagnostics, j'ai ceci: J'ai mis en environment "TZ=Europe/Paris", je comprends pas pourquoi j'ai du rouge alors que tout me semlbe correct. Avez-vous une idée svp ? Merci

Voici la vrai solution 😉 Si on choisi "Compatibilité moderne" alors il faut dans "Paramètres personnalisés" choisir "Compatibilité intermédiaire" sur ce qui concerne "MailPlus Server".

Finalement mon dernier commentaire n'a pas résolu le problème mais je pense qu'il n'y a pas de solution. Car j'ai trouvé cette remarque dans l'aide DSM: Merci

Finalement j'ai trouvé la solution pour pouvoir utiliser la "compatibilité moderne". Il faut dans "MailPlus Server \ Distribution \ Protocole" désactiver "Interdire l'authentification en texte brut..." après avoir fait cela outlook fonctionne.

Bonjour, Dans Profil TLS/SSL, vous pouvez choisir le niveau de sécurité des connexions chiffrées HTTPS. Il existe trois niveaux de compatibilité dont : Compatibilité moderne : uniquement compatible avec les derniers navigateurs et périphériques mobiles. Compatibilité intermédiaire : entre la compatibilité moderne et l'ancienne rétrocompatibilité. Il s'agit de la valeur par défaut du système. J'ai un serveur mailplus qui fonctionne sans problème, je suis en compatibilité intermédiaire et j'utilise Outlook. J'ai voulu passer en compatibilité moderne et la Outlook n'arrive plus à se connecter à mon serveur mail. J'ai donc remis intermédiaire et tout va bien. Est-ce normal, y a-t-il quelque chose à faire pour passer en moderne ? Merci

C'est ajouté, merci pour l'info. J'ai modifié comme ci-dessous: volumes: - /volume1/docker/fail2ban:/data:rw - /volume1/docker/vaultwarden/vaultwarden.log:/log/vaultwarden.log:ro network_mode: "host" cap_add: - NET_ADMIN - NET_RAW Quand vous parler du "jail" je suppose que c'est les fichiers conf présent dans le dossier "jail.d", je n'ai rien modifié ci-dessous le contenu: [DEFAULT] ignoreip = 172.16.0.0/12 192.168.0.0/16 10.0.0.0/8 # optional #Ban for 30 days bantime = 2592000 findtime = 86400 maxretry = 4 banaction = iptables-allports ignoreself = false [vaultwarden] enabled = true port = 80,443,3012 # alternative: anyport filter = vaultwarden logpath = /log/vaultwarden.log Oui effectivement, j'utilise le proxy inversé du nas. Merci pour votre aide Mon container est "up" depuis plusieurs minutes maintenant, donc j'espère qu'il fonctionne correctement. 2024-03-14 11:10:54,394 fail2ban.server [1]: INFO -------------------------------------------------- 2024-03-14 11:10:54,394 fail2ban.server [1]: INFO Starting Fail2ban v1.0.2 2024-03-14 11:10:54,395 fail2ban.observer [1]: INFO Observer start... 2024-03-14 11:10:54,431 fail2ban.database [1]: INFO Connected to fail2ban persistent database '/data/db/fail2ban.sqlite3' 2024-03-14 11:10:54,432 fail2ban.jail [1]: INFO Creating new jail 'vaultwarden-admin' 2024-03-14 11:10:54,452 fail2ban.jail [1]: INFO Jail 'vaultwarden-admin' uses pyinotify {} 2024-03-14 11:10:54,452 fail2ban.jail [1]: INFO Initiated 'pyinotify' backend 2024-03-14 11:10:54,457 fail2ban.filter [1]: INFO maxRetry: 4 2024-03-14 11:10:54,458 fail2ban.filter [1]: INFO findtime: 86400 2024-03-14 11:10:54,458 fail2ban.actions [1]: INFO banTime: 2592000 2024-03-14 11:10:54,458 fail2ban.filter [1]: INFO encoding: UTF-8 2024-03-14 11:10:54,458 fail2ban.filter [1]: INFO Added logfile: '/log/vaultwarden.log' (pos = 0, hash = a302e0746052998a8b39892655575de4b59eb37f) 2024-03-14 11:10:54,459 fail2ban.jail [1]: INFO Creating new jail 'vaultwarden' 2024-03-14 11:10:54,459 fail2ban.jail [1]: INFO Jail 'vaultwarden' uses pyinotify {} 2024-03-14 11:10:54,459 fail2ban.jail [1]: INFO Initiated 'pyinotify' backend 2024-03-14 11:10:54,460 fail2ban.filter [1]: INFO maxRetry: 4 2024-03-14 11:10:54,460 fail2ban.filter [1]: INFO findtime: 86400 2024-03-14 11:10:54,461 fail2ban.actions [1]: INFO banTime: 2592000 2024-03-14 11:10:54,461 fail2ban.filter [1]: INFO encoding: UTF-8 2024-03-14 11:10:54,461 fail2ban.filter [1]: INFO Added logfile: '/log/vaultwarden.log' (pos = 0, hash = a302e0746052998a8b39892655575de4b59eb37f) 2024-03-14 11:10:54,464 fail2ban.jail [1]: INFO Jail 'vaultwarden-admin' started 2024-03-14 11:10:54,464 fail2ban.jail [1]: INFO Jail 'vaultwarden' started @CyberFr@.Shad. Merci beaucoup

Bonjour, J'ai également créé un projet iventoy et j'ai la même chose, impossible d'accéder à l'interface Web. Sur github il est indiqué: "This does not work with rootless Docker. The container must be run as root." Est-ce que "privileged: true" dans le yaml exécute le container en root ? Merci

Je pense que c'est normal car c'est juste pour consulter le log et savoir quoi bloquer.

Bonjour, Je suis débutant sur docker et j'ai créé un Projet Vaultwarden qui fonctionne correctement dont voici ci-dessous un extrait du compose.yaml: version: "3" services: vaultwarden: image: vaultwarden/server:latest container_name: vaultwarden restart: always ports: - 3012:3012 - 3013:80 volumes: - /volume1/docker/vaultwarden:/data:rw environment: - ........ - TZ=Europe/Paris - LOG_FILE=/data/vaultwarden.log - LOG_LEVEL=warn - EXTENDED_LOGGING=true - ........ networks: default: name: vaultwarden driver: bridge Je voudrais me protéger un peu des attaques éventuelles, je pense que le mieux est donc de créer un autre projet comme "fail2ban". Voici donc le code du compose.yaml que j'ai fait pour ce nouveau container: version: '3' services: fail2ban: container_name: fail2ban restart: always image: crazymax/fail2ban:latest environment: - TZ=Europe/Paris - F2B_DB_PURGE_AGE=30d - F2B_LOG_TARGET=/data/fail2ban.log - F2B_LOG_LEVEL=INFO - F2B_IPTABLES_CHAIN=INPUT - SSMTP_HOST=smtp.domain.fr - SSMTP_PORT=587 - SSMTP_HOSTNAME=domain.fr - SSMTP_USER=mail@domain.fr - SSMTP_PASSWORD=psw - SSMTP_TLS=YES - SSMTP_STARTTLS=YES volumes: - /volume1/docker/fail2ban:/data:rw - /volume1/docker/vaultwarden:/data:ro network_mode: "host" privileged: true cap_add: - NET_ADMIN - NET_RAW J'ai bien les 3 dossiers action.d / filter.d /jail.d que j'ai pris depuis la page suivante: https://github.com/sosandroid/docker-fail2ban-synology Je n'ai rien changé dans le dossier action.d, pour les 2 autres j'ai juste conservé les fichiers conf vaultwarden. Cependant ce container ne fonctionne pas, il démarre puis il s'arrête. Il y'a donc probablement quelque chose que je n'ai pas fait correctement, savez-vous à partir de ces éléments me dire d'où peut le problème ? Me manque t'il quelque chose, ai-je besoin d'autres container, y'a t'il d'autre méthode pour se protéger ? Merci d'avance,

Finalement tous les champs sont maintenant complétés, je n'ai pourtant pas fait de modifications. Il y'a peut être un temps de latence après le démarrage du container... Donc tout est en ordre, merci pour votre aide et patience 🙂