Vous n'êtes pas identifié(e).
Mieux vaut utiliser useradd car adduser aurait créé le répertoire /home/machin$. Inutile d'utiliser smbpasswd car il n'y aura jamais aucun login de l'utilisateur machin$. Samba ne fait que vérifier la présence d'une ligne machin$ dans /etc/passwd.
Si vous souhaitez accepter toutes les machines dans votre domaine, décommentez la ligne suivante du fichier /etc/samba/smb.conf :
ce qui fera grossir /etc/passwd à chaque jonction de domaine. Créez aussi le groupe machines qui par défaut n'existe pas :
Dans mon message précédent, lors de ma tentative de jonction du domaine "DOM" avec l'utilisateur root, Samba répondait (au travers de la boîte de dialogue de Windows) :
(..) Le compte d'ordinateur spécifié est introuvable. (..)
Le compte introuvable dont parlait Samba n'était pas root mais machin$. À présent tout fonctionne !
ce qui a changé le message d'erreur lors de la jonction du domaine.
Tentative de jonction de "DOM" avec l'utilisateur root :
L'erreur suivante s'est produite lors de la tentative de jonction au domaine "DOM" :
Le compte d'ordinateur spécifié est introuvable. Contactez un administrateur pour vérifier si le compte fait partie du domaine. Si le compte a été supprimé, quittez le domaine, redémarrez, puis rejoignez le domaine.
Tentative de jonction de "DOM" avec l'utilisateur u :
L'opération de jonction a échoué. La raison peut en être qu'un compte d'ordinateur existant avec le nom "W8" a été créé antérieurement avec d'autres informations d'identification. Changez de nom d'ordinateur, ou demandez à votre administrateur de supprimer les vieux comptes au même nom. L'erreur était :
Accès refusé.
Tentative de jonction de "DOM" avec un utilisateur inconnu de Samba :
L'erreur suivante s'est produite lors de la tentative de jonction du domaine "DOM" :
Le nom d'utilisateur ou le mot de passe est incorrect.
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.
(..) que dis les logs coté serveur ?
/var/log/samba/log.nmbd
/var/log/samba/log.smbd
Pour faciliter la lecture de log.nmbd et log.smbd, je les ai effacés puis j'ai redémarré Samba, ce qui a recréé ces 2 fichiers vides, puis ils se sont remplis durant le démarrage de Samba. Ensuite j'ai tenté de rattacher un PC Windows au domaine "DOM", les fichiers de log n'ont pas grossi, Samba n'a laissé aucune trace de la tentative de jonction.
mkdir -p /home/samba/netlogon
mkdir -p /home/samba/profiles
chmod 777 /home/samba/profiles
smbpasswd -a root
smbpasswd -a u
pdbedit -Lw
Les clients Windows voient DEBIAN dans leur voisinage réseau : Windows demande de s'identifier, puis je peux voir les fichiers distants, donc aucun problème en mode groupe de travail.
Problème : les clients n'arrivent pas à joindre le domaine. Sur un client Windows, j'entre le nom du domaine "DOM", Windows demande l'identité d'un administrateur habilité à joindre le domaine (l'identité n'est demandée que si le domaine est reconnu, c'est donc bon signe) j'entre "root" et son mot de passe, mais Windows répond en affichant le message suivant :
L'erreur suivante s'est produite lors de la tentative de jonction au domaine "DOM" :
Le domaine spécifié n'existe pas ou n'a pas pu être contacté.
Je suis perdu. Je vous remercie de m'avoir lu, et si quelqu'un a une idée je le remercie d'avance.
Pour les shell et le shell bash, comme il y a plusieurs sortes de shell, le tableau est à compléter.
Le rapport entre les regexp, les shell (dont le bash) et la ligne de commande me paraît direct
Bash n'est pas un shell, mais un interpréteur de commandes.
On ne dit pas un shell mais le shell (ensemble de fichiers exécutables) ou du shell (langage de script).
En environnement de type UNIX, le shell correspond à l'ensemble des applications qui permettent à l'utilisateur d'effectuer des actions simples. Pour simplifier à l'extrême, on pourrait dire que le shell correspond à l'ensemble des fichiers exécutables du répertoire /bin dans lequel on trouve /bin/bash, /bin/cp, /bin/ls, /bin/mv, etc... auquel il faut rajouter /sbin en session root.
Mais le sens le plus général est de parler "du shell" en tant que langage, dont la grammaire de chaque ligne est interprétée par /bin/sh (ou ses descendants compatibles dont /bin/bash) pour aboutir à l'exécution d'autres programmes (la commande "cp x y" lance l'exécution de /bin/cp en lui passant 3 arguments: cp, x et y).
Shell = interprétation des lignes de commandes (bash) aboutissant à l'exécution d'un traitement simple (ls, cp, mv...). Sans tous ces exécutables de /bin (et /sbin en session root) l'interprétation grammaticale de /bin/bash ne servirait à rien.
J'aimerais l'avoir ton l'opinion avisée sur ce objet-texte, puisque j'utilise le terme "console".
Les textes (jaune et rose) ont l'air bons. À la place de "Console débutant", j'écrirais plutôt "Ligne de commande".
Terminal ou plutôt émulateur de terminal: logiciel qui, dans un environnement graphique, affiche une console.
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).
Avec son nouveau système d'exploitation ouvert, Bada, Samsung, numéro deux mondial des ventes de téléphones mobiles, est bien décidé à reprendre la main sur le segment des smartphones. Premier terminal à proposer Bada, le Wave s'illustre en smartphone tactile haut de gamme orienté réseaux sociaux, si l'on en croit sa fiche d'identité.
Cet exemple illustre parfaitement ce qu'est un terminal.
En tout cas, le débat posé ici propose du concret.
+1
C'est (..) par l'intermédiaire d'un terminal.
On peut faire de la ligne de commande en dehors d'un terminal.
En tout cas, se concerter est une bonne décision, afin de ne pas tomber dans la simplification extrême où tout deviendrait synonyme, comme si on cherchait à rendre le métier de cuisinier séduisant en prétendant que "tomates", "olives", "oignons" et "champignons" sont synonymes car figurant sur une même pizza. Je suis contre ce genre de séduction de l'extrême, et trouve donc cette discussion plus qu'enrichissante, bien que jusque-là j'ai plutôt mis l'accent sur ce qu'il ne fallait pas faire. Je tenterai de me rattrapper.
(..) mettre une/des image(s) pour illustrer le propos.
Bonne idée.
(..) fusionner ligne de commande avec commandes et de mettre la liste dans une page séparée comme celle-ci commande_linux_debutant
Sur le principe, je ne sais pas quoi en penser. Par contre, la casse est importante et les commandes (cp, mv...) doivent être écrites en minuscules. La convention veut que les majuscules soient réservées aux variables Shell, ou aux valeurs fixes (index ou énumération) comme dans le cas des primitives systèmes. On écrirait ainsi que la fonction fork() fait appel à la primitive FORK (sous-entendu: #define FORK 1), car on n'est pas censé connaître par cœur le numéro de l'appel-système FORK.