Auteur Sujet: Linux (et tous les autres OS) c'est *bientôt* du passé  (Lu 20656 fois)

0 Membres et 1 Invité sur ce sujet

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 674
  • La Madeleine (59)
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #12 le: 01 septembre 2016 à 19:43:48 »
Le niveau d'isolation n'est pas du tout le même.
Dans les deux cas, ton code métiers (db ? serveur mail ? fichiers ? whatever) est troué :)

underground78

  • Expert
  • Abonné Free fibre
  • *
  • Messages: 7 434
  • Orsay (91)
    • FreePON : suivi géographique du déploiement fibre EPON chez Free
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #13 le: 01 septembre 2016 à 20:44:16 »
ça a l'air d'être un modèle "merdique" à suivre.
Dans la vraie vie les bibliothèques dynamiques peuvent être un vrai enfer à gérer...

Par contre :
Ça existe depuis toujours, sous windows par exemple, on appele ça des gros-binaires-static-de-merde
Les binaires ne sont pas si souvent statiques ça que ça soit Windows. En fait c'est ça va même à l'encontre des bonnes pratiques conseillées par Microsoft.

corrector

  • Invité
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #14 le: 01 septembre 2016 à 20:50:56 »
Objet dynamique.

Une bibliothèque dynamique, c'est comme l'eau sèche.

vivien

  • Administrateur
  • *
  • Messages: 47 076
    • Twitter LaFibre.info
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #15 le: 01 septembre 2016 à 21:52:10 »
Je ne suis pas convaincu, si pour faire un ls il est nécessaire de lancer un container unikernels

Par contre pour les grosses appli je vois bien le principe mais comment faire si je souhaite netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c dans l'unikernels qui fait tourner apache ?

Aujourd'hui avec un container, tu as un Ubuntu server complet, donc cela fonctionne...

C'est vrai que SNAP, j'ai essayé et 120 Mo la calculatrice toute basique, j'ai été impressionné...uniquement par la taille à télécharger !

Un OS complet devrait dépasser les 100 Go si chaque binaire fait plus de 100 Mo.

J'ai testé snap

Voici la liste complète des applications disponibles, contre plusieurs dizaines de milliers au format .deb :
$ sudo snap find
Name                   Version                  Summary
audovia                3.2.2                    Database application for making music using JFugue MusicStrings
beagleblack            3.1                      OEM Beagle Bone Black
canonical-dragon       0.7.1                    The gadget snap for the dragonboard
canonical-i386         3.1.i386                 The gadget snap for generic i386 systems
canonical-pc           3.2                      AMD64 generic package
canonical-pc-linux     4.4.0-18+20160419.13-26  The ubuntu-core kernel snap
canonical-pi2          3.2                      Raspberry Pi 2 support package
go-example-webserver   16.04-4                  Minimal Golang webserver for snappy
hello-world            6.0                      Hello world example
http                   4.6692016                HTTPie in a snap
john-the-ripper        1.8.0-11765-g9a09113     John the Ripper Jumbo password cracker for Linux
links                  2.12-1                   Web browser running in text mode
moon-buggy             1.0.51.9                 Drive a car across the moon
morse-converter-py     1-2                      Simple command-line Morse converter
nmap                   7.12SVN-0.4              Nmap ("Network Mapper") is a free and open source utility for network discovery and security auditing
notes                  0.0.8~snap3.gita80fd1c   Note-taking application, write down your thoughts
shout                  0.53.0                   A self hosted web IRC client
squid3                 3.5.16-2                 Squid3 web proxy
sshtron                1.0                      multiplayer Tron via ssh
sudo                   1                        not sudo
tmux                   2.3bump1                 tmux
tor-middle-relay       0.2.7.6-6                Essential infrastructure node for Tor network
ubuntu-calculator-app  2.1+snap3                Ubuntu Calculator application for the Unity 7 desktop
ubuntu-clock-app       3.6+snap3                Ubuntu Clock application for the Unity 7 desktop
ubuntu-core            16.04+20160419.20-55     The ubuntu-core OS snap
xkcd-webserver         16.04-5                  Show random XKCD compic via a build-in webserver
yacas                  1.4.2                    Yet Another Computer Algebra System


