Debian-facile

Merci DosXX. Si cela peut en aider quelques uns, voici ce que j'ai appris ces derniers jours sur l'interaction Samba-Windows :

NetBIOS : protocole non-IP (donc non-routable) où chaque PC est identifié par un nom donné lors de l'installation de Windows : 15 caractères sans casse, affichés en majuscules dans l'Explorateur Windows et en minuscules dans les outils Samba. Un 16ème caractère caché sert à différencier des PC portant le même nom, bien que cela soit à éviter.

NetBEUI : implémentation brute de NetBIOS, non-encapsulée donc directement au-dessus de la couche Ethernet. À une époque où la consommation CPU, RAM et réseau était comptée, NetBIOS avait l'avantage de consommer peu et de tout prendre en charge (résolution de nom, envoi et réception de données...) de façon transparente pour l'utilisateur, grâce à une couche logicielle très mince. À cette époque, les piles TCP/IP n'existaient que sur des gros systèmes utilisant le modèle OSI à 7 couches.

Windows NT3 : partage de fichiers en mode "groupe de travail" ou "domaine", conçu pour la performance dans un réseau local isolé, à une époque où internet était inexistant, et devait être utilisable sur des PC bon-marché, donc réseau NetBEUI. Pour les domaines, il fallait installer un PDC (Primary Domain Controller) et des BDC facultatifs (Backup Domain Controller). L'identification des utilisateurs se faisait par une table nommé SAM, dont le fonctionnement est semblable aux fichiers /etc/passwd et shadow d'UNIX.

Windows NT4 : comme NT3, mais les PDC et BDC peuvent intervertir leurs rôles en fonction du traffic réseau ou d'autres critères.

Windows 2000 : on passe à internet avec la pile TCP/IP : fini les domaines NetBIOS, résolution de nom par DNS, transfert de fichiers avec CIFS directement sur TCP/IP. NetBIOS (maintenant encapsulé dans TCP/IP) peut néanmoins servir pour du "groupe de travail" où chaque machine doit être nommée, contrairement à du "domaine" où seul le nom DNS du serveur compte. Fini l'unique PDC qui gère tous les utilisateurs et leurs fichiers, remplacé par une hiérarchie de serveurs, donc fini la table SAM, remplacée par un annuaire hiérarchique LDAP distribué entre les serveurs. Possibilité de créer des profils locaux ou itinérants.

Côté clients : depuis Vista il n'y a plus de profils locaux ou itinérants, remplacés par des données locales et itinérantes au sein d'un même profil. Une fois l'identification passée, un "domaine" avec profils locaux n'apportait aucun avantage par rapport à des accès en mode "groupe de travail", et un profil itinérant demandait une longue synchronisation lors des ouvertures et fermetures de sessions. Pour des raisons de performance, Vista (et Windows 7 et 8) rapatrie les fichiers itinérants (base de registre, dossiers systèmes) lors de la connexion, et sauvegarde ces fichiers sur le serveur lors de la déconnexion, dans le dossier profile.V2 du répertoire de travail de l'utilisateur. Les fichiers locaux, souvent volumineux et en perpétuel changement, et sans intérêt au niveau de la config (comme les fichiers temporaires) ne transitent plus entre client et serveur.

Samba 3 : NetBIOS et SAM, donc les clients Windows voient Samba 3 comme un Windows NT4. Les clients Windows récents doivent travailler en mode compatibilité, d'où les 2 clés à rajouter dans la base de registre. Samba 3 ne permet pas d'échanger les rôles entre PDC et BDC comme le fait Windows NT4, toutefois avec notre matériel actuel ces changements de rôles ne sont plus justifiés.

Samba 4 : DNS et LDAP sur TCP/IP, mais Samba 4 est encore en version bêta, et très instable d'après mes tests sur Debian Wheezy.

NB : d'après mes essais (Windows 8 + Samba 3), les dossiers partagés netlogon, profiles et sysvol ne servent pas. Windows préfère créer un dossier profile.V2 dans le répertoire utilisateur plutôt qu'utiliser le partage profiles qui reste toujours vide. La jonction au domaine fonctionne très bien sans ces 3 partages.

Merci pour votre aide. Dans le registre du PC Windows j'ai rajouté les 2 valeurs DWORD suivantes :

ce qui a changé le message d'erreur lors de la jonction du domaine.

Tentative de jonction de "DOM" avec l'utilisateur root :

Tentative de jonction de "DOM" avec l'utilisateur u :

Tentative de jonction de "DOM" avec un utilisateur inconnu de Samba :

J'ai donc créé un nouvel utilisateur v côté Samba :

mais j'obtiens le même message d'erreur qu'avec l'utilisateur u.

Les meilleures définitions sont souvent non-informatiques. "Shell" est un mot anglais signifiant "coquille". Le shell est la coquille entre l'utilisateur (humain) et le noyau (primitives systèmes).

Lorsque l'utilisateur souhaite copier un fichier, il utilisera la partie du shell nommée ls. Lorsque l'utilisateur souhaite créer un répertoire, il utilisera la partie du shell nommée mkdir. ls et mkdir font donc partie intégrante de cette coquille (en anglais: "shell"). bash n'est que la sous-partie du shell chargée de dialoguer avec l'utilisateur, n'oublions pas le plus important: l'utilisateur s'en fiche de dialoguer, il veut des actions concrètes, et ça bash en est incapable, bash n'est que la "goutte d'huile" entre l'humain et les applications du shell.

