Il y a quelques temps de cela j’ai ajouté un groupe secondaire à mon utilisateur avec la commande :

sudo usermod -g groupe_secondaire mon_utilisateur

Mais cela à eu pour conséquence que ce nouveau groupe est devenu le groupe principal de mon utilisateur (visible qu’après déconnexion / reconnexion)

Voici donc la commande pour rétablir le groupe d’origine :

sudo usermod -g mon_groupe_principal mon_utilisateur

mon_groupe_principal = mon_utilisateur

Cela rétabli le groupe de l’utilisateur, mais le groupe secondaire ajouté précédemment est supprimé du compte de l’utilisateur on le rajoute donc avec la bonne commande (celle qu’il aurait fallu faire dès le début) :

sudo adduser mon_utilisateur groupe_secondaire

Pour voir le nouveau groupe ajouté avec la commande groups, il faut se déconnecter/reconnecter

Rque :

J’avais initialement publié cet article le 15/12 mais il était faut car j’utilisais  la commande :

newgrp mon_groupe_principal

Or cette dernière est temporaire, dès que vous vous déconnecté vous retrouvez le précédent groupe principal

Pour rappel le serveur X, est le serveur gérant l’affichage graphique (par opposition à l’affichage console = des lignes sur fond noir) de fenêtre.

X est le nom générique, 2 projets principaux peuvent être nommé ainsi XFree86 tombé en désuétude et Xorg utilisé sur la plupart des distributions.

Par défaut xorg peut être lancé par n’importe quelle utilisateur étant loggué sur une console, mais il se peut que l’on veuille lancer X dans un script d’init par exemple ou personne n’est loggué.

Typiquement mon script d’init freevo lance la commande « freevo -fs » qui elle même se charge de lancer X, cette commande étant lancée par l’utilisateur freevo (pas admin/root), le lancement échoue avec le message suivant :

X: user not authorized to run the X server, aborting.

Pour y remédier 2 solutions :

En éditant le fchier de configuration

Editer le fichier /etc/X11/Xwrapper.conf éditer la ligne suivante pour autoriser n’importe qui (anybody) à lancer X :

allowed_users=anybody

En reconfigurant le package

sudo  dpkg-reconfigure x11-common

Dans le bel écran ncurse qui apparait :

dpkg-reconfigure x11-common

Choisir :

« N’importe qui »

Le script d’init utilise su pour lancer Freevo est ses composants sous le login de l’utilisateur que l’on souhaite.

Voici ci-dessous les pré-requis au niveau de la configuration de l’utilisateur choisi mais aussi des droits sur certains répertoires pour que cela fonctionne.

Groupes de l’utilisateur

Si vous démarrez Freevo avec l’utilisateur créé lors de l’installation d’Ubuntu, il ne devrait pas y avoir de problème, par contre si vous créez un utilisateur spécifique à Freevo nommé au hasard freevo, il faudra lui ajouter des groupes.

Pour afficher les groupes de votre utilisateur la commande est :

sudo groups nom_user

Pour ajouter un groupe à un utilisateur :

sudo adduser nom_user nom_groupe

Les groupes nécessaire au bon fonctionnement de Freevo :

• audio : pour pouvoir utiliser le son
• cdrom : pour pouvoir utiliser le lecteur de CD/DVD

Droits sur les répertoires

Pour que Freevo puisse fonctionner correctement il faut l’utilisateur laçant Freevo ait des droits sur certains réperoires.

On changera donc les droits existant sur ces répertoires et fichiers afin qu’ils appartiennent à notre utilisateur, cela se fait avec la commande :

sudo chown mon_user:mon_user /mon_repertoire -R

Les répertoires concernés sont :

/var/cache/freevo :

Ce répertoire contient tout le cache de Freevo permettant l’accélération de l’affichage des vignette de photo, des images associé au fichier mp3, etc.

Ce répertoire est créé et alimenté avec la commande :

freevo cache

A noter que la première utilisation de cette commande avec un utilisateur stadard échouera puisqu’il n’aura pas les droits de créer le répertoire freevo dans /var/cache, 2 solutions :

• faire un sudo freevo cache, puis après faire le chown comme indiqué sur le sous-répertoire freevo et tous les fichiers générés
• créer manuellement le répertoire /var:cahce/freevo, le chowner avec l’utilisateur dédié à Freevo et exécuter freevo cache avec ce même utilisateur.

/var/log/freevo :

Contient l’ensemble des fichiers de log généré par Freevo.

Comme pour le répertoire précendent la première exécution de Freevo avec un utilisateur non-root échouera pour des raisons de droits de création du sous-répertoire freevo dans /var/log/

Répertoires multimédia :

J’entend par là les répertoires où sont stockés vos fichiers multimédia auxquel Freevo doit accéder.

