LaBienPensanceMaTuer a écrit 1611 commentaires

l'idée derrière ça c'est qu'il n'y a plus de silo et que la frontière est plus floue entre chaque fonction.

Si la frontière est suffisament floue pour qu'un profil "devops" ne rentre ni dans la case "profil dev" ni dans la case "profil sysadmin", alors j'imagine que ça a quand même un peu de sens que de créer une fonction "devops".

Mais c'est du boulot de sysadmin ça. Juste un sysadmin qui bosse dans une entreprise moderne. Et comme je le dis c'est un détournement de nom. Je sais bien j'ai un poste nommé devops. Ben la belle affaire je suis toujours un sysadmin et je bosse sur les même sujets que quand j'étais titré ingénieur système dans ma boite précente et qu'on avait mise en place avec les devs une intégration continue et une infra containers pour développer et déployer leurs nouvelles applis à bases de microservices.

La liste que tu as dressé est loin d'être exhaustive et semble clairement issue de ta compréhension et de ton expérience dans ce type de poste.
Ce n'est pas parce que c'est uniquement cela que tu as vu que d'autres entreprises ont uniquement ces attentes pour un profil devops.
Je me suis récemment entretenu avec un cabinet de recrutement qui me proposait un poste de devops et, au fil de la discussion, il est apparu que le profil recherché devait clairement avoir de fortes compétences à la fois en développement ET en sysadmin.

Bref, question d'opinion, c'est des technos récentes, et la façon de découper les responsabilités a fortement évoluée depuis ces dernières années.

Après, entre nous, si les cabinets de RH et les boites utilisent le terme "devops" comme un poste à part entière, je crois que c'est un peu eux qui ont raison, non ?

Devops, c'est une façon de travailler, pas un titre de poste

Euh… C'est pas tout à fait vrai ça.
Sachant qu'un devops à des compétences "hors-scope" du dév "à l'ancienne", c'est devenu un titre de poste à part entière.
T'as qu'à voir ça ou encore ça

… reste de tester le fonctionnel, en fait.

Si c'est un service réseau, connectes y toi et joue un bout du protocole qu'il implémente.
Si c'est un service de traitement de fichier, vérifie que ses sorties sont réellement produites.
Si c'est un service qui consomme/produit quoi que ce soit, trouve un moyen de te mettre entre la source ou la destination pour contrôler qu'il se passe quelque chose.

Dans l'absolu, savoir si un processus est 100% opérant sans controler son travail ou modifier son code est plutôt ardu et les rares méthodes qui existeraient seront quoi qu'il arrive un gros bidouillage possiblement couteux en perf, en temps et pas nécessairement possible.
En vrac: modules kernel pour contrôler au niveau du scheduler, hooks des symboles dynamiques utilisés par le binaire à coup de LD_PRELOAD, ptrace, gdb, strace, etc…

strace tout comme gdb utilise ptrace() (manpage)

strace permet à la fois de s'attacher à un processus pour en inspecter l'execution et de savoir, en tant que process si un autre est attaché.

Ce pdf semble au premier coup d'oeil intéressant et synthétique pour ce sujet.

que je dénigre. C'est pas parce que Java permet d'être multi-plateforme que le code que tu fais avec l'est forcément, et l'auteur d'origine ne semble pas comprendre ça lui même.

Ok, je vois ce que tu veux dire.
En effet… Allé… Admettons qu'en tant que bon architecte, il aie donné à ses dev des codings rules qui imposent portabilité.

Après curiosité personnelle: y a t il, à votre connaissance, des précédents dans l'histoire de Java sur des comportements qui differeraient (sur utilisation de lib & co communes au deux OS) en fonction de la plate-forme ?

Si il n'a pas accès aux sources, c'est potentiellement un soft proprio.

