Vu et Entendu... - Tag - Unix

Yet anOther Desktop Manager 3D

Pierre — Thu, 22 Mar 2007 19:29:00 +0100

Une gestion des bureaux virtuels... en 3 dimensions !

Systématiquement présent dans les différents Window Manager des systèmes Unix et Linux (pour Mac OS X je ne sais pas), les bureaux virtuels sont par défaut absents des système Windows. Microsoft propose néanmoins son Virtual Desktop Manager parmi ses Power Toys, mais celui que je vous présente aujourd"hui, Yod'm 3D a la particularité d'ajouter la 3 ème dimension à votre bureau !

C'est un peu gadget, mais les effets de rotation du cube contenant vos différents bureaux vrtuels sont saisissant... Certains trouveront ça un peu gadget... mais moi j'adore !

Je vous laisse en juger par vous même en téléchargeant le logiciel sur le site de l'auteur. Rien à installer, donc pas de risque de créer de perturbations dans votre système !

Source : Le Journal du Geek

Domaines virtuels avec Postfix

Pierre — Tue, 08 Nov 2005 23:58:00 +0000

Une petite modif de la configuration de mon Postfix afin d'héberger plusieurs domaines

Suite à l'hébergement d'un nouveau domaine pour le site Web de mon petit frère Thomas pour le BDE de son école, j'ai reçu un mail destiné à webmaster@domaine.com mais qui, vu la configuration sommaire de ma messagerie.. a fini dans ma boîte aux lettres... Heureusement il n'y en a eu qu'un, mais ceci m'a conforté dans le fait qu'il fallait que je fasse quelque chose !

J'ai donc fait quelques recherches sur la toile et après avoir laissé de côté les diverses solutions à base de MySQL et autres LDAP que je trouvais un peu lourdes dans le cadre d'un serveur personnel... Je suis tombé sur le Howto qui va bien : hébergement de sites virtuels avec Postfix.

Grosso modo, la problématique est simple... J'héberge 3 domaines sur ma machine : toto.com, titi.com, tata.com et dans la configuration qui était en place, quelque soit le domaine, un mail envoyé à un utilisateur user@toto.com arrivait dans la même boîte aux lettres que user@titi.com ou user@tata.com. Mon but étant bien entendu de distinguer ces 3 adresses pour qu'un mail envoyé à ces trois adresses arrive dans trois boîtes aux lettres différentes... !

Dans un premier temps j'ai donc modifié le fichier /etc/postfix/main.cf en remplaçant la ligne

mydestination = $mydomain, $myhostname, localhost.$mydomain, $myhostname.toto.com titi.com tata.com

par

mydestination = $mydomain, $myhostname, localhost.$mydomain, $myhostname.toto.com

ou $mydomain=toto.com

j'ai ensuite créé les deux domaines virtuels titi.com et tata.com en ajoutant les lignes suivantes :

virtual_mailbox_domains = titi.com tata.com
virtual_mailbox_base = /virtual
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_minimum_uid = 100
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
virtual_alias_maps = hash:/etc/postfix/virtual

Le domaine toto.com n'est pas impacté par l'ensemble de ces manipulations.

Une fois ces lignes ajoutées, les messages à destination des domaines titi.com et tata.com seront délivrés en toute indépendance des utilisateurs Unix du serveur.

Lorsqu'un mail va arriver à destination de user@titi.com, Postfix va aller consulter ces deux maps /etc/postfix/vmailbox et /etc/postfix/virtual afin de savoir ce qu'il faut faire.

on renseigne donc ces deux fichiers :

cat /etc/postfix/vmailbox
webmaster@titi.com   titi.com/webmaster/Maildir/
admin@titi.com  titi.com/admin/Maildir/
webmaster@tata.com   tata.com/webmaster/Maildir/
admin@tata.com  tata.com/admin/Maildir/

         
cat /etc/postfix/virtual
@tata.com  user@tutu.com
mailing@titi.com user1@domain1.com, user2@domain2.com, user3@domain3.com

on crée l'arobrescence /virtual/titi.com ...

mkdir -p /virtual/titi.com/webmaster /virtual/tata.com/webmaster /virtual/titi.com/admin /virtual/tata.com/admin

