Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

Raspberry Pi : installer simplement Docker dans Raspbian Jessie

Une ligne de commande de moins de 30 caractères

Raspberry Pi : installer simplement Docker dans Raspbian Jessie

Le 31 août 2016 à 12h00

La fondation Raspberry Pi vient d'annoncer que l'installation de Docker était désormais grandement simplifiée sur Raspbian Jessie. Cette opération se fait en effet via une seule ligne de commande.

Docker est un outil relativement prisé permettant de créer des conteneurs logiciels. Il est disponible sur de nombreuses plateformes, y compris sur certains NAS. On peut également l'installer sur un Raspberry Pi, mais il fallait alors passer par des systèmes alternatifs comme HypriotOS, ou bien mettre les mains dans le cambouis. Désormais, l'installation est prise en charge nativement par Raspbian Jessie.

Pour rappel, Raspbian est un système d'exploitation basé sur Debian (8.0 pour Raspbian Jessie) et spécialement conçu pour le micro-ordinateur de poche. Comme l'explique la fondation sur son blog, « vous pouvez maintenant installer le client Docker sur votre Raspberry Pi via une seule commande » :

curl -sSL get.docker.com | sh

Ensuite, vous pouvez créer vos propres conteneurs, ou bien en télécharger des déjà existants. Une des possibilités mises en avant par la fondation est d'utiliser le mode Swarm introduit avec la version 1.12 de Docker.

Pour rappel, cette fonctionnalité permet à Docker de créer des applications utilisant des conteneurs multiples répartis sur plusieurs systèmes hôtes, tout en pouvant les gérer sans logiciel supplémentaire. Vous pouvez ainsi construire facilement un « cluster » de Raspberry Pi, ce qui peut être utile pour certaines applications gourmandes.

Alex Ellis, développeur chez ADP et « Docker Captain », donne quelques exemples d'utilisations et de mise en place sur son blog. Il a également publié une vidéo sur l'utilisation du mode Swarm de Docker avec plusieurs Raspberry Pi :

Commentaires (74)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

Appeler sh/bash après un curl, ça reste quand même hyper laid/pas secure comme mode d’install <img data-src=" />

votre avatar

le micro-ordinateur de proche.



C’est une machine spécialisée dans les rencontres ? <img data-src=" />

votre avatar

Rien ne t’empêche de télécharger, lire le script et l’exécuter dans la foulée. Mais pour un environnement de test rapide ou pour 99,9999% des situations, le serveur n’est pas vérolé et ça suffit amplement.

votre avatar

Exactement ce à quoi je pensais….



rm -rf /

votre avatar

C’est pas vraiment le seul installeur dans ce cas !

Confère l’installation de OhMyZsh&nbsp;pour remplacer sh/bash <img data-src=" />

votre avatar

oui, il faut que l’image soit compilée pour l’architecture ARM.

Il y a déjà pas mal d’image pour ARM, et même des spécifiques pour RPI:



https://hub.docker.com/search/?q=RPI

votre avatar

non mais avant ça marchais sans problème ^^



tiens faudrait que je test aussi avec un chmod -R / vu le nombre de fois que des admins m’ont fait le coup :/

votre avatar

Juste pour dire, swarm existait déjà avant la 1.12. C’était juste horrible à utiliser et la 1.12 l’a intégré au moteur, rendant la mise en cluster accessible à tous.

votre avatar

Salut tout le monde! My French is a bit rusty so I wanted to say it’s great to see so many comments and questions. Please can you post them on my blog post or at Twitter @alexellisuk? curl|sh is the standard Docker installation method because most distributions run with stable, old packages. Arch Linux for ARM has a Docker 1.12.1 package if you want to try it. &nbsp;This works on Pi Zero, Pi 2 and Pi 3, probably even Pi 1. Looking forward to hearing from you. Alex

votre avatar







ForceRouge a écrit :



Raté, le fait que toute les dépendances soient inclues implique que le dev doivent suivre toutes les updates de sécurité de toutes ses dépendances.



Un bon exemple est openssl. Sur un système, des tonnes de logiciels s’en servent en dépendances, et quand la distribution met à jour openssl, tout le monde en profite.



Avec un containeur, le dev doit suivre les updates de openssl et relivrer un container à chaque mise à jour de celui ci. Pareil pour Apache httpd, pareil pour php, pareil pour python, pareil pour …





