Microsoft va travailler à l’implémentation au sein de Windows d’un client et d’un serveur OpenSSH. Une annonce qui n’était clairement pas attendue et qui en accompagne une autre : l’éditeur va contribuer au projet, ce qui laisse espérer une intégration renforcée avec le temps.
Une contribution à OpenSSH
OpenSSH est un outil particulièrement connu des administrateurs système travaillant avec des serveurs sous Unix ou Linux. Il permet notamment l’administration distante avec des lignes de commande tout en établissant des communications sécurisées avec les machines concernées.
Mais dès qu’il s’agissait de parcs hétérogènes avec des machines Windows, OpenSSH ne pouvait plus vraiment être utilisé, sauf en passant par exemple par PuTTY, qui permet d’envoyer des commandes depuis Windows vers d’autres machines.
De fait, l’annonce de Microsoft est importante : l’éditeur va aider et contribuer au projet OpenSSH. Conséquence, un client et un serveur seront développés pour Windows, ce qui permettra donc l’émission de commandes depuis le système, mais également leur réception depuis des machines sous Linux ou Unix.
La société indique avoir d’abord vérifié dans les solutions tierces ce qui pouvait éventuellement être adapté. On se demande d’ailleurs si elle n’a pas cherché à racheter un ou deux éditeurs dans ce domaine. Mais elle ajoute ne rien avoir trouvé de satisfaisant et s’être rendu compte qu’il valait mieux adopter directement « une solution éprouvée » en lui fournissant « une intégration étroite « avec Windows ».
L'équipe PowerShell en charge de l'intégration
Au sein de Windows, la compatibilité avec OpenSSH se fera par l’équipe de PowerShell, un choix qui semble logique. Point intéressant, Microsoft rappelle que ce n’est pas la première fois que son équipe se penche sur le support de SSH (Secure Shell). Elle avait déjà tenté le « coup » pendant le développement des versions 1 et 2 de PowerShell, mais c’est bien le « changement de culture » au sein de l’entreprise qui a permis cette fois la bascule.
Et Angel Calvo, responsable au sein de l’équipe PowerShell, remercie d’ailleurs la communauté qui, apparemment, a réussi à se faire entendre. Cependant, il n’y a aucune date annoncée pour l’arrivée du client et du serveur.
Il faudra sans doute au moins plusieurs mois avant que des préversions ne soient proposées, l’équipe n’étant pour l’instant que « dans les premières phases de la planification ». Autant dire que le développement n’a pas commencé et que Windows 10 n’en sera pas équipé. Toutefois, l’arrivée d’une préversion justement pour Windows Server 2016 n’est pas à exclure.
Commentaires (229)
#1
Il était temps ! C’est une bonne nouvelle :-)
#2
Incroyable, peut-être veulent-ils enfin se lancer sur le marché des serveurs ?
#3
Pratique …
Ca m’évitera d’utiliser ce programme qui n’est plus supporté :
Adresse Web :
http://www.toutes-les-solutions.fr/phpbb/topic593.html
… pour accéder à notre serveur Web.
#4
#5
Ca existe un OS Windows sans interface graphique ?
#6
MS-DOS
" />
" />
Edit : Ha bha non.. c’était pas un Windows.
#7
#8
#9
Un serveur OpenSSH sous Windows…
" />
Vivement IIS sous Linux…
#10
Quel est l’intérêt d’avoir des fenêtre en ASCII ?
" />
+1 à maestro321 et dematbreizh quoi.
edit :
#11
Sympathique nouvelle qui va effectivement faciliter la vie de l’administrateur. Cool.
#12
Ça me fait penser à l’ajout du copier/coller sur les iPhone
" />
#13
Ca fait 10 ans que j’attends un terminal digne d’un linux… c’est d’autant plus vrai aujourd’hui avec toutes ces techno qui demandent pas mal de manips a la mains (node.js, bower…).
Meme MS s y met avec ses nouveaux outils plus “open” qui demandent de passer par le super “powershell” mais bon, l’ide passe avant tout :x
#14
Allez, encore un effort et on aura le support des tunnels X11 dans SSH sous Windows.
#15
#16
#17
Chouette, de nouvelles failles de sécurité en vue :p
#18
Et encore, Server Core est encore en mode graphique, vu qu’on a des fenêtres d’Invite de commande (et non DOS, qui n’existe plus en tant que tel, mais comme VM).
Sinon, je crois que ce sera le nano qui n’aura plus rien comme interface. D’ailleurs, si je me souviens bien, on pourra même plus se connecter en local, uniquement à distance.
#19
#20
#21
Server Core et Windows IoT ont une interface graphique.
Windows nano server n’en aura pas (on peut le voir ici https://www.youtube.com/watch?v=mKe_XDNAmZ8), c’est du pur ligne de commande.
#22
Ca a l’air prometteur pour le coup !
#23
Ils sont en train de le sentir le vent tourner chez Microsoft !!!
" />
Dois-je m’en réjouir ? je sais pas trop, ils sont tellement vicelards que l’on pense à tout en même temps …
#24
Question con, ça sera libre ou pas ?
#25
Le support de X11 dans Windows ? Pourquoi pas. Alors oui, dans les distributions grand public de Linux, on est en train de passer doucement à Wayland. Mais faut pas oublier qu’il n’y a pas que Linux dans le monde Unix. En entreprise, y’as encore pas mal de HP-UX, d’AIX, etc, où sur certains, il y a du X11 pour certains logiciels.
Et encore, HP-UX et AIX, c’est pas si vieux que ça. Le pire que j’ai vu, c’était du serveur Bull. Au boulot, on a coupé le dernier que l’on avait suite à une migration de logiciel. Quand j’ai vu la date de mise en service et l’uptime, je me suis retrouvé sur les fesses. Il avait été mis en place 6 mois avant ma naissance et n’a JAMAIS été arrêté! Ca c’était du matériel! Bientôt 30 ans d’utilisation non stop. Je connais pas beaucoup de serveurs en entreprise qui peuvent se vanter d’avoir autant d’uptime.
#26
Exactement, le nouveau PDG de Microsoft a senti le vent venir bien longtemps avec Ballmer et il fait tout pour prendre le cap vers tout ce qui est Cloud.
Suffit de voir les derniers résultats financiers de Microsoft pour voir que le Cloud en général prend de plus en plus de place dans le CA et les bénéfices de la boite. A long terme, leur but, c’est que tout soit dans le cloud et que l’on paie un abonnement pour en profiter. Après tout, ça marche très bien pour Office 365 et Azure.
#27
#28
Version “core” : oui et cela est en prod chez bcp de client de Thalés …
" />
Par contre c’est juste l’enfer à gérer car il faut passer par :
Powershell,
VBS,
WMI,
etc …
…. pour gérer de manière complète un serveur en mode core.
… Ils leur restent juste à écrire le bash avec lequel on gère tout un serveur.
Mais c’est bien Microsoft est en train de tout pomper chez unix/linux : ils prennent la bonne voie.
#29
Parcequ’ils sont supporté? et qu’ils sont probablement plus performant / sécured par conséquent 
" />
#30
Et puis tu as quand même 2 programmes différent (même si c’est le même nom principal) tu as celui pour les lignes de commande (equivalent putty) et celui pour les transfère de fichiers (equivalent winscp) :p
#31
Il auraient pu racheter SmartFTP, il est vraiment bien !
#32
tout à fait pour l’uptime !
" />
Alors ok les “anciens” ne redémarraient jamais leurs babasses par contre quand il y avait des coupures de courants (programmées o pas) : c’était souvent folklo !!!!
#33
#34
#35
la t’es dur quand même …
" />
#36
#37
THE TROLL.
" />
#38
Yep, c’est aussi exactement ce que j’utilise :) Et ça fonctionne très bien!
#39
Un client SSH (et bien plus) pour windows : MobaXterm
 http://mobaxterm.mobatek.net/download-home-edition.html