Si c'est un soft proprio, il y a potentiellement des protections anti-debug qui empêcheront de l'executer via strace :-(

Ah oui coté formulation ça se pose là…

Tu es sévère, pour moi sa formulation de base m'a fait immédiatement pensé à un process "bloqué".

Sinon, une autre méthode, moins fiable mais un chouia moins violente, c'est de surveiller l'évolution des fichiers /proc/<pid>/stat ou encore statm et io: tu dumpes dans un coin, tu attends X secondes, tu redumpes et tu compares: si ça diffère entre deux dumps, c'est qu'il se passe des choses. Sinon, c'est qu'il se passe rien.

Ex:

~$ cat /proc/20783/stat > /tmp/1
~$ cat /proc/20783/stat > /tmp/2
~$ cat /proc/20783/stat > /tmp/3
~$ cat /proc/20783/stat > /tmp/4
~$ md5sum /tmp/[1-4]
77bfb8fb645744baf6b2f230c21ed3ab /tmp/1
77bfb8fb645744baf6b2f230c21ed3ab /tmp/2
f9d987e43632b72f935a90b8532b163d /tmp/3
f9d987e43632b72f935a90b8532b163d /tmp/4

Après, le risque, c'est que si le soft en question idle (parce qu'en attente d'une entrée quelconque) tu risques de le croire, à tort, planté.

Manque des mots ?

Je suis extrêmement surpris de la part de quelqu'un qui se défini comme un "architecte d'entreprise et le plus souvent architecte technique" d'être outré par le fait que les environnements de développement et ceux de la production doivent être forcément les mêmes dans une entreprise.

Attention, ne confond pas "Poste de travail du développeur" et "Environnement de développement".

Toutes boites opérant un service qui se respecte doit mettre en place au minimum 3 plate-formes:

• Plate-forme de dev: Ca peut être une VM sur leurs poste de travail ou un serveur de dev "remis à 0" tout les soirs dans lequel les dev peuvent tout casser sans impacter quiconque (typiquement, gros serveur et chaque dev à son instance de Tomcat sur un port genre 10001, 10002, 10003, …).

• Plate-forme de pré-prod: un intégrateur (ou autre) pousse le dév finalisé et on déroule des scénarios de test se rapprochant du réel pour vérifier:

  • Que les bugs supposés fixés le sont.
  • Qu'on a pas de regression sur les précédents fixs.
  • Que le fonctionnel est complet et conforme.

• Plate-forme de production: celle destinée au client. De la céramique en résumé.

On considère que les plate-formes de pré-prod et de prod doivent être iso: mêmes version d'OS / de service / de lib, etc…

Donc de ce coup, ça ne me choque pas qu'il râle qu'on aie "calqué l'environnement de prod sur le poste de travail des développeurs".
Peu importe l'OS des développeurs, rien n'empêche ceux-ci de tester leur dev sur une plateforme de développement qui s'approche de la pré-prod.

Par contre, là ou je te rejoins c'est que, de mon point de vue, c'est bien au rôle de l'architecte de pousser auprès de ses développeurs et de sa hierarchie ce mode de fonctionnement…
Donc plutôt que de râler, il devrait assainir la situation directement dans sa boite.
Après, en pratique, je conviens que c'est rarement aisé.

Alors … juste pour info, le ^W est une notation courante parmi les geeks pratiquant IRC: cela veut plus ou moins dire "ctrl-w" qui est le raccourçi permettant de supprimer le dernier mot dans un terminal (comme ctrl-u supprime la ligne, et ctrl-y recolle tout ce qui a été supprimé à coup de ctrl-w et ctrl-u précédemment).

C'est pour faire genre "je change le mot sans pour autant supprimer l'ancien", exemple:

Il est trop con^Wbrave

Pour le reste, totalement d'accord avec toi.

"Ca marche pas" ne donne pas suffisament de contexte pour qu'on puisse t'aider.

Décris nous exactement le mode opératoire suivi et les erreurs rencontrées et p-ê on pourra t'aider.

Sinon, premier élément de réponse: une machine virtuelle peut-être considérer comme une machine "logique" à part entière… Ce n'est donc pas parce que ta machine hôte parvient à faire fonctionner quelque chose que ta machine virtuelle va nécessairement y arriver.

Ca tombe bien, le sujet initial étant "pourquoi on ne vit pas près de notre lieu de travail".

Le rapport est pourtant simple: c'est autant de "contraintes" à prendre en considération lors du choix du lieu de vie.

• La vie de couple: le conjoint a aussi des contraintes qui doivent rentrer en considération
• Les enfants:
  • qui dit travail dit faire garder les enfants pendant leurs nombreuses vacances. Perso, dans ma ville loin de mon boulot, on a pas eu trop de mal à trouver de solution.
  • Je préfère que mes enfants joue dans mes 1600m2 de jardin que sur un balcon de 6m2 en haut d'une tour…
  • L'école, la proximité des grands parents, …

Euh … je crois que c'est plutôt supérieur ou égal à 125cm3.

Parce que, même si on en voit plus trop aujourd'hui, il existe encore sur le marché de l'occasion des scooter en 80cm3 et 110cm3 qui, si je ne me trompe pas, n'ont pas le droit d'emprunter les autoroutes.

Le rêve serait que je trouve un travail en informatique (Linux ;) )

