Le 10/06/2015 22:57, andre_debian@numericable.fr a écrit :
Je ne me prononcerai pas sur l'utilité de sudo pour éviter les polémiques (même si cela peut être très utile, mais dangereux si mal maîtrisé, pour déléguer juste certains droits à des utilisateurs particuliers) mais ce que propose André ne sert pas à grand chose : sudo n'est pas un service avec un démon qui s'exécute en permanence. "/etc/init.d/sudo start" se contente de modifier des droits dans /var/lib/sudo et "/etc/init.d/sudo stop" ne fait strictement rien !On Wednesday 10 June 2015 22:41:50 F. Marécaille wrote:Punaise!! bien vu andre_debian!! en passant par "su" et ensuite apt-get update cela fonctionne mais pas avec sudo apt-get update, pourquoi???[…] C'est parce que ton sudo n'est pas configuré, /etc/sudoers Stoppes le et après c'est soit $ ou # : /etc/init.d/./sudo stop ainsi que dans le "/etc/rc2.d" => # mv SXsudo KSXsudo X étant le n° du processus et S comme start et K comme kill. Il ne démarrera plus au prochain boot du pc. sudo est un truc d'Ubuntu qui ne m'a jamais plu.
Et tout cela ne nous explique pas pourquoi la commande "aptitude update" (ou plutôt "sudo aptitude update") ne fonctionnait pas. L'erreur initiale semblait être un soucis de connexion en IPv6 mais il semble que les causes pouvaient être multiples et nous n'avons pas de détails concernant les messages d'erreur après la désactivation d'IPv6. Le contenu du fichier /etc/sudoers ou le résultat de la commande "sudo -l" (exécutée par l'utilisateur qui faisait la mise à jour) seraient également intéressant pour faire un diagnostic (je n'aime pas lâcher une question sans comprendre d'où venait le soucis, même si un contournement a été trouvé).
@+ Jean-Jacques