Installation d'une calculatrice au format SNAP :
$ sudo snap install ubuntu-calculator-app
120.01 MB / 120.01 MB [==============================] 100.00 % 2.26 MB/s


Voila ce que cela donne : aucune option n'est disponible à part le "favorite" qui apparaît en bas :


Calculatrice au format .snap : 120 Mo compressé, avec aucune option et pas de localisation en françaus

Calculatrice au format .deb : 317 Ko compressé (cf dépôt Ubuntu) Elle propose bien plus d'option et a une interface localisé en Français.

Au niveau réseau, c'est complètement différent des .deb (qui sont signés et sont téléchargés en http)

.snap fait une première connexion en https sur search.apps.ubuntu.com qui pointe sur les serveurs de Canonical à Londres, quel que soit l'emplacement du client dans le monde.

.snap fait ensuite une seconde connexion, toujours en https sur public.apps.ubuntu.com qui pointe sur les serveurs de Canonical à Londres, quel que soit l'emplacement du client dans le monde.

Ces deux connexions, font quelques Ko après l'échange de clé https.

Enfin le téléchargement de 120 Mo est effectué depuis le CDN Internap, toujours en https.
Pour ma part c'est 068ed04f23.site.internapcdn.net qui a été utilisé (cela pointe vers 77.242.195.173, hébergé lui aussi à Londres)

Bref, l’infrastructure de distribution des .deb d'Ubuntu n'est pas utilisée (ce sont 405 serveurs a travers le monde proposant une bande passante cumulée de 859 Gb/s)


corrector

  • Invité
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #16 le: 01 septembre 2016 à 21:59:30 »
Effet waoou.