Ce qui n’est pas un problème sachant que le build et le deployment d’un nouveau container est fait de manière a être trivial. Et tu peux donc facilement mettre a jours et revenir en arrière, tester la mise a jours etc.


votre avatar

Toujours pas compris ce qu’est Docker et à quoi ça sert. Pas faute d’avoir lu des articles sur le sujet pourtant. Si quelqu’un a un lien du genre Docker pour les nuls, j’aimerai bien comprendre (je suis dev au passage).

votre avatar

Dans la vie y’a 2 types d’admin sys :

&nbsp;- ceux qui ont déjà fait une grosse connerie en root

&nbsp;- ceux qui vont bientot en faire une



Sinon, perso j’utilise Alpine au lieu de Raspbian sur mon rpi3 avec Docker..

votre avatar

Oh que oui. J’ai déjà vampirisé 95% du CPU d’une box physique de prod (qui faisait tourner des LPAR virtuels ofc) avec un script de monitoring. <img data-src=" />

votre avatar







ForceRouge a écrit :



Raté, le fait que toute les dépendances soient inclues implique que le dev doivent suivre toutes les updates de sécurité de toutes ses dépendances.



Un bon exemple est openssl. Sur un système, des tonnes de logiciels s’en servent en dépendances, et quand la distribution met à jour openssl, tout le monde en profite.



Avec un containeur, le dev doit suivre les updates de openssl et relivrer un container à chaque mise à jour de celui ci. Pareil pour Apache httpd, pareil pour php, pareil pour python, pareil pour …





C’est parfaitement faux et tu ne fais que montrer que tu n’as jamais dû mettre un tant soit peu les mains dans docker.



Une image docker, c’est avant tout une image parente, typiquement basée sur une distribution (genre debian) et un dockerfile qui dit quoi faire pour construire l’image.



Le dockerfile va avoir une ligne genre



apt-get update && apt-get install openssl libssl-dev -y



Et á chaque reconstruction d’image c’est la dernière version d’openssl qui sera utilisée par les instances docker.



Le mainteneur n’a STRICTEMENT rien à faire pour que ça reste à jour.



votre avatar

Donc avec cette ligne, tu casses potentiellement ton appli à chaque nouveau déploiement et si tu veux étendre un cluster, tu n’auras pas les mêmes versions pour chaque membre.



Je crois pas que tu apportes réellement une solution..

votre avatar







Cedrix a écrit :



Donc avec cette ligne, tu casses potentiellement ton appli à chaque nouveau déploiement et si tu veux étendre un cluster, tu n’auras pas les mêmes versions pour chaque membre.



Je crois pas que tu apportes réellement une solution..





Non: avec cette version tu créés une IMAGE qui peut ensuite être répluquée en autant d’INSTANCES qu’on veut, sur autant de serveurs, et autant de fois qu’on veut.



Et l’exemple ci-avant répondait à la critique précise de la ‘non mise à jour automatique’. Il est tout aussi trivial d’adapter un dockerfile pour au contraire fotcer une version précise de tel ou tel soft, ou le rendre confifurable en paramètre, ou….



Bref, renseignez vous 5 minutes sur le fonctionnement, plutôt qu’avancer n’importe quoi. Tout le monde gagnera son temps.


votre avatar

J’exécute 3 versions de PHP différentes sans utiliser docker, avec des paquets propres prit en charge par le gestionnaire de paquets de ma distro.

C’est pas compliqué de changer un numéro dans le fichier PKGBUILD et re-générer le paquet. Même ça si tu as la flemme sur AUR tu as des types qui partagent leurs PKGBUILD, t’as juste à taper sur yaourt.

Chaque version a son propre fichier de config, puisque le fichier de config a le numéro de la version dessus, tranquille.



Le type qui veut une version précise peut préciser dans ses scripts ce qu’il veut ou changer le PATH pour exposer uniquement la version souhaitée, ceux qui précisent pas utilisent la dernière version qui ne porte pas de numéro d’identification.



Tu peux isoler les différentes instances des programmes avec apparmor, Selinux, Grsecurity, tomoyo, et surtout éviter de faire tourner des trucs en root. (php tourne en tant que le compte utilisateur du gars qui a le site, nginx tourne en tant que nginx).



Passer d’une version à l’autre d’un logiciel revient à changer la cible du lien du nom du bin, un numéro à changer, chaque utilisateur peut choisir la version de son logiciel.

On peut activer/désactiver les versions de services avec systemctl.



Avec ça, quel(s) avantage(s) reste-il à Docker ?

