Y
ymai

  • 11 nov. 2008
  • Inscrit 18 mars 2006
  • 0 meilleure réponse
  • Petit nouveau Rédacteur potentiel
  • Je pense avoir trouvé la solution avec la commande newusers.
    Plus besoin de pouvoir coder les mots de passe; plus besoin du script.

    Comment marquer le sujet comme "Résolu"?
  • Minuteman wrote:Une fois tout à la fin ça me semblerait plus adapté.
    Correct dans le principe, bien sûr.
    Mais à vérifier. Il me semble avoir eu un souci lors d'un test où tous mes utilisateurs faisaient partie du même groupe général. NIS ne semblait pas apprécier de recevoir tant d'utilisateurs (plus de 1000). J'ai donc déplacé l'intégration dans NIS, un utilisateur à la fois.
  • Bonjour
    Merci d'avoir répondu.
    Je constate que l'encodage sha1 de "abcdefg" donne systématiquement
    2fb5e13419fc89246865e7a324f476ec624e8740
    cependant que /etc/passwd pour le même mot de passe donne, par exemple
    $1$KkYjjikp$xPHJsUk5ip0itlCNI6UgF1
    qui débute par $1$
    Je crains donc que l'encodage sha1 ne soit pas de mise.
    D'autant, il me semble d'après le manuel, que $1$ soit caractéristique de md5.

    En passant, je signale que l'utilisation de la fonction md5(), à la place de script() dans mon script ne donne pas de meilleurs résultats.
  • Bonjour
    Pour démarrer l'année scolaire, je dois ajouter plusieurs centaines d'utilisateurs "élèves" sur mon serveur d'authentification.
    J'utilise, pour ce faire, un script qui lit un fichier CSV contenant les informations nécessaires:
    username
    nom réel
    mot de passe
    groupe
    Le script fonctionne plutôt bien puisque les utilisateurs sont parfaitement créés avec leur répertoire personnel et leur groupe.
    Le souci vient de l'encryptage des mots de passe pour /etc/passwd qui ne se fait pas correctement bien que la forme desdits mots de passe semble correcte: :$1$evMmXOwB$FdN5vD9oYrHL42JgPpHCG1 , par exemple.
    J'imagine donc que la fonction PHP script() que j'utilise n'est pas la bonne fonction ou que je l'utilise mal.

    Ci-dessous, une version un peu nettoyée du script:
    Code:
    <?php
    $eleves=file('eleves2008.csv');

    // lecture ligne par ligne du fichier CSV => $eleves[]
    foreach($eleves as $key => $unEleve){
    $line = explode(',',rtrim($unEleve));
    if($line[0]!='""')
    $eleves[$key]=$line;
    }

    $listeclasses=array();
    $n=0;
    $nombreEleves = count($eleves);
    while($n < $nombreEleves)
    {
    // suppression des guillemets du CSV
    $user=str_replace("\"",'',$eleves[$n][0]);
    $mdp=str_replace("\"",'',$eleves[$n][1]);
    $nom=str_replace'"\"", '', $eleves[$n][2]);
    $classe=str_replace("\"",'',$eleves[$n][3]);
    .....
    // ++++++++++++++++++++++++++++++++++++++++
    // cryptage du mot de passe
    // NE FONCTIONNE PAS!!!
    $crpassword = crypt($mdp);
    // NE FONCTIONNE PAS!!
    // ++++++++++++++++++++++++++++++++++++++++

    $todo = "/usr/sbin/useradd $user -g $classe -m -c $nom ";
    $todo .= "-p $crpassword -d /home/eleves/$classe/$user -k /etc/squelette";
    system($todo);

    system ("chown -R $user:$classe /home/eleves/$classe/$user");

    // mise à jour de NIS
    system ("make -C /var/yp");
    $n++;
    }
    ?>


    Quelqu'un pourrait-il me mettre sur la bonne voie?
    Merci pour toute réaction.
  • Ouuupssss... Je pense avoir trouvé.
    Je regarde un peu plus en détails mon "menu.lst" et je trouve quelque chose qui m'avait échappé:
    default=0
    timeout=5
    splashimage=(hd0,3)/boot/grub/splash.xpm.gz
    hiddenmenu
    title Fedora (2.6.23.9-85.fc8)
        root (hd0,3)
        kernel /boot/vmlinuz-2.6.23.9-85.fc8 ro root=LABEL=/ acpi=on 
    rhgb quiet
        initrd /boot/initrd-2.6.23.9-85.fc8.img
    En d'autres termes, la ligne
        kernel /boot/vmlinuz-2.6.23.9-85.fc8 ro root=LABEL=/ acpi=on 
    rhgb quiet
    est bel et bien coupée. Autrement dit, rhgb quiet n'est jamais pris en compte.

    Finalement, il s'agit bien d'un problème lié à Grub.
    Je suis même tenté de penser qu'il s'agit d'un bug puisque cette coupure a dû, comme je le pressentais, avoir lieu au moment où j'ai activé le service acpid . J'en suis à penser que acpi=on suivi d'un Retour a été ajouté de manière déficiente par le système.

    J'ai restauré l'intégrité de la ligne problématique de menu.lst et tout fonctionne parfaitement.
  • Bonjour
    Merci pour cette tentative de me comprendre.
    J'ai donc dû mal m'exprimer ou bien je confonds tout (hypothèse très vraisemblable).

    Sommes-nous d'accord sur le fait que lors du démarrage de l'ordinateur, un décompte de 5 secondes laisse le temps de choisir l'OS et/ou le noyau que l'on souhaite utiliser?
    Ce décompte se fait sur une jolie image de couleur bleue au bas de laquelle on lit "FEDORA". Est-ce bien cette image qui doit se trouver dans le fichier splash.xpm.gz et qui répond effectivement à des conditions non triviales (14 couleurs max, compression gz, format .xpm) ?
    J'ai pu changer cette image pour une autre trouvée sur le web. L'image bootsplash était bien différente. Mais comme cela n'a rien changé à mon souci, je suis revenu à l'image de base.

    Sans doute l'image qui apparaît ensuite et qui cache le texte de notifications des démarrages ne doit-il donc pas être appelé "bootsplash". Je comprends que je fais fausse route et qu'elle n'a rien à voir avec Grub. Autant pour moi.
    Toujours est-il que c'est bien cette image, dans laquelle on peut -en principe- choisir de voir le détail du démarrage ou de le laisser caché.
    Mon problème est donc que je n'ai pas le choix: cette image (quelque chose comme ceci: http://www.bootsplash.org/images/e/ee/Silent-mode.jpg ) n'apparaît pas.
    Merci de m'indiquer la dénomination précise de cet écran afin que nous puissions nous comprendre.
  • Bonjour
    Au démarrage de mon portable, Grub me fait bien le décompte des secondes restant avant le démarrage sur le système par défaut. Et tout cela sur l'image bootsplash déclarée.
    Quoiqu'il arrive ensuite, l'image disparaît au profit des notifications textuelles du démarrage des services.
    Ce n'est pas très gênant, seulement pas très beau.

    Je ne suis pas 100% formel, mais il me semble que le problème est né lorsque j'ai activé l'ACPI (désactivée au départ pour permettre l'installation de FC8).
    J'ai déjà essayé de changer d'image bootsplash dans grub.conf
    splashimage=(hd0,3)/boot/grub/splash.xpm.gz
    Mais sans que cela ne change rien.

    Merci pour toute idée.
  • Résolu!!
    Tout le /home était, pour des raisons que j'ignore, passé en
    drwxr-x--- 86 root root 4096 déc 12 13:57 /home
    Il semble indispensable qu'il soit
    drwxr-x--x 86 root root 4096 déc 12 13:57 home

    J'ignore totalement les raisons de cette modification spontanée du sytème de fichiers. Mais c'est inquiétant.

    Je vais chercher comment on marque "Résolu" dans le titre.
  • Je crains qu'on se dirige vers la panne matérielle. Backup d'urgence en cours...
  • Nan, nan... Quand j'écris que c'est désactivé, c'est vraiment désactivé.
    Effectivement, par défaut, Selinux était bien là. Mais là, c'était bien volontairement désactivé.

    Le fait qu'il n'y a pas de mise à jour proposée vient peut-être du fait que mon système est obsolète: FC5.
    Je sens que je vais devoir me retirer sur la pointe des pieds.

    Dans yum.log, je vois que j'ai installé baobab, il y a trois jours. Et que j'ai réinstallé Firefox aujourd'hui; mais bien après la déclaration de la panne.
  • Merci pour ces pistes.
    kwizart wrote:Est ce que tu as modifié les permissions de ton /home ?
    Est ce que tu as vérifié les logs de connections (piraté?)
    Est ce que tu as activé selinux et est ce que les contextes sont adaptés....?

    Quand as tu fait des mises à jours du sytème pour la dernière fois ?
    Les permissions du /home n'ont pas été modifiées depuis des lustres. La situation actuelle est que
    /home appartient à root:root
    Les sous-répertoires correspondant
    * aux différentes classes dans l'école appartiennent à root:eleves
    * aux profs appartiennent à root:profs
    Ensuite, les répertoires de chaque utilisateur dans ces sous-groupes sont bien
    user:eleves ou user:profs (où "user" est bien l'identifiant personnel)
    Les logs des connexions n'indiquent rien d'équivoque autour de l'heure où le problème a commencé.

    Selinux n'est pas activé et ne l'a jamais été. J'avoue ne pas maîtriser.
    Une mise à jour serait-elle recommandée?
    [edit] Pas de mise à jour disponible[/edit]

    S'il fallait suivre la piste du piratage, comment comprendre que tous les paramètres semblent corrects, par ailleurs?
  • Bonjour
    Merci pour cette intervention TGV.
    Je trouve la section
    passwd:     files
    shadow:     files
    group:      files
    
    hosts:      files dns
    dans /etc/nsswitch.conf .
    Ce qui paraît relativement banal. Me tromperais-je?
  • Bonjour
    Je me permets de venir dans l'urgence sans avoir pu trouver de souci similaire dans les archives. Désolé si j'ai mal cherché.

    Situation: école avec 1100 utilisateurs potentiels sur un serveur Fedora. Accès par Samba (clients Windows) et par NIS pour les stations clients légers Edubuntu.
    Ce matin, 10h20, des utilisateurs se connectent sur leur client léger Edubuntu. Sans problème pour presque tous, sauf un qui se voit refuser l'accès (nom d'utilisateur et mot de passe correct).
    Après quelques minutes, les autres me signalent qu'il leur est devenu impossible d'accéder à leurs fichiers sur le même serveur.
    Lors d'une tentative de déconnexion/reconnexion, refus du serveur d'authentification Fedora: ils perdent leur accès.

    Je constate que mes utilisateurs Windows ne peuvent plus se connecter non plus.

    En SSH depuis mon serveur LTSP, je tente de me connecter sur le serveur: refus de mon mot de passe.
    [root@didactique /][root@didactique test]# ssh mai@172.16.95.3
    mai@172.16.95.3's password: 
    Last login: Wed Dec 12 12:01:26 2007 from 172.16.95.3
    Could not chdir to home directory /home/profs/mai: Permission denied
    -bash: /home/profs/mai/.bash_profile: Permission non accordée
    Je tente de créer un nouvel utilisateur:
    [root@didactique /]# /usr/sbin/useradd test
    [root@didactique /]# passwd test
    Changing password for user test.
    New UNIX password: 
    BAD PASSWORD: it is too short
    Retype new UNIX password: 
    passwd: all authentication tokens updated successfully.
    [root@didactique /]# su test
    bash: /home/test/.bashrc: Permission non accordée
    Je suis l'utilisateur bien connu "mai" sur ce serveur. Je tente un
    [root@didactique test]# su mai
    bash: /home/profs/mai/.bashrc: Permission non accordée
    J'ai vérifié les autorisations sur le fichier .bashrc
    -rwxr-x---   1 mai  profs     124 sep  4 11:13 .bashrc
    mon nom d'utilisateur est bien "mai" et je suis bien membre du groupe "profs"
    [root@didactique mai]# groups mai
    mai : profs eleves
    J'ai, bien sûr, tenté un redémarrage du serveur Fedora, sans résultat.
    Sur le serveur lui-même, je ne puis plus me connecter autrement qu'en "root".
    Tous mes utilisateurs sont toujours présents dans /etc/passwd et /etc/shadow. Reconnus également dans Webmin.

    Si quelqu'un avait une piste à me faire suivre, je serais extrêmement reconnaissant.
  • Visiblement, ma réponse n'est pas passée. Je retente le coup...

    Au boulot, j'ai deux machines FC3 et FC5. Pour autant que je me souvienne, aucun problème de connexion SSH entre-elles.
    L'hypothèse de souci au niveau du mot de passe me paraît improbable puisque c'est simplement le temps *avant* la demande de mot de passe qui est anormal. Dès que le mot de passe est donné, tout va bien immédiatement.
    Tout comme un autre intervenant, je connecte l'autre machine par son adresse IP directement, sans passer par DNS.

    Dans mon cas particulier, j'en viens donc à soupçonner mon routeur. Draytek 2900G. Si quelqu'un connaît...
  • Bonjour
    Je me permets de rebondir sur la question de lenteur d'accès SSH.
    En fait, j'observe le même phénomène sur mon réseau local sous Ubuntu 7.04.
    On retrouvera des traces de mes questions posées sur les forums ad-hoc à partir de http://www.google.be/search?q=Ubuntu+ssh+slow
    Aucune des solutions proposées n'a fonctionné.
    On verra que le bug est en cours pour Ubuntu. Aux dernières nouvelles, pas résolu.

    Ayant l'oeil attiré par la Fedora 7, je me décide de booter sur un Live CD. L'idée étant de l'installer après essai.
    Malheureusement, je constate exactement le même phénomène.
    Les connexions SSH fonctionnent sans souci sur des serveurs distants. En réseau local, c'est galère: 15 secondes d'attente avant la demande de mot de passe.
    Mon PC desktop est 192.168.1.10
    ssh yves@192.168.1.10 => 15 secondes avant mdp
    Exactement le même comportement depuis mon portable 192.168.1.12
    Mais ensuite, la connexion est bonne.

    Il doit y avoir un truc tout bête: je n'imagine pas que ces distributions puissent être utilisées en environnement professionnel sans que SSH ne fonctionne en local.
    Se pourrait-il qu'il s'agisse d'une particularité de mon matériel? Tant mon Desktop que mon portable?
    Autre hypothèse: je suis vraiment un boulet.

    Pour info
    [yves@localhost /]$ uname -r
    2.6.21-1.3194.fc7
    Merci pour toute information.
  • J'avais tenté une Ubuntu 6.10 car elle était passée sans problème sur mon portable Amilo Pro.
    Effectivement, pas de réseau.
  • Je n'ai pas noté, mais je pense que c'était simplement la notification du fait que mes droits étaient insuffisants.
    Bon, pas grave, j'imagine...
  • Bonjour
    Ce petit mot pour remercier tous ceux qui se sont penchés sur mon cas.
    Je confirme que le problème était d'abord celui du kernel. J'ai fait la mise à jour en utilisant la procédure indiquée là: http://fedoraproject.org/wiki/Bugs/FC6Common
    Ensuite, j'ai appliqué la méthode synthétisée par n1ck0, ci-dessus (en root depuis le point 1, toutefois; sinon, il me semble que cela ne passait pas).

    Je viens de tester la carte son, parfaitement détectée.
    Tout cela reste du domaine des incantations, pour moi. Merci pour votre patience.
  • Bonjour
    Chez moi, ça ne fonctionne plus à partir de là:
    # rpm -Uvh --replacefiles --replacepkgs glibc-2.5-3.i686.rpm
    erreur: Dépendances requises:
            glibc-common = 2.5-3 est nécessaire pour glibc-2.5-3.i686
            glibc = 2.5-10.fc6 est nécessaire pour (déjà installé) glibc-headers-2.5-10.fc6.i386
            glibc = 2.5-10.fc6 est nécessaire pour (déjà installé) glibc-devel-2.5-10.fc6.i386
    [edit]Ouuuuuppsssss.... J'ai pris le parti de lire le wiki qui m'a donné plein d'informations.
    Désolé pour le bruit. Cela me fait un peu d'humilité en rab pour mes interventions sur d'autres forums où je suis plus à l'aise (euphémisme)[/edit]