Seulement 120 Mo, je pensais que ce serait 10 fois plus!

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #17 le: 01 septembre 2016 à 22:39:01 »
Je ne suis pas convaincu, si pour faire un ls il est nécessaire de lancer un container unikernels
'faire un ls' n'est pas une "application serveur". C'est de l'administration. T'as pas forcement besoin de faire ca dans le meme contexte (=kernel+os) qu'une application déployée en prod.
Tu peux prevoir un container unikernel qui contient un shell complet (donc avec ls) par exemple. Mais c'est de l'admin.
Si ton app a un système de ficher (c'est pas forcement obligé avec un unikernel) et que tu souhaite 'ls' ce système de fichier il peut être accedé par partage via l'hyperviseur par exemple (comme 2 VMs peuvent partager un meme fs de leur hote).

Apres "faire de l'admin" (ou un ls) dans ce contexte d'unikernels n'a plus trop de sens aussi.

On raisonne trop en fonction des OS actuels et de l'admin qu'ils permettent ou nécessitent. Les unikernels permettront des trucs complètement différents ou une app a sa propre pile réseau (ou plusieurs), pas ou plein de filesystems et pas forcement des filesystems actuels ou connus, etc. Il faut donc aussi changer sa facon de raisonner sur l'architecture et le type des ressources (réseau, fichier, etc) et comment on y accède.

Par contre pour les grosses appli je vois bien le principe mais comment faire si je souhaite netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c dans l'unikernels qui fait tourner apache ?

Il ne faut pas forcement chercher a transposer ses habitudes avec l'unikernel.
L’exécutable du serveur web embarque sa propre couche tcp/ip , etc donc faire un netstat n'a pas trop de sens. Si on veut cette fonctionnalité il faut l'intégrer dans l'application directement ou partager la couche ip dans l'hyperviseur. etc

Aujourd'hui avec un container, tu as un Ubuntu server complet, donc cela fonctionne...

Tu n'es pas obligé. Les gens mettent souvent un Ubuntu (ou autre) complet par flemme mais si on veut être propre, securisé et léger il faudrait ne mettre que le strict nécessaire pour faire tourner l'app.

D'ailleurs pas mal de containers utilisent plutot Alpine (5Mo) ou Busybox (2Mo) plutot qu'un Ubuntu (180Mo).
Par exemple, le container officiel d'Apache utilise un full "debian:jessie" mais il y a aussi une version 'light' basée sur Alpine.

root@vdock:~# docker images
REPOSITORY                          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
httpd                               latest              929f5c8eee3f        4 weeks ago         195.4 MB
httpd                               alpine              59225972dbea        7 weeks ago         63.81 MB
=>presque 200MB pour un container Apache sur debian et 64MB pour le meme sur Alpine.

On arrive même à  faire des containers 'from scratch' donc sans aucune distrib (y'a donc pas de /bin/ls ou de shell dans le container. le dossier / est vide de base et on ajoute juste le binaire de l'app et éventuellement des fichiers statiques propre a l'app ou ses libs).

Ce qui est bien c'est qu'on a le choix. On peut faire un container 'plein' de trucs (donc avec un shell et ls dedans par exemple) ou juste avec l'application. Une version 'debug' ou y'a netstat et une version 'securé et opti' sans rien d'autre que l'app. etc

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 674
  • La Madeleine (59)
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #18 le: 01 septembre 2016 à 23:02:21 »
kgersen, tu peux me redire quel est l'intérêt ?
Avec, si possible, des cas typiques, avec et sans, histoire de bien mettre en lumière le gain apporté (et plus globalement, les différences)

Par exemple, quel intérêt de ne pas avoir ls ?

corrector

  • Invité
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #19 le: 01 septembre 2016 à 23:11:12 »
Je vois que je ne suis pas le seul à ne rien comprendre à ce concept!

BadMax

  • Client Free adsl
  • Expert
  • *
  • Messages: 3 481
  • Malissard (26)
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #20 le: 01 septembre 2016 à 23:15:07 »
Spawner des centaines voir des milliers d'instances d'une application ?

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 674
  • La Madeleine (59)
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #21 le: 01 septembre 2016 à 23:16:44 »
C'est déjà tout à fait faisable (et fait), que je sache
Et surtout, je ne vois pas en quoi retirer ls va "aider"

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #22 le: 02 septembre 2016 à 00:49:40 »
Pourquoi tu mettrais ls et tout /bin ou plein de truc s'ils ne servent jamais ? ls (et /bin plus généralement) impliquent que t'as un shell ou un moyen de les lancer (ou via l'application en appelant execve(2)).

T'as jamais vu de faille de secu ou d'exploit en vrai pour demander en quoi retirer ls va "aider"  ? faille dans application ou lib d'OS -> un intrus qui entre peut utiliser les binaires existants (dont ls, rm, etc) pour 'faire' des choses. si y'a pas de binaires autre que l'application -> l'intrus est plus limité dans ces actions (il doit télécharger ou refaire lui même ces commandes via des syscall, mais s'il n'y a plus de kernel y'a donc plus de syscall...ou si y'en a ils sont dans l'app et que ceux qu'elle utilise donc moins de surface d'action. Par exemple pour implèmenter un 'rm' il faut le syscall 'unlink' ou 'unlinkat' et passer le bon descripteur, avoir le driver du fs, etc).

Donc quel intérêt de laisser plein de binaires ("ls -1 /bin /sbin | wc -l" sur Ubuntu de base y'a plus de 300 binaires) ?

Apres le but 1er n'est pas de retirer 'ls' ou autre , ca c'est juste une conséquence bénéfique.

Autre facon de voir les choses: on parle de faire tourner des applications et rien qu'elles dans un contexte minimal ou la présence d'un OS et kernel complet n'apporte rien de plus a ces applications. Dans ce cas quel intérêt de garder l'OS et le kernel complet ?

Ou autre facon: quel intérêt d'avoir 'ls' si y'a pas de système de fichier présent ?

Il ne faut pas raisonner par rapport a une perception 'sysadmin' des choses : dans ce contexte d'unikernels, y'a plus besoin d'un sysadmin donc plus besoin de ses outils (ls et  /bin plus généralement, etc) du moins au niveau qu'on les connait actuellement (userland sur kernel).
Si sysadmin il y a encore, il s'occupera de l'hyperviseur et utilisera les outils propres a l'hyperviseur s'il a besoin de faire un ls (pour voir les "exe" qu'il peut lancer par exemple). Le sysadmin n'a pas acces et ne doit pas avoir accès a l’intérieur de ces "exe" (exe au sens unikernel donc application + unikernel). Tout comme un sysadmin ne va pas mettre son nez dans un binaire elf.

corrector

  • Invité
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #23 le: 02 septembre 2016 à 01:00:39 »
J'ai rien compris...