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

0 Membres et 1 Invité sur ce sujet

corrector

  • Invité
Linux (et tout les autres OS) c'est *bientot* du passé
« Réponse #48 le: 26 septembre 2016 à 01:28:37 »
Mais ceux que tu voulais préserver en utilisant l'option -a de la commande cp, pardi !
Je veux préserver les caractéristiques intrinsèques qui affectent l'interprétation du fichier. Par exemple, la permission EXECUTE rend un fichier exécutable (si il a le bon format), donc ça affecte son comportement. Les autres permissions, les propriétaires, etc. détermine qui peut faire quelle opération, donc c'est important de les préserver.

L'attribut atime n'est utile que si quelqu'un a la curieuse idée de l'utiliser, ce qui est très rarement le cas. C'est une méta-information sans aucun intérêt dans 97 % des cas (mais qui peut, parfois, être utile).

De toute façon, tu ne peux pas créer une copie identique d'une arborescence ou même d'un seul fichier, tel que TOUS les attributs Unix soient identiques!

denis999

  • Client Bbox fibre FTTH
  • *
  • Messages: 30
  • Saint Maurice (94)
Linux (et tous les autres OS) c'est *bientôt* du passé
« Réponse #49 le: 17 octobre 2016 à 17:54:33 »
Désolé pour le déterrage.

Je ne comprend pas bien le concept exposé.

J'ai l'impression de voir la même chose que quand j'installe une appliance packagée par un éditeur dans VMWare, avec comme nouveauté le but de légèreté et donc juste ne plus se contenter d'avoir une SUSE complète mais verrouillée comme je rencontre actuellement.
Du coup ca semble surtout un changement de packaging.

Enfin je vois les mêmes avantages / inconvénients que les "appliances", le fait de juste m'occuper de l'hyperviseur sans avoir à construire moi-même la VM hébergeant l'appli (et donc avoir un bloc certifié par l'éditeur), donc en théorie moins de souci appli car moins de diversité à gérer côté éditeur.

En contrepartie, je suis limité / bloqué sur ce que je peux diagnostiquer de l'appli puisque l'accès est  verrouillé.
De manière générale, je ne peux utiliser que les services / fonctionnalités prévues par le fournisseur (du coup, pas d'utilitaire pour voir ce que l'appli fait en terme de disque, RAM,...) et je suis dépendant de ses choix (par exemple de son absence de support d'un hyperviseur plus vieux que X mois, d'autoriser des comptes lignes de commandes limités, pas de séparation des interfaces réseaux admin/service/NAS...).

corrector

  • Invité
Linux (et tous les autres OS) c'est *bientôt* du passé
« Réponse #50 le: 17 octobre 2016 à 18:09:47 »
Désolé pour le déterrage.
Tu appelles ça un déterrage, après même pas 6 mois?

Non mais tu plaisantes!

Je ne comprend pas bien le concept exposé.
Donc je ne suis pas seul!

kgersen

  • Client Bouygues FTTH
  • Modérateur
  • *
  • Messages: 5 551
  • FTTH 1Gb/s sur Paris (75)
Linux (et tous les autres OS) c'est *bientôt* du passé
« Réponse #51 le: 19 octobre 2016 à 16:12:54 »
Désolé pour le déterrage.

Je ne comprend pas bien le concept exposé.

J'ai l'impression de voir la même chose que quand j'installe une appliance packagée par un éditeur dans VMWare, avec comme nouveauté le but de légèreté et donc juste ne plus se contenter d'avoir une SUSE complète mais verrouillée comme je rencontre actuellement.
Du coup ca semble surtout un changement de packaging.

Enfin je vois les mêmes avantages / inconvénients que les "appliances", le fait de juste m'occuper de l'hyperviseur sans avoir à construire moi-même la VM hébergeant l'appli (et donc avoir un bloc certifié par l'éditeur), donc en théorie moins de souci appli car moins de diversité à gérer côté éditeur.

En contrepartie, je suis limité / bloqué sur ce que je peux diagnostiquer de l'appli puisque l'accès est  verrouillé.
De manière générale, je ne peux utiliser que les services / fonctionnalités prévues par le fournisseur (du coup, pas d'utilitaire pour voir ce que l'appli fait en terme de disque, RAM,...) et je suis dépendant de ses choix (par exemple de son absence de support d'un hyperviseur plus vieux que X mois, d'autoriser des comptes lignes de commandes limités, pas de séparation des interfaces réseaux admin/service/NAS...).

tu m'a plutôt l'air d'avoir compris le concept ... tu vois juste les inconvénients sans voir les avantages.

