Vu et Entendu... - Tag - Solaris

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.

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

774

Pierre — Wed, 13 Oct 2004 19:57:00 +0000

....ou comment sécuriser efficacement un serveur Unix !!

Ce midi, de retour de déjeuner, alors que j'étais tranquillement en train de ~~surfer sur le oueb~~ travailler, un collègue DBA^[1] débarque dans mon bureau tout affolé :

Le collègue DBA:

- Il s'est passé quoi ce matin à 11h56-11h57 sur le serveur Trucmuche ?

"Moi :"

- Ben je sais pas.. j'étais pas là ce matin (en RTT pour être plus précis !) pourquoi ?

Le collègue DBA:

- Y a deux bases Oracle qui se sont plantés à cette heure là, et aussi d'autres à vers 11h30...

"Moi :"

- Ah bon ? Et c'est quoi les symptômes ?

Le collègue DBA:

- ça s'est arrêté brusquement...

"Moi :"

-...???!!!

Et c'est là que le boulet (qui est en fait en face de moi dans mon bureau) prend la parole...

"The Boulet :"

- Oui, c'est moi j'ai fait une fausse manip en voulant changer des permissions sur un répertoire !

"Moi :"

- Heu... ??!! T'as fait quoi au juste ?

"The Boulet :"

- Ben j'ai changé les permissions de / ^[2]

"Moi :"

- .....!!!!???

"The Boulet :"

- Mais j'ai remis comme c'était après !

C'est précisément à cet instant que je suis parti prendre un café afin d'éviter tout homicide.. c'est le client quand même !

Après analyse, il s'avère que cet individu avait modifié les permissions de la racine du système de la façon suivante :

root@trucmuche:/ # chmod 774 .

root@trucmuche:/ # pwd 

/

Oups !!!

Bon, Au final rien de dramatique, il ne s'agissait heureusement pas d'un serveur de production..! Cela peut paraitre banal au premier abord, mais en fait cette opération a eu pour effet d'interdire l'accès à l'arborescence située en dessous du répertoire (donc toute l'arborescence du serveur en l'occurrence) à tous les utilisateurs n'étant pas dans le groupe root, c'est à dire l'ensemble des utilisateurs de la machine...

Voilà le bal des boulets est ouvert ! A quand le prochain ?

Notes

[1] Administrateur de bases de données

[2] / est au sommet de l'arborescence du système de fichiers sous Unix. C'est ce qu'on appelle communément la racine du système. On peut faire une analogie (très !!!) grossière avec le C:\ des systèmes Micro$oft Window$