Par contre, aucun des désavantages n’a disparût, surtout les problèmes de sécurité.

Il n’y a pas de “dll-hell” sous linux, tu ne fais pas des bin statics, les logiciels vont utiliser la dernière version de ta librairie et c’est tout, à moins de remplacer OpenSSL par LibreSLL par exemple, tu ne vas pas casser quelque chose comme ça, à moins de jouer à l’apprenti sorcier avec les options de compilation.



Pour juste exécuter un logiciel il suffit de “./nomdubin”, docker est sensé simplifier ça ? Ça semble déjà assez simple.

votre avatar

C’est valable si c’est toi qui fait le conteneur, pas si tu le télécharges et l’installes.

votre avatar

Ca reste un problème. Tu n’as pas fait une image, tu as fait un script qui installera chaque fois les dernières versions..



Donc si je déploie en janvier 2016 une application pilote qui est tellement utilisée que je dois en déployer de nouveaux clones en février, mars et juin 2016, j’ai un risque d’avoir entre une et quatre versions différentes de ton image en production.



Ton dockerfile est un risque pour tout environnement opérationnel vu qu’il n’est pas susceptible de donner deux fois le même résultat pour une même exécution.



De plus le release management est horrible vu qu’il n’y a aucun versionning et on ne contrôle absolument pas ce qui est poussé en prod.



Ma remarque est également valable si tu déploies ton dockerfile en qualification en janvier et le même dockerfile en mars ou avril en production.



Bref, ton empressement à trouver une solution à un vrai problème de docker t’amène à créer d’autres problèmes bien plus graves.

votre avatar







Zulgrib a écrit :



J’exécute 3 versions de PHP différentes sans utiliser docker&nbsp;





C’est super pour toi. Dis-donc, si on t’appelle pas “Môosieur” avec tout ça…

&nbsp;

Tu noteras que t’es en complet HS, puisque&nbsp; jamais personne n’a prétendu que Docker faisait des choses impossibles à faire avant.



&nbsp;





Zulgrib a écrit :



Avec ça, quel(s) avantage(s) reste-il à Docker ?



&nbsp;

Sa simplicité et la fait qu’il propose une quantité déjà incroyable de containers prêts à l’emploi, en une ligne de commande simple, dans un nombre tout aussi incroyable de domaines divers et variés.



&nbsp;


votre avatar







Cedrix a écrit :



Ca reste un problème. Tu n’as pas fait une image, tu as fait un script qui installera chaque fois les dernières versions..





Oui, mais c’est exactement la même chose que n’importe quel script qui installerait une distribution en allant chercher les derniers paquetages disponibles.



Là, bizarrement, ça n’est pas vu comme un problème.





Cedrix a écrit :



Bref, ton empressement à trouver une solution à un vrai problème de docker t’amène à créer d’autres problèmes bien plus graves.





Moi je vois surtout ton empressement à casser du sucre sur le dos de docker (‘docker caylemal’) qui t’amène à vouloir trouver des pseudo-problèmes là où il n’y en a pas plus qu’ailleurs.

&nbsp;


votre avatar

Et pourtant :

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; –no-preserve-root

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; do not treat ‘/’ specially



&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; –preserve-root

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; do not remove ‘/’ (default)

votre avatar

Je vais essayer de faire une réponse constructive.



J’aime bien Docker, j’ai écrit des Dockerfiles, j’ai des fichiers compose, je vois le potentiel lorsque c’est bien utilisé.



En revanche je regrette qu’on vende cette technologie comme une révolution qui nous permettra bientôt de ne plus “ s’encombrer ” avec les habitudes existantes.&nbsp; Un sysadmin c’est pas un branlot qui ne fait que des apt-get install toute la journée. Il faut connaitre les outils et les logiciels, prévoir, réparer, car c’est toi qu’on appelle à 3h du matin lorsque la prod est en rade, pas celui qui écrit le Dockerfile.



Quand on rend certaines choses trop accessibles on se retrouve avec des bêtises, par exemple des SGBD sans mot de passe accessibles sur internet (“oh ? j’ai juste fait un docker run, ça marchait, je me suis pas posé de question”).



Voilà pourquoi j’aime pas cet aspect “débilisant” du marketing de Docker. Oui c’est un outil génial, on peut en faire n’importe quoi, mais il ne faut pas faire n’importe quoi.

votre avatar

L’éternel débat prod versus dev… :-)

votre avatar