Tente de monter ta boite ;-)
Démarre en tant qu'auto-entrepreneur en essayant de faire du remote (infogérence, développement au forfait) … quand tu auras crevé le plafond du CA d'auto-entrepreneur, alors c'est que tu pourras passer à un status plus important et vivre de ton activité !

Moi, ce qui m'étonne, c'est cette volonté d'organiser sa vie autour du travail.

Personnellement, je change de boite quand j'en ai marre. Donc, si je récapitule ces dernières années, j'ai changé de boite 3 fois: 4 ans, 6 mois et là je suis dans la même boite depuis bientôt 3 ans.

Il est juste impensable pour moi de choisir mon lieu de vie (d'autant que j'ai acheté) sur la base de mon lieu de travail car:

1. J'ai une femme, qui a aussi un lieu de travail.
2. Je change de travail
3. Vivre sur les bassins d'emploi de ma région ne m'intéresse pas.

Sinon, en vivant un peu plus loin de mon boulot, j'ai:

1. Une vue de ouf, dominante, sur la rade de Toulon.
2. Un cadre de vie plus agréable que dans les autres villes plus proche de mon travail: moins assiégés par les touristes, moins tourné vers le tourisme.
3. Une maison que je n'aurai jamais pu me payer plus proche de mon travail posée sur un morceau de colline auquel je n'aurai jamais pu prétendre.

Pour finir, je dirai que proximité ne veut pas nécessairement dire plus écolo et/ou plus confortable:
Avant, je faisais ~20km pour aller travailler: Marseille-Aubagne.
Maintenant, je fais ~45km : Six Fours-Aubagne.
Bizarrement, je passe moins de temps dans ma voiture sur le second trajet: 30 minutes constant, là ou auparavant, c'était 30 minutes de moyenne avec des pic à 1h30 les jours de match au vélodrome.
Si on y regarde bien, je pense que le bilan carbone est meilleur depuis que j'habite plus loin… et je ne parle pas du bilan stress (ouais, ça me rend fou d'être coincé dans les bouchons depuis 40 minutes et de me faire doubler par le bus des joueurs de l'OM escortés en grandes pompes par la police, ce qui a pour effet d'accroitre encore le bouchon…)

Il faut je pense arrêter de croire que toute donnée envoyée sur un serveur distant sert à faire du profilage publicitaire. Cela peut être le cas, mais il y a des tas de cas de figure où en fait ça n'a rien à voir.

Il y a ce que compte faire des données le fabricant … et il y a ce que pourrait faire des données un pirate mal intentionné.

Ah, et aussi …

Déjà, tes essais, c'est directement depuis le routeur ? Ou c'est depuis une machine derrière le routeur ?
Dans le premier cas (mais tu le sais probablement déjà), c'est les chaines INPUT et OUTPUT qui régissent le passage de ton flux. Dans le second cas (ça tu le sais c'est sur) c'est la chaine FORWARD.

