MilesTEG1

Page web inaccessible. J'ai fait mon réseau macvlan avec ça : docker network create -d macvlan \ --subnet=192.168.2.0/24 \ --ip-range=192.168.2.208/28 \ --gateway=192.168.2.1 \ -o parent=ovs_bond0 \ macvlan-network Et le lien avec l'ip virtuelle avec ça : ip link add macv0 link ovs_bond0 type macvlan mode bridge ip addr add 192.168.2.230/32 dev macv0 ip link set dev macv0 address 5E:00:01:02:03:04 ip link set macv0 up ip route add 192.168.2.208/28 dev macv0 Sachant que 192.168.2.230 est l'ip virtuelle que j'ai choisie pour mon conteneur, en dehors du DHCP du routeur, L'IP macvlan du conteneur lui-même est 192.168.2.210. Le réseau macvlan contenant les IP de .2.209 à .2.222 (car vu qu'on ne peut faire qu'un seul réseau macvlan, autant se laisser la possibilité d'avoir plusieurs IP. Et bien, le conteneur se lance, mais n'est pas accessible sur son IP 192.168.2.210...

@.Shad. Faut que je regarde quoi d'autres comme log ?

j'ai pas regardé les logs... mais la page internet ne se chargeait pas. Je retenterais demain pour voir.

@.Shad. C'est bien ce que j'ai fait. Mais ça n'a pas fonctionné...

J'ai essayé en mettant ovs_bond0, mais ça n'a pas fonctionné... Du coup, sauf si on trouve pourquoi ça ne fonctionnait pas, je suis revenu en arrière et enlevé l'aggrégation.

Bon et bien je n'arrive pas à faire fonctionner le réseau macvlan. L'ip macvlan ne fonctionne pas. Et je ne sais pas pourquoi.

@.Shad. Je m'autorépond 🙂 Il faut changer un truc : #ip link add macv0 link ovs_eth0 type macvlan mode bridge # Avec le Link Agrgegation, il faut changer ovs_eth0 ip link add macv0 link ovs_bond0 type macvlan mode bridge # par ovs_bond0 Et en faisant ifconfig je m'aperçois que j'ai une IPv6 sur cette interface : Est-ce qu'il est possible de la supprimer ? Voir de ne pas l'avoir à la création de cette interface virtuelle ? edit : haha, j'avais autre chose à modifier ! Le réseau macvlan lui-même... Le script de création du réseau macvlan doit être modifié de la même manière en replaçant ovs_eth0 par ovs_bond0.

@.Shad. Petite question : je suis en train d'envisager le test du Link Aggregation entre mon NAS et mon switch. Est-ce que ça va poser un problème pour le reseau macvlan et l'IP virtuelle du NAS (faite avec le script) ?

Salut, À mon avis le soucis est ailleurs. car transférer des fichiers depuis le Mac directement sur le nas, quel soit le moyen (wifi, câble) ne doit pas engendrer de corruption de données. il faudrait essayer avec une application de type FreeFileSync pour voir si le problème persiste, elle doit pouvoir vérifier sur la copie est bien faite. sinon comme les disques sont neufs et le nas aussi, il faudrait tester la ram du nas pour voir si elle est ok (ça se fait avec Synology assistant). pour tester les disques c’est plus complexe : voir tuto badblocks en écriture car la y a in soucis de corruption à écarter. est-ce que tu as vérifié tes fichiers sources ? Ont-ils aussi ces soucis de corruption ? il serait bien d’essayer de copier ces fichiers sur un autre support réseau mais pas sur le nouveau nas, et voir si la corruption recommence. encore un autre test : copier en local les fichiers sur un disque externe et lire depuis un autre ordi ou nas sur lequel sera connecté le disque dur externe. En dernier lieu il faudrait aussi tester la ram de l’ordinateur avec memtest. L’objectif de ces tests est de déterminer ce qui engendre la corruption de données : l’ordinateur source , le réseau , le nas , le disque du nas , la ram du nas ...? car je le répète copier des fichiers depuis le Finder ne doit pas causer de corruption. Je le fais très souvent et je n’ai jamais de soucis. ha dernière question : si tu transferts en wifi , elle est stable la connexion ? Y a pas de coupure ? encore un dernier essai : connecte le Mac au nas directement dans passer par un intermédiaire (Box , routeur, Switch) je pense encore à un truc : as tu d’autres ordinateurs chez toi ? Rencontres tu les mêmes soucis de corruption si tu y copies des fichiers ? as tu essayé dans l’autre sens : copier des fichiers depuis le nas ou un pc vers le Mac ? ps : il ne faut faire varier qu’un seul paramètre à la fois !