Vu de l’extérieur (de l'hyperviseur) oui c'est juste un changement de packaging.
Vu de l’intérieur c'est très différent, l'OS n'est plus la c'est juste une bibliothèque (library OS).

Pour ceux qui connaissent le C/C++ voici une bonne intro:

Ca parle de http://www.includeos.org/. En gros on commence son programme par "#include <os>" et le binaire produit tourne directement sans OS (il inclut un bootloader donc pour pouvoir démarrer sur une machine physique (plutot IoT) ou virtuelle).

Il ne faut pas non plus raisonner avec les architectures applicatives passées , grosses et souvent monolitiques.
On parle de micro-services la, avec des nuées d'instances.

Quand t'as 1000 ou plus instances d'une meme app si tu peux dégager 1000 fois l'OS et tout ce qui ne sert pas, le gain est énorme. Pouvoir faire un acces ssh sur chacun des 1000 instances ne sert a rien non plus...(et la sécurité, upgrade, etc)

Apres c'est l'éternel débat d'ou on met la 'frontière' d'intervention. Certains sysadmins ne supportent pas de devoir faire tourner des 'boites noires' sans pouvoir aller jeter un oeil dedans. Certains devs ne supportent pas que les sysadmins bidouillent dans leur apps. Il est vrai que quelque part certains métiers vont se simplifier...voir disparaitre.

Pour le support d'hypersiveur, tout va dépendre de la rétrocompatibilité qu'offrira celui-ci. On a le même souci avec une VM entre l'app et l'OS ou des libs.

J'ai pas bien compris "pas de séparation des interfaces réseaux admin/service/NAS".

Encore une fois c'est un domaine récent et en plein évolution. Tout n'est pas figé et il y a plusieurs façon de faire les choses. Comme au début des VM par exemple. Ce qui marche et est efficace va l'emporter et sans doute 'descendre' au niveau hardware comme ce fut le cas avec les VM (cf tout ce qu'Intel et d'autres ont fait pour améliorer le fonctionnement de la virtualisation en terme de cpu, io, mem, etc).

Il faudra aussi que les mentalités s'adaptent comme ce fut le cas avec les VMs.

denis999

  • Client Bbox fibre FTTH
  • *
  • Messages: 30
  • Saint Maurice (94)
Linux (et tous les autres OS) c'est *bientôt* du passé
« Réponse #52 le: 19 octobre 2016 à 18:16:11 »
tu m'a plutôt l'air d'avoir compris le concept ... tu vois juste les inconvénients sans voir les avantages.
 (...)
On parle de micro-services la, avec des nuées d'instances.
 (...)
Apres c'est l'éternel débat d’où on met la 'frontière' d'intervention. Certains sysadmins ne supportent pas de devoir faire tourner des 'boites noires' sans pouvoir aller jeter un oeil dedans. Certains devs ne supportent pas que les sysadmins bidouillent dans leur apps. Il est vrai que quelque part certains métiers vont se simplifier...voir disparaitre.
 (...)
J'ai pas bien compris "pas de séparation des interfaces réseaux admin/service/NAS".
 (...)
Je suis probablement plus dans les inconvénients du fait de ce que je vois au boulot.
Je m'ocuppe d'OS et de stockage sur des environnements virtualisés pour des appli de compta à base d'ERP.
Il m'arrive d'avoir à aller sur les machines pour voir comment se comporte l'appli dessus ou l'OS en terme de performance principalement notamment pour ce qu'ils demandent aux couche dessou (sur des VM à OS AIX et Linux).
Par ailleurs, nous avons un ordonnanceur externe pour les traitements applicatifs et une partie des traitements techniques (par exemple j'arrête les tomcat d'une appli puis je lance le recalcul des stats de la DB associée puis démarrage des tomcat dans le bon ordre le tout réparti sur une 20aines de serveurs, ok, l'exemple est un peu bateau).

Je me suis donc principalement intéressé à l'impact sur mon quotidien sachant que quasi tout les avantages / inconvénients pour un DEV ne me concernent pas (et pas de souci là dessus, chacun son métier).

Vu que je vais recevoir un "tout en un", il va falloir que les spec de DEV incluent d'autres fonctions que juste le mini-service afin d’intégrer celui-ci dans un environnement ou le monitoring de l'appli/"OS".
De plus, un partie des problématiques de perf repérée ce jour par les sysadmin devra être vue par l'éditeur et pour l'instant, je ne leur fait pas confiance pour dépenser plus de budget pour faire un bon produit en terme d'utilisation technique.
Avec le modèle proposé, je n'aurait plus aucun argument pour contrer un support.

C'est un point de vue sur la généralisation de ce mode de déploiement, l'idée technique est bien sur elle est correctement réalisée, mais j'ai des doutes sur la mise en œuvre.

Pour la séparation des interfaces réseaux admin/service/NAS.
Chez nous, les VM on 3 interfaces virtuelles :
  • une qui va vers le NAS sans traverser de firewall et qui sert aussi pour les backup IP en direct sur l'équipement de backup.
  • une qui sert à venir dessus en tant qu'administrateur (par exemeple en SSH)
  • une pour le service applicatif
Ca permet de bien s'y retrouver, gérer plus facilement les firewall (notamment d'avoir des FW périphériques différents) et les routes réseau et le diagnostique

Sur les appliance que je vois, il n'y a en général qu'une interface virtuelle avec une seule IP qui ne supporte qu'une donc passerelle et pas toujours la possibilité de rajouter des routes ce qui complique un peu le management.
Encore une fois, ca n'est pas une limite inhérente à la techno choisie mais des choix de mise en oeuvre au plus simple / moins couteux constatés.

PhilippeMarques

  • Expert
  • *
  • Messages: 859
  • SomeWhere
Linux (et tous les autres OS) c'est *bientôt* du passé
« Réponse #53 le: 19 octobre 2016 à 20:19:15 »
Cela a l'air pas mal :)
------------------------------------------------------------
Starting VM: 'Demo_Service.img'
------------------------------------------------------------
qemu-system-i386 -drive file=Demo_Service.img,format=raw,if=ide -device virtio-net,netdev=net0,mac=c0:01:0a:00:00:2a -netdev tap,id=net0,script=/root/IncludeOS_install/etc/qemu-ifup -nographic -smp 4 -m 128 -k en-us
================================================================================

                           #include<os> // Literally

================================================================================
     [ Kernel ] Stack: 0x9fb6c
     [ Kernel ] Boot args: 0xa58 (multiboot magic), 0x746 (bootinfo addr)
     [ Kernel ] Max mem (from linker): 128 MiB
                * Low memory: 640 Kib
                * High memory (from linker): 131072 Kib
     [ Kernel ] Assigning fixed memory ranges (Memory map)
                * Unavailable memory: 0x8100000 - 0x880ffffe
                * Last chunk of memory: 0x880fffff - 0xffffffff
     [ Kernel ] Printing memory map
                * Statman 8000 - 9fff (Statistics, 8192 / 8192 bytes used)
                * Kernel / service main stack a000 - 9fbff (N/A, 613376 / 613376 bytes used)
                * EBDA 9fc00 - 9ffff (Extended BIOS data area, 1024 / 1024 bytes used)
                * VGA/ROM a0000 - fffff (Memory mapped video memory, 393216 / 393216 bytes used)
                * ELF 100000 - 20e508 (Your service binary including OS, 1107209 / 1107209 bytes used)
                * Pre-heap 20e509 - 26cfff (Heap randomization area (not for use)), 387831 / 387831 bytes used)
                * Heap 26d000 - 80fffff (Dynamic memory, 282624 / 132722688 bytes used)
                * N/A 8100000 - 880ffffe (Reserved / outside physical range, 2147483647 / 2147483647 bytes used)
                * N/A 880fffff - ffffffff (Reserved / outside physical range, 2012217345 / 2012217345 bytes used)
       [ INTR ] Creating interrupt handlers
                + Default interrupt gates set for irq >= 32
       [ ACPI ] Reading headers
                OEM: BOCHS  Rev. 0
       [ ACPI ] Reading APIC information
                LAPIC base: 0xfee00000  (flags: 0x1)
                -> CPU 0 ID 0  (flags=0x1)
                -> CPU 1 ID 1  (flags=0x1)
                -> CPU 2 ID 2  (flags=0x1)
                -> CPU 3 ID 3  (flags=0x1)
                I/O APIC 0   ADDR 0xfec00000  INTR 0x0
                IRQ redirect for bus 0 from IRQ 0 to VEC 2
                IRQ redirect for bus 0 from IRQ 5 to VEC 5
                IRQ redirect for bus 0 from IRQ 9 to VEC 9
                IRQ redirect for bus 0 from IRQ 10 to VEC 10
                IRQ redirect for bus 0 from IRQ 11 to VEC 11
                LAPIC id: 0  ver: 50014

       [ APIC ] Enabling BSP LAPIC
                APIC_BASE MSR is now 0xfee00900

     [ IOAPIC ] Initializing
                Base addr: 0xfec00000  Redirection entries: 24
     [ IOAPIC ] Done
       [ APIC ] SMP Init
       [ APIC ] Initializing APs
       [ APIC ] Starting APs
                AP 1 started at 0x2b4000
                AP 2 started at 0x2b6000
                AP 3 started at 0x2b8000
       [ APIC ] All APs are online now

        [ BSP ] Enabling interrupts
                Enabled redirected IRQ 0 -> 2 on lapic 0
