Samba est désormais disponible en version 4.6. Ce logiciel d’interopérabilité, qui fournit une compatibilité avec les protocoles SMB et CIFS, reçoit de nombreuses améliorations, notamment pour Kerberos, les pilotes d’imprimantes et de meilleures performances.
Samba est l’implémentation libre, sous licence GPLv3, des protocoles SMB et CIFS de Microsoft. Ce logiciel existe depuis environ 25 ans et a beaucoup évolué, particulièrement avec l’arrivée de la branche 4.X. La nouvelle version 4.6 apporte bon nombre de nouveautés, particulièrement sur la gestion des imprimantes dans des environnements mixtes.
Diverses améliorations, notamment de performances
Ainsi, pendant que le travail avance sur l’implémentation du protocole MS-PAR de Microsoft, Samba peut désormais envoyer des pilotes d’imprimantes depuis des machines sous Windows 10, corrigeant au passage plusieurs bugs. Le serveur d’impression créé par Samba apparaît désormais comme étant sous Windows Server 2003 R2 SP2.
Parmi les autres améliorations, on notera en particulier le support du multiprocessus du serveur Netlogon, de nouvelles options pour contrôler les ports TCP utilisés par les services RPC, une nette améliorations des performances pour certaines opérations Active Directory (notamment en cas de grand nombre d’objets), un renforcement de la commande « dns » dans samba-tool ou encore des améliorations diverses pour winbind.
Plus d'options en matière de chiffrement
Signalons également plusieurs changements sur le support de Kerberos. Certaines opérations sont ainsi réalisées en s’appuyant sur le fichier kbr5.conf généré par Samba. Un nouveau paramètre vient d’y être ajouté, « kerberos encryption types », pour définir le type de chiffrement.
L’utilisateur peut ainsi forcer un chiffrement en particulier, qu’il soit fort ou ancien. Le paramètre « all » est compatible avec l’ancien comportement de Samba, « strong » n’autorise que les algorithmes AES, tandis que « legacy » renvoie vers l’ancien RC4-HMAC-MD5, utilisé par les premières versions d’Active Directory. Pour l’équipe, ce réglage peut permettre de résoudre certains problèmes d’environnements mixtes.
Commentaires (70)
#1
Pourquoi est-ce qu’on a encore besoin de pilotes d’imprimante de nos jours ?
#2
#3
On pourrait aussi utiliser le PDF comme pivot universel et l’envoyer à n’importe quelle imprimante.
#4
#5
#6
Samba, de Janeiro
" /> 
" />
" />
#7
#8
#9
#10
Je vois dans la doc de SAMBA qu’il est toujours question de réplication du dossier SysVol avec du rsync ou autre. La version 4.6 est également concernée ?
Je verrai ce weekend à tester cette mouture.
#11
Et comment imprimer en agrafant sur le côté ou en haut à gauche, quand on imprime via PDF ?
#12
#13
Pour charger les drivers sur le serveurs d’impressions, il faut parfois passer par un client (upload en gros). Ensuite les drivers sont bien distribué depuis le serveur.
#14
Oui PDF est assez proche de Postscript,. Il l’a même remplacé sous OSX et Linux comme format d’impression pivot.
Et pour tous ceux qui ont réagit à mon message négativement. J’ai bossé plusieurs années dans la conception d’imprimantes. Je n’ai pas juste sorti une idée en l’air.
De nombreuses imprimantes savent déjà imprimer du PDF.
L’impression sans pilote/driver est quelque chose qui a une réalité ailleurs que sous Windows. Airprint d’Apple en est un bon exemple. Il est par exemple disponible depuis les smartphones qui n’ont pas à traîner un historique de driver d’impression.
Un libreoffice sait sortir nativement du PDF. Il n’y a donc pas besoin de pilote pour imprimer en PDF, le système d’exploitation a seulement à fournir un protocole comme IPP pour imprimer. C’est ce protocole qui est utilisé par Airprint.
Ouvrez-vous un peu l’esprit et sortez des schémas que vous connaissez.
#15
Marrant, moi j’ai codé un firmware d’imprimante qui savait directement imprimer du jpeg.
#16
#17
Non, il peut servir de source d’injection de pilotes sur le serveur.
#18
Ce n’est valable que pour des impressions simples. Pour des imprimantes pro avec des options de partout il faut TRÈS souvent un driver un poil plus complexe qu’une impression pdf…
Et puis monitoring, access control tout çà…
#19
Oui, pendant longtemps, l’impression Postscript était chère aprce que Adobe avait le monopole et était la seule société fournissant une solution (peut-être le temps des brevets, je ne sais pas trop). Maintenant, il y a de la concurrence et embarquer un moteur d’impression Postscript dans une imprimante ne coûte plus très cher, même si cela reste un peu plus onéreux que du PCL. Tu peux avoir aussi l’impression native du PDF pour pas trop cher sans le Postscript.
Pour ce qui est réglages ou remontées d’états, on a mis ça de base dans les drivers puisqu’ils communiquaient déjà avec les imprimantes, mais ce n’est pas très rationnel en particulier pour les remontées qui doivent être possible même quand l’impression est finie.
Cela s’appuie d’ailleurs souvent sur des protocoles standards que ce soit le PJL ou le snmp (plus générique).
Et pour tout ce qui est paramétrage complexe de l’impression, il faut effectivement passer par du Postscript ou joindre des infos complémentaires au PDF envoyé ce que fait par exemplegoogle print dans son CJT (Cloud Job Ticket).
#20
#21
#22
#23
#24
#25
#26
#27
Oui.
" />
Blague à part :
Smartphones et tablettes ont introduit de nouveaux OS, sans parler de Chrome OS.
C’est d’ailleurs pour cela qu’il y a eu des travaux de tous les grands pour renouveler la façon de dialoguer avec une imprimante. Il était hors de question de réécrire de trop nombreux drivers propriétaires sur ces nouveaux OS. D’où les Airprint, Google Cloud Print. HP s’y est mis aussi avec sa solution d’impression par Internet (me souviens plus du nom) et même Microsoft a pas mal apporté à des travaux de normalisation du métier.
L’idée de base reste la même : un format standard pour transmettre le contenu à imprimer (le PDF le plus souvent), le moyen de spécifier l’impression (format papier, recto-verso, paysage ou portrait, nombre de copies, …) et la gestion des imprimantes et des Jobs d’impression. et la remontée des alertes.
#28
Rangez le matériel, je n’ai pas dit que ce firmware était sorti du labo
#29
#30
#31
Je ne comprends pas pourquoi il y a besoin d’un pilote par imprimante.
Un serveur web dans l’imprimante
un formulaire d’upload (jpeg,png,ps,pdf,svg)
avec les cases à cocher qui vont bien
(recto/verso,portrait/paysage,couleur/nb,a3/a4)
exposition des capacités via des services REST
et sur le client une imprimante virtuelle générique pour les logiciels qui ne peuvent pas exporter du pdf.
#32
#33
#34
En fait, le contenu électronique d’une imprimante est le moins cher possible, parce que les gens ne veulent pas acheter une imprimante trop chère. Du coup, le CPU qu’on y trouve ne sera pas capable de faire tout ce que tu lui demande, explicitement et implicitement:
Effectivement, les imprimantes postscript répondaient à ce modèle (si ce n’est que la communication ne se faisait pas par interface web), mais leur prix les réservait à des usages professionnels.
#35
Merci, j’ai compris.
J’étais effectivement hors contexte, car ce n’était pas le labo d’un fabricant d’imprimantes.
Et dire que le firmware n’est pas sorti du labo ne veut pas dire qu’il n’a servi à rien: Le simple fait de le voir fonctionner a validé un ensemble d’idées, ainsi que les composants électroniques utilisés.
#36
quelque chose de semblable existe et ça s’appelle postscript
#37
et encore REST ce serait pour ceux qui voudraient s’emer à faire un metadriver ou pour scanner l’état des imprimantes sur le réseau (récupérer les compteurs d’impression…)
tous les services basiques (ne relevant pas de l’administration) seraient accessibles via le serveur web de l’imprimante:
une page web pour l’impression
une page web pour la numérisation/ocr…
#38
#39
#40
Merci de vouloir m’apprendre quelque chose, mais lis donc les autres commentaires avant de répondre au premier message, tu éviteras les redites et de rater ton coup. Je m’y connais pas mal en impression.
Mais sais-tu que Postscript est un langage de programmation qui permet de coder tout type d’algorithme ?
#41
Je pense que c’est largement faisable avec un rasperry pi qui coûte moins de 6 euros prix public pour un CPU produit en UK et qui viendrait en remplacement de l’électronique déjà présente dont on pourrait encore déduire du prix
Plus de pilotes à installer = moins de développement (tu développes pour l’imprimante et pas pour windows 8⁄10, Mac, Linux) moins de support à assurer, de documentation à faire et à joindre avec l’imprimante
#42
#43
Le pilote est découpé en 2 :
Un pilote générique sur l’ordinateur (fourni par l’OS) qui comme une imprimante virtuelle transforme le PCL/gdi en un fichier pdf et qui le transfère vers un serveur web.
Un pilote spécifique dans l’imprimante qui fait l’interface entre le fichier fournir en entrée via le serveur web de l’imprimante et le hardware de l’imprimante.
Plus besoin de pilotes spécifique sur le poste
#44
En fait, côté logiciel, les CPUS entrée de gamme d’aujourd’hui sont en normalement suffisants, mais la vitesse d’impression qui en découlerait ne serait pas acceptable. Certaines astuces pour imprimer demanderait d’avoir accès au GPU du Pi: OpenCL par exemple ?
Malgré tout, la «carte mère» d’une imprimante doit être capable de piloter un paquet de périphériques analogiques, et ça peut assez vite rajouter un coût non-négligeable à la carte (en tenant compte des connecteurs aussi).
Il faut savoir qu’on est dans un domaine ou chaque ç prix de base de l’électronique peut compter.
En bref, pas infaisable, mais je ne pense pas que le prix qui en résulterait aujourd’hui soit acceptable par le public visé.
#45
En fait j’évoquais simplement le PI à titre d’exemple je n’imaginais pas vraiment d’intégrer le raspPi dans une imprimante existante. Le pi était un prétexte pour parler du problème de puissance qui -à mon avis- ne se pose même pas, pour ce que j’en imagine le hardware des imprimantes actuelles est suffisant.
Tu peux infecter des imprimantes avec des virus en profitant du fait que les imprimantes intègrent un interpréteur PS.
Donc -sauf erreur de ma part- l’essentiel du travail de décodage en fait DANS l’imprimante.
Du coup je ne vois pas ce qui pourrait occasionner une charge plus importante pour l’imprimante et qui nécessiterait de revoir fondamentalement la puissance du hardware.
Je remplace juste l’interface d’entrée qui permettait un dialogue dans des langages exotiques par un serveur web. Enfin serveur web c’est un bien grand mot. Dans l’absolu il pourrait même ne faire que servir des fichiers statiques et pousser le fichier vers l’interpréteur PS. Pour moi il n’y a même pas besoin de hardware supplémentaire je fais juste que modifier le fonctionnement de l’étage d’entrée.
#46
#47
Il y a imprimante et imprimante.
Le grand public aujourd’hui est sensible au prix de la bête, et c’est à peu près tout.
Ce qui fait que les imprimantes grand public sont victimes d’une course au moins-disant.
Rare sont ceux qui achètent une imprimante laser après avoir tout bien pesé.
Ensuite, il y a les imprimantes professionnelles, pour lesquelles l’acheteur regarde le prix à la page.
Et là, bye bye le jet d’encre.
Or, les imprimantes laser sont assez exigentes en terme de CPU: Une fois leprocessus lancé, on ne l’arrête plus, contrairement à ce qu’on peut faire avec une tête qui se promène sur la page. Du coup, l’interprète PS n’est pas un problème.
Par contre, sur les exemples que j’ai vu il y a quelques années, le décodage était fait dans le driver sur le PC, pour justement simplifier au maximum le travail du CPU de l’imprimante. L’électromique a évolué depuis, mais les fabricants n’ont pas nécessairement envie d’investir dans un changement majeur de leur base logicielle, toujours à cause de la course au moins-disant.
#48
Peu import, ce que tu propose n’a rien changer au fait que il faut un pilote dans l’OS pour imprimer directement.
#49
En fait, ça dépend, autant pour un problème de chariot j’ai eu des emmerdes avec le SAV d’Epson (sur une RX700 agée de 6 mois) et l’imprimante a fait 3 aller retours sans compter le coup de “mettez à jour votre pilote” (pou run pb de chariot bloqué
" />)
" /> (autre débat)
Autant pour HP (OfficeJet 7510 agée de 8 mois), aucun soucis pour le même problème, échange directe.
C’est pas sur le matos que les consommateurs sont vaches à lait, ce sont sur les cartouches
@fred42 @v1nce : merci de vos précisions.
#50
Les imprimantes me font l’effet des modems USB d’il y a quelques années.
Quand tu installais bêtement le pilote fourni par ton FAI tu te retrouvais avec des effets indésirables (modification page d’accueil…)
Quand tu étais un peu plus averti, tu pouvais installer que le strict nécessaire pour faire fonctionner le hardware sous windows.
Sous Linux il fallait se débrouiller pour charger le microcode etc.
Sous Mac ?
Aujourd’hui, je prends ma box je connecte le câble réseau et ça marche.
0 pilote à installer :
Le microcode est dans la box et je n’ai pas à m’en occuper.
L’OS fournit le pilote générique (Gestionnaire de connexions)
J’ai l’impression que c’est la même chose avec les imprimantes.
Si j’installe bêtement le pilote je me retrouve avec ce que l’éditeur a pu packager avec (OCR, modification menu contextuel)
Si tu te renseignes tu peux installer juste le nécessaire (ou Windows peut éventuellement le faire pour toi)
Avec une imprimante webifiée plus de pilote à installer : tu uploades ton pdf et ça marche.
Il faut juste une imprimante virtuelle générique (un peu à la CUPS) pour les logiciels incapables de sortir du pdf.
#51
1 pilote générique vs 1 pilote par imprimante ça fait une légère différence.
En plus ce pilote n’est même pas nécessaire si tu passes par l’interface de l’imprimante.
Ton imprimante reste utilisable même si elle n’est plus supportée par l’OS.
Et tu peux l’utiliser depuis un smartphone…
#52
#53
Si le pilote générique est géré par l’OS alors oui pour l’utilisateur c’est comme si tu n’avais plus de pilote (pas de truc à installer quand tu passes de ton PC à ton Mac…)
De plus si tu utilises le serveur web tu n’as plus besoin de pilote du tout.
En revanche, oui il faut toujours un microcode pour interpréter un fichier en commandes compréhensible par l’imprimante. Sauf que comme il est DANS l’imprimante OSEF.
#54
#55
#56
#57
#58
Perso, je considère que quelqu’un qui a eu un Amiga 1200 est un peu jeune.
" />
J’ai au moins une dizaine d’années de plus que toi il me semble.
J’ai aussi pratiqué l’assembleur 6502, d’abord en école d’ingé puis plus tard dans le milieu pro.
J’ai aussi commencé sur des 68008 et 68000 en 1985 au niveau pro. On les programmait plutôt en Pascal mais l’assembleur n’était jamais loin, surtout pour débugger ou patcher le code.
Edit : je voulais dire qu’il avait peut-être quitté le milieu pro avant que ce genre de processeurs baissent beaucoup et apportent une grosse puissance pour pas cher.
#59
#60
#61
j’ai une question ca sert a quoi ce logiciel car je n’ai pas tout compris ?
#62
Samba est un logiciel d’interopérabilité qui implémente le protocole propriétaire SMB/CIFS de Microsoft Windows dans les ordinateurs tournant sous le système d’exploitation Unix et ses dérivés de manière à partager des imprimantes et des fichiers dans un réseau informatique.
https://fr.wikipedia.org/wiki/Samba_(informatique)
#63
#64
#65
Oui, depuis la version 4.0 sortie en décembre 2012 (il y a plus de 4 ans déjà) Samba permet de mettre en place sur des serveurs Linux un contrôleur de domaine type AD, avec tout le bazar qui va avec (annuaire spécifique avec schéma spécifique, entrées DNS spécifiques, gestion réparties des rôles entre plusieurs serveurs, GPO pour gérer le parc des PCs Windows), sans avoir à gérer/payer les licences CAL indispensables lorsque le contrôleur de domaine/serveur de fichiers est sous Windows Serveur 201X.
#66
#67
Les capacités du hardware sont connues du “pilote” qui est DANS l’imprimante. Et donc celui-ci génère des pages web en conséquence (NB/couleur, marge, entrée/sortie papier, agrafage,vignettage,qualité…).
#68
#69
v1nce a écrit :
Les capacités du hardware sont connues du “pilote” qui est DANS l’imprimante. Et donc celui-ci génère des pages web en conséquence (NB/couleur, marge, entrée/sortie papier, agrafage,vignettage,qualité…).
Ça enlève la possibilité d’avoir un serveur central (tu envoies tes documents sur un serveur unique avec plusieurs imprimantes, tu te déplaces ensuite à l’imprimante la plus proche, tu t’authentifies et tu récupères tes documents).
Et comment faire pour imprimer de façon automatique depuis un programme ? Il ne faut pas des pages web, mais une API qui expose toutes les fonctionnalités. Et au final, ça revient à avoir un driver.
#70