Bah c’est dommage d’avoir un système de base qui gère les dépendances, le versioning, les updates, et tout, et pour Docker, qui est censé “simplifier” la vie des admins justement, de réinventer la roue, mais en moins bien. C’était si difficile de faire un paquet raspbian ?

votre avatar

Oui ils on changé le comportement par défaut et c’est je pense une bonne chose ! J’avais fait le test sur une VM a un moment, et même si ca ne marche plus, c’est le genre de commande que j’évite d’entrer dans mon terminal ! (Par prudence !)&nbsp;

votre avatar







seb2411 a écrit :



Tu build la nouvelle image avec la nouvelle version et tu la déploie. C’est quoi le problème ?



Le problème, c’est que tu ne fais pas d’update, tu réinstalles. Un patch de sécurité de 3 lignes dans un paquet php ? Tu refais une image…


votre avatar

Peu être mais en attendant c’est toujours les admin qui essuient les plâtres des dev… et cela h24…

votre avatar







alex.d. a écrit :



Le problème, c’est que tu ne fais pas d’update, tu réinstalles. Un patch de sécurité de 3 lignes dans un paquet php ? Tu refais une image…





Oui. Mais c’est trivial.


votre avatar







Trollalalala a écrit :



Ah bon ? Bouge pas j’essaye… <img data-src=" />&nbsp;&nbsp; <img data-src=" />







non mais je l’utilise pas non plus ^^



j’ai juste voulu faire une démo du source d’un fichier non executable,



sauf que j’ai oublier le echo dans mon fichier ^^



du coup j’ai sourcé un rm -Rf / xD et debian ma dit “non je fais pas ça !”



edit :

&nbsp;

root@openremote:# rm -Rf /

rm: il est dangereux d’opérer récursivement sur «&nbsp;/&nbsp;»

rm: utilisez –no-preserve-root pour inhiber cette mesure de sûreté

root@openremote:#


votre avatar

C’est trivial mais c’est à toi de le faire.

D’un côté, tu fais un apt-get upgrade régulièrement, qui fait l’upgrade ou te dit que c’est bon ; d’un autre côté, tu sais quels sont les trucs qu’il y a dans ton image, tu sais ce qui doit être mis à jour, et tu fais une nouvelle image trivialement.

L’un des deux systèmes me semble quand même plus fiable pour s’assurer que les mise à jour de sécurité soient faites rapidement.

votre avatar

Suis sysadmin, faut pas tenter de me convaincre…

votre avatar







Cedrix a écrit :



L’éternel débat prod versus dev… :-)





Ce ne sont pas des métiers qui s’opposent, d’ailleurs il y a les devops&nbsp;<img data-src=" />

Dans les deux cas c’est plutôt une question de bien faire son boulot au lieu de le bâcler à coup de tutos internet.


votre avatar

C’est aussi:




  • Alternative aux machines virtuelles (1 conteneur = 1 services) mais en plus léger

  • Permet de faire de la HA si utilisé en cluster. De plus le cluster n’a pas a être homogène vu que chaque conteneur fournit ses libs.



    Le coup du&nbsp;“oh ? j’ai juste fait un docker run, ça marchait, je me suis pas posé de question”&nbsp;se produit quand le ‘sysadmin’ fait pas son boulot correctement. Et même avec des choses peu accessibles, on a les mêmes&nbsp;problèmes&nbsp;car les&nbsp;gens récupèrent juste un script&nbsp;déjà&nbsp;tout fait sur des forums pour configurer leur trucs automatiquement.

votre avatar

Mec c’est une install sur un raspberry, tout le monde n’est pas un arrogant sysadmin.

votre avatar

Non c’était pour remuer le couteau… dans la plaie bien sur ! <img data-src=" />

votre avatar

Dev ops, c’est pas vraiment fait pour réconcilier les deux. On fait un shift left des problèmes…



Partout, c’est DEV ops ou dev OPS. On atteint un point où il serait bon que les sysadmin sachent faire du dev et les dev du sysadmin…. Trop de spécialisation tue le bon sens au nom de la ségrégation des tâches (pcq la sécurité de l’information qui s’en mêle, c’est rigolo aussi…)

votre avatar

Tu cherches juste à avoir le dernier mot, tu as volontairement évité le reste de mon commentaire.



Je ne casse pas du sucre sur docker, un problème de celui-ci est posé, tu arrives avec tes grands sabots et tu donnes une fausse bonne idée.