La façon dont tu as écrit ta règle de masquerading m'étonne aussi. Me concernant, j'ai l'habitude préciser une interface de sortie (-o eth0) plutôt qu'une plage d'adresse source… Y a pas de raison que ça ne marche pas … Mais ça risque de créer des trucs bizarres.

J'vais continuer à me gratter la tête car ton problème m'intrigue. Tiens nous au jus si tu trouves par toi même ;-)

Ok.
As tu essayé, dans le doute, de mettre une target -j LOG en guise de dernière règle de tes chaines iptables ?
Ca te permettra peut être d'y voir plus clair…

Je dois t'avouer que je sèche un peu … mais le setup et les flux impliqués ne sont pas hyper clairs dans ma tête.

Pourrais tu essayer de reposer le contexte de ton problème ?

Réponse courte: en HTTP/1.1 c'est mort (pour le use case précis que tu décris). en HTTP/2.0 … je sais pas :-(

HTTP/1.1

En HTTP/1.1, cela se passe comme suit:

1. Le client initie une connection TCP sur le port 443 du serveur.
2. S'ensuit une négociation de la couche de crypto: le fameux SSL.
3. Ensuite, une fois le canal de communication chiffré établit, les échanges HTTP commencent réellement.

Et, toujours en HTTP/1.1, c'est lors de ces échanges HTTP que le serveur va avoir connaissance du FQDN ciblé par la requête via le header Host: … Tu vois, j'imagine, le problème: ton serveur sait qu'il doit faire suivre la requête au pi QUE après avoir établit le canal chiffré, pas possible donc de présenter un autre certificat.

Tu as dès lors deux alternatives:

• Tout configurer sur le même nom, genre "home.example.com", "portal.example.com", bref, ce que tu veux et de faire ton routage cloud VS calendar sur une base d'URI:

  • portal.example.com/nextcloud/ => servi via DocumentRoot & co /
  • portal.example.com/calendar/ => servi à coup de ProxyPass.

A noter que tu te casses p-ê la tête pour rien: Nextcloud gère très bien les calendriers … de ce coup, ta seconde appli pourrait s'avérer inutile …

• Utiliser un certificat wildcard (*.example.com) sur le Apache de ton laptop, et ne pas te soucier outre mesure de la connection laptop <=> raspi.

HTTP/2.0

J'ai cru comprendre qu'HTTP/2.0 levait cette limitation … mais je n'est aucune certitude et une lecture rapide de cette page ne me permet pas d'être fixé.

Cependant ce lien semble dire que ça marche tout seul …

Ah je n'avais pas suivi ces évolutions …
Effectivement, là, c'est plus génant. Ma démarche perso serait de rester sur un robot "old-school" sans interaction Wifi/BT/Smartphone etc ….

Je dispose d'un nom de domaine cloud@example.com

Non, ça c'est une adresse email.

Je crois que c'est faisable avec les Virtualhost, cf la section «Utilisation simultanée de Virtual_host et de mod_proxy». Mais je ne voudrais pas faire de bêtises… Comment dois-je faire pour configurer ça correctement?

Il n'y a pas vraiment de gros risque: tu ne perdras pas tes données en faisant ce genre de bêtise.
En gros, tu vas devoir:

1. Définir autant de VirtualHost que tu as de sous-domaine (calendar.example.com = 1 Vhost, cloud.example.com = 1 autre Vhost).
2. Sur le VirtualHost cloud, tu fais pointer ton DocumentRoot vers ton NextCloud.
3. Sur le VirtualHost calendar, tu utilises les directives ProxyPass et ProxyPassReverse pour aller requêter l'autre machine.

Tout est couvert sur cette page de la doc Apache.

Je rejoins un peu Ted: être "libriste" c'est bien, mais faut pas sombrer dans des extrêmes.

