Vu et Entendu... - Tag - Administration

Procuration effectuée !

Pierre — Sat, 01 Mar 2008 13:31:00 +0100

Je peux donc partir l'esprit tranquille...

Bon, inutile de vous dire que j'ai touché le sommet de l'archaïsme de l'administration française...! Paperasse et compagnie quand tu nous tiens... En plus, si ça se trouve ça servira pas... Il n'y avait déjà pas eu de deuxième tour dans cette bonne ville de Charenton le Pont lors des élections législatives ! D'un autre côté, un peu de changement ne pourra pas faire de mal ! Affaire à suivre donc ! Le principal étant de remplir son devoir civique ! En attendant... je compte les jours avant mon envol pour cette belle République d'Irlande !

Charenton Numérique !

Pierre — Sun, 29 Oct 2006 20:57:00 +0100

Et oui, la ville de Charenton le Pont, dans laquelle j'habite est au top de la technologie !

En effet, fort d'un site Internet où sont disponibles nombre de documents administratifs bien utiles, la ville de Charenton a décidé de mettre en place des bornes d'accès Wifi dans les batiments de la ville (Bibliothèque, Théatre des Deux Rives, le Conservatoire, le marché couvert,...).. et ce gratuitement ! Bien sûr un filtrage est effectué afin d'interdire les sites illégaux... ou interdits au moins de 18 ans... mais c'est tout de même une sacré bonne nouvelle...!

Le comble... c'est que c'est pas par le journal de la ville que je l'ai appris... mais en lisant les dernières actualités de 01net... !

Postfix + SASL

Pierre — Sun, 28 Aug 2005 02:28:00 +0000

Un peu de technique sur ma p'tite Debian!

En ayant marre de devoir reconfigurer mon client de messagerie a chaque fois que je transporte mon portable dans un réseau autre que le mien. En effet, comme tout serveur de messagerie bien configuré qui soit, j'ai bien évidemment interdit l'envoi de mail depuis un réseau autre que le mien afin d'éviter d'en faire un Open Relay pour les Spammeurs !

Afin de contourner ce problème il est possible d'envoyer des mails depuis l'extérieur, sous réserve d'avoir configuré Postfix afin de s'authentifier avant l'envoi du message. Pour cela, plusieurs méthodes existent.. j'ai pour ma part opté pour les librairies SASL

Installation

Ayant déjà un serveur postfix opérationnel, je n'ai eu qu''à installer les librairies et utilitaires SASL Ceci se fait de façon très simple sous debian :

apt-get install  libsasl2 libauthen-sasl-cyrus-perl sasl2-bin postfix-tls libsasl2-modules

Configuration et mise en oeuvre

La partie configuration est un peu plus complexe.. il faut veiller à bien faire les choses dans l'ordre !

Configuration du démon saslauthd

Le fichier **/etc/default/saslauthd** est renseigné de la manière suivante si l'on souhaite utiliser le fichier shadow pour l'authentification. L'ensemble des mécanismes disponibles est donné par la commande suivante :

root@liberty:~# saslauthd -v
saslauthd 2.1.19
authentication mechanisms: sasldb getpwent kerberos4 kerberos5 pam rimap shadow ldap

Le fichier /etc/default/saslauthd

# This needs to be uncommented before saslauthd will be run automatically
START=yes

# You must specify the authentication mechanisms you wish to use.
# This defaults to "pam" for PAM support, but may also include
# "shadow" or "sasldb", like this:
# MECHANISMS="pam shadow"

MECHANISMS="shadow"
PARAMS="-r -m /var/spool/postfix/var/run/saslauthd"

Le répertoire /var/spool/postfix/var/run/saslauthd est créé avec les permissions qui vont bien :

mkdir -p /var/spool/postfix/var/run/saslauthd
chown postfix:sasl /var/spool/postfix/var/run/saslauthd

Cela permettra à Postfix de se connecter au démon.

Enfin le démon est démarré :

/etc/init.d/saslauthd start

Configuration de Postfix

Deux fichiers sont à prendre en compte :

On ajoute tout d'abord les ligne qui suivent au fichier /etc/postfix/main.cf :

smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain =
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_sasl_authenticated,
   permit_mynetworks,
   reject_unauth_destination

Puis le fichier /etc/postfix/sasl/smtpd.conf

pwcheck_method: saslauthd
mech_list: plain login

La configuration est rechargée :

postfix reload

Normalement tout est bon côté serveur, il ne reste plus qu'à configurer le client de messagerie. Pour ce faire, je prendrai le cas concret de celui que j'utilise quotidiennement, à savoir le fabuleux Thunderbird. Les configuration des autres logiciels du marché ne devrait pas beaucoup différer...!

Mise en oeuvre sur le client

Dans la boîte de configuration des comptes (menu Outils/Paramètre des Comptes), il suffit de sélectionner le serveur smtp et de renseigner le nom d'utilisateur avec celui qui correspond à votre adresse (c'est fait automatiquement à la création du premier compte) Il faudra juste le modifier si cela n'est pas juste.

Lors de l'envoi du premier mail, une boîte de dialogue apparaît pour que vous saisissiez le mot de passe du compte. Si vous ne sauvegardez pas le mot de passe, celui sera à resaisir à chaque envoi de mail.

Voilà, maintenant, il ne me reste plus qu'à tester si ça marche depuis l'extérieur... Je corrigerai les erreurs si nécessaire !

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"