Si tu es aveuglé par ton fanboyisme, soit… Essaye juste de rester objectif.



Perso, j’ai rien contre docker, ça ne me fait ni chaud ni froid.

votre avatar







Cedrix a écrit :



Tu cherches juste à avoir le dernier mot, tu as volontairement évité le reste de mon commentaire.





Le reste de ton commentaire n’apporte rien de plus:





  • quelqu’un explique qu’il veut des containers avec les dernières versions de lib à jour (#50)



  • je présente une solution triviale avec un auto-update (#62)

    &nbsp;

  • toi tu reprends cet exemple pour m’expliquer que ça cadre pas avec le besoin d’avoir un container qui au contraire doit garder des versions de libs stables (#67).





    Tu veux que je te dise quoi ? Que Docker caynul parce qu’ils n’ont pas inventé un “container Schrödinger” qui pourra en même temps garder une version stable d’une lib et en même temps upgrader tout seul vers la dernière version ? Sinon je suis forcément un fanboy sans objectivité ?



    T’es ridicule.

    &nbsp;

    &nbsp;


votre avatar

Allez, je te le laisse le dernier mot, tu ne débats pas, tu es insultant.



On en reste là.

votre avatar

News qui tombe à pic merci ! Juste quand je me plonge dans Docker pour remplacer mon bataillon de VM’s. Pour le Raspi j’imaginais même pas que c’était possible, vu l’architecture ARM.&nbsp;

(Docker ne tourne même pas sur un vieux core 2 duo sans Intel VT par exemple, alors un proco 32bits, j’y songeais même pas…)&nbsp;

j’avais déjà jeté un œil à Hypriot&nbsp;mais je voulais rester sur Raspbian où j’ai mes marques :)

votre avatar

Le dockerfile, c’est pour créer l’image.

Après tu la pousses dans un repo (avec version et tutti quanti), et c’est à partir de ça que tu déploies.



PS : ah zut, j’avais pas vu les dates.. J’espère relancer un peu le débat quand même <img data-src=" />

votre avatar

C’est pour les Raspberry Pi 3, vu que Docker ne passe qu’en 64 bits côté host, non?

votre avatar

Pour ceux qui ont la flemme d’importer une clé, ajouter un dépôt, faire un apt-get install ?? La base quand t’es admin quoi. Docker c’est bien mais on le vend comme un truc accessible aux débiles et c’est pas forcément un bon point.

votre avatar

Docker c’est la connerie pour déployer des applications avec ses dépendances au lieu d’utiliser les binaires systèmes à jours pour les dites dépendances histoire de se taper définitivement une vieille version de OpenSLL ou tout autre librairie critique, j’ai bon ?

votre avatar

C’est pas parce que tu es admin que tu ne veux pas une solution clés en main.

votre avatar







ErGo_404 a écrit :



Rien ne t’empêche de télécharger, lire le script et l’exécuter dans la foulée. Mais pour un environnement de test rapide ou pour 99,9999% des situations, le serveur n’est pas vérolé et ça suffit amplement.



Ça n’est quand même pas pour rien que les vrais systèmes de packaging utilisent des signatures, des dépendances explicites, des gestions de versions. Bref, là leur système, c’est la Slackware de 1994.

&nbsp;


votre avatar







Zulgrib a écrit :



Docker c’est la connerie pour déployer des applications avec ses dépendances au lieu d’utiliser les binaires systèmes à jours pour les dites dépendances histoire de se taper définitivement une vieille version de OpenSLL ou tout autre librairie critique, j’ai bon ?







Ste troll <img data-src=" />


votre avatar

Docker, c’est le truc pour simplifier l’installation, mais pour les updates bah… quelles updates ? C’est destinés aux applis qui ont une espérance de vie de moins de 3 mois&nbsp;<img data-src=" />

votre avatar

On parle de RPi là, des environnements de dev dédiés aux tests rapides. On s’en fout de savoir si c’est pérenne ou si ça respecte la mentalité de la distro ou quoi que ce soit.

Tout ce qui compte, c’est que ça soit rapide et que ça marche, ce qui est le cas.

votre avatar







alex.d. a écrit :



Docker, c’est le truc pour simplifier l’installation, mais pour les updates bah… quelles updates ? C’est destinés aux applis qui ont une espérance de vie de moins de 3 mois <img data-src=" />





Tu build la nouvelle image avec la nouvelle version et tu la déploie. C’est quoi le problème ?


votre avatar

Il existe des démonstrations via un sleep dans le .sh, où le serveur en face en fonction du comportement (bash va faire un sleep, curl non), te retourne tel ou tel fichier.

Curl : dl direct -&gt; fichier “normal”.

Bash : dl en partie puis sleep -&gt; malware

Très très fourbe….

votre avatar







ErGo_404 a écrit :



Rien ne t’empêche de télécharger, lire le script et l’exécuter dans la foulée. Mais pour un environnement de test rapide ou pour 99,9999% des situations, le serveur n’est pas vérolé et ça suffit amplement.



Qu’est-ce qui les empêche de fournir un .deb pour raspbian ? Pour le reste, il ne suffit que d’une fois pour exploser un poste : la commande n’utilise pas https, vive le spoof (surtout avec les failles tcp du moment)


votre avatar

un rm -Rf / ne fonctionne plus sur Debian :)

votre avatar

Ah bon ? Bouge pas j’essaye… <img data-src=" />&nbsp;&nbsp; <img data-src=" />

votre avatar







Zulgrib a écrit :



Docker c’est la connerie pour déployer des applications avec ses dépendances au lieu d’utiliser les binaires systèmes à jours pour les dites dépendances histoire de se taper définitivement une vieille version de OpenSLL ou tout autre librairie critique, j’ai bon ?







<img data-src=" />



Sauf qu’en vrai, les 2 concepts ont chacun des avantages et des inconvénients qui les rendent aussi désirables l’un que l’autre


votre avatar

Désolé, je bosse avec du sun et du unix et j’évite de taper cette commande. :-)