Ce genre d'équipement n'embarque rien qui soit, à ma connaissance, une menace pour la vie privé.
De plus, je pense sincèrement que penser pouvoir faire mieux seul dans ton coin en terme d'algo de detection et de "balayage" de la pièce que l'équipe R&D de Roomba est un poil présomptueux ;-)

Sinon, pour le retour d'expérience, on a deux Roomba à la maison: l'aspirateur et le laveur.
Ca marche bien, et surtout, tu trouves pléthore de pièces compatibles et pas chères pour remettre en état ton robot (batterie, lavette, brosses, etc…).
Perso, c'est plus sur ce critère que je choisirais: pérénité de l'équipement.

Je ne vois pas le problème que tap0 soit la route par défaut, une interface virtuelle/tunnel reste une interface
tap0: OpenVPN

Le problème est là: ton interface "virtuelle" est nécessairement reliée, via l'interface, à une interface physique et à un "peer" réel.
Admettons que la passerelle OpenVPN qui te permet de monter ton tap0 est sur l'adresse IPv4 publique (donc hors de ton réseau) 22.33.44.55.
Si tu places la route par défaut sur tap0 ET que tu ne forces pas une route via eth2 (ton WAN) vers 22.33.44.55 tu vas te retrouver avec tes paquets OpenVPN vers 22.33.44.55 routés via … ton OpenVPN.
Tu vois le hic ?

181.188.139.163 est l'IP publique du SuperNat de mon FAI 4G que j'utilise sur mon téléphone. Ca ne marche pas depuis mon téléphone.

Ok, donc adresse publique lambda.
Es tu sûr que cette adresse réponde "tout le temps" ?
Sur quel port TCP/IP et à quel protocole ? J'ai toujours quelques méfiances envers les trucs de FAI ;-)

Je reformule: Quand j'ai l'entrée dans ma table de routage, le packet n'est plus FORWARD.

Et avant ça fonctionne ?
En gros, l'idée, c'est plutôt que de faire passer ce trafic via OpenVPN plutôt que par ta connection FAI, c'est ça ?

Certaines info peuvent être sensible […]

Ok, donc en regardant les infos fournies:

• Bon, déjà la suspicion évoquée plus haut est caduque: tu as bien forcé une route vers ta passerelle OpenVPN via eth2. Donc on est déjà bon à ce niveau… en tout cas si 192.168.1.2 est bien le routeur qui te permet de joindre internet.

• As tu essayé de pinguer ta passerelle côté VPN (172.30.125.1) ? Elle répond ?

• Concernant ton dump de règle iptables et, en particulier, la règle de POSTROUTING je vois un premier problème: tu masquerades TOUT le trafic, sans distinction d'adresse physique source ou autre. En fonction de ton setup, ça peut marcher … ou pas. Vaut mieux dire que tu masquerades tout ce qui sort de tap0 et de eth2 explicitement (la même régle avec un -o <INTERFACE>.

• Je n'ai pas regardé en détail tes règles de PREROUTING… peut y avoir des choses qui interferent … Pour les tests, mieux vaut, si tu peux, passer par un ruleset "vide".

• Donc tu as déjà des choses dans ta chaine FORWARD: même conseil que précédemment: par sur un iptables -F FORWARD && iptables -P FORWARD ACCEPT voir si ça marche, ensuite tente d'affiner. Tu peux également ajouter à la fin (donc avant le DROP) une règle de LOG (-j LOG) histoire de voir si tes paquets sont droppés à cause du firewall.

Là, à vue de nez, le seul truc qui manque c'est d'activer le forwarding côté noyau:

$ sudo sysctl -a|grep -i ip_forward
net.ipv4.ip_forward = 0

Chez toi, ça doit valoir 1 pour que le noyau fasse passer les paquets d'une interface à l'autre ;-)

Je comprends que tu soit fatigué. Je ferai de mon mieux pour répondre à tes questions. Désolé si je ne suis pas claire, j'ai des problèmes à m'exprimer clairement.

Pas de soucis… je suis pas totalement "à bout" car j'ai encore envie de donner un coup de main!