J'ai dû transférer des utilisateurs d'un ordi à un autre, sans accès
physique sur l'un des 2 mac.
Donc j'ai joué avec rsync, nidump et niload.
Sauf que j'ai eu 2 problèmes :
D'un, les passwd n'ont pas suivis, j'ai dû faire un reset après coup.
peut-on fait un nidump qui conserve les passwd dans un format
"transportable" ?
De deux, j'ai pas trouvé comment ne pas écraser les utilisateurs
existants lors du niload, même avec l'option -m
N'ayant pas de machine de test en je l'ai fait à l'arrache, mais ça
m'intéresserait de savoir comment j'aurais dû m'y prendre pour bien
faire.
Donc j'ai fait un truc de ce genre :
macSource# niload -r /users . > Src_users.nidump
macDest# niload -r /users . > Local_users.nidump
puis j'ai mixé les 2 fichiers à la main et enfin :
macDest# niload -r /users . < mix_users.nidump
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
jayce.piel
Nicolas MICHEL wrote:
Donc j'ai fait un truc de ce genre : macSource# niload -r /users . > Src_users.nidump macDest# niload -r /users . > Local_users.nidump puis j'ai mixé les 2 fichiers à la main et enfin : macDest# niload -r /users . < mix_users.nidump
Merci d'avance :)
Alors pour le mot de passe, pas de solution, question de sécurité.
Pour la manip :
macSource# nidump passwd . > Src_users.nidump
macDest# niload passwd . < Src_users.nidump
If -r directory is specified instead of a flat-file file format, the input is interpreted as "raw" NetInfo data, as generated by nidump -r, and loaded into directory. Note that this operation will delete and replace the entire NetInfo subtree at the specified directory. Any existing records in this subtree will be lost.
niload overwrites entries in the existing directory with those given in the input. Entries that are in the directory aren't deleted if they don't exist in the input, unless the -d option is specified. niload must be run as superuser on the master NetInfo server for the given domain, unless one specifies the -p option, which allows one to run from anywhere in the network.
-- Anonyme ( jayce <@> mosx.net ) ********* MosX.net <http://www.mosx.net/> ********* (avec un put§@#* de problème DNS sur le domaine mosx.net)
Nicolas MICHEL <Nicolas.MICHEL@BonBon.net> wrote:
Donc j'ai fait un truc de ce genre :
macSource# niload -r /users . > Src_users.nidump
macDest# niload -r /users . > Local_users.nidump
puis j'ai mixé les 2 fichiers à la main et enfin :
macDest# niload -r /users . < mix_users.nidump
Merci d'avance :)
Alors pour le mot de passe, pas de solution, question de sécurité.
Pour la manip :
macSource# nidump passwd . > Src_users.nidump
macDest# niload passwd . < Src_users.nidump
If -r directory is specified instead of a flat-file file format, the
input is interpreted as "raw" NetInfo data, as generated by nidump -r,
and loaded into directory. Note that this operation will delete and
replace the entire NetInfo subtree at the specified directory. Any
existing records in this subtree will be lost.
niload overwrites entries in the existing directory with those
given in the input. Entries that are in the directory aren't
deleted if they don't exist in the input, unless the -d option
is specified. niload must be run as superuser on the
master NetInfo server for the given domain, unless one specifies
the -p option, which allows one to run from anywhere in the
network.
--
Anonyme ( jayce <@> mosx.net )
********* MosX.net <http://www.mosx.net/> *********
(avec un put§@#* de problème DNS sur le domaine mosx.net)
Donc j'ai fait un truc de ce genre : macSource# niload -r /users . > Src_users.nidump macDest# niload -r /users . > Local_users.nidump puis j'ai mixé les 2 fichiers à la main et enfin : macDest# niload -r /users . < mix_users.nidump
Merci d'avance :)
Alors pour le mot de passe, pas de solution, question de sécurité.
Pour la manip :
macSource# nidump passwd . > Src_users.nidump
macDest# niload passwd . < Src_users.nidump
If -r directory is specified instead of a flat-file file format, the input is interpreted as "raw" NetInfo data, as generated by nidump -r, and loaded into directory. Note that this operation will delete and replace the entire NetInfo subtree at the specified directory. Any existing records in this subtree will be lost.
niload overwrites entries in the existing directory with those given in the input. Entries that are in the directory aren't deleted if they don't exist in the input, unless the -d option is specified. niload must be run as superuser on the master NetInfo server for the given domain, unless one specifies the -p option, which allows one to run from anywhere in the network.
-- Anonyme ( jayce <@> mosx.net ) ********* MosX.net <http://www.mosx.net/> ********* (avec un put§@#* de problème DNS sur le domaine mosx.net)
Nicolas.MICHEL
Anonyme wrote:
Alors pour le mot de passe, pas de solution, question de sécurité.
J'y avait pensé, mais ça ne prends que les info unix classique. Il va donc manquer quelques info. (comment, mcx, picture, ...) Bon, en fait à part le hash j'en ai rien à battre de ces info. Et comme le ShadowHash ne passe pas de toutes façon, je me suis compliqué la vie pour rien.
Note that this operation will delete and replace the entire NetInfo subtree at the specified directory. Any existing records in this subtree will be lost.
Ok, donc avec un nidump -r, il faut effectivement faire ce que j'ai fait, c'est à dire compléter le dump à la mano.
Merci Jayce :) -- Nicolas
Anonyme <jayce.piel@gmail.com> wrote:
Alors pour le mot de passe, pas de solution, question de sécurité.
J'y avait pensé, mais ça ne prends que les info unix classique.
Il va donc manquer quelques info. (comment, mcx, picture, ...)
Bon, en fait à part le hash j'en ai rien à battre de ces info.
Et comme le ShadowHash ne passe pas de toutes façon, je me suis
compliqué la vie pour rien.
Note that this operation will delete and
replace the entire NetInfo subtree at the specified directory. Any
existing records in this subtree will be lost.
Ok, donc avec un nidump -r, il faut effectivement faire ce que j'ai
fait, c'est à dire compléter le dump à la mano.
J'y avait pensé, mais ça ne prends que les info unix classique. Il va donc manquer quelques info. (comment, mcx, picture, ...) Bon, en fait à part le hash j'en ai rien à battre de ces info. Et comme le ShadowHash ne passe pas de toutes façon, je me suis compliqué la vie pour rien.
Note that this operation will delete and replace the entire NetInfo subtree at the specified directory. Any existing records in this subtree will be lost.
Ok, donc avec un nidump -r, il faut effectivement faire ce que j'ai fait, c'est à dire compléter le dump à la mano.
Merci Jayce :) -- Nicolas
laurent.pertois
Anonyme wrote:
Alors pour le mot de passe, pas de solution, question de sécurité.
Euh, en copiant les fichiers de /var/db/shadow/hash sans changer le nom et en vérifiant qu'ils correspondent bien au GeneratedUID sur la nouvelle machine, ça doit suivre.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Anonyme <jayce.piel@gmail.com> wrote:
Alors pour le mot de passe, pas de solution, question de sécurité.
Euh, en copiant les fichiers de /var/db/shadow/hash sans changer le nom
et en vérifiant qu'ils correspondent bien au GeneratedUID sur la
nouvelle machine, ça doit suivre.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Alors pour le mot de passe, pas de solution, question de sécurité.
Euh, en copiant les fichiers de /var/db/shadow/hash sans changer le nom et en vérifiant qu'ils correspondent bien au GeneratedUID sur la nouvelle machine, ça doit suivre.
-- 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:
Anonyme wrote:
Alors pour le mot de passe, pas de solution, question de sécurité.
Euh, en copiant les fichiers de /var/db/shadow/hash sans changer le nom et en vérifiant qu'ils correspondent bien au GeneratedUID sur la nouvelle machine, ça doit suivre.
Merci ! Archivé ....
Donc en fait ce que j'ai fait était juste, "concaténer" 2 "niload -r /users . " mais j'aurais dû également copier les fichier qui sont dans /var/db/shadow/hash et dont le nom corresponds au UUID des users que je veux importer ?
Alors pour le mot de passe, pas de solution, question de sécurité.
Euh, en copiant les fichiers de /var/db/shadow/hash sans changer le nom
et en vérifiant qu'ils correspondent bien au GeneratedUID sur la
nouvelle machine, ça doit suivre.
Merci !
Archivé ....
Donc en fait ce que j'ai fait était juste, "concaténer" 2
"niload -r /users . " mais j'aurais dû également copier les fichier qui
sont dans /var/db/shadow/hash et dont le nom corresponds au UUID des
users que je veux importer ?
Alors pour le mot de passe, pas de solution, question de sécurité.
Euh, en copiant les fichiers de /var/db/shadow/hash sans changer le nom et en vérifiant qu'ils correspondent bien au GeneratedUID sur la nouvelle machine, ça doit suivre.
Merci ! Archivé ....
Donc en fait ce que j'ai fait était juste, "concaténer" 2 "niload -r /users . " mais j'aurais dû également copier les fichier qui sont dans /var/db/shadow/hash et dont le nom corresponds au UUID des users que je veux importer ?
-- Nicolas
laurent.pertois
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
Donc en fait ce que j'ai fait était juste, "concaténer" 2 "niload -r /users . " mais j'aurais dû également copier les fichier qui sont dans /var/db/shadow/hash et dont le nom corresponds au UUID des users que je veux importer ?
Oui, et c'est d'ailleurs là qu'on remercie Apple d'utiliser des UUID et pas un nom ou un uid pour distinguer les fichiers.
-- 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:
Donc en fait ce que j'ai fait était juste, "concaténer" 2
"niload -r /users . " mais j'aurais dû également copier les fichier qui
sont dans /var/db/shadow/hash et dont le nom corresponds au UUID des
users que je veux importer ?
Oui, et c'est d'ailleurs là qu'on remercie Apple d'utiliser des UUID et
pas un nom ou un uid pour distinguer les fichiers.
--
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:
Donc en fait ce que j'ai fait était juste, "concaténer" 2 "niload -r /users . " mais j'aurais dû également copier les fichier qui sont dans /var/db/shadow/hash et dont le nom corresponds au UUID des users que je veux importer ?
Oui, et c'est d'ailleurs là qu'on remercie Apple d'utiliser des UUID et pas un nom ou un uid pour distinguer les fichiers.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
