Tâche #15504: Après migration d'un module Horus vers 2.4.2 eth0 n'apparaît plus dans le diagnose - Horus - Ensemble Ouvert Libre Évolutif

Tâche #15504

Distribution EOLE - Scénario #15554: Traitement express (13-15)

Après migration d'un module Horus vers 2.4.2 eth0 n'apparaît plus dans le diagnose

Ajouté par Jerome WATREMEZ il y a environ 8 ans. Mis à jour il y a environ 8 ans.

Statut:

Fermé

Priorité:

Normal

Assigné à:

Fabrice Barconnière

Version cible:

Distribution EOLE - sprint 2016 13-15 - Equipe MENESR

Début:

17/03/2016

Echéance:

% réalisé:

100%

Temps estimé:

1.00 h

Temps passé:

4.33 h

Restant à faire (heures):

0.0

Description

Ajouter ifconfig dans le PATH de l'utilisateur eole

Demande originale :

Bonjour,

Lors d'une migration d'un module eole HORUS 2.2 vers un HOUS 2.4.2, je me suis aperçu d'un dysfonctionnement au niveau du diagnostic.

Lorsque j'ouvre une session locale en tant que "root" -> le diagnostic fonctionne.
Lorsque j'ouvre une session locale en tant que "eole" -> la carte eth0 est inexistante.

Une capture d'écran du message d'erreur est en pièce-jointe.

bug_eole-242.PNG Voir (4,78 ko) Jerome WATREMEZ, 17/03/2016 08:49

Révisions associées

Révision af20d61d (diff)
Ajouté par Fabrice Barconnière il y a environ 8 ans

diagnose en console avec utilisateur eole : chemin ifconfig complet

ref #15504 @10m

Révision fa306aae (diff)
Ajouté par Fabrice Barconnière il y a environ 8 ans

diagnose en console avec utilisateur eole : chemin ifconfig complet

ref #15504 @10m

Historique

#1 Mis à jour par Gérald Schwartzmann il y a environ 8 ans

Sujet changé de eth0 inexistante pour eole@HORUS 2.4.2 à Après migration d'un module Horus vers 2.4.2 eth0 n'apparaît plus dans le diagnose

#2 Mis à jour par Fabrice Barconnière il y a environ 8 ans

Tracker changé de Demande à Tâche
Description mis à jour (diff)
Temps estimé mis à 1.00 h
Tâche parente mis à #15270
Restant à faire (heures) mis à 1.0

#3 Mis à jour par Fabrice Barconnière il y a environ 8 ans

Il est possible d'ajouter la ligne suivante dans le template sudoers :

Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin

#4 Mis à jour par Fabrice Barconnière il y a environ 8 ans

/bin/login -- ne passe pas les variables d'environnement.
On peut reproduire le problème soit :

en se connectant eole directement depuis la console
en se connectant root en ssh puis en lançant /bin/login -- avec l'utilisateur eole

Le problème n'est pas présent en 2.3 ni en 2.5. S'agit-il d'un comportement Ubuntu différent entre ces 2 versions ?

#5 Mis à jour par Fabrice Barconnière il y a environ 8 ans

Le fichier login est généré par un template fournis par eole-fichier
En remettant le fichier original fourni par le paquet login le diagnose a accès au PATH sbin

#6 Mis à jour par Fabrice Barconnière il y a environ 8 ans

Le problème est identique en 2.5 sur Horus et Scribe.
Sur Amonecole ce fichier est instancié dans le conteneur. Sur le maître, on conserve le fichier d'origine du paquet et le problème ne se pose pas.

Il faut peut-être revoir ce template.

#7 Mis à jour par Fabrice Barconnière il y a environ 8 ans

 This module parses environment configuration file(s)
# and also allows you to use an extended config
# file /etc/security/pam_env.conf.
# 
# parsing /etc/environment needs "readenv=1" 
session       required   pam_env.so readenv=1

En ajoutant cette ligne dans le template, c'est OK.

#8 Mis à jour par Fabrice Barconnière il y a environ 8 ans

Je ne suis pas certain de la solution car avec ceci, l'utilisateur eole a le chemin /sbin dans son PATH.
Auparavant, ce n'était pas le cas, c'est au moment du sudo que le PATH est modifié.

Peut-être du coté de /etc/login.defs
Le PATH en sudo reste celui de ENV_PATH défini dans /etc/login.defs
En 2.3, il prend la valeur de ENV_SUPATH + concaténation avec /usr/X11R6/bin