Le script cherche le mot "windows" dans tous les fichiers du répertoire courant (excepté le script lui-même), et si c'est le cas, le fichier sera déplacé dans le répertoire ciblé par la variable POUBELLE (qui n'est pas définie dans la portion que tu nous a montré).
Je m'auto-réponds dans le cas où quelqu'un souhaiterait faire la même chose un jour…
Finalement, j'ai compilé Open vSwitch dans l'image de mon routeur. Du coup, je crée un simple tunnel GRE entre deux bridges Open vSwitch et tout fonctionne parfaitement.
J'ai un peu avancé sur le problème. Il se trouve qu'en passant le verbose a 4, je voyais que des paquets étaient jetés par OpenVPN. J'ai donc augmenté la valeur du paramètre tcp-queue-limit (de 64 à 256).
Maintenant, les paquets sont jetés au niveau de l'interface tap. Je suis donc en train de voir si je peux pas augmenter la valeur à ce niveau également.
Le débit est passé de 2Mo/s à 6Mo/s pour l'instant… (même débit en FTP et SCP)
C'est possible oui. Déjà dans un premier temps, j'ai limité la bande passante du transfert à 100M, puisque avec SCP sinon, c'était mes VM qui limitaient à cause du CPU.
Je vais quand même cette série de tests histoire de voir si quelque chose est déjà mis en évidence. Ensuite concernant le test réel, je pourrai voir quel outil je peux utiliser pour "perturber" la connexion. Je sais qu'un outil existant pour ajouter de la latence et simuler des pertes de paquets.
Sinon, entre chez moi et mon serveur dédié, je viens de regarder, j'ai environ 5-6 ms de latence pour le ping, ce qui me semble tout à fait raisonnable.
Pour résumer, une première série de tests en "conditions optimale" mais avec un débit similaire (100M) afin de voir si des éléments de configuration ont un impact. Dans un second temps, la même série de test mais avec un outil qui perturbe la liaison.
Je ne sais pas si au final ça amènera une solution, mais bon qui ne tente rien a rien :D
Ouep, ça les changements d'interface je m'en doutais un peu xD
Hm, je vais faire le test entre 2 VM :
- transfert d'un fichier aléatoire de 700M en utilisant leur réseau classique
- transfert d'un fichier aléatoire de 700M en utilisant une liaison OpenVPN tap (2 tests : tcp et udp)
- transfert d'un fichier aléatoire de 700M en utilisant une liaison OpenVPN tun (2 tests : tcp et udp)
Si j'ai encore la motivation, j'essaierai de faire un test avec IPSec
J'ai déjà fait le premier test, j'obtiens un débit de 19 Mo/s environ, ça servira de base de départ
Ouép je sais bien, c'est pour ça que je disais que même en SCP j'atteignais des débits corrects.
Pour info, j'ai tenté y a quelques jours de désactiver l'encryption OpenVPN afin de voir si ça arrangeait les choses, ce qui n'est malheureusement pas le cas… ^
Ok, je le précisais, c'était d'après mes souvenirs, j'espérais me tromper, apparemment, heureusement c'était le cas.
Par contre, en regardant rapidement sur le net, à priori, c'est moins évident pour du routage entre plusieurs réseaux.
Est-ce qu'il sera toujours possible de router tous les réseaux entre eux avec du tun ? Si on regarde mon premier post, on peut noter que des sites possèdent plusieurs réseaux qui doivent tous être routés entre eux. Qu'est ce que ça change côté architecture ? Pour le moment, des routes sont poussées à chaque client VPN qui indique comment joindre chaque réseau :
- le tunnel openvpn fourni un réseau 172.16.0.0/24, chaque client a donc une IP sur ce réseau
- pour chaque client (via ccd) j'indique comment joindre les réseaux qu'il ne connait pas : pour le réseau 192.168.1.0/24 tu passes par 172.16.0.2, pour le réseau 192.168.24.0/24 tu passes par 172.16.0.3, etc…
En passant par tun, ce système peut-il encore fonctionner ?
Donc, dans mon cas, pour le moment, tun (je pense que si je passe tout en ipv6, je ne m'embêterai pas avec du VPN, mais du firewall).
Je vais voir dans la doc openvpn si la transition est aussi simple que ça, de mémoire, le tun est uniquement en point à point, du coup ça impliquerait (d'après ce que je me souviens) à une instance par client.
J'avoue que je n'ai jamais vraiment compris quand est-ce qu'il fallait utiliser tun ou tap. Dans mon cas, avec un serveur central + 3 clients, est-ce que c'est toujours possible de faire du tun ? Concernant l'architecture finale, qu'est ce qui change ?
Tout à fait, le contrôle d'intégrité est fait par les connexions à l'intérieur du tunnel, du coup, le faire deux fois n'est pas nécessaire.
Par contre, comme je le disais dans une autre réponse, je me suis trompé en expliquant mon problème, puisque OVH bride les connexions UDP, j'étais déjà passé en TCP
Salut, j'ai écrit l'article un peu vite tout à l'heure… En fait, je m'étais déjà rendu compte du bridage UDP et mon VPN est donc bien dores et déjà en TCP… Désolé pour l'information erronée… !
Si si c'est mieux, disons que j'ai un débit de 6-7 Mo/s, donc à peu de choses près mon débit réel hors VPN.
J'avais tenté de faire des tests avec iperf en UDP mais bon, le comportement d'iperf est très différent en UDP, car il faut définir une bande passante max et tout, je trouve ça moins clair.
Quoiqu'il en soit, avec une connexion TAP en TCP c'est mieux (résolu).
Me reste juste à régler mes problèmes NFS et j'suis bon ^
Merci pour l'info, même si on a eu l'idée en même temps, mais au moins ça confirme mes investigations… :)
Donc si j'ai bien compris, voici ce que nous devons faire :
- ajouter la route pour le réseau 239.0.0.0/8 sur les interfaces tap0 des machines pira et yoda (clients VPN), qui sont également utilisées pour router le trafic sur les réseaux locaux
- configurer un serveur multicast sur astatine qui se chargera d'arroser les réseaux locaux dès qu'un paquet multicast arrivera d'une source ou d'une autre
Avec ceci, du coup, n'importe quelle machine appartenant au réseau de yoda ou de pira pourra envoyer/recevoir des paquets multicast ?
Si c'est bien ça, le seul truc pour lequel je dois me documenter est le routeur multicast :)
De ce que je comprends, c'est que sur chaque client VPN (donc dans notre cas, pira, yoda et meteor), il faut ajouter la route pour le multicast.
Du coup, j'imagine qu'avec tout ça, tous les paquets correspondant au multicast vont attérir sur astatine (qui est notre serveur VPN, et qui route toutes les connexions).
Il faudra donc également configurer cette machine pour que dès qu'elle reçoit un paquet multicast, elle arrose les autres réseaux ?
Dans un premier temps, nous allons faire simple : on voudrait que si elle reçoit un paquet provenant du réseau de pira, elle arrose le réseau de yoda, et vice-versa. Du coup, j'imagine que c'est du simple iptables ou existe-t-il un genre de "broker" qui permettrait de forward des paquets multicast ?
C'est ce que nous avons conclu suite à nos recherches, mais le problème, c'est que nous ne savons pas trop où mettre cette route, et vers où la router.
Ce que nous avons essayé de faire, c'est que depuis la machine lappy (192.168.24.24) on puisse accéder au serveur UPnP AV que fourni la machine salon (192.168.1.31).
Avec UPnP Proxy (installé respectivement sur pira et yoda), nous arrivions depuis lappy à naviguer dans la liste des dossiers / fichiers, mais pas à lire les médias.
Nous faisions des tcpdump à ce moment là, et effectivement, nous avons vu des connexions avec des adresses IP avec une tête comme 239.0.0.0/8.
Du coup, je pense que cette piste est plutôt bonne, il ne reste plus qu'à comprendre ce qui est attendu, afin de l'implémenter. Sauf que mes connaissances en multicast sont assez limitées, et je n'arrive pas à comprendre exactement ce qu'il faut faire… :(
Merci pour ta réponse. Je me suis trompé en exposant mon problème. Nous sommes bien en tap (sur de l'UDP). Tous les clients ont donc une interface tapX avec une adresse IP en 172.17.0.0/24.
Cette interface ne sert qu'à mettre en place un tunnel entre chaque client et le serveur. Ensuite, à travers ce tunnel, les seules adresses IP que l'on utilise sont les adresses IP du réseau local de chaque site (192.168.1.0/24 chez moi, 192.168.24.0/24 chez mon pote, etc…).
Si j'ai bien compris donc, tu utilises bien le système de configuration embarqué dans LDAP (cn=config), avec la réplication activée, mais tu ne synchronises pas du tout la partie configuration ?
Cela me semble plus logique (mis à part pour les schémas).
Du coup ça pourrait déjà être quelque chose de fonctionnel concernant la mise en place de la réplication.
Tu n'as que ces entrées pour activer la réplication ? C'est à dire si j'ai bien compris :
- le chargement du module syncrepl (logique…)
- la configuration du module (apparemment la définition de l'autre nœud)
Mais je n'ai pas compris à quoi sert la dernière entrée ?
Nous aurons sûrement besoin d'adapter cette configuration, car nous souhaitons avoir deux maîtres.
Si tu as des informations / conseils, je suis preneur. La documentation à ce sujet sur le net n'est pas toujours très claire / à jour.
Tout d'abord, pourquoi versionner le PNG. Tout simplement parce qu'on voudrait qu'il soit généré toujours de la même manière, et qu'il pourra être utilisé à plusieurs endroits (pages wiki, documentations, etc etc). Donc un utilisateur peut en avoir besoin, et on voudrait que ça soit toujours "le même".
Pour éviter les modifications d'historique côté serveur, j'ai pensé à une autre solution, pourriez-vous me dire ce que vous en pensez :
- mise en place d'un hook pre-commit sur chaque dépôt de travail de ce qui mettent à jours le schéma (on va être 2 ou 3 à tout casser) : ce hook génère les deux PNG (le schéma et la vignette), puis les ajoute au commit
- mise en place d'un hook pre-receive côté serveur, pour vérifier que les deux PNG sont présents dans le commit. Si un des deux fichiers est absent, le hook refuse le push et fourni à l'utilisateur l'URL de la page wiki qui indiquera comment installer le hook local.
Le hook de pre-commit (côté client donc) ainsi que le jar (le truc qui génère les PNG) seront versionnés eux-aussi dans un dépôt git, ce qui facilitera l'installation des hooks.
Techniquement, je suis sur que cette solution est réalisable. Maintenant, est-ce que c'est "propre" du point de vue de la philosophie git, je ne sais pas.
# Le script troller
Posté par Thomas Bétrancourt (site web personnel) . En réponse au message Explication d'un Script Shell. Évalué à -4.
Le script cherche le mot "windows" dans tous les fichiers du répertoire courant (excepté le script lui-même), et si c'est le cas, le fichier sera déplacé dans le répertoire ciblé par la variable POUBELLE (qui n'est pas définie dans la portion que tu nous a montré).
# finalement, c'était pas si compliqué...
Posté par Thomas Bétrancourt (site web personnel) . En réponse au message OpenWRT -- Tunnel gretap <-> Open vSwitch. Évalué à 1.
Hello,
Je m'auto-réponds dans le cas où quelqu'un souhaiterait faire la même chose un jour…
Finalement, j'ai compilé Open vSwitch dans l'image de mon routeur. Du coup, je crée un simple tunnel GRE entre deux bridges Open vSwitch et tout fonctionne parfaitement.
# tcp-queue-limit
Posté par Thomas Bétrancourt (site web personnel) . En réponse au message Tunnels OpenVPN - remplacement par solution plus robuste. Évalué à 1.
Yop,
J'ai un peu avancé sur le problème. Il se trouve qu'en passant le verbose a 4, je voyais que des paquets étaient jetés par OpenVPN. J'ai donc augmenté la valeur du paramètre tcp-queue-limit (de 64 à 256).
Maintenant, les paquets sont jetés au niveau de l'interface tap. Je suis donc en train de voir si je peux pas augmenter la valeur à ce niveau également.
Le débit est passé de 2Mo/s à 6Mo/s pour l'instant… (même débit en FTP et SCP)
[^] # Re: TC et NETEM
Posté par Thomas Bétrancourt (site web personnel) . En réponse au message Tunnels OpenVPN - remplacement par solution plus robuste. Évalué à 0.
Merci pour l'info, ça devait être ça l'outil dont je parlais, je finis les tests today, je vous tiens au jus :)
[^] # Re: UDP ?
Posté par Thomas Bétrancourt (site web personnel) . En réponse au message Tunnels OpenVPN - remplacement par solution plus robuste. Évalué à 0.
C'est possible oui. Déjà dans un premier temps, j'ai limité la bande passante du transfert à 100M, puisque avec SCP sinon, c'était mes VM qui limitaient à cause du CPU.
Je vais quand même cette série de tests histoire de voir si quelque chose est déjà mis en évidence. Ensuite concernant le test réel, je pourrai voir quel outil je peux utiliser pour "perturber" la connexion. Je sais qu'un outil existant pour ajouter de la latence et simuler des pertes de paquets.
Sinon, entre chez moi et mon serveur dédié, je viens de regarder, j'ai environ 5-6 ms de latence pour le ping, ce qui me semble tout à fait raisonnable.
Pour résumer, une première série de tests en "conditions optimale" mais avec un débit similaire (100M) afin de voir si des éléments de configuration ont un impact. Dans un second temps, la même série de test mais avec un outil qui perturbe la liaison.
Je ne sais pas si au final ça amènera une solution, mais bon qui ne tente rien a rien :D
[^] # Re: UDP ?
Posté par Thomas Bétrancourt (site web personnel) . En réponse au message Tunnels OpenVPN - remplacement par solution plus robuste. Évalué à 0.
Ouep, ça les changements d'interface je m'en doutais un peu xD
Hm, je vais faire le test entre 2 VM :
- transfert d'un fichier aléatoire de 700M en utilisant leur réseau classique
- transfert d'un fichier aléatoire de 700M en utilisant une liaison OpenVPN tap (2 tests : tcp et udp)
- transfert d'un fichier aléatoire de 700M en utilisant une liaison OpenVPN tun (2 tests : tcp et udp)
Si j'ai encore la motivation, j'essaierai de faire un test avec IPSec
J'ai déjà fait le premier test, j'obtiens un débit de 19 Mo/s environ, ça servira de base de départ
Je posterai les résultats si ça vous intéresse
[^] # Re: Étape par étape
Posté par Thomas Bétrancourt (site web personnel) . En réponse au message Tunnels OpenVPN - remplacement par solution plus robuste. Évalué à 2.
Ouép je sais bien, c'est pour ça que je disais que même en SCP j'atteignais des débits corrects.
Pour info, j'ai tenté y a quelques jours de désactiver l'encryption OpenVPN afin de voir si ça arrangeait les choses, ce qui n'est malheureusement pas le cas… ^
[^] # Re: UDP ?
Posté par Thomas Bétrancourt (site web personnel) . En réponse au message Tunnels OpenVPN - remplacement par solution plus robuste. Évalué à 1.
Ok, je le précisais, c'était d'après mes souvenirs, j'espérais me tromper, apparemment, heureusement c'était le cas.
Par contre, en regardant rapidement sur le net, à priori, c'est moins évident pour du routage entre plusieurs réseaux.
Est-ce qu'il sera toujours possible de router tous les réseaux entre eux avec du tun ? Si on regarde mon premier post, on peut noter que des sites possèdent plusieurs réseaux qui doivent tous être routés entre eux. Qu'est ce que ça change côté architecture ? Pour le moment, des routes sont poussées à chaque client VPN qui indique comment joindre chaque réseau :
- le tunnel openvpn fourni un réseau 172.16.0.0/24, chaque client a donc une IP sur ce réseau
- pour chaque client (via ccd) j'indique comment joindre les réseaux qu'il ne connait pas : pour le réseau 192.168.1.0/24 tu passes par 172.16.0.2, pour le réseau 192.168.24.0/24 tu passes par 172.16.0.3, etc…
En passant par tun, ce système peut-il encore fonctionner ?
[^] # Re: UDP ?
Posté par Thomas Bétrancourt (site web personnel) . En réponse au message Tunnels OpenVPN - remplacement par solution plus robuste. Évalué à 1.
Donc, dans mon cas, pour le moment, tun (je pense que si je passe tout en ipv6, je ne m'embêterai pas avec du VPN, mais du firewall).
Je vais voir dans la doc openvpn si la transition est aussi simple que ça, de mémoire, le tun est uniquement en point à point, du coup ça impliquerait (d'après ce que je me souviens) à une instance par client.
En espérant me tromper.. :p
[^] # Re: UDP ?
Posté par Thomas Bétrancourt (site web personnel) . En réponse au message Tunnels OpenVPN - remplacement par solution plus robuste. Évalué à 1.
J'avoue que je n'ai jamais vraiment compris quand est-ce qu'il fallait utiliser tun ou tap. Dans mon cas, avec un serveur central + 3 clients, est-ce que c'est toujours possible de faire du tun ? Concernant l'architecture finale, qu'est ce qui change ?
[^] # Re: UDP ?
Posté par Thomas Bétrancourt (site web personnel) . En réponse au message Tunnels OpenVPN - remplacement par solution plus robuste. Évalué à 1.
Tout à fait, le contrôle d'intégrité est fait par les connexions à l'intérieur du tunnel, du coup, le faire deux fois n'est pas nécessaire.
Par contre, comme je le disais dans une autre réponse, je me suis trompé en expliquant mon problème, puisque OVH bride les connexions UDP, j'étais déjà passé en TCP
[^] # Re: Étape par étape
Posté par Thomas Bétrancourt (site web personnel) . En réponse au message Tunnels OpenVPN - remplacement par solution plus robuste. Évalué à 1.
Tout à fait, en dehors du VPN, j'atteins environ les 9-10 Mo/s en SCP
[^] # Re: UDP bridé
Posté par Thomas Bétrancourt (site web personnel) . En réponse au message Tunnels OpenVPN - remplacement par solution plus robuste. Évalué à 1.
Salut, j'ai écrit l'article un peu vite tout à l'heure… En fait, je m'étais déjà rendu compte du bridage UDP et mon VPN est donc bien dores et déjà en TCP… Désolé pour l'information erronée… !
[^] # Re: UDP
Posté par Thomas Bétrancourt (site web personnel) . En réponse au message OpenVPN lent CentOS 6.3. Évalué à 0.
Si si c'est mieux, disons que j'ai un débit de 6-7 Mo/s, donc à peu de choses près mon débit réel hors VPN.
J'avais tenté de faire des tests avec iperf en UDP mais bon, le comportement d'iperf est très différent en UDP, car il faut définir une bande passante max et tout, je trouve ça moins clair.
Quoiqu'il en soit, avec une connexion TAP en TCP c'est mieux (résolu).
Me reste juste à régler mes problèmes NFS et j'suis bon ^
Merci pour l'info, même si on a eu l'idée en même temps, mais au moins ça confirme mes investigations… :)
[^] # Re: UDP
Posté par Thomas Bétrancourt (site web personnel) . En réponse au message OpenVPN lent CentOS 6.3. Évalué à 0.
On a eu la même idée, et effectivement, je suis passé en TCP ce weekend, et c'est un peu mieux.
Dommage de la part d'OVH
[^] # Re: a vrai dire
Posté par Thomas Bétrancourt (site web personnel) . En réponse au message Dvorak ou Bépo. Évalué à 0.
Pourtant tu as mis (presque) tous les accents de ta phrase là ^
[^] # Re: Ajouter une route ?
Posté par Thomas Bétrancourt (site web personnel) . En réponse au message UPnP AV à travers un VPN. Évalué à 1.
J'ai regardé rapidement, j'ai entendu parler de igmpproxy également, il faut que je regarde tout ça !
Merci pour les infos !
[^] # Re: Félicitations
Posté par Thomas Bétrancourt (site web personnel) . En réponse au message UPnP AV à travers un VPN. Évalué à 1.
lol… c'est juste pour la beauté du geste ! :)
[^] # Re: Ajouter une route ?
Posté par Thomas Bétrancourt (site web personnel) . En réponse au message UPnP AV à travers un VPN. Évalué à 2.
Ok,
Donc si j'ai bien compris, voici ce que nous devons faire :
- ajouter la route pour le réseau 239.0.0.0/8 sur les interfaces tap0 des machines pira et yoda (clients VPN), qui sont également utilisées pour router le trafic sur les réseaux locaux
- configurer un serveur multicast sur astatine qui se chargera d'arroser les réseaux locaux dès qu'un paquet multicast arrivera d'une source ou d'une autre
Avec ceci, du coup, n'importe quelle machine appartenant au réseau de yoda ou de pira pourra envoyer/recevoir des paquets multicast ?
Si c'est bien ça, le seul truc pour lequel je dois me documenter est le routeur multicast :)
Merci à vous
[^] # Re: Ajouter une route ?
Posté par Thomas Bétrancourt (site web personnel) . En réponse au message UPnP AV à travers un VPN. Évalué à 2. Dernière modification le 10 septembre 2012 à 13:40.
Merci à toi et à NeoX pour ces précisions ! :)
De ce que je comprends, c'est que sur chaque client VPN (donc dans notre cas, pira, yoda et meteor), il faut ajouter la route pour le multicast.
Du coup, j'imagine qu'avec tout ça, tous les paquets correspondant au multicast vont attérir sur astatine (qui est notre serveur VPN, et qui route toutes les connexions).
Il faudra donc également configurer cette machine pour que dès qu'elle reçoit un paquet multicast, elle arrose les autres réseaux ?
Dans un premier temps, nous allons faire simple : on voudrait que si elle reçoit un paquet provenant du réseau de pira, elle arrose le réseau de yoda, et vice-versa. Du coup, j'imagine que c'est du simple iptables ou existe-t-il un genre de "broker" qui permettrait de forward des paquets multicast ?
[^] # Re: debit adsl
Posté par Thomas Bétrancourt (site web personnel) . En réponse au message UPnP AV à travers un VPN. Évalué à 4.
Je suis en fibre, 50M en upload
[^] # Re: Ajouter une route ?
Posté par Thomas Bétrancourt (site web personnel) . En réponse au message UPnP AV à travers un VPN. Évalué à 2. Dernière modification le 10 septembre 2012 à 11:01.
C'est ce que nous avons conclu suite à nos recherches, mais le problème, c'est que nous ne savons pas trop où mettre cette route, et vers où la router.
J'ai uploadé un schéma décrivant le réseau entier : http://imageshack.us/f/189/networkschema.png/
Ce que nous avons essayé de faire, c'est que depuis la machine lappy (192.168.24.24) on puisse accéder au serveur UPnP AV que fourni la machine salon (192.168.1.31).
Avec UPnP Proxy (installé respectivement sur pira et yoda), nous arrivions depuis lappy à naviguer dans la liste des dossiers / fichiers, mais pas à lire les médias.
Nous faisions des tcpdump à ce moment là, et effectivement, nous avons vu des connexions avec des adresses IP avec une tête comme 239.0.0.0/8.
Du coup, je pense que cette piste est plutôt bonne, il ne reste plus qu'à comprendre ce qui est attendu, afin de l'implémenter. Sauf que mes connaissances en multicast sont assez limitées, et je n'arrive pas à comprendre exactement ce qu'il faut faire… :(
[^] # Re: Peut-être passer à tap
Posté par Thomas Bétrancourt (site web personnel) . En réponse au message UPnP AV à travers un VPN. Évalué à 2.
Hello,
Merci pour ta réponse. Je me suis trompé en exposant mon problème. Nous sommes bien en tap (sur de l'UDP). Tous les clients ont donc une interface tapX avec une adresse IP en 172.17.0.0/24.
Cette interface ne sert qu'à mettre en place un tunnel entre chaque client et le serveur. Ensuite, à travers ce tunnel, les seules adresses IP que l'on utilise sont les adresses IP du réseau local de chaque site (192.168.1.0/24 chez moi, 192.168.24.0/24 chez mon pote, etc…).
[^] # Re: Re
Posté par Thomas Bétrancourt (site web personnel) . En réponse au message OpenLDAP -- @(#) $OpenLDAP: slapd 2.4.21 (Dec 19 2011 15:18:58) $. Évalué à 0. Dernière modification le 05 septembre 2012 à 17:11.
Si j'ai bien compris donc, tu utilises bien le système de configuration embarqué dans LDAP (cn=config), avec la réplication activée, mais tu ne synchronises pas du tout la partie configuration ?
Cela me semble plus logique (mis à part pour les schémas).
Du coup ça pourrait déjà être quelque chose de fonctionnel concernant la mise en place de la réplication.
Tu n'as que ces entrées pour activer la réplication ? C'est à dire si j'ai bien compris :
- le chargement du module syncrepl (logique…)
- la configuration du module (apparemment la définition de l'autre nœud)
Mais je n'ai pas compris à quoi sert la dernière entrée ?
Nous aurons sûrement besoin d'adapter cette configuration, car nous souhaitons avoir deux maîtres.
Si tu as des informations / conseils, je suis preneur. La documentation à ce sujet sur le net n'est pas toujours très claire / à jour.
# Bien ce que je pensais :(
Posté par Thomas Bétrancourt (site web personnel) . En réponse au message git hooks : post-receive / git add. Évalué à 1.
Merci pour vos réponse !
Tout d'abord, pourquoi versionner le PNG. Tout simplement parce qu'on voudrait qu'il soit généré toujours de la même manière, et qu'il pourra être utilisé à plusieurs endroits (pages wiki, documentations, etc etc). Donc un utilisateur peut en avoir besoin, et on voudrait que ça soit toujours "le même".
Pour éviter les modifications d'historique côté serveur, j'ai pensé à une autre solution, pourriez-vous me dire ce que vous en pensez :
- mise en place d'un hook pre-commit sur chaque dépôt de travail de ce qui mettent à jours le schéma (on va être 2 ou 3 à tout casser) : ce hook génère les deux PNG (le schéma et la vignette), puis les ajoute au commit
- mise en place d'un hook pre-receive côté serveur, pour vérifier que les deux PNG sont présents dans le commit. Si un des deux fichiers est absent, le hook refuse le push et fourni à l'utilisateur l'URL de la page wiki qui indiquera comment installer le hook local.
Le hook de pre-commit (côté client donc) ainsi que le jar (le truc qui génère les PNG) seront versionnés eux-aussi dans un dépôt git, ce qui facilitera l'installation des hooks.
Techniquement, je suis sur que cette solution est réalisable. Maintenant, est-ce que c'est "propre" du point de vue de la philosophie git, je ne sais pas.
Merci encore pour vos réponses.