#40
#41
#42
Sinon FileZilla gère très bien le SFTP …
#43
Oui, ça s’appelle le Core mode de windows server :)
edit: maxi grilled
#44
Pour faire en sorte que ça continue de fonctionner
" />
#45
payant cher ami, mais très bien en effet !
sinon mRemoteNG !!!! GNU/GPL sir ….
(filzela fait aussi le taf pour le transfert de fichiers)
#46
#47
EXACTEMENT.
Un poste non connecté au web (style station mao avec un hackintosh) se comporte à merveille depuis des années …. : les maj tuent vos machines , sachez le !!!
#48
essaies Debian …tu vas découvrir un nouveau continent !!!!
#49
pourquoi faire du ssh pour arriver en powershell alors qu’on peut deja ouvrir des powershell a distance ? :/
#50
#51
#52
Et si le meilleur moyen de gérer un OS (ou une intelligence artif) n’étais aucunes de ces méthodes ?
… intéresses toi à l’ordinateur quantique : un nouveau monde ….
#53
j’ai connu un vieux loulou qui tournait sur une debian 3 : cela te poses un problèmes ?
Elle faisait exactement ce qu’il voulait sur du vieux matos, pourquoi mettre à jour ou changer ?
#54
interopérabilité
" />
#55
ou tu le geres a distance avec des outils comme server manager.
les ui sont retires petits a petis pour la gestion des services de toute facon donc autant apprendre le powershell, ce qui est pas bien complique
#56
#57
Debian n’est pas exempt de failles de sécurité ^^
#58
pas compliqué ?
hum, pas sure : powershell est orientée objet cela change beaucoup de chose !!!!
#59
#60
C’est une excellente nouvelle !
Pour ma part je vois ça comme un canal, dans lequel je fais passer ce que je veux (du Powershell en l’occurrence).
J’ai du mal à comprendre la plupart des commentaires, ça balance beaucoup je trouve, c’est dommage.
#61
#62
#63
#64
au hasard, samba4 ?
sur un FreeNAS par ex
#65
Pas mieux.
Microsoft développe un système d’exploitation commercial, ils n’ont pas toutes les libertés qu’il faudrait avoir pour développer ce genre de programmes.
Lorsqu’ils prennent des décisions de types : Est-ce que ce choix technique désavantage nos ventes ?, ils nuisent à la qualité de leur système.
Ils ne peuvent se soustraire par magie de leur essence même de vendeur de système qui doit plaire.
#66
Comprends pas trop le critère avec ou sans interface graphique pour “comparer” aujourd’hui la qualité d’un OS serveur.
" />
Certes, un mode console est très léger pour l’accès à la gestion mais il me semble qu’on est très loin du contexte de l’époque ou l’accès console avait légitimement le monopole (bande passante -même locale-, puissance requise pour l’affichage, taille d’écran, conception rudimentaire des outils d’administration, …).
Pour avoir une dedibox en U2250, il va de soit que je n’ai même pas imaginé l’administrer en X mais je ne vois pas ce que ça aurait de choquant, si le matos suivait.
Par ailleurs, ce n’est pas parce que Windows a une interface graphique qu’on est obligé de passer par du rdp sa gestion
Le tout ou rien a encore de belles années devant lui apparemment.
#67
#68
#69
#70
Oui enfin bon, sinon y’a cmder http://gooseberrycreative.com/cmder/)
Ca remplace l’invite de commande ms-dos qui n’a pas évolué depuis windows 95, y’a pratiquement toutes les commandes linux, la colorisation, le ssh, le grep, les onglets etc …
#71
#72
La meilleur combinaison des deux : Bitvise !
#73
#74
Cela ne résoud que la forme du problème, pas le fond. On ne cherche pas à tout prix à utiliser une ligne de commande.
Dans le monde Unix, la règle qui fait foi, c’est de développer les fonctions le plus simplement possible. Toute l’intelligence et la complexité des outils viennent de l’intéraction de ces fonctions entre elles avec les opérateurs de flux (pipe, redirection, …). Or, dans l’idéal, lorsque tu clique un bouton, cela devrait être envisageable que de pouvoir lire le log de toutes ces opérations, afin d’être capable de reproduire ou modifier. C’est pourquoi beaucoup d’administrateur serveur refuse un GUI. Si, par malheur, le développeur du GUI a codé dans la logique du GUI une forme d’intelligence, tu ne peux plus reprodruire la même suite d’opération sur d’autres machines sans être dépendant dudit GUI. Et c’est un problème conséquent car tu entres dans une affaire de dépendance qui peut n’avoir ni fin ni début.
#75
ben, LDAP ^^
AD c’est l’implémentation MS de LDAP, donc …
#76
Ai-je dit le contraire ?
#77
Merci beaucoup, c’est très pratique.
J’utilisais Console2 avec GoW, cmder a l’air pas mal et surtout plus joli.
#78
Et un noyau Unix c’est pour quand ?
#79
#80
1 - connais pas Terminal (à tester donc)
Mais j’ai lu :
“Serious problem with this release. Connections are dropped at random, and when a connection is dropped (or sometimes when deliberate… (more)”
2 - Leduf’ , a ton service :http://www.ledufakademy.fr/?p=330
Samba 4.x est un AD killer … (comme le pinard il va se bonifier en veillisssant !!) il est super simple !!!
#81
#82
Les gens ne se battent pas,
Ce n’est que virtuel,
Alors moi, cela me va.
Je préfère cela plutôt que de me retrouver à Gaza dans une salle de classe, ou sur un marché Irakien ….
#83
Nous avons là une divergence de point de vue ;)
#84
#85
Freenas samba 4, avec domaine AD ?
euh je crois pas qu’il soient en 4.x …
Car sinon vl’a la galère avec le GUI (je n’ai jamais à freenas pour cela …)
#86
Doublon.
#87
C’est juste un site perso (sans aucune prétention), pour partager mes tests techniques .. alors bon l’orthographe , la relecture : c’est pas mon point fort.
J’espère que tu voudras bien m’en excuser ?
#88
On peut dire que M$ se sort vraiment les doigts du c..c.. conduit auditif.
#89
#90
#91
quand tu auras une attaque réseau massive : tu comprendras l’intérêt de gérer l’incident en ligne de commande … surtout sur des liaisons distantes
" />
Pourquoi , d’après toi, TOUT les appareils réseaux (notamment les coeurs) se gérent en ligne de commande et pas en gui ?
#92
#93
eh bien teste … ce bon pinard mon ami !!!!
#94
Yup et on peut le coupler à Putty Pageant de mémoire
#95
Ceci est une revolution !!
Pour un fois qu’in peut tiliser cette phase sans se faire sworder …
#96
#97
#98
#99
sympa , je vais tester.
#100
oh milles excuses.
J’ai tester “puppet” : c’est juste énorme !!!!
PuppetLabs j’ai fait une maquette : il es vraiment bien.
#101
#102
un vieux patchnote de l’année derniere, trouvé au hasard
“Release Notes for FreeNAS 9.2.1.1-RELEASESamba (SMB/CIFS support) upgraded to version 4.1.4, with select key fixes cherry-picked from 4.1.5.”
#103
l’éditeur va contribuer au projet, ce qui laisse espérer une intégration renforcée avec le temps.
Ils veulent ajouter une backdoor pour la NSA ?
#104
Une très bonne nouvelle, pour deux raisons :
Et éventuellement une troisième raison : ça clouera le bec à ceux qui mettent en opposition « Microsoft » et « Logiciel Libre ». Microsoft aujourd’hui fait du logiciel libre, et s’ouvre à l’interopérabilité avec les systèmes UNIX, et c’est tant mieux ! J’espère qu’ils continueront longtemps dans cette voie.
#105
ha !
" />)
tu forces ~ à la connexion ?
solution pifométrique, j’ai abandonné l’idée d’AD ou un équivalent sur un réseau où je suis tout seul (et ma copine refuse que je touche à son ordi
#106
… je pense que notre ami n’a jamais entendu parlé de scheduler pro genre $univers ou m control ….
#107
Ca ne fonctionne pas chez moi, il lui manque la DLL api-ms-win-crt-runtime-l1-1-0.dll.
J’ai dû installer une maj des runtimes C++ :
http://download.microsoft.com/download/0/4/1/041224F6-A7DC-486B-BD66-BCAAF74B691…
#108
hum j’ai testé il y 4 ou 5 mois et c’était encore une 3.x … donc ils auraient intégré la jonction à AD ?
#109
#110
J’essaie de comprendre de quoi on parle mais je n’y arrive pas.
Dur !
#111
#112
Mouaih …
#113
#114
toi avec ton avatar tu m’ennerves … à chaque fois !!!
(c’est quoi son nom au juste ??)
#115
#116
Le client SSH va servir à pouvoir se connecter vers d’autres serveurs qui ne sont pas Windows.
Le serveur SSH va permettre de se connecter aux serveurs Windows à partir de serveur ne l’étant pas.
Dans les deux cas, ça renforce l’interopérabilité.
#117
#118
#119
#120
sais pas, moi je tourne avec FreeBSD (une vielle 9.1, scripts d’install en cours d’adaptation pour la 10)
#121
IIS je sais pas, mais avec OWIN et .net core on peut maintenant faire tourner du asp.net sur Linux et Mac OS X ^^
#122
De quel cas d’usage tu parle ?
A une époque on pouvait se connecter en ssh depuis Windows sous Putty et utiliser XMing comme serveur X et ça marchait très bien : Il suffisait d’activer le X11 forwarding sur Putty
#123
#124
#125
#126
#127
#128
oui beaucoup de choses justes dans ce texte.
Je rajoute que les serveurs RedHat (les RHEL) s’installent par défaut avec le GUI.
Mais bon les admin les configurent en cli … normal !
#129
Tu dis cela parce que tu te positionnes en tant qu’utilisateur de poste de travail.
Au niveau d’un serveur c’est beaucoup moins important (voir pas souhaitable du tout car ça consomme des ressources).
Il nous arrive de déployer des images et de lancer des scripts à distance pour installer et configurer des serveurs windows. Ces machines n’ont ni écran ni clavier et le service “remote desktop” n’est même pas activé. On envoie des commandes et on consulte les événements à distance. Le fait de pouvoir utiliser SSH simplifiera l’administration car on pourra utiliser les mêmes outils pour administrer les machines linux, unix et windows (et les consoles vmware esx, etc..)
#130
Pour un ldaphttps://www.fusiondirectory.org/
jamais testé , le poret semble pas mal et ne souffre pas beaucoup de commentaire négatif.
#131
Shalom Harlow
https://www.pinterest.com/cloverbelle/shalom-harlow/
#132
#133
#134
ouaih sauf que MS est un cancer quand il impose son os sur les pc de grande surface etc etc.
" />)
Et c’est mon avis définitif.
Alors qu’un linuxmint, ubuntu ou fedora est aussi bien (voir mieux
#135
#136
#137
Sinon, il y a openSSH via Cygwin. En plus, contrairement à PowerShell, on y gagne un truc qui ne fait pas qu’imiter un shell et rootFS unix comme ce dernier mais sur lequel aucun script voulu portable d’un OS à l’autre ne passera (car les options de commandes identiques ne sont pas compatibles).
Mais bon, manquera un équivalent du serveur X pour pouvoir tirer la quintessence, cad autre chose que du mode texte. Ca leur évitera la complexité de coder le support côté serveur du ssh -X (ou -Y).
Mais bon… enfin! C’est vraiment le truc sans lequel je ne sais pas vivre.
#138
#139
Cela s’appelle Windows Server Core edition. Et c’est bien pratique.
#140
#141
Le GUI a l’avantage d’être accessible facilement pour un SysAdmin venant d’un autre écosystème.
Exemple réel: l’équipe Unix doit intégrer une appli Win64 dans son infra (pas le choix). Je déploie un Win 2008 Core. 2 jours après on me demande d’installer le GUI car les admins ne savaient pas comment utiliser powershell ou les commandes ligne de base (cf netsh). En fait, ils auraient pu y arriver mais avec une courbe d’apprentissage importante.
Autre exemple inverse: je dois installer un load balancer qui roule sous une saveur Linux quelconque. L’éditeur a développé un GUI qui me permet de configurer le LB en quelques minutes. En utilisant seulement le CLI, il m’aurait fallu beaucoup plus de temps (rtfm, etc.) ou emmerder un sysadmin linux.
#142
Terrible MobaXterm, en plus c’est développé par un Français. C’est la boîte à outils ultime sous Windows, c’est portable, c’est parfait
#143
Dans le premier cas tu passe ta semaine à comprendre comment ca marche, quels paquets sont compatibles entre eux et lequels ne le sont pas.
Dans le second un singe savant est capable de faire ton job, et je considère que le mien c’est justement de remplacer les utilisateurs qui sont plus cons qu’un singe savant.
Le but ultime d’un logiciel c’est que la prise en main/l’ergonomie permette une compréhension immédiate de “comment le faire fonctionner”. Donc à partir du moment ou tu tape une ligne de commande c’est que les dévellopeurs ont mal fait leur boulot.
Et pour info je dois découvrir 1 OS et 3⁄4 soft par mois. Donc si à chaque fois faut passer une semaine à se former et une autre à develloper des scripts je vais travailler vraiment tard le soir.
#144
#145
#146
#147
#148
Son avatar me fait penser à ça :
" />
Adresse Web :
https://youtu.be/hkuY_qDoVrI?t=131
#149
#150
Sous ms tu veux configurer tes dns pas te problème tu modifie ta carte réseau
Sous linux j’ai du passé une heure à expliquer à mon client que t’avais beau modifier /etc/resolv.conf si t’avais fait un system-config-network ca le ré écraserai au démarrage. Sans compter que tu peux les foutre dans le ifcfg-ethX.
Fin bref pour beaucoup toucher aux 2 j’irais pas chier sur l’un ou l’autre.
#151
Prochaine étape : ajouter Vim
#152
#153
Yep ici => https://dev.windows.com/en-us/iot
#154
Mais le Scripting c’est qu’une rustine parce que les devs OS/appli ont mal fait leur boulot.
Je vais prendre un exemple tout con :
En une semaine n’importe quel mec pas con est capable d’installer un solution cyberArk gérant l’utilisant de milliers de compte à privilège. Pareil avec un AD/exchange ca a été bien développé t’as rien à scripter juste à configurer.
Ca fait un mois que j’essaie de monter une maquette samba3/zimbra avec un seul openLDAP, bas j’ai pas encore trouvé la solution.
#155
L’exécution de commandes depuis vim n’a pas de prix. Et si tu fais un peu de dev, les avantage sont innombrables
" />
#156
#157
#158
#159
Microsoft supportera le SSH dans le Windows.
" />
#160
Peut être, mais ce qui est aussi impressionnant que cet uptime, c’est le fait que ça n’ait pas coupé depuis 30 ans!
Après, ça ne faisait pas parti des machines dont je m’occupais. D’ailleurs, je ne savais même pas qu’elle existait, j’ai découvert son existence quand on a changé notre infrastructure dans une nouvelle salle info.
#161
#162
Dommage, c’était bien OpenSSH. Maintenant il va planter avec un simple “cd ~” (en plus de planter le serveur)
" />
#163
Ce n’est pas qu’une histoire de ressource.
Plus il y a d’éléments chargés, plus il y a des risques de plantage et sur un serveur en prod, un plantage c’est le mal
Avec une interface graphique, il faut rajouter
=> toute la gestion des fenetres
=> pilote graphique
=> pilote souris
=> peut-etre même un pilote sonore
=> et j’en passe (bouton des menus, gestion menu contextuelles souris, barre des taches etc …)
Ca rajoute potentiellement bien + d’éléments “à risque”.
Un ex dans le matériel, c’est les cartes mères haut de gamme qui ont le taux de retour SAV le + haut (cf hardware.fr) pour une raison simple, intégration de tout un tas de feature qui rajoute donc de potentielles problèmes.
#164
#165
Je parle du cas de la news : le support de ssh natif dans Windows, sans logiciel tiers.
#166
Ca a l’air intéressant comme truc ceci dit 
" />
#167
J’ai jamais vu un shell en dash qui ne fonctionne pas avec bash. Tu as des exemples ?
L’inverse n’est bien sûr pas vrai, il suffit d’avoir un seul “bashism”, et ils sont nombreux.
Et si on vise la portabilité, il vaut mieux de cantonner à ce qui est “Posix”.
#168
#169
#170
#171
#172
Je vais pas passer sur les trollers qui n’ont pas touché a un Windows depuis 95 et pensent que rien n’a changé….
Mais sinon concretement c’est quoi l’interet ?
Ne pas avoir a utiliser putty (ou autre) depuis Windows pour se connecter a une machine linux/unix ?
pouvoir se connecter en ligne de commande depuis un linux sur un windows ? (mais faudra derriere taper du powershell donc ca ralera tjs chez les bash addicts
#173
#174
#175
#176
#177
#178
#179
#180
#181
#182
#183
#184
#185
http://gooseberrycreative.com/cmder/
#186
#187
Samba4=ad+gpo
#188
Plus d’activité / plus de pognon pour le projet. C’est positif pour le projet et le contrôle du code.
" />
Sinon c’est quand même plutôt marrant que ce soit microsoft qui se retrouve non seulement à adopter, mais aussi à soutenir une brique de base du monde gnu/linux.
J’imagine que le principal risque serait que microsoft prenne plus ou moins le contrôle du bouzin par l’importance que l’entreprise prendrait de par sa participation élevée…
#189
#190
#191
Eh, apprends déjà a écrire français… puis a lire anglais pour les pages man…
la bonne vieille attaque sur l’ortho quand on a rien a dire…
pour ce genre de remarque essaye au moins de le faire sans fautes
#192
Je lis tant de commentaires de personnes qui parlent sans connaitre.
Je travaille sur Linux / VMware depuis pas mal de temps et j’entends à longueur de journées ce genre de préjugés.
Cela fait plusieurs années que les produits MS (AD, hyperv, sharepoint, exchange), pour parler de ce que j’ai vu en déploiement par mes collègues , sont totalement installables et administrables en Powershell.
Winrm existe aussi depuis les premières versions de powershell pour faire de l’admin distante et sécurisée en ligne de commande.
Bref, si on s’en tient à ce pourquoi le PowerShell est destiné, à l’administration des produits MS (et autres genre Veeam et VMware) le Powershell est très bien.
PS n’est pas destiné à remplacer bash.
L’ajout du SSH permettra d’utiliser des terminaux plus sexys et de piloter plus facilement via Unix/Linux des produits MS, comme par exepemple avec Nagios, Puppet ou Job scheduler.
#193
#194
#195
ben le gros souci en open source : c’est que bien souvent (voir toujours) il existe la brique , le composant , souvent très bien foutu (cf. puppet, fusiondirectory, glpi etc etc) …. mais on ne le connais pas, on n’en a pas connaissance de son existence même !
Le marketing est moins intense que chez les proprios .
#196
Devines !!!!
" />
#197
Oui, depuis Windows serveur 2008, avec les versions “Core”.
#198
#199
Pour info, avec Cygwin, on a déjà un client SSH, autrement plus sympa que putty/kitty.
#200
#201
#202
#203
#204
#205
#206
#207
Ah ouhais … Ca me rappelle le coup d’un vieux serveur Novell Netware oublié et muré dans un coin qui fonctionnait toujours …
#208
#209
Oui je sais ce qu’est Cygwin et j’ai bien compris ce que Microsoft proposera. Quant à Cygwin, ce n’est ni lourd ni difficile à installer.
#210
#211
Heu si … Windows serveur propose par défaut une interface graphique sur ces serveurs. Seulement dans certains cas d’instalation spécifique il t’est possible de n’en installer qu’une version minimaliste avec juste un terminal … dans une fenêtre.
#212
Les clients Linux peuvent s’authentiifer sur Samba4, pour les GPO effectivement je ne crois pas qu’il y ait d’équivalent établi.
#213
#214
#215
#216
#217
Effectivement, c’était un vieux Questar. Après, quand tu dis que c’est increvable parce que c’est du lowtech, comment dire… A l’époque, ça devait être du hitech
" />
Sinon, pour ceux qui ne voient pas l’intérêt du support de SSH dans Powershell, moi j’en vois un. Pouvoir lancer à distance sur un serveur Unix des scripts dont on a besoin pour intégrer le résultat dans le script Powershell.
Ca se voit souvent dans les cas où il y a une appli sous Unix, une appli sous Windows, et où l’on doit exécuter un script sur la machine Unix pour ensuite récupérer le fichier généré par ce script afin de le prendre et l’intégrer dans l’application Windows.
Et des cas comme ça, tu peux en rencontrer pas mal en entreprise, surtout dans les grosses.
#218
Ce dont il parlait, c’est en fait l’application de la philosophie Unix : le “Do One Thing and Do It Well !”
Au lieu de réinventer la roue et développer des usines à faire des usines à gaz pour chaque besoin, on a un arsenal d’outils légers spécialisés et redoutablement puissants capables d’être mis en relation.
Sans oublier un détail de poids dans l’approche du tout intégré : dès que c’est mal intégré, c’est une catastrophe. Tu évoques par exemple un besoin de faire de la planification, mais j’ai déjà vu des progiciels intégrant leur propre gestionnaire de jobs qui étaient une catastrophe. Pas souples, choix limités, gestionnaire buggé… Au final on était obligé de passer par une cron pour déclencher la tâche planifiée du logiciel, c’est con ! Sans oublier que le niveau de logs ou la capacité à agir sur le job sera de la roulette russe en fonction de l’outil. Et s’il y a une chose que je hais par dessus tout, ce sont les applications qui ne disent rien. Encore plus inutiles qu’un utilisateur qui va couiner “CA MARCHE PAAAAAAAAAAAAAS” elles vont cracher un “Error” et c’est partie pour le diagnostique à tâtons et le coût de l’incident qui explose. Et des devs internes de ce genre, j’en ai subi…
Accessoirement sur le même sujet, en entreprise, dans un gros SI on a tendance à avoir un ordonnanceur qui pilote tous les plans batchs de la boîte tel un TWS par exemple (comme ça y’a les remontés d’alerte, c’est standard, la planif est maîtrisée par tout le monde, etc). Si le logiciel est pas prévu pour s’interfacer avec hop, une boîte noire dans le SI de la boîte.
Encore si le progiciel apporte une solution technique standard (genre il a en bundle son propre Tomcat ou sa base Postgres/MySQL ce genre de truc) c’est facile à administrer et à faire évoluer car le socle technique est connu. Mais si l’éditeur a réinventé la roue pour chaque besoin, les admins derrière vont en chier et au final la boîte se retrouvera à payer du support constamment et dépendre de l’éditeur plutôt que de bénéficier de l’expertise de ses admins pour faire le boulot de base.
#219
Merci pour l’info c’est de la balle je garde
#220
De toute façon, pour qu’openssh espère percer un jour chez le grand public, il lui faut une interface graphique…
#221
#222
#223
#224
#225
#226
#227
#228