puis les Maildir pour chaque utilisateur virtuel (dans le cas de Mailbox, seul /virtual/titi.com/ /virtual/tata.com/ sont à créer à priori)

maildirmake /virtual/tata.com/webmaster/Maildir/ ...

L'utilisateur Unix propriétaire de ces répertoires est alors créé

groupadd -g 5000 vmail
useradd -g vmail -u 5000 vmail -d /virtual -m

Et enfin Postfix est redémarré :

/etc/init.d/postfix restart

A la suite de ça, si tout a été fait correctement, les comportements vont être les suivants :

les mails à destination de user@toto.com seront délivrés comme ils l'étaient avant.
Les mails à destination de webmaster@titi.com, admin@titi.com, webmaster@tata.com et admin@tata.com seront déposées dans les boîtes aux lettres virtuelles correspondantes
Tous les autres mails à destination du domaine tata.com seront reroutés vers l'adresse user@tutu.com
Les mails à destination de mailing@titi.com seront reroutés vers user1@domain1.com, user2@domain2.com et user3@domain3.com
Tous les autres mails à destination de titi.com seront notifiés "User Unknown" par le système de messagerie.

En ce qui me concerne, j'ai pour l'instant laissé de côté la partie boîtes virtuelles, il faut en effet que je potasse la configuration du serveur IMAP que j'utilise : Courier-Imap. Donc pour le moment, c'est uniquement un systèe de redirections que j'utilise. Vu que la majorité des mails sont pour moi, je vais pas non plus multiplier les compte de messageries...! Par contre, c'est pratique car ça permet de multiplier les adresses mail afin de savoir d'où provient le mail et de pouvoir faire du tri et du filtrage facilement :

Par exemple, pour chaque site où je rentre mon mail, je mets le nom du site en lieu et place de ma véritable adresse, cela permet de déceler par quel intermédiaire mon adresse a pu être spammée (par exemple) ou de classer mes mails en fonction du destinataire... Et bien d'autres choses encore...

Création d'un Ramdisk sous Solaris

Pierre — Mon, 20 Dec 2004 17:10:00 +0000

Les différentes étapes nécessaires à la création d'un File System en RAM sous Solaris 9

Lors de leur fonctionnement, certaines applications, ont besoin de générer des fichiers temporaires pour le traitement de leur données. Ces fichiers temporaires sont habituellement créés dans un répertoire de travail, tel /tmp ou /var/tmp. Ces fichiers n'étant que des données temporaires, ils sont généralement supprimés après leur traitement, dans le cas contraire, il est nécessaire de mettre en place une purge régulière du répertoire de travail. Au delà d'une certaine charge, les accès au disque peuvent devenir important et auraient tendance à ralentir les performances globales du serveur, il peut alors être utile dans ce cas, et lorsque les ressources du serveur sont suffisantes en terme de mémoire, de travaille sur un système de fichiers virtuel monté en RAM, aussi appelé ramdisk.

Création d'un Ramdisk :

Le périphérique est créé à l'aide de la commande ramdiskadm (1M) à laquelle on précise le nom et la taille du device :

par exemple, pour crééer un ramdisk de 512 Mo nommé virtualdisk on lancera la commande :

ramdiskadm -a virtualdisk  512m

Il est alors nécessaire de construire un système de fichiers sur ce nouveau périphérique à l'aide de la commande newfs (1M) :

echo y | newfs /dev/rramdisk/virtualdisk

Le point de montage est créé à l'aide de la commande mkdir (1) et le système de fichiers monté avec la commande mount (1M) :

mkdir -p /ramdisk/virtualdisk
mount /dev/ramdisk/virtualdisk /ramdisk/virtualdisk

Il est alors possible d'utiliser le système de fichiers de la même manière que s'il était sur disque, à la différence près que les données écrites sur ce file system ne survivront pas à un redémarrage du serveur.

Suppression d'un Ramdisk :

La suppression d'un ramdisk créé précédemment se fait en effectuant les étapes inverses de celles effectuées lors de la création.

Le démontage du File System est effectuée à l'aide de la commande umount (1M) et le point de montage est supprimé avec la commande rmdir:

umount /ramdisk/virtualdisk
rmdir /ramdisk/virtualdisk

Le ramdisk est supprimé par la commande 'ramdiskadm (1M)'' :

ramdiskadm -d virtualdisk

Automatisation lors du démarrage du serveur.

Afin de s'affranchir de toutes opérations manuelles, la création et suppression des ramdisk ont été automatisés dans le script ramdisk. Ce script est placé dans le répertoire /etc/init.d, et des liens sont effectués dans /etc/rc2.d et/tsc/rc3.d afin que cela soit pris en compte au démarrage.

ln -s /etc/init.d/ramdisk /etc/rc3.d/S99ramdisk
ln -s /etc/init.d/ramdisk /etc/rc2.d/K01ramdisk

Ainsi les ramdisk définis dans le script de démarrage seront automatiquement créés au démarrage et supprimés lors de l'arrêt du serveur.

Synchronisation de répertoires distants

Pierre — Wed, 27 Oct 2004 13:31:00 +0000

ce billet fait suite à celui décrivant la sauvegarde système des domaines d'un SunFire 15K, et décrit la mise en place d'une synchronisation du répertoire de sauvegarde avec le deuxième SC du 15K

Description globale de la réplication

Plutôt que de sauvegarder sur bande les fichiers générés et de nécessiter une intervention manuelle, le répertoire de backup sera répliqué sur le deuxième system controller du SunFire 15K. La synchronisation des deux serveurs sera effectuée à l'aide de l'utilisatire rsync.

Dans la suite du document, on effectuera donc la synchronisation du sf15k01sc1 sur le sf15k01sc0. Le sf15k01sc0 sera donc considéré comme Maître et le sf15k01sc1 comme Esclave. En tout état de cause, toutes les modifications devront être faites sur le serveur maître (sf15k01sc0), sous peine d’être supprimées lors de la synchronisation.

Pré requis à la mise en place de cette réplication

La commande rsync doit être présente sur chacun des serveurs.
Un espace de stockage suffisant doit être créé sur chaque serveur
Les clefs ssh des utilisateurs effectuant cette réplication (root dans notre cas) doivent avoir été configurées pour permettre l'autologin.

Installation de rsync

La version de Solaris isntallée sur les SC n'inclut pas l'utilisatire rsync, par conséquent, celui ci sera installé depuis le package rsync-2.6.3-sol8-sparc-local librement téléchargeable sur le site Sunfreeware.com. A noter que le package popt-1.7-sol8-sparc-local doit également être installé.

L'installation du package se fait de façon classique :

Décompression des paquets :

gunzip /tmp/popt-1.7-sol8-sparc-local.gz
gunzip /tmp/rsync-2.6.3-sol8-sparc-local.gz

Puis installation de ceux ci à l'aide de la comande pkgadd :

pkgadd -d /tmp/popt-1.7-sol8-sparc-local
pkgadd -d /tmp/rsync-2.6.3-sol8-sparc-local

l'ensemble des données à synchroniser entre les deux SC sont situées dans le répertoire /export/install.

Configuration de l'autologin SSH

Création des clefs publiques et privés sur chaque serveur :

/usr/local/bin/ssh-keygen -t rsa

Puis copie de la clef publique dans le fichier authorized_keys du serveur distant afin de permettre l'autologin :

/usr/local/bin/ssh root@10.0.66.120 < .ssh/id_rsa.pub '[ ! -d ${HOME}/.ssh ] && mkdir -p ${HOME}/.ssh ;\ 
 cat  >> .ssh/authorized_keys'

L'opération est réalisée sur les deux SC et on vérifie que l'autologin est effectif.

Mise en place de la synchronisation