@maxou56 Ha oui en effet, je viens de vérifier sur mon nas, et je n'ai pas ce menu déroulant. L'onduleur est reconnu directement. Je pencherais pour un soucis de câble USB... ou bien qu'il est mal connecté d'un coté ou d'un autre...

@P4E Dans ta première capture tu as sélectionné « Serveur Onduleur ... » du coup dessous faut spécifier un serveur. Sauf que toi tu as mis un onduleur en usb. Il faut donc changer le choix du type d’onduleur. Là je ne sais plus ce qui doit être mis et je suis sur mon mobile donc pas moyen de vérifier...

Si tu places ton fichier .yml dans le dossier monitoring, et que dans ce fichier yml les chemins d'accès sont cohérents avec les dossiers dans monitoring, oui c'est bon. Faudra se placer dans ce dossier monitoring pour lancer la commande docker-compose up -d . Tu peux aussi utiliser Portainer si tu l'as installé ^^

Oui il faut laisser ça comme ça @Elrick Ce coté correspond au chemin d'accès à l'intérieur du conteneur, donc c'est indépendant du chemin d'accès choisi sur ton NAS. Tu pourrais avoir mis /volume1/docker/blabla/toto/machin/truc/telergah/blabla/encore/un/telegraph.conf que le chemin dans le conteneur resterait le même. Si tu le changeais, le conteneur ne saurait pas retrouver le fichier de configuration car il est fabriqué ainsi 😉

D'après Orange, le loopback est défini ainsi : Livebox 4 : le loopback - Assistance Orange J'avais donc bien compris 🙂

C'est le principe de la démarche/méthode scientifique 🙂 Ne faire varier qu'un seul paramètre à la fois pour observer un éventuel effet. Si plusieurs paramètres sont modifiés en même temps, on ne peut pas savoir lequel est responsable d'un éventuel effet, ou pire, s'ils ne s'annulent pas l'un l'autre...

Oups, validé sans avoir écrit mon message... Je coupe, et écrit mon message. Message édité avec ce qui suit : @oracle7 Super ce que tu as proposé. J'allais justement dire que ce serait une bonne idée de tout refaire depuis 0, donc on enlève tout ce qui a été fait, puis on reprend de 0 pour être sûr qu'il n'y a pas eu une couille dans le pâté à force de faire des essais à droits et à gauche. @pascalg57 je pense que tu devrais suivre cette recommandation et suivre à la lettre le mini tuto de @oracle7, et surtout à la moindre hésitation, incompréhension, ou au moindre soucis de type "je trouve pas"/"ça marche pas", tu arrêtes et tu demandes. Je voulais aussi revenir sur ça @.Shad. : D'après mes connaissances, qui je le conçois ne sont pas tout le temps parfaites, le loopback c'est plutôt ce qui permet depuis ton réseau local d'accéder via ton nom de domaine au NAS (ou autres trucs hébergés chez toi). Le loopback permettant comme tu le décrivais que ta box pointe sur elle-même pour le nom de domaine. Sans loopback, ça ne fonctionne pas. C'est ce qui est arrivé l'an dernier avec une MAJ foireuse des livebox 4 et 5 (et qui est potentiellement encore le cas pour certaines LB5)... Le loopback avait été cassé, du coup, on ne pouvait plus accéder au NAS via son nom de domaine. C'est ce qui m'avait poussé, en plus d'autres raisons, à investir dans un routeur, le RT2600AC. Après j'ai peut-être mal compris le principe du loopback...

