Jessie, problème de droits

Bonjour, j’ai une machine qui sert de serveur musical. J’ai installé Jessie à partir de zéro il y a quelques semaines. J’ai deux petits problèmes:

-Le partage NFS fonctionne très mal: les fichiers s’affichent dans le dossier, mais lorsque je veux copier quelque chose dans le répertoire, j’ai un message “opération non permise”. Monter le dossier en root ne change rien.

-J’ai mis un script avec une tâche cron pour que la machine se mette en veille toute seule à une heure h. Mais cela ne fonctionne pas, car elle réclame un mot de passe.

Voici le fichier sudoers du serveur:

[code]# User privilege specification
root ALL=(ALL:ALL) ALL
minerve ALL=(ALL:ALL) ALL

Allow members of group sudo to execute any command

%sudo ALL=(ALL:ALL) ALL, NOPASSWD: /usr/sbin/hibernate, /sbin/reboot[/code]

ainsi que /etc/exports:

et le script pour hiberner, qui fonctionne très bien (et sans mot de passe) sur mon autre machine sous Jessie, avec un fichier sudoers identique:

Donc, j’ai l’impression que ces deux problèmes n’en sont qu’un, et que j’ai un problème de permissions quelque part. Ne sachant où chercher, je me tourne vers vous. Merci.

…ah oui, et le message d’erreur quand je veux mettre la machine en hibernation:

Authentification requise pour mettre le système en hibernation. Authenticating as: root

Et en plus il faut obéir dans les cinq secondes:

Password: Failed to execute operation: Connexion terminée par expiration du délai d'attente Failed to start hibernate.target: Access denied polkit-agent-helper-1: pam_authenticate failed: Authentication failure

salut
c’est pas plutôt (comme disait Mickey)

wiki.archlinux.org/index.php/Sy … management

ce genre de cron je l’ai mis dans la crontab systeme , pas d’histoire de mot de passe
forum.ubuntu-fr.org/viewtopic.p … #p19955211

Salut Grandtoubab,

Désolée, j’avais retranscrit la commande de mémoire, c’est bien systemctl. J’ai édité mon message.

Pour la tâche cron:

Je veux mettre la machine en hibernation, pas l’éteindre. Elle est au fond d’un placard, vraiment pas accessible, et doit être réveillée à distance au moyen d’un téléphone, ce qu’on ne peut pas faire si la machine est éteinte.

Et puis, à chaque mise à jour c’est la même chose: la commande qui servait à hiberner ne fonctionne plus, et il faut en trouver une autre…

Sur ma machine principale (jessie aussi), systemctl hibernate fonctionne très bien sans mot de passe. Les deux fichiers sudoers sont identiques, les /etc/group aussi. Donc je ne comprends pas…

j’ai bien compris que tu veux hiberner
je te donne simplement un exemple de tache dans la crontab syteme…

Oh pardon! J’avais juste vu “poweroff”, et non le “root” juste avant. J’ai mis ça dans ma crontab, et ça va sûrement fonctionner. Merci.

Mais cela ne résoud pas mon problème: sur mon autre machine je n’ai pas besoin d’être root, et sur celle-ci je n’en avais pas besoin avant. Et puis il y a ce problème de partage NFS qui ne fonctionne pas correctement. Comment trouver l’origine du problème? J’ai installé Jessie en partant de zéro, et n’ai rien bidouillé…

ne confond pas les crontab utilisateur (root, ou user)que l’on modifie avec crontab -e et la crontab système dont je parle dans mon exemple

Merci, c’est corrigé.

Du coup l’ordinateur se met bien en veille automatiquement (encore heureux :smiling_imp: ), mais il refuse catégoriquement de se réveiller avec l’application Wakeonlan.

La commande sudo ethtool eth0 | egrep "^[[:blank:]]*Wake-on: (g|d)" donne ceci: Wake-on: g

Donc la carte réseau n’est pas en cause…j’ai bien revérifié l’adresse Mac. Lorsque j’envoie les paquets magiques avec wakeonlan [adresse mac], il n’y a pas de message d’erreur, mais la machine ne se réveille pas.

J’ai suivi à la lettre ce tuto doc.ubuntu-fr.org/wakeonlan. Wakeonlan fonctionnait à la perfection sur cette machine sous Wheezy.

Si ça se trouve c’est un problème de permissions, il me manque peut-être juste un paquet sur ma bécane. Sauf que j’ai beau chercher, je ne trouve pas…

Quand la machine à réveiller par Wake On Lan est en veille, est-ce qu’il y a un voyant qui reste allumé (du côté du connecteur RJ45 de la carte réseau de cette machine) ?

Si non, c’est peut-être que l’interruption (WoL) est bien en place pour accepter le signal, mais la carte réseau n’est pas alimentée, et du coup, elle ne transmet pas le signal de réveil.

Peut-être une option du BIOS concernant la mise en veille et/ou le Wake On Lan…

=======

C’est pas du [mono]Wake On Lan[/mono], mais au cas où tu veuille la réveiller à une certaine heure, peut-être que le fil de discussion suivant pourrait t’intéresser => Power On By RTC Alarm": Oui !, c’est possible !

Merci MicP :confused: . Je reformule ma question:

Je suis à la recherche DU truc qui débloque, et qui m’empêche:

1°) de copier des fichiers dans un dossier partagé en NFS (mais pas de les supprimer)

2°) de mettre ma machine en hibernation sans être root, bien que j’aie configuré /etc/sudoers

