C'est la 3ème machine en 3 jours sur laquelle les utilisateurs
n'arrivent pas à se loguer. (via le plug-in AD)
Sur la première, en 10.3.9, j'ai passé la combo update et après ça même
les utilisateurs locaux ne pouvaient plus se loguer.
En console, pas de problème à se loguer.
Ce n'était pas la base netinfo, je l'ai recréé sans succès.
J'ai passé la machine en 10.4 en sans chercher plus loin.
Sur la seconde, en 10.3.9 aussi, une update de sécurité et c'est
repartit. Je ne peux même pas affirmer que le problème était le même,
bien que les symptomes soient identiques.
Sur la 3ème, en 10.4.8, j'ai voulu faire l'update pour commencer mais
elle échoue : " installer: The install failed." Et la machine ne reboot
plus. Dans les logs, je trouve ceci :
"BomFatalError - cpio read error: bad file format"
quand bien même j'ai pris successivement la maj chez Apple puis sur un
autre serveur, depuis le système puis avec un disque externe.
Donc j'ai 2 questions :
- avez vous eu une telle épidémie récement chez vous ?
- pour le problème d'update qui plante, à part du pousse CD je peux
faire quoi ? J'aimerais bien diagnostiquer mais j'ai pas d'idées.
Merci d'avance :)
--
Nicolas - MICHEL at bluewin point ch
AIM : michelnicolas
mais sur les machines qui ont un problème, ça donne ça :
uidB94967294(Jean Dupont) gid (staff) groups (staff)
Donc en gros dscl n'est plus capable de récupérer le username, mais il trouve quand-même quelque chose.
J'ai fait un sudo killall -USR1 DirectoryService
pour analyser les logs des DirectoryServices, mais j'y comprends pas grand chose à ce charabia ...
Ah, j'ai eu 2 machines de plus ce matin qui ont le même problème, c'est bien une épidémie. :-( -- Nicolas - MICHEL at bluewin point ch AIM : michelnicolas
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Bonjour
C'est la 3ème machine en 3 jours sur laquelle les utilisateurs
n'arrivent pas à se loguer. (via le plug-in AD)
Un signe particulier, si je fais un "id toto", je devrais avoir un truc
comme ça :
mais sur les machines qui ont un problème, ça donne ça :
uidB94967294(Jean Dupont) gid (staff) groups (staff)
Donc en gros dscl n'est plus capable de récupérer le username, mais il
trouve quand-même quelque chose.
J'ai fait un
sudo killall -USR1 DirectoryService
pour analyser les logs des DirectoryServices, mais j'y comprends pas
grand chose à ce charabia ...
Ah, j'ai eu 2 machines de plus ce matin qui ont le même problème, c'est
bien une épidémie. :-(
--
Nicolas - MICHEL at bluewin point ch
AIM : michelnicolas
mais sur les machines qui ont un problème, ça donne ça :
uidB94967294(Jean Dupont) gid (staff) groups (staff)
Donc en gros dscl n'est plus capable de récupérer le username, mais il trouve quand-même quelque chose.
J'ai fait un sudo killall -USR1 DirectoryService
pour analyser les logs des DirectoryServices, mais j'y comprends pas grand chose à ce charabia ...
Ah, j'ai eu 2 machines de plus ce matin qui ont le même problème, c'est bien une épidémie. :-( -- Nicolas - MICHEL at bluewin point ch AIM : michelnicolas
Nicolas-MICHEL'_remove_'
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
pour analyser les logs des DirectoryServices, mais j'y comprends pas grand chose à ce charabia ...
Bon, je note un peu tout ce que je trouve ici, parce que j'ai pas l'impression de pouvoir m'en sortir seul. Toute proposition sur ce que je dois chercher est bienvennue :)
Au fait, comment on fait pour vider le cache des DirectoryServices ?
Sur un mac qui a le problème, quand je fais # dscl localhost -list /Active Directory/ad.isrec.ch/Users J'ai la liste de tous les utilisateurs.
Mais pour certains utilisateurs, un -read ne fonctionne pas : # dscl localhost -read /Active Directory/ad.isrec.ch/Users/nmichel read: Invalid Path Alors que pour d'autre le -read me sort les info demandées. Sur une machine "saine" la même commande retourne les info souhaitées.
J'ai isolé le -read dans le debug.log, ça donne 74 lignes qui ne me disent rien. Voici les 7 dernières :
2007-10-02 10:23:51 CEST - Client: DirectoryService, PID: 360, API: dsCloseDirService(), Server Used : DAR : Dir Ref 16777703 : Result code = 0 2007-10-02 10:23:51 CEST - ADPlugin: Sending lookupd flushcache! 2007-10-02 10:23:51 CEST - ADPlugin: Open found 2 records 2007-10-02 10:23:51 CEST - Client: dscl, PID: 520, API: dsOpenRecord(), Active Directory Used : DAR : Node Ref = 16777685 : Record Ref = 0 : Result code = -14136 2007-10-02 10:23:51 CEST - Reference 0 error = -14071 2007-10-02 10:23:51 CEST - Plug-in call "dsOpenRecord()" failed with error = -14136. 2007-10-02 10:23:51 CEST - Port: 28515 Call: dsOpenRecord() == -14136
Selon Apple, l'erreur -14136 veux dire "Requested record was not found". <http://developer.apple.com/documentation/Networking/Reference/Open_Dire ctory_Ref/Reference/reference.html>
-- Nicolas - MICHEL at bluewin point ch AIM : michelnicolas
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
pour analyser les logs des DirectoryServices, mais j'y comprends pas
grand chose à ce charabia ...
Bon, je note un peu tout ce que je trouve ici, parce que j'ai pas
l'impression de pouvoir m'en sortir seul.
Toute proposition sur ce que je dois chercher est bienvennue :)
Au fait, comment on fait pour vider le cache des DirectoryServices ?
Sur un mac qui a le problème, quand je fais
# dscl localhost -list /Active Directory/ad.isrec.ch/Users
J'ai la liste de tous les utilisateurs.
Mais pour certains utilisateurs, un -read ne fonctionne pas :
# dscl localhost -read /Active Directory/ad.isrec.ch/Users/nmichel
read: Invalid Path
Alors que pour d'autre le -read me sort les info demandées.
Sur une machine "saine" la même commande retourne les info souhaitées.
J'ai isolé le -read dans le debug.log, ça donne 74 lignes qui ne me
disent rien. Voici les 7 dernières :
2007-10-02 10:23:51 CEST - Client: DirectoryService, PID: 360, API:
dsCloseDirService(), Server Used : DAR : Dir Ref 16777703 : Result code
= 0
2007-10-02 10:23:51 CEST - ADPlugin: Sending lookupd flushcache!
2007-10-02 10:23:51 CEST - ADPlugin: Open found 2 records
2007-10-02 10:23:51 CEST - Client: dscl, PID: 520, API: dsOpenRecord(),
Active Directory Used : DAR : Node Ref = 16777685 : Record Ref = 0 :
Result code = -14136
2007-10-02 10:23:51 CEST - Reference 0 error = -14071
2007-10-02 10:23:51 CEST - Plug-in call "dsOpenRecord()" failed with
error = -14136.
2007-10-02 10:23:51 CEST - Port: 28515 Call: dsOpenRecord() == -14136
Selon Apple, l'erreur -14136 veux dire "Requested record was not found".
<http://developer.apple.com/documentation/Networking/Reference/Open_Dire
ctory_Ref/Reference/reference.html>
--
Nicolas - MICHEL at bluewin point ch
AIM : michelnicolas
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
pour analyser les logs des DirectoryServices, mais j'y comprends pas grand chose à ce charabia ...
Bon, je note un peu tout ce que je trouve ici, parce que j'ai pas l'impression de pouvoir m'en sortir seul. Toute proposition sur ce que je dois chercher est bienvennue :)
Au fait, comment on fait pour vider le cache des DirectoryServices ?
Sur un mac qui a le problème, quand je fais # dscl localhost -list /Active Directory/ad.isrec.ch/Users J'ai la liste de tous les utilisateurs.
Mais pour certains utilisateurs, un -read ne fonctionne pas : # dscl localhost -read /Active Directory/ad.isrec.ch/Users/nmichel read: Invalid Path Alors que pour d'autre le -read me sort les info demandées. Sur une machine "saine" la même commande retourne les info souhaitées.
J'ai isolé le -read dans le debug.log, ça donne 74 lignes qui ne me disent rien. Voici les 7 dernières :
2007-10-02 10:23:51 CEST - Client: DirectoryService, PID: 360, API: dsCloseDirService(), Server Used : DAR : Dir Ref 16777703 : Result code = 0 2007-10-02 10:23:51 CEST - ADPlugin: Sending lookupd flushcache! 2007-10-02 10:23:51 CEST - ADPlugin: Open found 2 records 2007-10-02 10:23:51 CEST - Client: dscl, PID: 520, API: dsOpenRecord(), Active Directory Used : DAR : Node Ref = 16777685 : Record Ref = 0 : Result code = -14136 2007-10-02 10:23:51 CEST - Reference 0 error = -14071 2007-10-02 10:23:51 CEST - Plug-in call "dsOpenRecord()" failed with error = -14136. 2007-10-02 10:23:51 CEST - Port: 28515 Call: dsOpenRecord() == -14136
Selon Apple, l'erreur -14136 veux dire "Requested record was not found". <http://developer.apple.com/documentation/Networking/Reference/Open_Dire ctory_Ref/Reference/reference.html>
-- Nicolas - MICHEL at bluewin point ch AIM : michelnicolas
laurent.pertois
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Toute proposition sur ce que je dois chercher est bienvennue :)
Il n'y a pas eu de changements dans ton AD ? (restrictions d'accès par machines...)
Sinon, côté AD il n'y a pas de traces dans leurs logs ?
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Toute proposition sur ce que je dois chercher est bienvennue :)
Il n'y a pas eu de changements dans ton AD ? (restrictions d'accès par
machines...)
Sinon, côté AD il n'y a pas de traces dans leurs logs ?
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Sinon, côté AD il n'y a pas de traces dans leurs logs ?
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Nicolas-MICHEL'_remove_'
Laurent Pertois wrote:
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Toute proposition sur ce que je dois chercher est bienvennue :)
Il n'y a pas eu de changements dans ton AD ? (restrictions d'accès par machines...)
Aucunes modif particulières dans l'AD, si ce n'est qu'on a ajouté un ou deux utilisateurs. Mais rien dans le changement de stratégie.
Un autre truc étrange, ça semble un peu aléatoire : Une utilisatrice avait ce problème vendredi, (le 2ème cas que je décris) après une update de sécurité elle pouvait se loguer à nouveau. Hier ça fonctionnait bien et ce matin ça veux plus.
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Toute proposition sur ce que je dois chercher est bienvennue :)
Il n'y a pas eu de changements dans ton AD ? (restrictions d'accès par
machines...)
Aucunes modif particulières dans l'AD, si ce n'est qu'on a ajouté un ou
deux utilisateurs. Mais rien dans le changement de stratégie.
Un autre truc étrange, ça semble un peu aléatoire :
Une utilisatrice avait ce problème vendredi, (le 2ème cas que je décris)
après une update de sécurité elle pouvait se loguer à nouveau. Hier ça
fonctionnait bien et ce matin ça veux plus.
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Toute proposition sur ce que je dois chercher est bienvennue :)
Il n'y a pas eu de changements dans ton AD ? (restrictions d'accès par machines...)
Aucunes modif particulières dans l'AD, si ce n'est qu'on a ajouté un ou deux utilisateurs. Mais rien dans le changement de stratégie.
Un autre truc étrange, ça semble un peu aléatoire : Une utilisatrice avait ce problème vendredi, (le 2ème cas que je décris) après une update de sécurité elle pouvait se loguer à nouveau. Hier ça fonctionnait bien et ce matin ça veux plus.
Sinon, côté AD il n'y a pas de traces dans leurs logs ?
Bonne idée, j'ai pas regardé de ce côté.
Merci Laurent :) -- Nicolas - MICHEL at bluewin point ch AIM : michelnicolas
laurent.pertois
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Une utilisatrice avait ce problème vendredi, (le 2ème cas que je décris) après une update de sécurité elle pouvait se loguer à nouveau. Hier ça fonctionnait bien et ce matin ça veux plus.
Vois aussi si certains comptes machines ne doivent pas changer le mot de passe, Mac OS X ne sait pas le faire pour le moment. Il y a un article à ce sujet sur afp548 avec un script.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Une utilisatrice avait ce problème vendredi, (le 2ème cas que je décris)
après une update de sécurité elle pouvait se loguer à nouveau. Hier ça
fonctionnait bien et ce matin ça veux plus.
Vois aussi si certains comptes machines ne doivent pas changer le mot de
passe, Mac OS X ne sait pas le faire pour le moment. Il y a un article à
ce sujet sur afp548 avec un script.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Une utilisatrice avait ce problème vendredi, (le 2ème cas que je décris) après une update de sécurité elle pouvait se loguer à nouveau. Hier ça fonctionnait bien et ce matin ça veux plus.
Vois aussi si certains comptes machines ne doivent pas changer le mot de passe, Mac OS X ne sait pas le faire pour le moment. Il y a un article à ce sujet sur afp548 avec un script.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Nicolas-MICHEL'_remove_'
Laurent Pertois wrote:
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Une utilisatrice avait ce problème vendredi, (le 2ème cas que je décris) après une update de sécurité elle pouvait se loguer à nouveau. Hier ça fonctionnait bien et ce matin ça veux plus.
Vois aussi si certains comptes machines ne doivent pas changer le mot de passe, Mac OS X ne sait pas le faire pour le moment. Il y a un article à ce sujet sur afp548 avec un script.
Tu parles de cet article ? <http://www.afp548.com/article.php?story 061128094058598> Respecting AD account workstation restrictions
A ce que je comprends, l'AD permet de restreindre l'accès de certains utilisateurs à certaines machines. Par exemple, dire que toto n'a pas le droit de se loguer sur le pc de la compta. Cette info est stockée dans un champ SMBUserWorkstations. Le script vérifie donc le contennu de ce champ et si le nom du mac s'y trove, il te "kill".
A noter qu'il y a un petit bug dans le script, ils confondent le LocalHostName et le "AD Computer Account" :
J'ai malheureusement pas le temps de faire remonter le bug.
Pour revenir à mon problème, il est lié à l'authentification sur l'AD. Vu la situation, je fais des comptes locaux partout où il faut et basta. De toutes façon dans 2 mois tout va changer ici.
Merci encore, Laurent :) -- Nicolas - MICHEL at bluewin point ch AIM : michelnicolas
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Une utilisatrice avait ce problème vendredi, (le 2ème cas que je décris)
après une update de sécurité elle pouvait se loguer à nouveau. Hier ça
fonctionnait bien et ce matin ça veux plus.
Vois aussi si certains comptes machines ne doivent pas changer le mot de
passe, Mac OS X ne sait pas le faire pour le moment. Il y a un article à
ce sujet sur afp548 avec un script.
Tu parles de cet article ?
<http://www.afp548.com/article.php?story 061128094058598>
Respecting AD account workstation restrictions
A ce que je comprends, l'AD permet de restreindre l'accès de certains
utilisateurs à certaines machines. Par exemple, dire que toto n'a pas le
droit de se loguer sur le pc de la compta. Cette info est stockée dans
un champ SMBUserWorkstations. Le script vérifie donc le contennu de ce
champ et si le nom du mac s'y trove, il te "kill".
A noter qu'il y a un petit bug dans le script, ils confondent le
LocalHostName et le "AD Computer Account" :
J'ai malheureusement pas le temps de faire remonter le bug.
Pour revenir à mon problème, il est lié à l'authentification sur l'AD.
Vu la situation, je fais des comptes locaux partout où il faut et basta.
De toutes façon dans 2 mois tout va changer ici.
Merci encore, Laurent :)
--
Nicolas - MICHEL at bluewin point ch
AIM : michelnicolas
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Une utilisatrice avait ce problème vendredi, (le 2ème cas que je décris) après une update de sécurité elle pouvait se loguer à nouveau. Hier ça fonctionnait bien et ce matin ça veux plus.
Vois aussi si certains comptes machines ne doivent pas changer le mot de passe, Mac OS X ne sait pas le faire pour le moment. Il y a un article à ce sujet sur afp548 avec un script.
Tu parles de cet article ? <http://www.afp548.com/article.php?story 061128094058598> Respecting AD account workstation restrictions
A ce que je comprends, l'AD permet de restreindre l'accès de certains utilisateurs à certaines machines. Par exemple, dire que toto n'a pas le droit de se loguer sur le pc de la compta. Cette info est stockée dans un champ SMBUserWorkstations. Le script vérifie donc le contennu de ce champ et si le nom du mac s'y trove, il te "kill".
A noter qu'il y a un petit bug dans le script, ils confondent le LocalHostName et le "AD Computer Account" :
J'ai malheureusement pas le temps de faire remonter le bug.
Pour revenir à mon problème, il est lié à l'authentification sur l'AD. Vu la situation, je fais des comptes locaux partout où il faut et basta. De toutes façon dans 2 mois tout va changer ici.
Merci encore, Laurent :) -- Nicolas - MICHEL at bluewin point ch AIM : michelnicolas
laurent.pertois
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Tu parles de cet article ? <http://www.afp548.com/article.php?story 061128094058598> Respecting AD account workstation restrictions
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Tu parles de cet article ?
<http://www.afp548.com/article.php?story 061128094058598>
Respecting AD account workstation restrictions
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Nicolas-MICHEL'_remove_'
Laurent Pertois wrote:
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Tu parles de cet article ? <http://www.afp548.com/article.php?story 061128094058598> Respecting AD account workstation restrictions
Ah, c'est intéressant en effêt. Je ne savais même pas qu'il y avait un mot de passe lié au compte de l'ordinateur.
Si j'ai bien compris l'article, sortir le mac de l'AD puis l'y remettre résouds ce problème. J'ai déjà tenté ça sans succès.
De toutes façon dans 2 mois tout va changer ici.
Ah ? tu changes quoi ? ton AD ?
Dès la fin de l'année, l'ISREC, la boite pour qui je bosse, va cesser d'exister en tant qu'institut et sera absorbée par l'EPFL, une grosse école du coin ( du niveau d'une uni, mais plus orientée ingénieurie). Donc dès novembre on aura une fibre qui nous reliera et on passera tous les ordinateur dans leur domaine, avec changement de compte, changement de mail, changement de serveurs, et je serai fonctionnaire fédéral :)
-- Nicolas - MICHEL at bluewin point ch AIM : michelnicolas
Ah, c'est intéressant en effêt.
Je ne savais même pas qu'il y avait un mot de passe lié au compte de
l'ordinateur.
Si j'ai bien compris l'article, sortir le mac de l'AD puis l'y remettre
résouds ce problème. J'ai déjà tenté ça sans succès.
De toutes façon dans 2 mois tout va changer ici.
Ah ? tu changes quoi ? ton AD ?
Dès la fin de l'année, l'ISREC, la boite pour qui je bosse, va cesser
d'exister en tant qu'institut et sera absorbée par l'EPFL, une grosse
école du coin ( du niveau d'une uni, mais plus orientée ingénieurie).
Donc dès novembre on aura une fibre qui nous reliera et on passera tous
les ordinateur dans leur domaine, avec changement de compte, changement
de mail, changement de serveurs, et je serai fonctionnaire fédéral :)
--
Nicolas - MICHEL at bluewin point ch
AIM : michelnicolas
Ah, c'est intéressant en effêt. Je ne savais même pas qu'il y avait un mot de passe lié au compte de l'ordinateur.
Si j'ai bien compris l'article, sortir le mac de l'AD puis l'y remettre résouds ce problème. J'ai déjà tenté ça sans succès.
De toutes façon dans 2 mois tout va changer ici.
Ah ? tu changes quoi ? ton AD ?
Dès la fin de l'année, l'ISREC, la boite pour qui je bosse, va cesser d'exister en tant qu'institut et sera absorbée par l'EPFL, une grosse école du coin ( du niveau d'une uni, mais plus orientée ingénieurie). Donc dès novembre on aura une fibre qui nous reliera et on passera tous les ordinateur dans leur domaine, avec changement de compte, changement de mail, changement de serveurs, et je serai fonctionnaire fédéral :)
-- Nicolas - MICHEL at bluewin point ch AIM : michelnicolas
laurent.pertois
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Si j'ai bien compris l'article, sortir le mac de l'AD puis l'y remettre résouds ce problème. J'ai déjà tenté ça sans succès.
Bon, ok.
Ah ? tu changes quoi ? ton AD ?
Dès la fin de l'année, l'ISREC, la boite pour qui je bosse, va cesser d'exister en tant qu'institut et sera absorbée par l'EPFL, une grosse école du coin ( du niveau d'une uni, mais plus orientée ingénieurie). Donc dès novembre on aura une fibre qui nous reliera et on passera tous les ordinateur dans leur domaine, avec changement de compte, changement de mail, changement de serveurs, et je serai fonctionnaire fédéral :)
Félicitations :-)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Si j'ai bien compris l'article, sortir le mac de l'AD puis l'y remettre
résouds ce problème. J'ai déjà tenté ça sans succès.
Bon, ok.
Ah ? tu changes quoi ? ton AD ?
Dès la fin de l'année, l'ISREC, la boite pour qui je bosse, va cesser
d'exister en tant qu'institut et sera absorbée par l'EPFL, une grosse
école du coin ( du niveau d'une uni, mais plus orientée ingénieurie).
Donc dès novembre on aura une fibre qui nous reliera et on passera tous
les ordinateur dans leur domaine, avec changement de compte, changement
de mail, changement de serveurs, et je serai fonctionnaire fédéral :)
Félicitations :-)
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Si j'ai bien compris l'article, sortir le mac de l'AD puis l'y remettre résouds ce problème. J'ai déjà tenté ça sans succès.
Bon, ok.
Ah ? tu changes quoi ? ton AD ?
Dès la fin de l'année, l'ISREC, la boite pour qui je bosse, va cesser d'exister en tant qu'institut et sera absorbée par l'EPFL, une grosse école du coin ( du niveau d'une uni, mais plus orientée ingénieurie). Donc dès novembre on aura une fibre qui nous reliera et on passera tous les ordinateur dans leur domaine, avec changement de compte, changement de mail, changement de serveurs, et je serai fonctionnaire fédéral :)
Félicitations :-)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
