sygirard a écrit 50 commentaires

Oui cette partie là comme je disais je l'avais vu, mais je suis pas sur que je puisse l'utiliser sans "hardware ethernet"

Car, j'explique, j'aurai un serveur DHCP par machine (partie mécanique, le PC, l'automate), et que sur chaque machine, je veux le même fichier de conf.

Donc une adresse MAC spécifique dans le fichier de conf ne me convient pas.

Désolé, j'avais pas spécifié cette subtilité.

Bonjour,

je reviens vers vous comme convenu.

Je rappellle que mon serveur DHCP me sert uniquement pour réaliser la mise à jour en automatique d'un automate dans une machine.

J'ai fait des tests de configuration DHCP, et il semble que celle qui suit soit la meilleure pour ce que je cherche à faire.

ddns-update-style none;

ignore client-updates;
allow booting;
allow bootp;

class "ma_classe" {
   match if substring (option dhcp-client-identifier, 0, 9) = "\000MON_UID";
   option vendor-encapsulated-options "/NAME=config.xml /ADDRESS=192.168.1.1 /PROTOCOL=ftp";
}

subnet 192.168.1.0 netmask 255.255.255.0 {
   option routers                192.168.1.1;
   option subnet-mask            255.255.255.0;
   option time-offset            -18000;
   option broadcast-address      192.168.1.255;
   pool {
      allow members of "ma_classe";
      range 192.168.1.2 192.168.1.2;
   }
}

Je dois attribuer une adresse IP fixe à l'automate. L'utilisation de "range" dans "pool" ne me plait pas. Surtout pour un "range" d'une IP.
Je sais qu'on peut utiliser fixed-address, mais dans un "pool" ça marche pas, et dans "class" je sais pas si on peut l'utiliser.
Dans un "host" oui à ce que j'ai vu mais je pense pas que ça me soit utile.

Mon fichier de conf est-il bon, ou est-ce que c'est mal fait ? Il fonctionne bien, mais si c'est pas propre, je vois pas trop l'utilité de le garder comme ça.

Ensuite, comme je l'expliquais, si un jour en rebranchant les cables, l'opérateur les inverse, je me retrouve avec mon serveur DHCP sur le réseau du client, où il y a déjà un serveur DHCP. Et je ne veux pas que le miens mette la pagaille sur leur réseau.

Ma configuration suffit-elle à éviter des problèmes ?

Sinon, quelqu'un connaitrait-il le moyen de bloquer les trames venant des autres machines n'ayant pas l'UID "dhcp-client-identifier" que j'ai choisi ?

J'ai beau chercher sur le net, j'ai pas trouvé ce que je voulais. Ou alors j'ai horriblement mal cherché.

Merci pour votre aide.

Sylvain

J'ai dis une connerie. C'est pas les rpath qui sont différents.

C'est les chemins que l'on retrouve dans les logs d'erreurs.

Genre /home/../../../maLib.so:21 : ERROR …

C'est la seule chose qui change si compilé dans un job jenkins différent.

De plus, si j'utilise la commande "readelf -h", seule la valeur de "Start of section headers" est différente. Alors que tout est identique pour la même lib lorsque je compile mon installeur et mon patch dans le même job Jenkins.

Désolé si je blablate pour rien dire, juste que j'essaie de trouver ce qui me fait cette différence, uniquement parce que le workspace où je compile est différent (seulement le path, puisque les variables d'environnement sont identiques)

Pour infos, et pour ceux que ça intéresse, j'ai trouvé le problème.

Pour la génération d'un installeur complet et d'un patch j'utilise un job Jenkins différent, et donc un workspace différent (oui j'utilise mercurial, rappelez vous, et pour la première utilisation d'un job je fais un clone et le workspace prend le nom du job Jenkins).

J'ai eu une idée, et pour la tester j'ai fait en sorte de produire l'installeur et le patch dans le même job jenkins, et donc dans le même workspace.

Et là Oh Miracle !!!!! j'avais juste mes 2 librairies impactées dans le patch … Ça marche !!!!

P… de rpath

Je fais mes md5sum avant de les virer … ça pouvait donc pas marcher.

On ne s’ennuie jamais ;-) J'adore mon boulot ^{^}

En y réfléchissant, l'histoire du patch de version ne peut pas vraiment être la cause.

Car d'une part le numéro de version ne change pas, d'autre part, on intègre dans la librairie la date/heure de génération.

Et comme vu ci-dessus, deux génération qui se suivent, avec le même TAG mercurial, génèrent les mêmes MD5, excepté pour la fameuse lib qui contient la version et la date de génération.