[ PCI Manager ] Probing PCI bus
                |
                +--+ Host Bridge (0x0)
                |
                +--+ ISA Bridge (0x1)
                |
                +--+ Mass Storage Controller
                |  +--+ Driver: Not found
                |
                +--+ Other Bridge (0x80)
                |
                +--+ Display Controller
                |
                +--+ Ethernet Network Controller (0x0)
                |  +--+ Driver: Found
     [ Virtio ] Attaching to  PCI addr 0x18
                [x] Vendor ID is VIRTIO
                [x] Device ID 0x1000 is in a valid range (Virtio LEGACY)
                [x] Device Revision ID (0x0) supported

                [ Resource @ BAR 0 ]
                  Address:  0xc000 Size: 0x20
                  Type: IO Resource

                [ Resource @ BAR 1 ]
                  Address:  0xfebd1000 Size: 0x1000
                  Type: Memory Resource

                [x] Unit has valid I/O base (0xc000)
                [*] Reset device
                [x] Device has 3 MSI-X vectors
                MSI-X vector 0 pointing to cpu 0 intr 96
                MSI-X vector 1 pointing to cpu 0 intr 97
                MSI-X vector 2 pointing to cpu 0 intr 98
     [ Virtio ] Initialization complete
  [ VirtioNet ] Driver initializing
                [x] Negotiated needed features
                [x] Negotiated wanted features
                [x] Device handles packets w. partial checksum
                [x] Guest handles packets w. partial checksum
                [x] There's a control queue
                [x] Queue can handle any header/data layout
                [x] We can use indirect descriptors
                [x] There's a Ring Event Index to use
                [ ] There are multiple queue pairs
                [x] Merge RX buffers
                [x] RX queue assigned (0x5c5000) to device
                [x] TX queue assigned (0x5c9000) to device
                [x] CTRL queue assigned (0x5cd000) to device
  [ VirtioNet ] Adding 128 receive buffers of size 1546
                [x] Valid Mac address: c0:01:0a:00:00:2a
                [x] Signalled driver OK
  [ VirtioNet ] Driver initialization complete
                [x] Link up

                |
                o
    [ Devices ] Listing registered devices
                |
                +--+ NIC
                |  + #0: VirtioNet Driver
                |
                o
     [ Kernel ] Estimating CPU-frequency
                |
                +--(10 samples, 0.000100 sec. interval)
                |
                +--> 2289.853328 MHz
       [ APIC ] Measuring APIC timer...
                Enabled redirected IRQ 0 -> 2 on lapic 0
       [ CMOS ] Setting 24 hour format UTC
     [ Kernel ] Calling custom initialization functions
     [ Kernel ] Starting IncludeOS Demo Service