Pour rappel ces dossiers sont paramétrés via les variables suivantes du fichier /etc/freevo/local_conf.py :

VIDEO_ITEMS, AUDIO_ITEMS, IMAGE_ITEMS, TV_RECORD_DIR, XMLTV_FILE  

cf . http://voidandany.free.fr/index.php/parametrage-de-freevo/

Droit pour démarrer le serveur X

Editer /etc/X11/Xwrapper.conf et modifier la ligne comme suit :

allowed_users=anybody

Plus de détail ici : Démarrer le serveur X avec un utilisateur non connecté

Tout d’abord le contexte, dans le cadre de la ré-installation de sweetBox sous Jaunty, j’ai créé un utilisateur que nous appelleront « toto »  existant sous Gutsy et j’ai voulu que « toto » sous Jaunty utilise le même /home que « toto » sous Gutsy (Jaunty et Gutsy partageant déjà la même partition /home)

Donc voici les étapes de la création de « toto » sous Jaunty

sudo -s
 
mv /home/toto /home/toto-gutsy
 
adduser toto                    # répondre aux questions
 
mv /home/toto /home/toto-jaunty
 
mv /home/toto-gutsy /home/toto

Problème lorsque j’ai fait un ls -ltr de /home/toto voici ce que j’ai vu :

-rw-r--r-- 1 1002 1002 2,2K 2009-06-04 01:29 dead.letter
drwxr-xr-x 4 1002 1002 4,0K 2009-06-02 01:29 downloads
-rwxr-xr-x 1 1002 1002   36 2009-02-17 12:57 essai.sh
drwxr-xr-x 6 1002 1002 4,0K 2009-06-04 20:00 flexget
-rw------- 1 1002 1002 3,4M 2009-01-22 22:01 Maildir
...

Le user et group propriétaire n’est toto comme attendu mais 1002 qui est l’uid et gid de toto sous Gutsy.

Cela vient du fait que mon toto sous Jaunty n’a pas le même uid et gid que sous Gutsy :

id toto

Retourne :

uid=1001(toto) gid=1001(toto) groupes=1001(toto)

Il faut donc modifier cet UID et GID sous Jaunty pour les faire coller avec cceux de Gutsy (ainsi on pourra booter indiféremment sous les 2 OS et avoir un toto propriétaire de son /home)

Modifier l’UID d’un utilisateur

sudo usermod -u 1002 toto

Vérification :

id toto
uid=1002(toto) gid=1001(toto) groupes=1001(toto)

Modifier le GID d’un groupe

sudo groupmod -g 1002 toto

Vérification :

id toto
uid=1002(toto) gid=1002(toto) groupes=1002(toto)

Et voila….

Ce dernier se trouve donc sur la même partition que la racine du système (/).

Lors de l’installation de Gutsy (il ya maintenant pas mal de temps) j’avais à l’inverse placé le point de montage /home sur une partition dédiée.

L’idée est maintenant d’utiliser cette partition dédié à /home dans Gutsy (déjà le cas) et dans Jaunty, pour cela il faut donc déplacer le /home de Jaunty.

Dasn la suite on appellera :

• new_home : répertoire /home de Gutsy qui sera notre nouveau /home pour Jaunty
• old_home : répertoire /home de Jaunty créé lors de l’installation. Jaunty étant fraichement installé il ne contient  rien d’important.

Lors de l’installation de Jaunty j’ai créé un utilisateur ayant le même login qu’un de ceux présent sous Gutsy on à donc un risque d’écrasements de donnée, on procédera donc par étape ainsi :

1. renommage du répertoire mon_user sous new_home (= /home de Gutsy) en mon_user_gutsy
2. copie du répertoire mon_user de old_home (= /home de Jaunty) dans new_home
3. montage de new_home en tant que /home de Jaunty
4. reboot sous Jaunty
5. si OK renommage de mon_user en mon_user_jaunty et de mon_user_gutsy en mon_user dans new_home (permet d’utiliser le profil Gutsy sous Jaunty)
6. reboot sous Jaunty
7. si OK reboot sous Gutsy pour voir si l’utilisation du profil par Jaunty n’a pas tout cassé
8. si OK on a fini….

Les manipulations décrites sont réalisés sous Jaunty.

Copie des donnée de old_home vers new_home

Monter new_home :

sudo mkdir /mnt/new_home
sudo mount /dev/sda4 /mnt/new_home

Renommer le répertoire de l’utilisateur commun (pour éviter les risques d’écrasement):

sudo mv /mnt/new_home/mon_user /mnt/new_home/mon_user_gutsy

Copier le /home de Jaunty dans new_home :

cd /home
sudo cp -ax * /mnt/new_home/

Sauvegarde de old_home

Le contenu du /home de Jaunty vient d’être copié sur la partition contenant le /home de Gutsy, mais 2 précautions valent mieux qu’une, on le sauvegarde ailleurs.