Il doit y avoir une différence entre mon générateur d'installeur full et mon générateur de patch.

DONC LAISSEZ TOMBER LA QUESTION, JE PENSE QUE TOUT CE JOUE DANS MES SCRIPTS ET PAS PAR RAPPORT A CMAKE/GCC.

Merci encore et désolé …

Je précise que ça peut être que cette histoire de patch de version car entre les deux TAG mercurial et donc entre les deux générations Jenkins, aucune modification de code.

Bien, j'ai réussi à faire deux compilations du même projet, même TAG avec le job Jenkins, et j'ai les mêmes MD5.
Le problème ne vient donc pas de Jenkins. Dommage je trouve pas de smiley tête de clown ^{^}

Je pense que ça vient donc de nos patchs de numéro de version que l'on fait dans les sources cpp d'une librairie qui impactent plus que ce que je pensais.

Désolé, je pense vous avoir dérangé pour rien.

Je reviens vers vous pour dire ce qu'il en est.

Merci encore.

Et bien apparemment oui, puisque tu vois, je me suis connecté sur la machine sur laquelle est exécuté le script du job Jenkins, en tant qu'utilisateur que l'on a créé spécifiquement pour ça.

On utilise "hg" comme gestionnaire de projet.

Je me suis donc rendu dans le home de l'utilisateur, puis dans workspace, puis le nom du job Jenkins.

J'ai effectué les mêmes manipulations que le script, à savoir :

hg pull http://…
hg update -C LE_TAG_POUR_MA_VERSION

puis lancement du script de compilation et génération.

J'ai donc fait ça hier soir depuis mon terminal connecté sur l'utilisateur spécifique pour les job Jenkins.
J'ai récupéré les md5 de mes fichiers.

J'ai refais exactement les mêmes manipulations ce matin depuis mon terminal.

J'ai comparé les md5, et mise à part deux lib (ce qui est normal), ils sont tous similaires.

Hors, si je lance deux fois mon Job jenkins avec le même TAG, j'ai pas les mêmes md5. C'est du délire.

Je refais le test pour confirmer, histoire de pas passer pour un clown, mais je suis presque sur que les md5 étaient différents. Pas tous, certes, mais l'intégralité de mes lib sur.

Je test et je reviens.

Je viens de faire des tests depuis hier.

Nous avons des scripts qui permettent de générer un installer de base du projet ou un patch versionné.
Dans les deux cas on compile tout le projet, et on fait le md5 des fichiers qui nous intéressent juste après la compilation.

Dans le cas où je lance ces scripts en local sur mon poste (compilation distribué activée), j'arrive à avoir le même md5 pour les binaires et librairies.

Mais dans le cas où je lance ces scripts par Jenkins, mode normal de livraison logiciel chez nous, et bien j'ai des différences.

Le système Linux sur lequel nous travaillons est verrouillé au niveau des mises à jour pour être en phase avec les PC qui sont chez les clients qui ne sont pas forcément connectés à internet pour d'éventuelles mises à jour …

J'ai activé ça dans /etc/ssh/sshd_config sur mon serveur :

GatewayPorts yes

du coup maintenant j'ai ce que tu me disais :

tcp 0 0 0.0.0.0:3301 0.0.0.0:* LISTEN 64487/sshd: name

Et cela sans mettre 0.0.0.0:3301:localhost:22 .. juste ce que j'avais 3301:localhost:22 suffit

Et maintenant TOUT BAIGNE !!!!!!!!!!!!!!!!!!!!! EXTRA !!!!!!!!!!!!!

Depuis mon poste, si je tape :

ssh -p 3301 user_machine_distante@mon_serveur

Je suis connecté à ma machine distante.

ET le plus beau … c'est que j'ai également accès en SFTP avec FileZilla depuis mon … et la c'est tout simplement MAGIQUE !!!!

Merci de m'avoir mis sur la voie.

Merci à tous.

P…. suis content

Euh … comment on ferme un topic ? Merci

j'ai essayé ça :

ssh -R 0.0.0.0:330X:localhost:22 -D 7979 mon_user@mon_serveur -p 444 -N

et ça aussi du coup :

ssh -R 330X:0.0.0.0:22 -D 7979 mon_user@mon_serveur -p 444 -N

Mais ça change rien. J'ai toujours :

tcp 0 0 127.0.0.1:3301 0.0.0.0:* LISTEN 59691/sshd: name