================================================================================
      [ Inet4 ] Bringing up a IPv4 stack
      [ Inet4 ] Negotiating DHCP...
     [ DHCPv4 ] Negotiating IP-address (xid=2316641875)
      [ Inet4 ] Network configured
                IP:             10.0.0.42
                Netmask:        255.255.255.0
                Gateway:        10.0.0.1
                DNS Server:     10.0.0.1
*** TEST SERVICE STARTED ***
================================================================================
 IncludeOS v0.9.3-10-g65ffb9c
 +--> Running [ IncludeOS Demo Service ]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

BadMax

  • Client Free adsl
  • Modérateur
  • *
  • Messages: 3 328
  • Malissard (26)
Linux (et tous les autres OS) c'est *bientôt* du passé
« Réponse #54 le: 21 octobre 2016 à 16:45:01 »
Pour la séparation des interfaces réseaux admin/service/NAS.
Chez nous, les VM on 3 interfaces virtuelles :
  • une qui va vers le NAS sans traverser de firewall et qui sert aussi pour les backup IP en direct sur l'équipement de backup.
  • une qui sert à venir dessus en tant qu'administrateur (par exemeple en SSH)
  • une pour le service applicatif
Ca permet de bien s'y retrouver, gérer plus facilement les firewall (notamment d'avoir des FW périphériques différents) et les routes réseau et le diagnostique