Je pense que si tu as un parefeu bien paramétré l'ouverture des ports en question n'est pas dramatique. Ces ports sont ouverts depuis un paquet d'année chez moi, et ce n'est que quand j'ai ouvert le port 22 (oui grosse erreur d'une époque où j'étais un peu plus naïf et surtout ayant moins de connaissances...) que j'ai eu un certains nombre d'attaques, mais heureusement pour moi, à l'époque j'avais déjà plutôt bien paramétré mon parefeu du NAS. (maintenant j'ai en plus le parefeu d'un routeur RT2600AC derrière ma box, en DMZ). Sinon, bah le NAS ne sert plus à grand chose comme le dit @Dimebag Darrell...

ah oui aussi, toutafé 🙂

Le port 6690 c’est le port de Drive server pour la synchronisation. donc s’il utilise le client Drive pour synchroniser ses fichiers ça me parait logique que ce soit ouvert. les ports 80 et 443 ça doit être pour Let’s Encrypt et sites web utilisant son nom de domaine. L’autre port je ne sais pas...

En lisant vos échanges je pense que le soucis est au niveau du reverse proxy. @pascalg57fait nous des captures de ton reverse proxy , en masquant ton nom de domaine , mais en faisant aussi des captures des paramètres des différentes entrées dans le reverse proxy.

@.Shad. Merci beaucoup ! Sans le -t tout fonctionne parfaitement 😄 Je n'avais pas pensé à aller voir la doc, mais je t'avoie que si je lavais fait, je n'aurais pas trouvé... 👍🏻 En tout cas, super merci !!