Qu'est ce que tu appelles ma machine de rebond ? Mon serveur ?

Dans ce cas j'ai ça :

tcp 0 0 127.0.0.1:3301 0.0.0.0:* LISTEN 62684/sshd: name

Je vais essayer d'expliquer un peu mieux.

J'ai une machine chez un client (n'importe où dans le monde) connectée au réseau entreprise de ce même client, réseau qui à accès à internet.
Sur cette machine, il existe l'utilisateur user_machine.

J'ai un serveur en France, connecté au réseau entreprise de ma société, et accessible depuis internet.
Sur ce serveur il existe un user nommé user_serveur.

Ma machine chez le client crée un tunnel ssh vers le serveur en utilisant l'utilisateur user_serveur. En faisant la redirection des port 22 et 5900. Le tout par le port 444. Et j'utilise les socket également pour pouvoir faire fonctionner un chat (-D 7979). Ce qui donne la commande suivante en imaginant que la machine est la première connecté au serveur (X=1)

ssh -R 3301:localhost:22 -R 5901:localhost:5900 -D 7979 user_serveur@mon_serveur -p 444 -N

Ensuite, si j'ouvre un terminal sur mon serveur, je peux faire ce que je veux (ssh, scp, sftp) avec les commandes suivantes que je sais utiliser en fouillant dans les MAN de chacune d'entre elles :

ssh -p 3301 user_machine@localhost
scp -P 3301 le_fichier user_machine@localhost
sftp -o Port=2201 user_machine@localhost

Mais cela fonctionne uniquement avec l'utilisateur user_serveur puisque le tunnel ssh a été créé avec cet utilisateur. Avec un autre user du serveur cela ne fonctionne pas. Ce qui est très bien pour moi.

Voila ce que j'ai si j'essaie de le faire depuis un autre utilisateur du serveur :

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
Please contact your system administrator.
Add correct host key in /home/utilisateur/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/utilisateur/.ssh/known_hosts:2
ECDSA host key for [localhost]:3301 has changed and you have requested strict checking.
Host key verification failed.
Couldn't read packet: Connection reset by peer

Maintenant, je me situe sur mon poste. Il est sur le réseau interne de mon entreprise. J'ai accès donc en interne au serveur. Je n'ai ni l'utilisateur user_serveur, ni user_machine sur ma machine.

Je voudrais envoyer un fichier, ou en récupérer un, sur la machine chez le client. Pour cela il faut que j'utilise le user qui est sur la machine, soit user_machine, sachant que ce user n'existe pas sur le serveur.

En gros je voudrais traverser mon serveur comme s'il n'existait pas.

Après je suis pas un expert dans le domaine, c'est pour ça que je requière voter aide.

Merci

J'ai "connection refused" quand je fais ça

je faisais une réponse à toi au départ, puis j'ai dériver sur la réponse d'olivier car j'étais en train de faire les tests en même temps. Désolé ..

J'ai pas bien compris à quel endroit tu veux que je remplace locahost par adresse IP de la machine. Dans la requete ssh qui crée le tunnel ?
Et vu que l'IP de la machine externe sera une IP appartenant au réseau interne du client, je pense pas que ça m'aidera .. et utiliser l'adresse IP du routeur du client non plus …

Après même réponse pour le proxy dans mon client ssh sur mon poste. L'IP de la machine ne me servira pas. Et de toute façon je ne l'ai pas.

Ou alors j'ai pas vraiment compris comment fonctionne ce que tu veux me faire faire.

Je cherche également en parallèle un client SFTP que je pourrai intégrer à mon site. Ça m'aiderai tout aussi bien je pense.

Désolé si je me suis mal fait comprendre …

S'il faut plus d'explication car je suis pas clair tu me dis ..

je n'ai pas d'IP pour les machines externes … car elles sont chez des clients, dans leur réseau entreprise, derrière un routeur/firewall.

D'où les tunnels SSH … cela me permet via ShellInABox et NoVNC sur un site web d'avoir accès à la machine pour faire du support sans demander une modification des règles de sécurité chez les clients.
Oui, je redirige le port 22 et le port 5900.
Je voulais rediriger le port du ftp, comme ça je mettais net2ftp dans le site et mon problème était réglé.

Sauf que je bride ftp à un seul répertoire, pour éviter toute intrusion depuis le réseau usine (ou autre) chez les clients.
Puis aujourd'hui, seul un automate nécessite ftp pour pouvoir réaliser ses mise à jour.

Un sftp depuis mon serveur, de la manière suivante, fonctionne très bien :