Ayant pratiqué cette segmentation je plussoie sur les avantages de configuration des règles de firewall quand on a plusieurs interfaces réseaux distinctes en terme d'utilisation. N'avoir qu'une seule adresse IP/Vlan est vraiment pénible surtout quand un auditeur sécurité demande à avoir un aperçu sur les flux autorisés.


Thornhill

  • Client SFR fibre FTTH
  • *
  • Messages: 992
  • Saint-Médard-en-Jalles (33)
Linux (et tous les autres OS) c'est *bientôt* du passé
« Réponse #55 le: 27 octobre 2016 à 19:41:32 »
Vous avez pensé à la maintenance ?
Si chaque "vm" embarque ses piles logicielles de base qu'on sort donc d'un OS commun, imaginez le chemin de croix pour patcher une faille de sécurité commune, avec les centaines d'éditeurs qui vont devoir produire leur patch !
C'est déjà pénible avec X OS différents, mais alors si on passe à Y applis avec Y=100*X...

kgersen

  • Client Bouygues FTTH
  • Modérateur
  • *
  • Messages: 5 551
  • FTTH 1Gb/s sur Paris (75)
Linux (et tous les autres OS) c'est *bientôt* du passé
« Réponse #56 le: 28 octobre 2016 à 22:23:25 »
Vous avez pensé à la maintenance ?
Si chaque "vm" embarque ses piles logicielles de base qu'on sort donc d'un OS commun, imaginez le chemin de croix pour patcher une faille de sécurité commune, avec les centaines d'éditeurs qui vont devoir produire leur patch !
C'est déjà pénible avec X OS différents, mais alors si on passe à Y applis avec Y=100*X...

on est en 2016... il ne s'agit pas d'aller 'a la main' accéder a chaque 'vm ou 'image' pour patcher, mettre a jour ou administrer.

En production, tout ce passe au sein d'un système qui s'auto-heal, s'auto-corrige et ou tout ses aspects de maintenance sont pris en compte des le départ via l'utilisation d'un orchestrateur.

Au cours des derniers années il y a eu de gros travaux et avancées sur ces outils d'automation, orchestration et de gestion de clusters ou d'essaims (swarm).

cf Docker Swarm, Apache Mesos, Kubernetes, etc

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 565
  • La Madeleine (59)
Linux (et tous les autres OS) c'est *bientôt* du passé
« Réponse #57 le: 28 octobre 2016 à 22:36:01 »
kgersen a une vue "google" de la situation;

Thornhill

  • Client SFR fibre FTTH
  • *
  • Messages: 992
  • Saint-Médard-en-Jalles (33)
Linux (et tous les autres OS) c'est *bientôt* du passé
« Réponse #58 le: 28 octobre 2016 à 23:03:55 »
on est en 2016... il ne s'agit pas d'aller 'a la main' accéder a chaque 'vm ou 'image' pour patcher, mettre a jour ou administrer.

Tu n'as pas bien compris le sens de ma remarque : tu confonds nombre de VM et nombre d'éditeurs.
Si chaque éditeur d'applis embarque sa propre libC, son propre bash, etc, bref ses propres fonctions de bases autrefois communes aux OS classiques, tu vas multiplier les sources de fournisseurs logiciels, et tu vas pleurer pour maintenir ça, avec ou sans orchestration.
Et ce, que tu ais 200 ou 10000 VM...


kgersen

  • Client Bouygues FTTH
  • Modérateur
  • *
  • Messages: 5 551
  • FTTH 1Gb/s sur Paris (75)
Linux (et tous les autres OS) c'est *bientôt* du passé
« Réponse #59 le: 28 octobre 2016 à 23:27:07 »
Tu n'as pas bien compris le sens de ma remarque : tu confonds nombre de VM et nombre d'éditeurs.
Si chaque éditeur d'applis embarque sa propre libC, son propre bash, etc, bref ses propres fonctions de bases autrefois communes aux OS classiques, tu vas multiplier les sources de fournisseurs logiciels, et tu vas pleurer pour maintenir ça, avec ou sans orchestration.
Et ce, que tu ais 200 ou 10000 VM...

en quoi c'est différent de maintenant ? Soit l'éditeur fourni un binaire soit il fournit un source. Dans le 1er cas c'est a lui de fournir une nouvelle version, dans l'autre tu recompile/rebuild avec la libC ou le "libOS" a jour.

Je ne comprend pas bien pas la 'complexité' que tu vois en terme de maintenance.

 

Mobile View