La synchronisation est effectuée depuis le (ou les serveur(s) esclave(s) à l'aide de la commande suivante :

/usr/local/bin/rsync -a --delete  --rsh="ssh -l root" root@10.0.147.212:/export/install/ /export/install/

On prendra bien soin de ne pas omettre le "/" final après chaque nom de répertoire afin de copier le contenu du répertoire, et nom le répertoire lui même, sans quoi, l'arborescence ne sera pas identique sur le serveur cible. La première exécution effectue la copie de tous les fichiers du serveur Maître vers le serveur Esclave et peut prendre un temps non négligeable. Les exécutions suivantes ne concerneront que les fichiers modifiés depuis la dernière synchronisation. Un nombre de fichiers élevé dans le répertoire conduira cependant à un temps d'exécution relativement important. Cette commande peut alors ête ajoutée à la crontab pour une exécution quotidienne.

L'option -a correspond au mode Archive et l'équivalent de l'ensemble des options : -rlptgoD L'option --delete permet la supression des fichiers qui ne sont pas présents sur le serveur maître, et nous assure d'avoir le même contenu sur l'ensemble des serveurs. L'ensemble des options existantes est décrite dans la page de man de rsync

Installation OpenSSH sur Solaris 8

Pierre — Mon, 25 Oct 2004 15:36:00 +0000

Description de l'installation d'OpenSSh Version 3.5p1 ainsi que de ses dépendances sur une plateforme Solaris 8

Prérequis à l'installation d'OpenSSH

Afin de satisfaire les dépendances requises package openssh version 3.5p1, les packages suivants devront être installés :

L'ensemble des packages ont été téléchargés sur le site SunFreeware.Com.

Selon la version des patchs du système, il peut s'avérer nécessaire d'installer le patch système 112438 (Random Patches). Cette installation est nécessaire au bon fonctionnement du serveur sshd . La dernière version de ce patch est disponible sur le site du constructeur SUN.

Description de l'installation

Eventuelle installation du patch 112438

Si le patch 112438 est installé, la commande :

showrev –p | grep 112438

doit renvoyer une sorie du type :

Patch: 112438-01 Obsoletes:  Requires:  Incompatibles:  Packages: SUNWcarx, SUNWcsr, SUNWmdb, SUNWmdbx, SUNWhea

Si c'est la cas, toute la partie concernant l'installation du patch peut être ignorée, sinon on procédera à l'installation du patch de manière classique.

L’installation du patch proprement dit se fait de manière classique :

patchadd –M /tmp 112438-01

L’installation du patch nécessite un redémarrage du serveur pour que celui ci effectue la reconstruction des ses périphériques (fichiers présents dans /dev et /devices). Cependant dans le cas d’un serveur de production, où un redémarrage ne peut pas être envisagé, il est possible d’effectuer les opérations de façon manuelle et sans perturber le service. L’opération va consister à charger le driver « Random » dans le noyau et à créer les devices correspondant.

On passe donc les commandes suivantes afin de s'assurer que le driver n'est plus présent dans le noyau :

rem_drv random

Cette première commande produira vraisemblablement une erreur, elle est uniquement là pour s’assurer que le driver n’a pas été préalablement enregistré auprès du système, et permet de s’assurer que la commande suivante enregistrera le driver correctement au niveau du système.

add_drv random

Cette commande permet d’enregistrer le driver auprès du système d’exploitation. On vérifiera le code de retour de cette dernière :

echo $?

Et on s’assurera que celui ci est égal à 0

Ensuite, afin de pouvoir créer les périphériques il est nécessaire de récupérer le major correspondant dans le fichier /etc/name_to_major.

MAJOR=$(grep -w random /etc/name_to_major | awk '{print $2}')

Les devices sont créés via la commande suivante :

mknod /devices/pseudo/@0:random c ${MAJOR} 0
mknod /devices/pseudo/@0:urandom c ${MAJOR} 1

On leur donne les bons droits (au niveau du groupe)

chgrp sys /devices/pseudo/*random*

puis on crée les liens dans /dev :

ln -s ../devices/pseudo/random@0:random /dev/random
ln –s ../devices/pseudo/random@0:urandom /dev/urandom

Le chargement du driver dans le noyau est alors effectué :

modload /kernel/drv/random

Arrêt des services et désinstallation des packages préalablement installés ( mise à jour )

Dans le cas d’une installation et non d’une mise à jour, cette étape sera omise

Les démons qui seront mis à jour doivent être arrêtés avant d’effectuer la mise à jour. Par conséquent, à partir de l’étape suivante, il est nécessaire d’effectuer une connexion sur la console, ou via le protocole telnet.

Arrêt du démond prngd :

/etc/init.d/prngd stop

Arrêt du démond sshd :

/etc/init.d/sshd stop

L’opération est effectuée à l’aide de la commande pkgrm :

pkgrm –n SMCossh
pkgrm –n SMCprngd
pkgrm –n SMCosslc

Lors de l’opération si une confirmation d’effacement est demandée, on répondra de manière affirmative (yes).

Installation des nouveau packages et démarrage des services

Décompression des paquets téléchargés :

gunzip /tmp/openssh-3.5p1-sol8-sparc-local.gz
gunzip /tmp/openssl-0.9.6g-sol8-sparc-local.gz
gunzip /tmp/libgcc-3.2-sol8-sparc-local.gz

puis installation des paquetages :

pkgadd -d /tmp/openssl-0.9.6g-sol8-sparc-local
pkgadd -d /tmp/openssh-3.5p1-sol8-sparc-local
pkgadd -d /tmp/libgcc-3.2-sol8-sparc-local

On s'assure que le scripts de démarrage sshd est bien présent dans /etc/init.d et que le lien a bien été mis en place dans /etc/rc2.d :

ln /etc/init.d/sshd /etc/rc2.dS99sshd

Ajout d'un utilisateur sshd

mkdir /var/empty
chown root:sys /var/empty
chmod 755 /var/empty
groupadd sshd
useradd -g sshd -c 'sshd privsep' -d /var/empty -s /bin/false sshd

/var/empty should not contain any files.

Génération des clefs publiques et privés du serveur :

/usr/local/bin/ssh-keygen -t rsa1 -f /usr/local/etc/ssh_host_key -N ""
/usr/local/bin/ssh-keygen -t dsa -f /usr/local/etc/ssh_host_dsa_key -N ""
/usr/local/bin/ssh-keygen -t rsa -f /usr/local/etc/ssh_host_rsa_key -N ""

Puis redémarrage du service :

/etc/init.d/sshd start

La commande "ssh -V" doit désormais renvoyer "OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f"

Sauvegarde système d'un SunFire 15K

Pierre — Mon, 25 Oct 2004 14:32:00 +0000

Description des opérations nécessaires afin de mettre en place une sauvegarde système automatique de 6 domaines d'un SunFire 15K sous Solaris 9. Le principe consiste à effectuer une sauvegarde des File System / et /usr à l'aide de la commande ufsdump. Cependant, ne disposant pas de lecteur de bandes sur les domaines, chaque File system est sauvegardé dans un fichier compressé situé sur un des System Controller (SC) du 15K. Une synchronisation des deux System Controller est alors réalisée à l'aide de la commande rsync pour permettre une redondance des données.

Sur chaque System Controller

Création des répertoires

L'arborescence suivante est créée sous la racine /export/install/exploitation :

scripts :

Exécutables communs à tous les domaines

conf :

Fichiers de configuration communs à tous les domaines

cfg/host :

Fichiers de configuration spécifiques au serveur sauvegardé, un répertoire par domaine.

backup/host :

Emplacement des sauvegardes système, propre à chaque serveur,un répertoire par domaine.

La création des répertoires est réalisée à l'aide des commandes suivantes :

 
mkdir /export/install/exploitation/scripts
mkdir /export/install/exploitation/conf

for name in "host1 host2 host3 host4 host5 host6"
do
     mkdir -p /export/install/exploitation/backups/${name}
     mkdir /export/install/exploitation/cfg/${name}
done

Configuration du serveur NFS

Le fichier contenant la liste des File System à exporter doit éventuellement modifié afin de permettre le partage des répertoires créés ci dessus. On s"assurera que la ligne suivante est présente dans le fichier /etc/dfs/dfstab :

share -F nfs -o rw,anon=0 /export/install

Le cas échéant on modifiera le fichier en conséquences, et on réexportera le réperotire si celui ci l'était déjà :

unshare /export/install

share -F nfs -o rw,anon=0 /export/install

devient :

share -F nfs -o rw,anon=0 /export/install

Puis :

unshare /export/install/
share -F nfs -o rw,anon=0 /export/install

Mise en place d'une purge automatique des fichiers

Une purge automatique des fichiers de sauvegarde est mise en place afin de supprimer les anciens fichiers de sauvegarde. On ne conservera que deux exemplaires de la sauvegarde système de chaque domaien dans les répertoires /export/install/exploitation/backups/host.

Mise en place le l'utilitaire logrotate sur les SC

Récupération du package :

Le package logrotate est récupéré sur le site Sunfreeware.com Celui-ci est alors transféré sur chaque system controller du SUnfire 15K et sera installé de la même manière sur les deux. On installera le package dans la version suivante :logrotate-3.6.9-sol8-sparc-local.gz ainsi que la dépendance suivante : popt-1.7-sol8-sparc-local.gz

Installation du package

Les packages sont transférés via FTP sur chaque Sytem Controller :

cd /tmp
gunzip logrotate-3.6.9-sol8-sparc-local.gz
pkgadd -d logrotate-3.6.9-sol8-sparc-local

gunzip popt-1.7-sol8-sparc-local.gz
pkgadd -d popt-1.7-sol8-sparc-local

Configuration de logrotate

On ajoute le fichier backups dans le répertoire /etc/logrotate.d.

Configuration de la crontab

On ajoute le scipt logrotate dans le répertoire /etc/cron.d.

La crontab est éditée et la ligne qui suit est ajoutée pour une exécution quotidienne de la rotation des fichiers à 5h00 du matin.

0 5 * * *  /etc/cron.d/logrotate

Sur Chaque Domaine Sauvegardé

Mise en place de l'automontage des répertoires

Création des répertoires :

mkdir -p /adm/exploitation/backups
mkdir -p /adm/exploitation/scripts
mkdir -p /adm/exploitation/conf
mkdir -p /adm/exploitation/cfg

Configuration de l'automonteur :

echo "/adm/exploitation    auto_adm -nobrowse" >> /etc/auto_master

echo "scripts    -ro     sf15k01sc0:/export/install/exploitation/scripts" >> /etc/auto_adm
echo "backups            sf15k01sc0:/export/install/exploitation/backups/$(hostname)" >> /etc/auto_adm
echo "conf       -ro     sf15k01sc0:/export/install/exploitation/conf" >> /etc/auto_adm
echo "cfg                sf15k01sc0:/export/install/exploitation/cfg/$(hostname)" >> /etc/auto_adm

Mise en place de la sauvegarde automatisée

La sauvegarde du système est planifiée deux fois par mois à l'aide de la crontab. L'entrée suivante est donc ajoutée dans la crontab de chaque domaine :

0 1 20,5 * * /adm/exploitation/scripts/save_syst.ksh

Script de Sauvegarde et fichiers de configuration

Trois fichiers sont nécessaire au bon fonctionnement de la sauvegarde :

/adm/exploitation/scripts/save_syst.ksh : Exécutable lancé par la crontab, global à tous les domaines.

/adm/exploitation/cfg/save_syst.cfg : Fichier de configuration propre à chaque domaine.

/adm/exploitation/conf/save_syst.lst : Liste des File system à sauvegarder

Mise en place d'un dépôt CVS

Pierre — Sun, 24 Oct 2004 17:30:00 +0000

Afin de développer mon site perso, j'ai mis en place un dépôt CVS sur le serveur, j'y accède via le réseau à travers le protocole pserver.

Installation des binaires CVS

L'installation sous debian se fait de manière triviale :

apt-get install cvs cvsutils

Création d'un utilisateur dédié

Pour des raisons de sécurité, un utilisateur dédié sera créé. Tous les fichiers et processus créés lui appartiendront.

Création du Home Directory et du répertoire de dépôt des fichiers :

mkdir -p /home/cvs/depot

Création de l'utilisateur

groupadd  cvs
useradd -g cvs -d /home/cvs/ cvs
chown -R cvs:cvs /home/cvs

Un Mot de passe est éventuellement attribué à l'utilisateur cvs si l'on souhaite effectuer une délégation de l'administration du serveur CVS.

Mise en place du dépôt

Pour la suite des opérations, on se connectera avec l'utilisateur cvs créé précédemment.

Inititalisation du dépôt

On définit la variable CVSROOT correspondant au répertoire dans lequel nous allons créer les fichiers

export CVSROOT=/home/cvs/depot

Le dépôt est alors initialisé :

cvs init

on peut alors voir qu'un répertoire CVSROOT (à ne pas confondre avec la variable $CVSROOT) a été créé sous le répertoire /home/cvs/depot. C'est dans ce répertoire qu'est présente toute la configuration du dépôt.

Configuration de l'authentification

Afin de permettre l'authentification des utilisateurs, la configuration va être légèrement modifiée. On va d'ailleurs utiliser les commandes CVS pour modifier le fichier de configuration :

cd /tmp
export CVSROOT=/home/cvs/depot
cvs checkout CVSROOT

Le fichier CVSROOT/config est édité :

la ligne

#SystemAuth=no

est décommentée pour devenir

SystemAuth=no

La modification est alors mise à jour sur le dépôt :

cvs commit

Création des utilisateurs du dépôt

Les utilisateurs du dépôt sont recensés dans un fichier '"passwd'' de la forme :

[utilisateur CVS]:[mot de passe crypté]:[utilisateur unix]

Où :

utilisateur cvs correspond au login sur le serveur cvs
mot de passe crypté est obtenu à l'aide de la commande htpasswd fournie avec Apache
utilisateur unix est en fait le propriétaire des fichiers et des processus (cvs dans notre cas)

Exemple :

On crée l'utilisateur pierre :

le mot de passe crypté est obtenu de la manière suivante :

htpasswd -n pierre
New password:
Re-type new password:
pierre:/DSunBSY9WZsY

la ligne à ajouter dans le fichier $CVSROOT/passwd est donc la suivante :

pierre:/DSunBSY9WZsY:cvs

Configuration du démon xinetd

Les manipulations qui suivent sont à effectuer avec l'utilisateur root. Les processus serveurs CVS seront lancés via le super démon xinetd lors de la connexion de l'utilisateur. Il existe d'autre type de connexions, comme via le protocole SSH (Source Dico du net) par exemple, cependant, l'accès étant actuellement limité au réseau local et fermé à l'extérieur (Internet) cela ne s'avère pas nécessaire. Cela fera néanmoins peut être l'objet d'un prochain billet.

On va ajouter le fichier cvspserver avec le contenu qui suit dans le répertoire /etc/xinetd.d

service cvspserver
{
        socket_type = stream
        protocol = tcp
        wait = no
        user = cvs
        server = /usr/bin/cvs
        server_args = -f --allow-root=/home/cvs/depot pserver
        only_from = 192.168.0.2
}

On s'assurera toutefois que la ligne

includedir /etc/xinetd.d/

est présente dans le fichier /etc/xinetd.conf et on l'y ajoutera le cas échéant.

On vérifie que le démon xinetd écoute bien sur le port d'écoute alloué à CVS (2401)

# netstat -lntp | grep 2401
tcp        0      0 0.0.0.0:2401            0.0.0.0:*               LISTEN      18361/xinetd

Opérations courantes avec CVS

Avant toute chose, il est essentiel de définir la valeur de la variable CVSROOT et de se connecter pour pouvoir travailler :

Pour une connexion via le protocole pserver, celle ci devient :

export CVSROOT=:pserver:pierre@192.168.0.1:/home/cvs/depot
cvs login
Logging in to :pserver:pierre@bretagne:2401/home/cvs/depot
CVS password:

Import d'un répertoire (ou module ) dans le dépôt :

cd /home/user/sources
cvs import -m "Premier import des Sources" Sources Pierre Version1

Téléchargement des sources :

cvs checkout module

Mise à jour des sources :

cvs update

Mise à jour de ses fichiers sur le serveur :

cvs commit

Déconnexion :

cvs logout

WinCVS

Pour une utilisation sous environnement graphique, on peut télécharger l'excellent logiciel libre WinCVS, disponible pour les environnements Win32,MacOS et Linux

Quelques liens...

cet article est une synthèse à ma façon des liens qui suivent :