Que les tutos aient un classement, cela peut se comprendre, mais je ne vois pas pourquoi faire figurer "Console débutant" dans un tuto.

Après, je n'ai fait part que de mon impression. Imaginez que vous lisez un texte qui n'a rien à voir, et que vous tombez sur "Console débutant" au milieu de nulle part. Ne trouveriez-vous pas ça bizarre?

<mode=psychologue>
J'enlèverais le mot "débutant", ce mot est comme "émulateur de ..." : il en rassurera certains, fera peur à d'autres, mais ce qui ne me plaît pas c'est qu'il met une barrière psychologique entre 2 sortes de gens, alors que notre souhait à tous (et j'espère le souhait de chaque débutant) étant de devenir confirmé. Je ne veux pas devenir quelque chose que l'on met à l'écart, même derrière une barrière psychologique.
</mode>

À l'école primaire, on n'apprend pas les maths pour débutant ou le français pour débutant, on apprend les maths et le français.

Pas la peine de préciser "émulateur", sinon il faudrait aussi écrire "émulateur de console". De plus, un émulateur de terminal étant lui-même un terminal, autant écrire tout simplement "terminal". Il faut se remettre dans le contexte de l'époque pour comprendre l'emploi du mot "émulateur":

DEC VT100


NCD 88K


Un DEC VT100 est à la fois une console (au sens matériel) et un terminal (au sens réseau). De même, un NCD 88K est à la fois une console et un terminal. Les employés des années 80 utilisaient le mot "terminal" plutôt que "console", car l'employé de bureau (qu'il soit développeur, comptable, commercial, etc...) cherchait à faire exécuter ses traitements sur la grosse machine (Mainframe) et à lire les résultats.

Les habitudes aidant, le terme "VT100" désignait dorénavant une façon de communiquer (séquences d'échappement, etc...) compatible avec la console VT100 de DEC, largement répendue. La console NCD 88K est un "Terminal X". On ne dit pas "Terminal 88K" car le système X Window est apparu avant les consoles NCD, le protocole X ayant servi de base aux consoles NCD dont la 88K.

Le terme "émulateur de terminal" fait référence à ce matériel désuet, dans le sens où la console Linux émule un terminal DEC VT100 (pour être exact, il s'agit plutôt d'un VT102 amélioré). L'application X (X Window System) est un émulateur de terminal NCD, certes énormément amélioré depuis plus de 20 ans, mais émulateur quand-même. Cependant, nous ne vivons plus dans les années 80, et personne (ni les développeurs, et encore moins les débutants) voient en ces applications des émulateurs de DEC VT100 et NCD 88K.

Le terme "émulateur" étant complètement désuet aujourd'hui, je propose de l'oublier car on obtiendrait ceci: "xterm et gnome-terminal sont des émulateurs de terminaux VT102, fonctionnant eux-mêmes dans un émulateur de terminal X" . Évidemment, en cours d'histoire de l'informatique, ce terme prend tout son sens, mais certainement pas dans un cours d'initiation à l'informatique.

Autre remarque : les mots "console" et "terminal" ne font pas forcément référence au mode texte, qui n'est qu'un cas particulier ne correspondant même plus à l'utilisation majoritairement graphique d'un terminal en 2011 (terminal X).

Voici un extrait de cette page :

Cet exemple illustre parfaitement ce qu'est un terminal.

Et toi, quelles sont tes définitions ?

L'important n'est pas d'utiliser Console ou Terminal, mais de comprendre de quoi on parle.

Gnome n'est pas à prendre comme une référence, pas plus que KDE avec konsole. Mais puisqu'on parle de Gnome, ils ont voulu mettre l'accent sur le rôle joué par l'appli (par rapport à la grosse machine à contacter derrière) plutôt que sur l'implémentation de l'appli elle-même.

De plus, il est impropre de dire "L'application Terminal" puisqu'il en existe plusieurs: xterm, rxvt, gnome-terminal, konsole, etc...

Le terme traitement est ambigu, car il peut s'agir d'un gros traitement sur le système à commander (exécution de sed, wget, aptitude, retouche d'image, etc...) ou du minuscule traitement préalable à l'intérieur de bash qui aboutira sur le lancement de sed (par exemple). Je trouve ridicule d'attribuer le mot "traitement" à l'analyse grammaticale de bash qui doit durer 1/100 de seconde, il est plus logique d'appeler "traitement" le travail réalisé par sed ou wget. J'ai du mal à dire qu'une ligne comme "alias l='ls --color'" est un traitement, ou alors ce mot perdra tout son sens, dans la mesure où en informatique: tout est traitement, autant ne plus parler dans ce cas.

Je propose donc : toutes les lignes de commandes sont interprétées par bash, certaines engendrant un traitement (ou exécution, je trouve le terme "exécution" moins ambigu que "traitement").

Dans le menu de Gnome, "Terminal" fait référence au terminal par défaut dans l'environnement Gnome (qui peut être gnome-terminal) de même que "Navigateur Web" fait référence au navigateur web par défaut (qui peut être iceweasel). On ne peut donc pas dire L'application Terminal, mais plutôt un terminal.