Looking for Computer Science  & Information Technology online courses ?
Check my new web site: https://www.yesik.it !


Le répertoire /etc/profile.d est un répertoire qui contient des fragments (snippets) de scripts d'initialisation. L'objectif de ce dossier est d'avoir une approche plus modulaire qu'en allant modifier directement des scripts d'initialisation monolithiques.

Au lancement d'un Bourne shell par un utilisateur, le script /etc/profile est exécuté. Celui-ci déclenche à son tour l'exécution des scripts contenus dans le dossier /etc/profile.d. Le mécanisme peut être adapté à d'autres shells, comme le C-shell par exemple.

Mais toutes les distributions ne disposent pas de ce mécanisme. Debian, en particulier prévient dans son manifeste contre la création automatique de ce dossier – et plus généralement contre la nécessité d'utiliser des scripts d'initialisation pour les packages. Pourquoi? Parce que rien ne garantit le shell utilisé par l'utilisateur pour se connecter. Rien ne garantit même qu'il utilise un shell! La philosophie de Debian consiste donc à dire que dans ces conditions, un logiciel ne doit pas reposer sur des scripts d'initialisation pour son fonctionnement[1]. C'est d'ailleurs un des rôles des mainteneurs de s'assurer que les logiciels debianisés remplacent ce mécanisme par un quelconque autre pour s'assurer que les logiciels fonctionnent avec des valeurs par défaut satisfaisantes.

Ce point de vue se défend. En particulier pour l'éditeur d'une distribution. Par contre, du point de vue de l'administrateur, les choses peuvent parfois être un peu nuancées. En effet, en tant qu'administrateur, vous savez quels shells de connexion sont utilisés pas vos utilisateurs. Par ailleurs, vous serez sans doute aussi amené à installer des logiciels manuellement. Et, à moins de débianiser vous même ces logiciels, un jour ou l'autre vous allez vous retrouvez dans l'obligation de devoir mettre en place des scripts d'initialisation. Voici donc comment ajouter et utiliser le dossier /etc/profile.d sur les distributions qui n'en disposent pas.

Note:

La politique de Debian n'interdit pas à l'administrateur de créer un dossier profile.d. Elle l'interdit aux mainteneurs des paquets Debian. En tant qu'administrateur, vous avez le loisir de modifier les fichiers de configuration situés dans /etc à votre guise.

Si vous avez une machine Debian sous la main, jeter un coup d'oeil au fichier /usr/share/doc/base-files/FAQ. Il contient toute une section à ce sujet.

Créer profile.d

Après cette mise au point, il est temps de rentrer dans le vif du sujet. Commençons par créer le répertoire profile.d: 

sh# mkdir /etc/profile.d

Reste aussi à modifier les scripts d'initialisation de votre système pour qu'ils chargent le contenu de ce répertoire. Et là, il va falloir modifier le script d'initialisation de chaque shell de connexion utilisé par vos utilisateurs.

bash.bashrc

Si vous – ou vos utilisateurs – utilisez le shell Bash (ou compatible), ajoutez les lignes suivantes au script /etc/bash.bashrc: 

PROFILE_DIR=/etc/profile.d
 
if [ -d "${PROFILE_DIR}" ]; then
  for i in ${PROFILE_DIR}/*.sh
  do
    . "$i"
  done
fi

Ajoutez le même code au fichier /etc/profile.

csh.cshrc

Si vous – ou vos utilisateurs – utilisez le C shell (csh ou tcsh), ajoutez les lignes suivantes au script /etc/csh.cshrc: 

set PROFILE_DIR=/etc/profile.d
 
if ( -d ${PROFILE_DIR} ) then
        foreach i ( ${PROFILE_DIR}/*.csh )
                source $i
        end
endif

Utilisation

Voilà, en fait tout ce que nous avons fait, c'est de nous assurer qu'à l'ouverture d'un shell, les scripts adaptés au shell en question et situés dans /etc/profile.d soient exécutés. Reste à créer ces scripts. Ici, à nouveau, il faudra en faire un par shell utilisé! Comme quoi, la philosophie de Debian "zéro script d'initialisation" se tient finalement...

Pour vous convaincre du fonctionnement du système, vous pouvez par exemple créer les scripts suivants:

bash

Au démarrage d'un shell, les scripts correspondants dans /etc/profile.d sont exécutés (dans l'exemple ci-dessus, il s'agit d'un bash).

Créez le fichier /etc/profile.d/local-demo.sh: 

sh# cat > /etc/profile.d/local-demo.sh << EOF
#
# Demo initialization script for bash(1)
#

echo "Hello,"
echo "You are using a bash (or compatible) shell!"
EOF

csh, tcsh

Créez le fichier /etc/profile.d/local-demo.csh: 

csh# cat > /etc/profile.d/local-demo.csh << EOF
#
# Demo initialization script for csh(1)
#

echo "Hello,"
echo "You are using a C (or compatible) shell!"
EOF

Les alternatives

/etc/environment

Une remarque pour terminer: tous les scripts dont nous venons de parler ne sont exécutés qu'au démarrage d'un shell interactif. Autrement dit quand un utilisateur se connecte. Ils ne permettent pas d'initialiser l'environnement au démarrage de la machine.

Dans ce cas, des alternatives sont possibles. Par exemple, si l'initialisation se résume à définir une ou plusieurs variables d'environnement, modifier le fichier /etc/environment peut suffire (à condition que votre distribution fasse usage de ce fichier – sur un système Unix-like récent utilisant PAM, c'est sans doute le cas). Debian, par exemple, utilise ce fichier pour initialiser la variable LANG au démarrage de la machine: 

sh$ cat /etc/environment
LANG="en_US.UTF-8"

Liens symboliques

L'utilisation d'un lien symbolique permet de suivre un chemin vers un exécutable à partir d'un emplacement connu (comme /usr/local/bin).

Si tout ce que vous avez à faire est de modifier le PATH pour rendre les exécutables facilement accessibles, il est aussi possible de rajouter des liens symboliques à partir de /usr/local/bin vers les exécutables à rendre disponibles. Par exemple, en supposant que je veuille rendre accessible les exécutables de /opt/scala/bin sans modifier la variable d'environnement PATH, je pourrai utiliser ceci: 

sh# (
    cd /opt/scala/bin
    find * -executable -type f -exec ln -s `pwd`/'{}' /usr/local/bin/'{}' \;
)

Scripts intermédiaires

Finalement, vous avez toujours la possibilité de remplacer chaque exécutable par un script qui initialise l'environnement avant de lancer le programme réel.

Par exemple, Apache Ant nécessite que ANT_HOME soit initialisé. Après l'avoir installé dans /usr/local/share/apache-ant, je pourrais contourner le problème d'initialisation en créant le script suivant dans /usr/local/bin: 

sh# cat > /usr/local/bin/ant << EOF
#!/bin/sh
#
# initialize environment and run ant
#
export ANT_HOME=/usr/local/share/apache-ant
$ANT_HOME/bin/ant
EOF


Comme vous le voyez, en fonction de vos besoins et de votre environnement, les solutions peuvent varier. A vous de faire votre choix...

Références

Récupérée de « http://www.chicoree.fr/w/Profile.d_et_ses_alternatives »