votre avatar

Le problème c’est que, trop souvent, le test du dev se retrouve en prod car ‘ça marche en dev’….

votre avatar







Obidoub a écrit :



Pour ceux qui ont la flemme d’importer une clé, ajouter un dépôt, faire un apt-get install ?? La base quand t’es admin quoi. Docker c’est bien mais on le vend comme un truc accessible aux débiles et c’est pas forcément un bon point.





C’est à cause de genre de comportement qu’on veut vous remplacer par des fichiers text!&nbsp;<img data-src=" />


votre avatar

Si ca avait pas été changé, sans le mode verbose tu te serais dit “tiens c’est long a s’exécuter…” <img data-src=" />

toujours vérifier ses rm et dd 18 fois avant de valider !!

votre avatar







al_bebert a écrit :



non mais je l’utilise pas non plus ^^



j’ai juste voulu faire une démo du source d’un fichier non executable,



sauf que j’ai oublier le echo dans mon fichier ^^



du coup j’ai sourcé un rm -Rf / xD et debian ma dit “non je fais pas ça !”



edit :

&nbsp;

root@openremote:# rm -Rf /

rm: il est dangereux d’opérer récursivement sur «&nbsp;/&nbsp;»

rm: utilisez –no-preserve-root pour inhiber cette mesure de sûreté

root@openremote:#





Bon ben ca me parait evident, la bonne commande a executer est:

# rm -rf –no-preserve-root /



Je vous regarde faire les malins :-)


votre avatar

A - “Vous avez fait des tests de charge ?”

B - “Des quoi ?”

A - “Bah des tests de charge, voir comment on supporte de transaction à la seconde et si sur la durée on a pas des fuites de ressources”

B - “Ah, on vend ce type de prestation aussi ? On peut facturer ça combien tu crois ?”

A - “Ca dépend, tu payerais combien pour qu’un mec essaye la 2cv que tu viens d’acheter au prix d’une ferrari ?”



Conversation que j’ai eu avec un CP après que le client râle qu’on dépasse pas les 1tps alors qu’on lui a vendu du rêve à plus de 100tps …

votre avatar

Ça fait partie du boulot pourtant.

votre avatar







Trollalalala a écrit :



Oui ils on changé le comportement par défaut et c’est je pense une bonne chose ! J’avais fait le test sur une VM a un moment, et même si ca ne marche plus, c’est le genre de commande que j’évite d’entrer dans mon terminal ! (Par prudence !)&nbsp;





Depuis que j’ai lancer un rm trop large (bon, ca restait des logs heuresement mais pas génial quand même) , je vérifies aussi toujours plusieurs fois mes rm avant de les lancer.



Sinon, il y a toujours la possibilité de définir un alias pour redéfinir le comportement de rm :)


votre avatar







alex.d. a écrit :



C’est trivial mais c’est à toi de le faire.