sftp -o Port=330X user@localhost

Maintenant il faut que j'arrive à faire en sorte que la meme commande (ou ssh ou scp) que je fais depuis un autre PC arrive sur le serveur et soit redirigée vers la machine externe.

Précision supplémentaire, seul un user spécifique du serveur peut se connecter à distance vers les machines externes à cause du tunnel créé avec ce user.

Bien, il y a des choses que je n'ai pas testé car je me suis peut être lancé un peu vite dans cette idée de "ne rien répondre du tout". Et pour moi iptables était la meilleure solution.
Disons que mon responsable IT n'était pas spécialement prêt à avoir une nouvelle fois les pannes.

Et que pour expliquer plus clairement le projet, ce PC, n'est autre qu'un clone qui se retrouvera dans une machine, comme les autres, chez des clients. Et on voudrait absolument éviter le problème que l'on a eu ici dans nos locaux.
Cela serait gênant que notre serveur DHCP, suite à une mauvaise manipulation, fasse "tomber" toute une ligne de production et fasse perdre beaucoup de billets.
Même si on peut espérer que leur réseau est plus solide que le notre …

D'après toi, ce type de configuration pour le serveur :
class "host_name" {
match if substring (hardware, 1, 3) = 00:0B:AB;
}
subnet 10.0.0.0 netmask 255.255.255.0 {
pool {
range 10.0.0.16 10.0.0.32;
allow members of "host_name";
}
}

Est suffisante pour mon besoin ?

Je vais me poser sur cette configuration, lancer wireshark pour voir ce qu'il se passe et je fais un retour.

Si ça fonctionne comme je le souhaite, désolé pour toute la discussion qui a du vous prendre du temps alors que la solution était sous mes yeux.

Juste que je voudrais toutes les IP commençant par AA:BB:CC soit un total de 16 777 215 adresse MAC possible …
Je me vois mal ajouté autant de règle via iptables … il va me jeter ^{^}

J'ai pensé essayer les "-m string --string " et "-m string --hex-string " mais ça ne fonctionne que pour la partie "Data" de la trame, et non pas pour les headers.

Après il y a aussi les "-m u32" mais c'est pareil, ne remonte pas jusqu'au header contenant la MAC.
Ou alors j'ai pas pigé comment faire.

J'ai essayé les commandes suivantes :
=> iptables -A INPUT -i eth1 -m mac --mac-source aa:bb:cc:* -j ACCEPT
=> iptables -A INPUT -i eth1 -m mac --mac-source aa:bb:cc: -j ACCEPT

Aucune des deux ne fonctionne, et me retourne :
iptables v1.4.12.1: ether
Try `iptables -h' or 'iptables --help' for more information.

Je continue mes recherches …

Oui c'est ce que j'ai paramétré dans le fichier /etc/sysconfig/dhcpd :

DHCPD_INTERFACE="eth1"

Vais essayer.

Merci

Pensais pas que ça serait aussi simple que ça … j'ai rien trouvé sur le net.

Merci encore

Bon j'ai bien trouvé comment faire ce que je voulais avec les iptables.

Quelque chose du genre :

iptables -A INPUT -i eth1 -m mac --mac-source AA:BB:CC:DD:EE:FF -j ACCEPT

Maintenant, est-ce que quelqu'un a une idée pour que le filtre s'applique sur toutes les MAC commençant par "AA:BB:CC" par exemple ?
C'est ça qu'il me faudrait ..

Merci

Le PC contenant ce serveur DHCP est dans une machine (eth0 va vers le réseau usine, eth1 va vers un automate).
C'est sur eth1 que tourne mon serveur DHCP.

Pour des raisons de simplification d'utilisation entre notre application et toutes les données qui transites, j'ai désactivé le firewall.

Va donc falloir que je le réactive et fasse toute la configuration si je ne trouve pas une autre solution.

Pour info, je suis sous OpenSuse 12.1

Vais voir avec les règles "iptables".

Merci

Merci pour ta réponse.

J'avais noté les "host" pour gérer les IP en fonction des adresses MAC comme tu le présente.
J'ai même trouvé cet exemple qui me convient car je veux autoriser tous les appareils similaires d'une même marque :
class "host_name" {
match if substring (hardware, 1, 3) = 00:0B:AB;
}
subnet 10.0.0.0 netmask 255.255.255.0 {
pool {
range 10.0.0.16 10.0.0.32;
allow members of "host_name";
}
}

Par contre cette histoire de ne "rien" répondre est la plus importantes ….