Bonjour, J'ai un soucis avec le script en fin de message (car il est un peu long...). La commande docker suivante ne passe pas : docker exec -u $ID_USER_NAS -it -w /$GITEA_BACKUP_DIR $(/usr/local/bin/docker ps -qf "name=$NOM_CONTENEUR") bash -c "/app/gitea/gitea dump -c /$GITEA_DATA_DIR/gitea/conf/app.ini" Et même la version sans variables ne passe pas : docker exec -u 1060 -it -w /backup-data $(/usr/local/bin/docker ps -qf "name=gitea") bash -c "/app/gitea/gitea dump -c /data/gitea/conf/app.ini" L'erreur retournée dans le mail de notification est : Que la commande soit précédée par un sudo ou non, ou que le chemin /usr/local/bin/ devant ou non, ça ne fonctionne pas mieux... Pour être sûr que la commande docker fonctionne dans uns script, j'ai fait un petit script test avec : docker ps Dans l'email de notification je reçois bien le résultat d'un docker ps avec la liste des conteneurs lancés. Donc la commande docker est bien reconnue. Ce qui ne va pas est donc ce qui suit... Je précise que lancer le script depuis une invite SSH (iTerm2 ou Windows Terminal), fonctionne bien : Donc voilà, comment rendre fonctionnelle cette ligne de commande permettant de faire la sauvegarde des données via ce qui est fourni par la doc officielle ? Merci d'avance. Le script lui même : ##============================================================================================== ## ## ## Script gitea-backup.sh ## ## ## ##============================================================================================== ## ## ## gitea-backup.sh [<méthode de backup>] ## ## <méthode de backup> est facultatif. S'il n'est pas spécifié, on fait les deux ! ## ## <méthode de backup> = gitea_dump ## ## = archive_dossier ## ## ## ##============================================================================================== ##============================================================================================== ## ## ## Objectif du script : faire une sauvegarde de l'installation Gitea @ Docker ## ## Il y a aura un shutdown du conteneur le temps de la sauvegarde afin que la base de ## ## données ne soit pas modifiée pendant le backup, puis le conteneur sera redémarré. ## ## ## ## Il faudra créer une tâche planifiée pour lancer la sauvegarde toutes les nuits, par ## ## exemple à 3h du matin. ## ## ## ##============================================================================================== ## ## ## Une méthode officielle de backup de la base de données est présente ici : ## ## https://docs.gitea.io/en-us/backup-and-restore/#backup-command-dump ## ## ## ##============================================================================================== # Récupération des arguments qu'on place dans des variables constantes declare -r nb_arg=$# # Nombre d'argument(s) fourni(s) au script. declare -r methode="$1" # 1er argument fourni if [ "$methode" = "--help" ] || [ "$methode" = "-help" ] || [ "$methode" = "-h" ] || [ "$methode" = "--h" ]; then echo "Le script gitea-backup.sh permet de faire une sauvegarde des données du conteneur Gitea." echo "Utilisation : gitea-backup.sh [<méthode de backup>]" echo "L'argument <méthode de backup> est facultatif. S'il n'est pas spécifié, on fait les deux !" echo " <méthode de backup> = gitea_dump" echo " = archive_dossier" echo exit 0 fi mode_backup=0 # 0 = aucune méthode indiquée ; 1 = gitea_dump ; 2 = archive_dossier ##──── ──────────────────────────────────────────────────────────────────────────────────────── ##──── ──────────────────────────────────────────────────────────────────────────────────────── ## ## ## VALEURS À PERSONNALISER ## ## ## ## Chemin d'accès vers votre dossier docker et vers le dossier de backup de gitea ## # Chemin du dossier qui contient le dossier des données (data) et des backups (backup-data) GITEA_DOCKER_DIR=/volume1/docker/gitea # Les noms des dossiers montés dans le conteneur doivent êtres identiques à ceux présents sur la machine hôte. Sinon faudra modifier le script... # Nom du dossier contenant les backups qui doit exister car il doit être monté dans le conteneur à l'aide du docker-compose.yml. GITEA_BACKUP_DIR=backup-data # Nom du dossier contenant les donneés de Gitea (data) GITEA_DATA_DIR=data # Nom du conteneur NOM_CONTENEUR=gitea # ID de l'utilisateur du NAS qui a les droits sur le conteneur ID_USER_NAS=1060 ##──── ──────────────────────────────────────────────────────────────────────────────────────── ##──── ──────────────────────────────────────────────────────────────────────────────────────── echo "$(date "+%R:%S - ") Script de sauvegarde des données du conteneur Gitea" ##============================================================================================== ## Vérification de la présence des dossiers du conteneur ## cd $GITEA_DOCKER_DIR num_erreur=$? # On stocke le code de retour de la commande précédente. if [ $num_erreur -ne 0 ]; then # Si ce code n'est pas 0, il y a eu une erreur, on arrète le script. echo " Le chemin '$GITEA_DOCKER_DIR' est invalide ! Veuillez vérifier le chemin d'accès..." echo " Abandon, avec code d'erreur $num_erreur" exit $num_erreur fi if [ ! -d "$GITEA_BACKUP_DIR" ] || [ ! -d "$GITEA_DATA_DIR" ]; then # Au moins un des dossiers n'existe pas if [ ! -d "$GITEA_BACKUP_DIR" ]; then # Le dossier $GITEA_BACKUP_DIR n'existe pas ! echo " Le dossier '$GITEA_BACKUP_DIR' n'existe pas !" fi if [ ! -d "$GITEA_DATA_DIR" ]; then # Le dossier $GITEA_DATA_DIR n'existe pas ! echo " Le dossier '$GITEA_DATA_DIR' n'existe pas !" fi echo " Abandon, avec code d'erreur $num_erreur" exit 999 else echo "-- Les dossiers $GITEA_BACKUP_DIR et $GITEA_DATA_DIR existent bien. On peut continuer." fi ##============================================================================================== ##============================================================================================== ## ## ## Définition du mode de backup à faire en fonction de la méthode donnée en argument ## case $methode in gitea_dump) # Méthode gitea_dump sélectionnée ## mode_backup=1 #echo "mode_backup=$mode_backup" ;; archive_dossier) # Méthode archive_dossier sélectionnée ## mode_backup=2 #echo "mode_backup=$mode_backup" ;; *) # Aucune méthode sélectionnée ## mode_backup=0 #echo "mode_backup=$mode_backup" ;; esac ##============================================================================================== ##============================================================================================== ## ## ## Partie concernant les sauvegardes ## if [ $mode_backup -eq 0 ] || [ $mode_backup -eq 1 ]; then # Aucune méthode n'est choisie ou bien méthode gitea_dump sélectionnée # Rappel des variables : # GITEA_DOCKER_DIR=/volume1/docker/gitea # GITEA_BACKUP_DIR=backup-data # GITEA_DATA_DIR=data # NOM_CONTENEUR=gitea # ID_USER_NAS=1060 echo "-- Sauvegarde via Gitea dump. (un peu chiant à restaurer...)" echo "###############################################################################" # Dans la commande suivante, les chemins d'accès donnés en paramètres sont des chemins d'accès à l'intérieur du conteneur, montés avec le docker-compose.yml. # Exemple de commande sans variables : # docker exec -u 1060 -it -w /backup-data $(docker ps -qf "name=gitea") bash -c '/app/gitea/gitea dump -c /data/gitea/conf/app.ini' docker exec -u $ID_USER_NAS -it -w /$GITEA_BACKUP_DIR $(/usr/local/bin/docker ps -qf "name=$NOM_CONTENEUR") bash -c "/app/gitea/gitea dump -c /$GITEA_DATA_DIR/gitea/conf/app.ini" num_erreur=$? # On stocke le code de retour de la commande précédente. if [ $num_erreur -ne 0 ]; then # Si ce code n'est pas 0, il y a eu une erreur, on arrète le script. echo "!!!!!! Erreur lors de la commande de backup gitea dump." #echo "!!!!!! Commande lancée :" #echo " docker exec -u $ID_USER_NAS -it -w /$GITEA_BACKUP_DIR $(docker ps -qf "name=$NOM_CONTENEUR") bash -c "/app/gitea/gitea dump -c /$GITEA_DATA_DIR/gitea/conf/app.ini"" echo "!!!!!! Abandon, avec code d'erreur $num_erreur" exit $num_erreur fi echo "###############################################################################" echo "-- Sauvegarde via Gitea dump terminée." fi if [ $mode_backup -eq 0 ] || [ $mode_backup -eq 2 ]; then # Aucune méthode n'est choisie ou bien méthode archive_dossier sélectionnée echo "-- Sauvegarde par création d'une archive de tout le dossier $GITEA_DATA_DIR" echo "###############################################################################" echo "-- Extinction du conteneur $NOM_CONTENEUR" cd $GITEA_DOCKER_DIR # Même si on est censé déjà être là... docker stop $NOM_CONTENEUR tar -czf $GITEA_BACKUP_DIR/Gitea-Data-Backup-`date +%Y-%m-%d--%Hh%Mm%Ss`.tar.gz ./$GITEA_DATA_DIR # On Linux/Unix, in order to backup directories you must use tar : # - to backup a directory : tar cf - directory | 7z a -si directory.tar.7z # - to restore your backup : 7z x -so directory.tar.7z | tar xf - tar cf - ./$GITEA_DATA_DIR | 7z a -si $GITEA_BACKUP_DIR/Gitea-Data-Backup-`date +%Y-%m-%d--%Hh%Mm%Ss`.7z echo "-- Archive de tout le dossier $GITEA_DATA_DIR créée." echo "-- Redémarrage du conteneur Gitea..." docker start $NOM_CONTENEUR echo "###############################################################################" echo "-- Processus de sauvegarde par création d'archive terminé." fi echo "$(date "+%R:%S - ") Fin du script de sauvegarde des donneés du conteneur Gitea" exit 0 ## ## ##==============================================================================================

Bon par contre, les emails de notifs sont bien plus beaux !!! je valide !! Aller, faut qu'il fasse une fonctionnalité pour faire les MAJ 😄

Autant pour moi... J'ai extrapolé mes update à moi 🙂 À priori pour le moment, il y a ça : Donc rien de sensationnel 😉 Mais peut-être qu'il y aura de nouvelles fonctionnalités 😉 Moi ce que j'aimerais, c'est une interface qui montre quel conteneur à une mise à jour possible, et un bouton pour faire la MAJ manuellement. Et des cases à cocher pour dire : lui je veux des MAJ automatiques 😉

Aucune idée... Ça semble lié au notification Gotify que tu utilises, car j'ai pas eu ce message dans ma notif email. Aucune idée là-dessus... Là par contre, comme tu as plusieurs fois influxDB, ça fait autant de mise à jour. j'espère que ça ne télécharge qu'une seule fois l'image... mais j'en mettrais pas ma main au feu 😮