D’un côté, tu fais un apt-get upgrade régulièrement, qui fait l’upgrade ou te dit que c’est bon ; d’un autre côté, tu sais quels sont les trucs qu’il y a dans ton image, tu sais ce qui doit être mis à jour, et tu fais une nouvelle image trivialement.

L’un des deux systèmes me semble quand même plus fiable pour s’assurer que les mise à jour de sécurité soient faites rapidement.





Un exemple qui me vient en tête, avec les actions en live sur le serveur, au final tu ne sais plus ce qui a été fait ou pas sur le serveur et tu n’es plus en mesure de redéployer ton serveur en cas de problème.


votre avatar

Oui mais il faut aussi des outils comme ça pour les gens comme moi, qui testent parfois des solutions sur un environnement ou la sécurité n’est pas un problème et où on veut juste “que ça marche”.



Le bon sysadmin doit bien lire la doc et connaître l’environnement, je suis tout à fait d’accord avec toi, mais là le problème c’est la personne, pas l’outil.

votre avatar

Utiliser un gestionnaire de paquets qui tient la route n’empêche pas d’utiliser puppet. C’est complémentaire.

&nbsp;

votre avatar







Cedrix a écrit :



Le problème c’est que, trop souvent, le test du dev se retrouve en prod car ‘ça marche en dev’….







En même temps un raspberry c’est pas un outil professionnel donc il n’y a pas vraiment d’histoire de dev/prod, on parle de DIY là… Donc que l’équipe docker n’ait pas envie de maintenir un paquet pour raspbian, qui n’aura de toute manière que vocation à faire joujou, je peux le comprendre.



Sinon pour rajouter ma pière à l’edifice sur le débat prod vs dev, bah en fait je vois pas trop le débat. Si un sysadmin laisse un dev gérer un environnement docker c’est qu’il a pas envie de tafer et du coup c’est un peu son problème si il y a une couille. Les devs ne décident pas de tout à ce que je sache et un workflow ça s’établie à plusieurs. Donc si tout le monde est d’accord pour utiliser Docker alors les sysadmin sont censé fournir un truc béton, le dev lui bah il utilise son environnement de Dev qui est censé être en accord avec la prod. S’il bosse “à sa sauce” et que rien ne fonctionne comme prévu ensuite bah là pour le coup c’est de sa faute.



Bref je suis dev, et à part si on est dans une petite boîte en mode tu dois tout faire je vois pas en quoi la prod serait mon problème. Moi on me dit qu’il faut que ça marche pour tel environnement je vais faire en sorte que ce soit le cas, je vais pas débarquer en disant que ça marche mais qu’il faudrait changer les versions des softs utilisés.



Les fois où j’ai eu des problèmes c’est juste quand les gens ne travaillent pas ensembles et du coup rien n’est spécifié donc le dev se démerde et fait comme il le sent et le sysadmin n’a qu’à faire avec parce que de toute façon on ne lui a jamais parlé du projet avant le jour où il faut faire la MEP ^^ Mais là c’est pas une question de débat dev/prod, c’est juste du management en carton comme on sait bien le faire chez nous en donnant des responsabilité à des mecs qui savent faire de l’agile, faire un kanban, assigner des tâches exotiques pour remplir les heures sur les graphs, mais qui n’ont aucune idée de ce que c’est de dev ou de gérer des serveurs ^^


votre avatar

Question pour les spécialistes de Docker.



Vu que TeamSpeak ne veut pas sortir de version ARM du serveur, est-ce que docker permettrait de lancer facilement teamspeak-server sur le rasp 3 ?

votre avatar

Si vous n’aimez pas Docker ou si vous n’en avez pas besoin, ne l’installez pas.



Ceci dit, apt-get et docker n’ont pas le même objectif.



apt-get sert a installer/mettre à jour des programmes sur un système.

docker sert a exécuter des programmes sur un système.



En particulier docker permet:




  1. exécuter des versions différentes qu’on veut d’un même programme.

  2. isoler les différentes instances de programmes qui s’exécutent

  3. activer/désactiver/switcher facilement d’une version d’un programme à une autre.



    Le fait que toutes les dépendances soient incluent dans le programme c’est une contrainte technique qu’on peut voir comme un avantage (pas de dll-hell) ou un inconvénient (duplication). Mais c’est un petit prix a payer pour avoir les fonctionnalités offertes par docker.

votre avatar







Zulgrib a écrit :