sudo mv /home /home_jaunty

Montage de new_home

Démontage de new_home (monté précedemment) et montage de la partition en tant que /home :

sudo umount /mnt/new_home
sudo mount /dev/sda4 /home

Dès lors si on fait un ls /home on doit voir le contenu du /home de gutsy c’est à dire le répertoire du user en cours (mon_user),  le répertoire du user en cours sous gutsy (mon_suer_gutsy) et les répertoires des autres users gutsy.

Montage permanent (fstab)

Si tout est OK, on rendra ce montage permanent.

Pour cela il faut trouver UUID de la partition :

sudo blkid /dev/sda4

Noter le chiffre barbare qui s’affiche (ou mieux le copier).

Editer fstab :

sudo vim /etc/fstab

Et ajouter une ligne (à adapter) :

UUID=[UUID résultant de la commande blkid]     /home     ext3     default    0    2

Reboots et tests

Rebooter sous Jaunty et faire quelques tests (rapide puisqu’à cette étape rien n’est installé sous Jaunty !!).

Vu que tout est OK on peut essayer d’utiliser le repertoire Gutsy du user en cours.

sudo mv /home/mon_user /home/mon_user_jaunty
sudo mv /home/mon_user_gutsy /home/mon_user

Rebooter sous Jaunty et refaire quelques tests (on doit alors avoir beaucoup plus de chose sous /home/mon_user).

Rebooter sous Gutsy et vérifier que le montage de /home/mon_user sous Jaunty n’a rien cassé.

Dans mon cas tout c’est bien passé, j’ai donc récupéré l’ensemble des données de mon_user à la fois sous Jaunty et Gutsy…..

Edit :

28/06/2010 : remplacement de la commande vol_id (supprimée à partir d’Ubuntu 9.10)  par blkid pour retrouver les UUID des disques durs

Puis  j’ai essayé de créer des utilisateurs « virtuels » servant à lancer des « services »  au sens non informatique du terme (service maintenance, service mediacenter).

Le tout pour essayer de cloisonner les droits (ce que je n’ai pas encore pris le temps de faire).

Bref intialement j’avais créé un utilisateur « down » correspondant aux taches de téléchargements, puis au fur et à mesure j’ai ajouté d’autres taches à cet utilisateur et donc son nom ne représentait plus ce qu’il faisait.

J’ai donc dû le renommer, voici les étapes.

Pour les commande ci-dessous on parlera d’un utilisateur old_name que l’on renomme en new_name.

Renommage de old_name en new_name

 
Identification de l’utilisateur à modifier :

id old_name

Ce qui donne :

uid=1002(old_name) gid=1002(old_name) groupes=1002(old_name)

Changement du login de l’utilisateur et de son groupe

sudo usermod -l new_name old_name
sudo groupmod -n new_name old_name

Identification de l’utilisateur avec l’ancien nom :

id old_name

Ce qui doit donner :

id: old_name: usager inexistant.

Indiquant que l’utilisateur n’existe plus.

Si on fait de même avec le nouveau nom : 

id new_name

On aura :

uid=1002(new_name) gid=1002(new_name) groupes=1002(new_name )

Voila pour la partie renommage de l’utilisateur proprement dit, mais il y a pas mal de petites choses à faire pour que l’utilisateur récupère tout ce qu’il avait avant le renommage.

 
Ré-affectation du /home

Renommage du répertoire :

sudo mv /home/old_name /home/new_name

Affectation du nouveau répertoire à l’utilisateur :

sudo usermod -d /home/new_name new_name

Changement des droits sur les fichiers :

sudo chown new_name:new_name /home/new_name -R

Récupération des droits sudo

Pour cela on édite le fichier sudoer via l’outil visudo :

sudo visudo

 
Remplacer les occurrences de old_name par new_name, exemple :

old_name ALL=(ALL) ALL

Par

new_name ALL=(ALL) ALL

Réaffectation des taches cron

Si votre utilisateur avait des taches Cron il faut les ré-affecter sur le nouveau nom, cela se fait simplement en déplaçant les fichiers correspondants :

sudo mv /var/spool/cron/crontabs/old_name  /var/spool/cron/crontabs/new_name

Modification des données personnelles de l’utilisateur

Le login de l’utilisateur est modifié mais pas sa description et autres données qui sont renseignés lors de la création d’un utilisateur.

Nom complet :

 
sudo chfn -f "Nom complet du nouvel utilisateur"  new_name

 
Autres informations :

La commande :

chfn new_name

Repose les mêmes questions que lors de la création d’un utilisateur :

Mot de passe :
Changing the user information for svc
Enter the new value, or press ENTER for the default
        Full Name: Nom complet du nouvel utilisateur
        Room Number []:
        Work Phone []:
        Home Phone []: