Auteur : Bruno Philippe

Utilisez des adresses SCAN sans DNS

Utilisez des adresses SCAN sans DNS

L’installation par défaut d’une couche Grid Infrastructure nécessite un certain nombre d’adresses IP (avec résolution) pour notamment l’utilisation de la fonctionnalité SCAN. Par exemple si vous utilisez deux instances systèmes pour construire une couche Grid Infrastructure, vous devez réserver au moins neuf adresses IP différentes avec des noms associés.

Explication :

  • 1 @ IP + 1 nom pour l’instance système 1 dans le réseau dit publique
  • 1 @IP + 1 nom pour l’instance système 2 dans le réseau dit publique
  • 1 @IP + 1 nom pour l’instance système 1 dans le réseau dit privé
  • 1 @IP + 1 nom pour l’instance système 2 dans le réseau dit privé
  • 1 @IP + 1 nom pour l’instance système 1 dans le réseau dit publique (VIP)
  • 1 @IP + 1 nom pour l’instance système 2 dans le réseau dit publique (VIP)
  • 3 @IP + 1 nom dans le réseau dit publique (SCAN)

Ces couples « adresses IP + noms » sont « normalement » enregistrés dans un service DNS (ce n’est pas obligatoire pour le réseau dit privé). Vous pouvez néanmoins vous passez d’un service DNS en spécifiant l’ensemble de ces adresses IP + ces noms dans le fichier hosts de chaque instance système où vous souhaitez déployer la couche Grid Infrastructure.

Ci-dessous un exemple d’entrées d’un fichier hosts pour l’installation d’une couche Grid Infrastructure sur deux instances systèmes.

#-- Nodes --#

# Public network
192.168.10.5 rac1
192.168.10.6 rac2
# Private network
192.168.100.5 rac1-priv
192.168.100.6 rac2-priv

#-- Cluster --#

# VIP address
192.168.10.100 rac1-vip
192.168.10.101 rac2-vip
# SCAN address
192.168.10.102 oraclu01-scan
192.168.10.103 oraclu01-scan
192.168.10.104 oraclu01-scan

Essayez maintenant d’installer une couche Grid Infrastructure en utilisant uniquement une résolution local sans que les enregistrements des couples adresses IP + noms soient indiqués dans le service DNS. Le défi est lancé…

Vous obtiendrez surement ces erreurs dans vos logs d’installation de la couche Grid Infrastructure. Cela fera suite à l’exécution du CVU (Cluster Verify Utility).

INFO: -----------------------------------------------
INFO: Verification Result for Node:rac2
WARNING: Result values are not available for this verification task
INFO: Error Message:PRVG-1101 : SCAN name "oraclu01-scan" failed to resolve
INFO: Cause: An attempt to resolve specified SCAN name to a list of IP addresses failed because SCAN could not be resolved in DNS or GNS using ''nslookup''.
INFO: Action: Check whether the specified SCAN name is correct. If SCAN name should be resolved in DNS, check the configuration of SCAN name in DNS. If it should be resolved in GNS make sure that GNS resource is online.
INFO: Error Message:PRVF-4657 : Name resolution setup check for "oraclu01-scan" (IP address: 192.168.10.102) failed
INFO: Cause: Inconsistent IP address definitions found for the SCAN name identified using DNS and configured name resolution mechanism(s).
INFO: Action: Look up the SCAN name with nslookup, and make sure the returned IP addresses are consistent with those defined in NIS and /etc/hosts as configured in /etc/nsswitch.conf by reconfiguring the latter. Check the Name Service Cache Daemon (/usr/sbin/nscd) by clearing its cache and restarting it.

INFO: Error Message:PRVF-4657 : Name resolution setup check for "oraclu01-scan" (IP address: 192.168.10.103) failed
INFO: Cause: Inconsistent IP address definitions found for the SCAN name identified using DNS and configured name resolution mechanism(s).
INFO: Action: Look up the SCAN name with nslookup, and make sure the returned IP addresses are consistent with those defined in NIS and /etc/hosts as configured in /etc/nsswitch.conf by reconfiguring the latter. Check the Name Service Cache Daemon (/usr/sbin/nscd) by clearing its cache and restarting it.
INFO: Cause: Inconsistent IP address definitions found for the SCAN name identified using DNS and configured name resolution mechanism(s).
INFO: Action: Look up the SCAN name with nslookup, and make sure the returned IP addresses are consistent with those defined in NIS and /etc/hosts as configured in /etc/nsswitch.conf by reconfiguring the latter. Check the Name Service Cache Daemon (/usr/sbin/nscd) by clearing its cache and restarting it.

INFO: Error Message:PRVF-4657 : Name resolution setup check for "oraclu01-scan" (IP address: 192.168.10.104) failed
INFO: Cause: Inconsistent IP address definitions found for the SCAN name identified using DNS and configured name resolution mechanism(s).
INFO: Action: Look up the SCAN name with nslookup, and make sure the returned IP addresses are consistent with those defined in NIS and /etc/hosts as configured in /etc/nsswitch.conf by reconfiguring the latter. Check the Name Service Cache Daemon (/usr/sbin/nscd) by clearing its cache and restarting it.

Etrangement l’utilitaire CVU d’Oracle tente d’obtenir une résolution DNS pour l’enregistrement SCAN (qui lui indiqué en paramètre de l’installation via la GUI ou via un fichier réponse). Que vous ayez configuré ou non un service DNS sur les instances systèmes, les erreurs ci-dessous se produiront.

L’utilitaire CVU exécute toujours une résolution DNS du nom SCAN. Si le nom SCAN est oraclu01-scan, l’utilitaire Oracle exécute la sous-commande suivante.

# /usr/sbin/nslookup oraclu01-scan

La réponse à cet incident est d’utiliser un service DNS avec des enregistrements correctes !? Et vous auriez raison de le faire. Cependant il existe une autre solution basée sur la mise en place d’un script (en lieu et place du binaire nslookup).

Ci-dessous la méthodologie à suivre pour remplacer le binaire nslookup par un script (à faire bien entendu sur toutes les instances systèmes où la couche Grid Infrastructure sera déployée).

# mv /usr/sbin/nslookup /usr/sbin/nslookup.orig
# touch /usr/sbin/nlookup
# chmod +x /usr/sbin/nslookup

Il faut éditer ce nouveau fichier nslookup et y ajouter le contenu ci-desssous en l’adaptant notamment avec vos informations réseaux.

#!/bin/bash

LISTE=$*
HOSTNAME="${@: -1}"

if [[ $HOSTNAME = "oraclu01-scan" ]];
then
    echo "Server:          192.168.112.30"
    echo "Address:         192.168.112.30#53\n"
                        
    echo "Name:     oraclu01-scan"
    echo "Address:  192.168.112.102"
    echo "Name:     oraclu01-scan"
    echo "Address:  192.168.112.103"
    echo "Name:     oraclu01-scan"
    echo "Address:  192.168.112.104"
else
    /usr/sbin/nslookup.orig $LISTE
fi

Cette solution vous permettra ainsi d’installer une couche Grid Infrastructure sans utiliser des enregistrements DNS spécifiques pour l’ensemble des couples adresses IP + noms. Cette solution est viable dans des environnements type « tests d’infrastructure », elle ne l’est certainement pas dans des environnements avec des utilisateurs.

 

Cas pratique de l’audit dans Solaris

Cas pratique de l’audit dans Solaris

Comme évoqué lors de mon précédent article, je vais détailler un cas pratique de configuration de l’audit. Le contexte technique est le suivant : enregistrer l’ensemble des exécutions provenant des utilisateurs. Le système Solaris (11.3) héberge des Zones non  Globales.

La configuration de l’audit dans les Zones non Globales s’effectue de deux manières. Soit la stratégie est opérée par la Zone Globale : la configuration est alors identique à chaque Zone non Globale, les enregistrements d’audit sont disponibles sur la Zone non Globale. Soit la stratégie est opérée pour chaque Zone non Globale : la configuration peut être adaptée à chaque environnement, les enregistrements d’audit sont disponibles sur chacun des environnements.

Un point important à spécifier, si vous exécutez des BrandZ (Solaris 10) sur la Zone Globale, la stratégie opérée par la Zone Globale ne fonctionnera pas pour les BrandZ. Seule la configuration par Zone non Globale fonctionnera dans ce contexte.

Dans ce cas pratique, j’applique la stratégie pour chaque Zone non Globale. Il faut donc ajouter la stratégie suivante sur la Zone Globale du système.

# auditconfig -setpolicy +perzone

Sur chaque Zone non Globale de ce système, le service d’audit doit être activé.

# audit -s
# auditconfig -getcond
audit condition = auditing

Le but est d’enregistrer l’ensemble des exécutions des utilisateurs. Pour obtenir des enregistrements pertinents, il est intéressant d’ajouter la stratégie argv (cela permet d’associer les arguments d’une commande). L’ajout de cette stratégie est à positionner dans chaque Zone non Globale. Sa mise en place dans la Zone Globale peut avoir sont intérêt notamment si certaines commandes (ou connexion) s’exécutent depuis celle-ci via zlogin(1M).

# auditconfig -setpolicy +argv

La stratégie d’audit sur la Zone Globale doit être la suivante.

# auditconfig -getpolicy
configured audit policies = argv,cnt,perzone
active audit policies = argv,cnt,perzone

La stratégie d’audit par Zone non Globale doit être la suivante.

# auditconfig -getpolicy
configured audit policies = argv,cnt
active audit policies = argv,cnt

La classe d’audit gérant les exécutions se nomme ex. Elle prend en compte tous les événements execve(2M) (incluant pfexec(1M) si celui est actif sur votre système).

0x0000000080000000:ex:exec
# auditrecord -c ex

execve
  system call execve               See execve(2)
  event ID    23                   AUE_EXECVE
  class       ps,ex                (0x0000000080100000)
      header
      path
      [attribute]                  omitted on error
      [exec_arguments]             output if argv policy is set
      [exec_environment]           output if arge policy is set
      subject
      [use_of_privilege]
      return

pfexec
  system call pfexec               See execve(2) with pfexec enabled
  event ID    116                  AUE_PFEXEC
  class       ps,ex,ua,as          (0x0000000080160000)
      header
      path                         pathname of the executable
      path                         pathname of working directory
      [privilege]                  privileges if the limit or inheritable                                     set are changed
      [privilege]                  privileges if the limit or inheritable
                                   set are changed
      [process]                    process if ruid, euid, rgid or egid is
                                   changed
      exec_arguments
      [exec_environment]           output if arge policy is set
      subject
      [use_of_privilege]
      return

On associe la classe d’audit « ex » à la classe d’audit « lo » (gestion des connexions utilisateurs) aussi bien pour les événements provenants d’utilisateurs que des événements provenant du système (événements attribuables et non-attribuables).

# auditconfig -setflags lo,ex
user default audit flags = ex,lo(0x80001000,0x80001000)

# auditconfig -setnaflags lo,ex
non-attributable audit flags = ex,lo(0x80001000,0x80001000)

Les classes d’audit activées sur la Zone Globale sont les suivantes.

# auditconfig -getnaflags -getflags
active non-attributable audit flags = ex,lo(0x80001000,0x80001000)
configured non-attributable audit flags = ex,lo(0x80001000,0x80001000)
active user default audit flags = ex,lo(0x80001000,0x80001000)
configured user default audit flags = ex,lo(0x80001000,0x80001000)

Les classes d’audit activées sur chaque Zone non Globale sont les suivantes.

# auditconfig -getnaflags -getflags
active non-attributable audit flags = ex,lo(0x80001000,0x80001000)
configured non-attributable audit flags = ex,lo(0x80001000,0x80001000)
active user default audit flags = ex,lo(0x80001000,0x80001000)
configured user default audit flags = ex,lo(0x80001000,0x80001000)

Pour appliquer les modifications des classes d’audit, il est nécessaire de l’indiquer au système et d’exécuter les commandes suivantes sur chaque environnement (sur la Zone Globale et sur toutes les Zones non Globales).

# auditconfig -conf
Configured 283 kernel events.

# auditconfig -aconf
Configured non-attributable event mask.

Par défaut, l’ensemble des enregistrements sont écrits via le plugin audit_binfile(5M). Un seul fichier est généré pour l’ensemble des enregistrements. A vous de voir selon votre activité, si vous devez limiter ce fichier selon sa taille ou la périodicité. J’opte souvent pour les deux.

# auditconfig -setplugin audit_binfile p_age=1d

# auditconfig -setplugin audit_binfile p_fsize=512M

# auditconfig -getplugin audit_binfile
Plugin: audit_binfile (active)
        Attributes: p_dir=/var/audit;p_minfree=1;p_fsize=512M;p_age=1d

Cette modification est à faire sur chaque environnement (sur Zone Globale et sur toutes les Zones non Globales). Pensez tout de même à mettre en place une suppression de ces fichiers (une fois qu’ils sont sauvegardés) sinon vous risquez de saturer votre pool ZFS.

# crontab –l root | grep audit
0 5 * * * find /var/share/audit -type f -mtime +4 -exec /usr/bin/rm {} \;

Il vous est maintenant possible de suivre l’activité des utilisateurs sur le(s) système(s). Par exemple, vous pouvez diagnostiquer facilement ce genre d’événement dans votre journal d’audit.

<record version="2" event="execve(2)" host="compile" iso8601="2016-09-04 16:31:31.235 +02:00">
<path>/usr/bin/rm</path>
<attribute mode="100555" uid="root" gid="bin" fsid="65538" nodeid="49437" device="18446744073709551615"/>
<exec_args><arg>rm</arg><arg>/etc/hosts
</arg></exec_args>
<subject audit-uid="bruno" uid="bruno" gid="grpadm" ruid="bruno" rgid="grpadm" pid="1062" sid="3492816039" tid="11705 136704 gw.homeunix.org"/>
<return errval="success" retval="0"/>
</record>

Configuration de l’audit dans Solaris

Configuration de l’audit dans Solaris

L’audit consiste à collecter des données sur l’utilisation des ressources système. Ces données, enregistrées sous forme d’événements, peuvent être utilisées pour déterminer la responsabilité quand aux actions survenues sur ce système.

Il y a un double avantage à activer l’audit sur les systèmes. D’un point de vue sécuritaire, cela ajoute notamment une brique complémentaire à votre « arsenal ». D’un point de vue exploitation, cela permet d’améliorer votre diagnostic, en traçant notamment l’ensemble des actions exécutées sur vos systèmes.

Chez plusieurs clients, l’activation de l’audit m’a permis d’analyser plus efficacement des événements survenus sur des serveurs sur lesquels j’opérais des actions.

Sans être exhaustif, il est important d’évoquer les concepts suivants :

  • La stratégie d’audit détermine les caractéristiques d’enregistrement d’audit,
  • Les événements (d’audit) sont regroupés en classe d’audit,
  • Les enregistrements d’audit sont collectés dans les journaux d’audit,
  • Les classes d’audit peuvent être collecter en cas de réussite, d’échec ou les deux,
  • Les classes d’audit sont modifiables (ajout de préfix par exemple),
  • Des nouvelles classes d’audit peuvent être créées (besoin spécifique),
  • Les événements attribuables proviennent des utilisateurs,
  • Les événements non attribuables proviennent soit du noyau (interruption) soit avant l’authentification d’un utilisateur,
  • Les événements synchrones sont associés à un processus dans le système.

La configuration de l’audit peut s’avérer complexe. C’est pourquoi l’étude de la configuration par défaut permet d’appréhender plus rapidement cette fonctionnalité offerte dans le système Solaris.

Let’s go !!

L’audit est configuré via un service SMF cependant pour piloter ce service il est préférable d’utiliser la commande audit(1M). Par défaut ce service est déjà activé dans Solaris, la commande auditconfig(1M) permet de le vérifier rapidement.

# auditconfig -getcond
audit condition = auditing

Dans le cas contraire, il suffit d’activer le service via la commande audit(1M).

# audit -s

La stratégie d’audit par défaut est « minimale » : afin de minimiser les exigences en matière de stockage et de réduire le nombre de demandes de traitement du système, la plupart des options de la stratégie d’audit ont donc été désactivées. Ce qui peut être judicieux lorsque la disponibilité du système est plus importante que la sécurité (attention votre RSSI dira certainement l’inverse).

# auditconfig -getpolicy
configured audit policies = cnt
active audit policies = cnt

Selon le système installé et vos besoins, la stratégie d’audit devra vraisemblablement  être adaptée. Par exemple dans un environnement exécutant des Zones non Globales (aka containers), il est judicieux de mettre en place une stratégie d’audit permettant d’enregistrer les événements de chaque Zone non Globale. La description des stratégies d’audit est consultable via l’aide mémoire de la commande auditconfig(1M).

Tout comme la stratégie d’audit, il n’y a qu’une seule classe d’audit configurée par défaut. Celle-ci enregistre uniquement les événements liés aux connexions des utilisateurs. Aussi bien pour les événements attribuables…

# auditconfig -getflags
active user default audit flags = lo(0x1000,0x1000)
configured user default audit flags = lo(0x1000,0x1000)

…que pour les événements non attribuables.

# auditconfig -getnaflags
active non-attributable audit flags = lo(0x1000,0x1000)
configured non-attributable audit flags = lo(0x1000,0x1000)

Les programmes pouvant faire l’objet d’un enregistrement liés aux connexions des utilisateurs sont consultables via la commande auditrecord(1M).

# auditrecord -c lo

Admin Server Authentication
  program     admin (various)      See SMC, WBEM, or AdminSuite
  event ID    6213                 AUE_admin_authenticate
  class       lo                   (0x0000000000001000)
      header
      subject
      [text]                       error message
      return
[...]

Il est aussi possible de vérifier à partir d’un programme que celui-ci est bien compris dans une classe d’audit. Par exemple pour vérifier si le programme « su » est lié aux connexions des utilisateurs il suffit saisir la commande suivante et de vérifier la classe d’audit.

# auditrecord -p su

su
  program     /usr/bin/su          See su(1M)
  event ID    6229                 AUE_role_logout
  class       lo                   (0x0000000000001000)
      header
      subject
      return
[...]

Les classes d’audit disponibles par défaut sont consultables directement dans le fichier audit_class. Ci-dessous une liste non exhaustif des classes d’audit configurés sur un système Solaris (version 11.3).

0x0000000000000100:nt:network
0x0000000000000200:ip:ipc
0x0000000000001000:lo:login or logout
0x0000000000008000:cy:cryptographic
0x0000000000100000:ps:process start/stop
0x0000000080000000:ex:exec

Par défaut, les journaux d’audit sont des fichiers binaires stockés sur le serveur (3 modes sont disponibles pour stocker ces journaux d’audit : en local, en remote ou via le service syslog). La configuration des ces 3 modes s’effectuent via les 3 plugins suivants.

# auditconfig -getplugin audit_binfile
Plugin: audit_binfile (active)
        Attributes: p_age=0h;p_dir=/var/audit;p_fsize=0;p_minfree=1

# auditconfig -getplugin audit_syslog
Plugin: audit_syslog (inactive)
        Attributes: p_flags=

# auditconfig -getplugin audit_remote
Plugin: audit_remote (inactive)
        Attributes: p_hosts=;p_retries=3;p_timeout=5

L’analyse des journaux d’audit (dans le cas de fichiers binaires) s’effectue via la commande praudit(1M) qu’il est judicieux de coupler avec la commande auditreduce(1M).

Par exemple, les informations concernant l’enregistrement d’une tentative de connexion root (via le programme su) sont les suivantes.

header,69,2,su,,compile,2016-08-29 18:27:57.063 +02:00
subject,bruno,root,root,root,root,2035,548799308,12281 136704 gw.homeunix.org
return,success,0

Les informations enregistrées pour chaque événements d’audit est défini par un ensemble de jetons d’audit. Chaque classe d’audit défini un certain nombre (modifiable) de jetons d’audit. Dans l’exemple ci-dessus, il y a 3 jetons d’audit pour cet enregistrement

  • header : marque le début d’un enregistrement d’audit)
  • subject : décrit un utilisateur qui exécute ou tente d’effectuer une opération
  • return : contient l’état de retour de l’appel système et la valeur de retour du processus

Pour obtenir le descriptif de chaque élément de chaque jeton d’audit, il suffit d’utiliser la commande praudit(1M).

# praudit -x 20160828220542.not_terminated.compile
[...]
<record version="2" event="su" host="compile" iso8601="2016-08-29 18:27:57.063 +02:00">
<subject audit-uid="bruno" uid="root" gid="root" ruid="root" rgid="root" pid="2035" sid="548799308" tid="12281 136704 gw.homeunix.org"/>
<return errval="success" retval="0"/>
</record>
[...]

A travers cet article, j’espère que vous vous êtes familiarisé avec cette fonctionnalité fort intéressante disponible dans Solaris. Dans un prochain article, j’aborderai la configuration de l’audit pour un système hébergeant des Zones non Globales en utilisant des classes d’audit complémentaires.

 

 

J’ai perdu mon DNS

J’ai perdu mon DNS

Je ne vais pas vous parler d’un phénomène paranormal bien qu’au premier abord cela m’a paru assez étrange.

Lors de l’initialisation d’un cluster Oracle Rac (12c) dans des Kernel Zone Solaris (11.3), la configuration DNS mise en place (via le service smf dns/client) disparaissait étrangement. J’ai accusé à tort le processus d’initialisation d’Oracle Rac en cherchant en vain ce qui pouvait provoquer ce changement de configuration DNS. J’imagine les sourires de mes collègues d’Oracle quand j’ai posé la question sur les listes de support interne !? Je suis passé pour un fou… Quoique.

Il y a bien évidement une réponse technique à cette erreur. Solaris 11 utilise des profils de configuration réseau (Network Configuration Profil – NCP) selon deux modes : manuel ou automatique.

Le choix du mode s’effectue lors de l’installation du système Solaris. Si NCP utilise le mode automatique, le protocole DHCP est activé sur l’une des interfaces réseau du système. Les éléments de configuration suivants adresse IP, route par défaut et serveurs DNS sont alors obtenus par le service DHCP. La perte des paramètres DNS provenait donc de cette mauvaise configuration du profil NCP.

Pour vérifier votre configuration NCP, il suffit de saisir la commande suivante :

# netadm list
Comme vous pouvez le voir ci-dessous la configuration automatique est activée :
# netadm list -x Automatic
TYPE        PROFILE        STATE          AUXILIARY STATE
ncp         Automatic      online         active
ncu:phys    net0           online         interface/link is up
ncu:ip      net0           online         interface/link is up
loc         Automatic      online         active
Par défaut le mode automatique permet la configuration du service DNS :
# netcfg list loc automatic
loc:Automatic
        activation-mode                 system
        enabled                         false
        nameservices                    dns
        nameservices-config-file        "/etc/nsswitch.dns"
        dns-nameservice-configsrc       dhcp

Pourquoi ce mode automatique ? Le mode automatique a été principalement mis en œuvre pour simplifier la configuration réseau des ordinateurs portables. Ce mode ne convient absolument pas à des serveurs comme vous avez pu le lire. La modification du mode automatique en mode manuel a fixé définitivement mon erreur.

Je vous invite à lire (ou plutôt relire) l’excellent article de Andrew Walton concernant ce sujet.