Docker c’est la connerie pour déployer des applications avec ses dépendances au lieu d’utiliser les binaires systèmes à jours pour les dites dépendances histoire de se taper définitivement une vieille version de OpenSLL ou tout autre librairie critique, j’ai bon ?







Exact







Eryas a écrit :



Question pour les spécialistes de Docker.



Vu que TeamSpeak ne veut pas sortir de version ARM du serveur, est-ce que docker permettrait de lancer facilement teamspeak-server sur le rasp 3 ?



Non, c’est pas la même architecture CPU. Docker ne virtualise pas le CPU.







127.0.0.1 a écrit :



Si vous n’aimez pas Docker ou si vous n’en avez pas besoin, ne l’installez pas.



Ceci dit, apt-get et docker n’ont pas le même objectif.



apt-get sert a installer/mettre à jour des programmes sur un système.

docker sert a exécuter des programmes sur un système.



En particulier docker permet:




  1. exécuter des versions différentes qu’on veut d’un même programme.

  2. isoler les différentes instances de programmes qui s’exécutent

  3. activer/désactiver/switcher facilement d’une version d’un programme à une autre.



    Le fait que toutes les dépendances soient incluent dans le programme c’est une contrainte technique qu’on peut voir comme un avantage (pas de dll-hell) ou un inconvénient (duplication). Mais c’est un petit prix a payer pour avoir les fonctionnalités offertes par docker.







    Raté, le fait que toute les dépendances soient inclues implique que le dev doivent suivre toutes les updates de sécurité de toutes ses dépendances.



    Un bon exemple est openssl. Sur un système, des tonnes de logiciels s’en servent en dépendances, et quand la distribution met à jour openssl, tout le monde en profite.



    Avec un containeur, le dev doit suivre les updates de openssl et relivrer un container à chaque mise à jour de celui ci. Pareil pour Apache httpd, pareil pour php, pareil pour python, pareil pour …


votre avatar







ForceRouge a écrit :



Raté, le fait que toute les dépendances soient inclues implique que le dev doivent suivre toutes les updates de sécurité de toutes ses dépendances.



Un bon exemple est openssl. Sur un système, des tonnes de logiciels s’en servent en dépendances, et quand la distribution met à jour openssl, tout le monde en profite.



Avec un containeur, le dev doit suivre les updates de openssl et relivrer un container à chaque mise à jour de celui ci. Pareil pour Apache httpd, pareil pour php, pareil pour python, pareil pour …







Sauf a tester des trucs expérimentaux comme RancherOS, il ne faut pas voir Docker comme un package-manager qui permet de maintenir son OS à jour.



Docker et VirtualBox servent a exécuter une “image binaire” avec une bonne garantie d’exécution (car indépendant de la plateforme). La où une image VirtualBox contient un OS complet, une image Docker contient une application complète (La partie OS étant fournie par Docker via l’OS hôte).



Si ton objectif est de maintenir ton linux à jour, VirtualBox n’est clairement pas le bon outil.

Si ton objectif est de maintenir ton openssl à jour, docker n’est clairement pas le bon outil.


votre avatar







Poischack a écrit :



Il existe des démonstrations via un sleep dans le .sh, où le serveur en face en fonction du comportement (bash va faire un sleep, curl non), te retourne tel ou tel fichier.

Curl : dl direct -&gt; fichier “normal”.

Bash : dl en partie puis sleep -&gt; malware

Très très fourbe….







Tu parles sans doute de ce PoC : https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/



Pour avoir tester, ça fonctionne très bien. Il se base sur le user agent envoyé par le client lors du curl (meme chose avec un wget). Pour contourner un -H”Firefox” fonctionnera.

D’où l’hérérie du curl | bash qui exécute le fichier téléchargé sans aucune vérification préalable et en HTTP (intégrité, confidentialité, toussa…).



Même en environnement de dév étant donné que le dév se retrouvera en prod ou que cette vieille habitude se fera en prod… Suffit de voir ceux qui utilisent OhMyZsh en prod, il y a de forte chance que cette méthode est été utilisé… (déjà vu pour du déploiement automatisé)


votre avatar

Synology ne permet d’utiliser docker que sur du x86.

J’avais compris que c’était parce que les conteneurs en général sont fait pour du x86.



Ca veut dire que ceux qui veulent utiliser docker sur rpi vont devoir trouver/faire des conteneurs arm ?

Raspberry Pi : installer simplement Docker dans Raspbian Jessie

Fermer