3°) de réveiller ladite machine par Wakeonlan, bien que la carte-réseau soit bien configurée…

Y-a-t-il un (ou plusieurs) voyant(s) au dessus ou à côté du connecteur de la carte réseau de la machine que tu essaie de réveiller par le Wake on Lan ?

=======
NOTE : AMHA tu éviterais beaucoup de confusions et aurait sans aucun doute plus de réponses en créant un fil pour chacun de ces 3 problèmes :

  • Problème accès NFS
  • Problème Wol
  • Problème mise en veille

Non, pas de voyants…mais regarde mon message de 6h10…

Merci pour la réponse concernant le voyant : Du coup pas moyen de savoir si la carte est alimentée quand la machine est a l’arrêt.
Il devrait y avoir une option du BIOS permettant les réveils par PCI, par USB, etc. (chaque BIOS à sa formulation spécifique concernant ces fonctionnalités).
C’est ce genre d’option qui permet de garder la carte réseau alimentée même si la machine est à l’arrêt.

=======
J’avais lu ton message du 08 Juin 2015, 07:10 (UTC+0200), mais je n’y avais rien trouvé concernant l’existence d’un voyant : J’y vois seulement que le signal de réveil envoyé par la carte réseau sera pris en compte par le circuit de la carte mère qui va permettre la remise en route de la machine, mais si la carte réseau n’est pas alimentée elle ne pourra pas envoyer ce signal.

Mais j’ai dit que ça fonctionnait à la perfection sous Jessie sur cette machine. Et je n’ai pas touché au BIOS.

Peut-être que l’envoi des paquets fonctionne mais que la machine ne se réveille pas parce qu’elle veut un mot de passe. C’est possible ça?

Le réveil par Wake On Lan est totalement indépendant du système d’exploitation de la machine qui va être réveillée, c’est l’électronique de la machine qui s’en occupe.

Dès que le “magic paquet” est reçut par une carte réseau qui sait le reconnaître, elle envoie un signal vers le même circuit électronique qui détecte l’appui sur le bouton marche/arrêt de la machine.
Si ce circuit a été “paramétré” pour tenir compte de ce signal (par la commande ethertool …), il remettra la machine en route comme si quelqu’un avait appuyé sur le bouton Marche Arrêt,
mais il faut aussi que la carte réseau reste sous tension quand la machine est à l’arrêt (ce qui est le cas quand la machine est en mode “hibernation”)

La différence entre Arrêt et hibernation réside dans le fait que la machine sauvegarde son état (copie de la RAM dans le Swap) juste avant de se mettre à l’arrêt.
Quand une machine démarre, si elle trouve dans le swap une sauvegarde, elle restaure l’état de la machine qui avait été enregistré, sinon, elle démarre normalement.

=============

[quote]…je n’ai pas touché au BIOS.…[/quote]Le BIOS est un micro-programme de gestion du matériel qui mémorise la configuration matérielle et initialise les composants de la machine au moment de sa mise en route (POST). Il permet aussi de modifier certains paramètres en présentant une interface plus ou moins conviviale.
Généralement, le système d’exploitation ne modifie pas la configuration des composants de la machine qui a été faîte par le BIOS, mais certains paramètres des composants électroniques peuvent se voir modifiés par le système d’exploitation, ou plus précisément par l’intermédiaire des différentes couches qui partent du SE jusqu’au matériel, comme par exemple la synchronisation de l’heure et la date par NTP, du refroidissement, de la fréquence d’horloge de certains micro-processeurs, de l’alimentation, et cela peut causer parfois de très rares conflits d’accès (BIOS ASUS par exemple). Note perso : Bien fait pour eux! Yzavaient qu’à fournir les sources.
En utilisant le Wake On Rtc, je signalais, dans le fil que j’ai cité, que malgré le fait que la remise en route programmée par la méthode que j’utilisais fonctionnait parfaitement, l’affichage des Heure/dates de réveil (et d’autres paramètres de la RTC) par l’intermédiaire de l’interface du BIOS était incohérent.

Nan mais, ce que je suis %@#…

En branchant le câble réseau, ça fonctionne mieux comme ça. Merci MicP, pour ta réponse qui m’a fait investiguer un peu plus.

Je n’ai plus qu’à résoudre mon problème de partage NFS. Merci pour les réponses déjà données.

[quote]En branchant le câble réseau, ça fonctionne mieux comme ça.[/quote] :laughing: :laughing: :laughing: Ça me rassure : je ne suis pas le seul à être distrait, car bien sûr ça aussi ça m’est arrivé. :slightly_smiling:

:smiley:

Bon, sinon j’avance dans mon enquête. Le dossier partagé en NFS s’appelle /serveur. Or, lorsque je tape ls -l dans un terminal, j’ai ceci:

drwxr-xr-x 2 minerve minerve 4096 mai 25 15:11 samsung -rw-r--r-- 1 minerve minerve 411808872 oct. 17 2014 sauvegarde site 171014.zip drwxr-xr-x 2 minerve minerve 4096 mai 24 12:33 serveur drwxr-xr-x 30 minerve minerve 20480 juin 7 21:31 téléchargements

Mais voilà ce qui se passe lorsque je clique sur le dossier /serveur pour l’ouvrir:

ls -l drwxrwxrwx 1 systemd-timesync users 327680 juin 8 11:06 serveur

Et la ligne correspondante dans le /etc/fstab du client:

Cela me paraît vraiment très étrange.