Archive for admin

Deux tips rsync pour la route!

Si vous ne connaissez pas rsync, je vous conseille le man et les différents tutoriels existant sur le sujet. Ici, je vais faire deux petites utilisations de rsync vous permettant d’aller un peu plus loin (sans aller au bout du monde).

1) Vous avez besoin de synchroniser un répertoire source en reproduisant l’arborescence source ou une partie de cette arborescence, alors l’option -R est faite pour vous. Exemple:
Vous souhaitez backuper /home/anchorage mais pas l’ensemble de /home/ sur /nas/backup en gardant l’arborescence source /home/anchorage…:

rsync -aR /./home/anchorage/ /nas/backup

Vous obtiendrez une sauvegarde /nas/backup/home/anchorage
Utilisation du -R (relative path) avec le “.” pour définir la racine à partir d’où on garde le chemin. Très utile et devenue pour moi indispensable!

2) L’option -b (backup) est aussi une petite merveille. Elle vous permet de backuper sur la destination les fichiers qui sont modifiés avant de les synchroniser et par conséquent de garder plusieurs versions antérieures. Reprenons l’exemple ci-dessus. Nous voulons maintenant garder l’historique de nos modifications

rsync -aRb --backup-dir=/nas/backup/inc/`date +%y-%m-%d` /./home/anchorage /nas/backup/main/

Traduction?
Nous sauvegardons maintenant /home/anchorage dans /nas/backup/main/home/anchorage et à chaque modification d’un fichier dans /nas/backup/main/home/anchorage, nous créons un répertoire /nas/backup/inc/2012-08-29/ avec les fichiers qui vont être modifiés dans le répertoire de sauvegarde principal. Il suffit alors de mettre en cron cette commande et nous gardons l’historique quotidien de tous les fichiers.
Attention, cette option ne fonctionne qu’en local!

En espérant que cela puisse vous être utile.

Posted in admin, shell | Leave a comment

Mettre à jour ses machines debian

Hello,

Je ne connaissais pas mais un moyen simple de mettre à jour l’ensemble un parc de debian est d’utiliser apt-dater! C’est très simple, il suffit d’installer apt-dater, sur la machine depuis laquelle vous souhaitez faire une mise à jour de votre parc et apt-dater-host, sur chacune des machines du parc.

Les pré-requis:
-Sur votre machine de contrôle , avoir un utilisateur (non root) qui a un accès ssh par clé sans passphrase sur chacune des machines.
-Sur vos machines à updater, avoir un utilisateur (non root) qui soit sudoer, sans passowrd au moins sur aptitude ou apt-get

Comment cela fonctionne-t-il?
Il n’y a pas de configuration à faire sur les machines à mettre à jour. Sur la machine de contrôle, il faut aller dans le fichier $HOME/.config/apt-dater/hosts.conf pour ajouter l’ensemble des machines que vous souhaitez mettre à jour (user@hostname).

Ensuite, la commande apt-dater sur la machine de contrôle et hop, c’est parti!

Merci à Korben pour l’info

Posted in admin, open-source | Leave a comment

Un module puppet d’installation pour paquet debian avec preseeding

J’installais jusqu’à aujourd’hui des paquets debian avec puppet à condition que ceux-ci n’aient pas de configuration interactive lors de l’installation. Cela limitait sérieusement le nombre de paquets que j’étais en mesure d’installer par l’intermédaire de puppet. Impossible par exemple d’installer un serveur mysql, ou samba, pour qui il est nécessaire de répondre à des questions. La solution est relativement simple, puisqu’elle consiste à utiliser le concept de preseeding de debian dans puppet.
Si vous ne connaissez pas le preseeding, explication rapide, c’est relativement simple: l’outil debconf-set-selections du paquet debconf-utils permet de charger les réponses aux questions avec l’installation depuis un fichier plat:

debconf-set-selections < mysql-server.preseed
apt-get install mysql-server

Le format est relativement simple, et une recherche google vous permet de retrouver pour de nombreux paquets la meilleur configuration.

J’ai par conséquent écrit la classe suivante permettant de réaliser les deux opérations ci-dessous dans puppet:

class install {
        # je crée une classe me permettant d'installer des paquets.
        file { "/etc/apt/sources.list":
                # le fichier sources.list utile pour pointer sur les repo. Attention, il est nécessaire dans mon exemple de pointer sur le repo backport de lenny
                mode => "644",
                owner => root,
                group => root,
                source => "puppet://$fileserver/$environment/etc/apt/sources.list"
        }
        define pkginstall ($pkgname,$preseed='no')
        # la fonction pkginstall est en charge de l'installation, avec pour parametre, le nom du paquet et le preseeding oui ou non. Par défaut, c'est non.
        {
                case $preseed {
                        yes: {
                                #si c'est oui, on appelle la fonction preseed_package
                                preseed_package { "$pkgname": }
                               # et on installe en prenant par défaut le paquet de backport
                                exec { "install_$pkgname":
                                        command => "apt-get update && sudo apt-get -t lenny-backports -y install $pkgname",
                                        path => "/bin:/usr/bin/:/usr/sbin",
                                        timeout => "-1",
                                        require => Exec["debconf-set-selections_$pkgname"]
                                }
                        }
                        no: {
                                # si c'est non, c'est de l'install simple de backport
                                exec { "install_$pkgname":
                                        command => "apt-get update && sudo apt-get -t lenny-backports -y install $pkgname",
                                        path => "/bin:/usr/bin/:/usr/sbin",
                                        timeout => "120",
                                }
                        }

                }

        }
        define preseed_package () {
                file { "/var/local/preseed":
                        ensure => directory,
                }
                file { "/var/local/preseed/$name.preseed":
                        # le fichier de preseeding est installé dans /var/local/preseed/ avec comme format nomdepaquet.preseed, mysql-server.preseed, par exemple.
                        source => "puppet://$fileserver/$environment/var/local/preseed/$name.preseed",
                        mode => "644",
                        owner => root,
                        group => root,
                }
                exec { "debconf-set-selections_$name" :
                        # le fichier de preseed est utilisé avec debconf-set-selections, la commande issue du paquet debconf-utils permettant de charger le preseed.
                        command => "debconf-set-selections < /var/local/preseed/$name.preseed",                         require => [Exec["install_debconf-utils"],File["/var/local/preseed/$name.preseed"]],
                        path => "/bin:/usr/bin/:/usr/sbin",
                }
        }
}

Comment l’utiliser maintenant?
Sur mes machines, en général, j’installe les deux premiers paquets rsync et debconf-utils, ce qui me donne, à titre d’exemple, une classe d’install de base:

class baseinstall {
        install::pkginstall {
                "rsync":
                        pkgname => "rsync";
                "debconf-utils":
                        pkgname => "debconf-utils";
        }
}

Ensuite, prenons l’exemple d’un serveur http sous apache et mysql-server. Vous pourrez noter que la plupart des packages sont installés sans preseeding, excepté mysql-server.

class http {
        install::pkginstall {
                "apache2":
                pkgname => "apache2";
                 "mysql-server":
                pkgname => "mysql-server",
                preseed => "yes";
                "php5":
                pkgname => "php5";
                "php-pear":
                pkgname => "php-pear";
                "php5-cli":
                pkgname => "php5-cli";
                "php5-gd":
                pkgname => "php5-gd";
                "php5-mysql":
                pkgname => "php5-mysql";
                "php5-mcrypt":
                pkgname => "php5-mcrypt";
                "memcached":
                pkgname => "memcached";
                "php5-memcache":
                pkgname => "php5-memcache";
}

Le fichier /var/local/preseed/mysql-server.preseed sera placé dans votre serveur de fichier de l’environnement puppet utilisé.

mysql-server mysql-server/root_password select
mysql-server-5.1        mysql-server/root_password_again        password PASS
mysql-server-5.1        mysql-server/root_password      password PASS
mysql-server-5.1        mysql-server/error_setting_password     error
mysql-server mysql-server/root_password select PASS
mysql-server mysql-server/root_password_again select PASS
mysql-server-5.1        mysql-server-5.1/start_on_boot  boolean true
mysql-server-5.1        mysql-server-5.1/postrm_remove_databases        booleanfalse
mysql-server-5.1        mysql-server-5.1/nis_warning    note
mysql-server-5.1        mysql-server-5.1/really_downgrade       boolean false
mysql-server-5.1        mysql-server/password_mismatch  error
mysql-server-5.1        mysql-server/no_upgrade_when_using_ndb  error

En espérant que cela vous aidera.

Ciao

Posted in admin, mysql | 2 Comments

Migration à chaud de vm avec libvirt et kvm (3/3)

Dans mon article précédent, la migration à chaud de vm en utilisant libvirt et kvm n’avait pas fonctionné. Pour être plus précis, ma vm migrait bien d’un host à l’autre, était pingable mais se retrouvait avec un système de fichier en lecture seule. Regretable! Pourquoi? Simplement parce que le transfert du contexte durant la migration se fait par ssh en root (je n’ai pas encore trouvé le moyen de changer cela). Le fichier est exécuté par kvm qui tourne sous le user libvirt-qemu avec les droits 755 et n’a donc pas accès en écriture à la vm après la migration.
Mais pourquoi cela fonctionne-t-il quand je redémarre la vm par la fonction :

virsh create toto.xml

Cette fonction change les owners et groups du fichier de disk de vm, ce que ne fait pas la fonction migrate.

La solution est donc d’ajouter le user libvirt-qemu au groupe root et de mettre les droits 775 au fichier de disks de vm.

En conclusion, une restriction d’utilisation est identifiée: la nécessité d’ouvrir le ssh à root. Ce qui n’est pas une bonne pratique. Il faut au moins supprimer la connexion par mot de passe et la remplacer par une connexion par clé.

Posted in admin, virtualization | Leave a comment

Migration à chaud de vm avec libvirt et kvm (1/3)

Bonjour,

L’objectif de cet article est de vous relater mes expériences de migration à chaud de VM (machines virtuelles) entre deux serveurs KVM utilisant libvirt-bin.
En préambule, j’ai eu quelques soucis de mise à jour de version de libvirt-bin. Ce sera le sujet de la première partie.

Pour information, j’utilise deux serveurs HP Proliant G5 qui sont au début de mes expérimentations en debian lenny, 2.6.26-amd64 pour le kernel et en version 0.4.6 pour libvirt-bin.

Stockage centralisé des VMs
Dans l’état actuel des choses, mes VMs sont stockées dans l’arborescence locale de chacune des machines. Ceci ne rend pas la migration d’une machine à l’autre possible. Pour ce faire, il faut être équipé d’un stockage centralisé, de type SAN ou NFS. NFS est la méthode la plus économique et la plus facile à mettre en oeuvre. Dans l’idéal, pour avoir un intérêt en production, j’aurais besoin d’une autre machine pour faire serveur nfs. Ce n’est pas le cas, je configure donc ma première machine en serveur NFS. J’exporte le répertoire où je stocke les disques et le répertoire où je stocke les fichiers xml de description des vms utilisé par libvirt. Par défaut, celui-ci est en /etc/libvirt/qemu.

Mon fichier /etc/exports de la machine nfs server:

/home/stephbul/vms/disks monlan/255.255.255.0(rw,no_subtree_check,no_root_squash)
/home/stephbul/vms/vms monlan/255.255.255.0(rw,no_subtree_check,no_root_squash)

nfs1 est le serveur nfs1 et monlan est mon réseau local, comme défini dans /etc/networks. Je restreins l’accès à ce nfs au seul réseau monlan.

Mes fichiers /etc/fstab de mes deux machines:

nfs1:/home/stephbul/vms/disks /sbufarm/disks nfs rw,rsize=4096,wsize=4096,hard,async 0 0
nfs1:/home/stephbul/vms/vms /sbufarm/vms nfs rw,rsize=4096,wsize=4096,hard,async 0 0

Attention, à ne pas oublier de changer les chemins d’accès dans vos fichiers xml de description de vos VMs.

Il est maintenant temps de faire les premiers essais. Malheureusement, je note vite que la fonction de migration n’est disponible dans l’hyperviseur qu’à partir de la version 0.5.0. Etant en 0.4.6, il est nécessaire de faire une mise à jour de libvirt. Ne souhaitant pas me lancer, à l’origine dans un upgrade depuis lenny vers squeeze de mes deux HP Proliant G5 utilisé pour différents services, j’ai décidé de tenter le package pinning, fonction bien pratique de debian pour utiliser la version de debian squeeze pour libvirt-bin qui est la 0.8.1.
Malheureusement les dépendances de libvirt ont nécessité un upgrade de udev. Et celui-ci m’a fait tombé sur le problème connu chez debian (bug #566000).

Preparing to replace libudev0 149-1 (using .../libudev0_150-2_i386.deb)
....
Unpacking replacement libudev0 ...
Preparing to replace udev 149-1 (using .../archives/udev_150-2_i386.deb)
....
Since release 150, udev requires that support for the CONFIG_SYSFS_DEPRECATED feature is disabled in the running kernel.

Please upgrade your kernel before or while upgrading udev.

AT YOUR OWN RISK, you can force the installation of this version of udev
WHICH DOES NOT WORK WITH YOUR RUNNING KERNEL AND WILL BREAK YOUR SYSTEM
AT THE NEXT REBOOT by creating the /etc/udev/kernel-upgrade file.
There is always a safer way to upgrade, do not try this unless you
understand what you are doing!


Il semble nécessaire d’installer un nouveau kernel, mais l’installation n’est alors plus possible du fait de la dépendance cassée…
Bon, comment m’en suis-je sorti?


$ apt-get update
# Désinstallation de libvirt-bin
$ apt-get remove libvirt-bin
$ apt-get autoremove
# Désinstallation de tous les kernels
$ apt-get remove linux-image-2.6....
# Installation du dernier kernel par son méta-package
$ aptitude install linux-image-2.6-amd64
$ reboot
$ aptitude full-upgrade
$ reboot

Cela correspond à ce que je ne voulais pas faire (un upgrade vers squeeze), mais c’était devenu nécessaire.
Ensuite, je réinstalle libvirt-bin

$ apt-get install libvirt-bin

Ce qui me donne

$ virsh --version
0.8.1

Je peux enfin commencer mes tests. Ce que vous trouverez dans un le post suivant.

Posted in admin, virtualization | Leave a comment

Migration à chaud de vm avec libvirt et kvm (2/3)

Vous avez pu lire dans l‘article précédent la préparation des tests de migration. Passons aux choses sérieuses maintenant.

Comment effectuer une migration à chaud?
La commande est assez simple :

virsh migrate --live domain destinationURI

où l’URL est définie comme cela:

qemu://host/system # pour kvm
xen://host # pour xen

Par défaut, si on ne le précise, le transport d’une machine à l’autre se fait par TLS. J’utilise ssh, donc l’URI devient:

qemu+ssh://host/system

Je me lance.
Alors, sur ma machine at-at-3:

at-at-3:/sbufarm/vms# virsh list
Id Name State
----------------------------------
1 diodore running

Sur ma machine destination at-at-1:

at-at-1:/sbufarm/vms# virsh list
Id Name State
----------------------------------

Je tente un ping sur la machine

ping -i 0.2 diodore
PING 10.165.144.66 (10.165.144.66) 56(84) bytes of data.
64 bytes from 10.165.144.66: icmp_seq=1 ttl=63 time=0.357 ms
64 bytes from 10.165.144.66: icmp_seq=2 ttl=63 time=0.395 ms
64 bytes from 10.165.144.66: icmp_seq=3 ttl=63 time=0.358 ms
64 bytes from 10.165.144.66: icmp_seq=4 ttl=63 time=0.372 ms
64 bytes from 10.165.144.66: icmp_seq=5 ttl=63 time=0.351 ms
64 bytes from 10.165.144.66: icmp_seq=6 ttl=63 time=0.374 ms

que je laisse tourner.

Et eventually (tu parles, à mon avis, ce n’est que le début)

virsh migrate --live diodore qemu+ssh://at-at-1/system

Je surveille le ping

64 bytes from 10.165.144.66: icmp_seq=632 ttl=63 time=198 ms
64 bytes from 10.165.144.66: icmp_seq=633 ttl=63 time=199 ms
64 bytes from 10.165.144.66: icmp_seq=634 ttl=63 time=200 ms
64 bytes from 10.165.144.66: icmp_seq=635 ttl=63 time=200 ms
64 bytes from 10.165.144.66: icmp_seq=636 ttl=63 time=197 ms
64 bytes from 10.165.144.66: icmp_seq=637 ttl=63 time=198 ms
64 bytes from 10.165.144.66: icmp_seq=638 ttl=63 time=198 ms
64 bytes from 10.165.144.66: icmp_seq=639 ttl=63 time=200 ms
64 bytes from 10.165.144.66: icmp_seq=640 ttl=63 time=200 ms
64 bytes from 10.165.144.66: icmp_seq=641 ttl=63 time=197 ms
64 bytes from 10.165.144.66: icmp_seq=648 ttl=63 time=2.24 ms
64 bytes from 10.165.144.66: icmp_seq=649 ttl=63 time=0.399 ms
64 bytes from 10.165.144.66: icmp_seq=650 ttl=63 time=1.54 ms
64 bytes from 10.165.144.66: icmp_seq=651 ttl=63 time=0.388 ms
64 bytes from 10.165.144.66: icmp_seq=652 ttl=63 time=0.378 ms
64 bytes from 10.165.144.66: icmp_seq=653 ttl=63 time=3.29 ms
64 bytes from 10.165.144.66: icmp_seq=654 ttl=63 time=3.30 ms
64 bytes from 10.165.144.66: icmp_seq=655 ttl=63 time=1.85 ms

et voilà, c’est fait. On voit ici que le temps de réponse du ping augmente sensiblement, puis s’arrête une ou dexu secondes pour redémarrer sur l’autre machine.
Sur la machine de destination, on obtient:

at-at-1:/sbufarm/vms# virsh list
Id Name State
----------------------------------
1 diodore running

Sur ma machine source at-at-3:

at-at-3:/sbufarm/vms# virsh list
Id Name State
----------------------------------

ouaouh! ET BIEN NON, aucune satisfaction, puisque la machine ping, mais les accès aux disques ne fonctionnent pas.
La console indique les erreurs suivantes:

hda: task_pio_intr: status 0x41 {DriveReady Error}
hda: task_pio_intr: status 0x04 {DriveStatus Error}
hda: possibly failed opcode 0x39

La destruction de la vm et sa recréation (à partir du même fichier de disk) fonctionne parfaitement.

Voici aujourd’hui, l’état de mes investigations. Si quelqu’un a une idée, elle est bien venue!

Posted in admin, virtualization | Leave a comment

Administration de mon serveur Samba (2/2)

Suite et fin de mes aventures avec Samba.

Une fois l’identification des users faite sur mysql, il me reste à mettre à jour la base de mots de passe de samba. Je rappelle que lors d’une mise à jour du mot de passe unix (voir mes posts précédents), le mot de passe samba n’est mis à jour que quand l’utilisateur se logge. Ce qui ne correspond pas à mon application, mes utilisateurs ne se loggent pas.

Par conséquent, il est nécessaire de faire la mise à jour de la base de mots de passe samba par un autre moyen. J’ai décidé, à regret, de faire un cron sur la liste (pas longue) de mes utilisateurs. Voici mon scripts et les explications associées:
-Le script prend en paramètre un fichier de connexion à la base mysql où sont stockés les users. Ce fichier est sensible, il faut par conséquent restreindre les droits à root seulement.
-Le format de ce fichier est le suivant:

USER=monuser
PASS=sonmotdepass
USERDB=systemdb
UTABLE=usertable

-Le principe de ce script est de passer la commande smbpasswd pour tous les utilisateurs listés dans la base mysql. Cette commande met à jour les mots de passe de la base samba. J’utilise l’option -s qui permet de passer le mot de passe et sa confirmation par stdin.
Je passe la commande comme ceci:

(echo motdepasse; echo motdepasse) | smbpasswd -s -a leuser

Pour la périodicité du cron associé, il ne vous reste qu’à choisir sa fréquence et d’avertir les utilisateurs du service.
Si vous avez mieux…

Posted in admin, samba | Leave a comment

Petit tip samba avec libpam-smbpass

Dans la suite de mon post sur libpam-smbpass, je note qu’il est important d’utiliser le backend samba tdbsam, et par conséquent, d’avoir l’option dans /etc/samba/smb.conf.

passdb backend = tdbsam

Pourquoi? Parce si ce n’est pas le cas, vous utilisez le back-end avec fichier smbpasswd, qui ne gère pas bien l’effacement des users en base. Je rappelle que libpam-smbpass permet de synchroniser les users unix et samba. Par conséquent, si vous effacez un compte unix, vous espérez qu’il soit aussi effacé en base samba. Avec smbpasswd, ce n’est pas le cas, il faut le supprimer ensuite soi-même et, c’est là que la mini-catastrophe se produit:

smbpasswd -x monuser

vous dit que monuser n’est pas un user unix et que la base est corrumpue. Il faut alors recréer le compte unix, passer la commande smbpasswd -x mon user et effacer le compte unix à nouveau.
Avec tdbsam, à la suppression du user unix, la suppression du user samba est effective.

Posted in admin, samba | Leave a comment

Administration de mon serveur Samba (Etape 1/2)

A titre de rappel, j’ai une série de bases mysql qui stockent les utilisateurs de certaines applications, ces bases sont synchronisées par des triggers mysql. Je cherche depuis hier à mettre en place un serveur samba dont les users seraient provisionnés à partir de la base mysql centrale de mon système. Mes utilisateurs ne se loggent pas sur la machine en tant qu’utilisateurs unix, mais comme requis par samba, il doivent être vus comme des utisateurs unix. J’ai donc décidé, après de longues recherches sur google, dans les codes de certaines applications, d’aller au plus simple:

-Mes utilisateurs unix seront des utilisateurs virtuels, je vais utiliser libnss-mysql pour les gérer, ce qui me permettra de les synchroniser facilement avec mes triggers mysql. (Etape 1)

-Mes utilisateurs samba (les mêmes en fait) seront gérés par le backend tbdsam, backend par défaut de samba. Il me faudra une passerelle de ma base mysql vers ma base samba. Je ne suis pas encore fixé sur ce fonctionnement, mais je vois mal comment je vais pouvoir éviter le polling sur un changement de champs mysql par un cron.(Etape 2)

Etape 1: gestion des comptes unix par mysql

On trouve de nombreux posts d’autres bloggers sur ce sujet, et j’ai dû prendre un peu partout pour faire fonctionner le tout sur mon serveur debian, en lenny.

Voici ma démarche:

  • Installation de libnss-mysql et de libpam-mysql
apt-get install libnss-mysql libpam-mysql

Et non libnss-mysql-bg. Il y a confusion dans debian sur le package.

  •  Configuration de /etc/nsswitch.conf

Par défaut, nss est configuré pour utiliser /etc/passwd et /etc/shadow pour faire l’authentification et l’autorisation. Le principe dans notre cas consiste non pas à remplacer cela par mysql, mais à compléter la possibilité d’utiliser mysql. Ce qui signifiera qu’on pourra utiliser les deux, d’abord, le mode fichier, par exemple pour les comptes systèmes, puis mysql pour les autres. Pour se faire, il faut avoir un fichier /etc/nsswitch.conf comme celui-ci:

passwd:         compat mysql

group:          compat mysql

shadow:         compat mysql

hosts:          files dns

networks:       files

protocols:      db files

services:       db files

ethers:         db files

rpc:            db files

netgroup:       nis

Dans certains cas, le “compat”, décrivant le mode d’utilisation par fichier peut être remplacé par “files”.

  • configuration de /etc/nss-mysql.conf et de /etc/nns-mysql-root.conf

La conf de libnss-mysql se fait pas ces deux fichiers, le premier pour les comptes et le deuxième pour shadow. On décrit simplement le moyen d’accéder à la base mysql qu’on va utiliser (host, dbname, user, password, table et correspondance de champs). Les deux sont basés sur le même principe. La syntaxe est assez explicite et bien expliquée dans les commentaires (au moins pour debian).

Attention,  /etc/nss-mysql-root.conf ne doit être lisible que par root, donc

chmod 400 /etc/nss-mysql-root.conf
  • configuration de pam

On ne touche qu’aux fichiers communs aux services d’autorisation (common-auth, common-password, common-session, common-account). De la même façon qu’on a configuré nss, on va configurer les moyens d’accès par pam en fonction du besoin

/etc/pam.d/common-auth :

account    sufficient        pam_unix.so nullok_secure

account    required        pam_mysql.so user=monuser passwd=xxxxxxx host=localhost db=nss_mysql table=user usercolumn=user.user_name

/etc/pam.d/common-passwd :

password   sufficient   pam_unix.so nullok obscure min=5 max=12 md5

password    required      pam_mysql.so nullok user=root passwd=bullit host=localhost db=nss_mysql table=user usercolumn=user.user_name passwdcolumn=user.password crypt=1

Le crypt = 1, signifie que le mot de passe sera encrypté dans le base mysql. Pour qu’il soit en clair (à éviter, bien entendu), c’est crypt=0. Pour débugger, c’est plus pratique.

/etc/pam.d/comm-account

auth    sufficient        pam_unix.so nullok_secure

auth    required        pam_mysql.so user=root passwd=bullit host=localhost db=nss_mysql table=user usercolumn=user.user_name passwdcolumn=user.password crypt=1

Et le dernier
/etc/pam.d/common-session :

session    sufficient        pam_unix.so nullok_secure

session    required        pam_mysql.so user=root passwd=bullit host=localhost db=nss_mysql table=user usercolumn=user.user_name
  • Il est maintenant temps de créer la base mysql.
create database nss_mysql;

USE nss_mysql;DROP TABLE IF EXISTS groups;

CREATE TABLE groups (

group_id int(11) NOT NULL auto_increment primary key,

group_name varchar(30) DEFAULT '' NOT NULL,

status        char(1) DEFAULT 'A',

group_password varchar(64) DEFAULT 'x' NOT NULL,

gid int(11) NOT NULL

);

DROP TABLE IF EXISTS user;

CREATE TABLE user (

user_id int(11) NOT NULL auto_increment primary key,

user_name varchar(50) DEFAULT '' NOT NULL,

realname varchar(32) DEFAULT '' NOT NULL,

shell varchar(20) DEFAULT '/bin/sh' NOT NULL,

password varchar(40) DEFAULT '' NOT NULL,

status char(1) DEFAULT 'N' NOT NULL,

uid int(11) NOT NULL,

gid int(11) DEFAULT '65534' NOT NULL,

homedir varchar(32) DEFAULT '/tmp' NOT NULL,

lastchange varchar(50) NOT NULL default '',

min int(11) NOT NULL default '0',

max int(11) NOT NULL default '0',

warn int(11) NOT NULL default '7',

inact int(11) NOT NULL default '-1',

expire int(11) NOT NULL default '-1'

);

DROP TABLE IF EXISTS user_group;

CREATE TABLE user_group (

  user_id int(11) DEFAULT '0' NOT NULL,

  group_id int(11) DEFAULT '0' NOT NULL

);

Attention, le mot de passe doit être crypté (rappelez-vous le crypt=1), donc pour importer les utilisateurs, il est nécessaire d’utiliser la fontion interne à mysql encrypt().

  • Il est maintenant temps de provisionner ses users pour faire des premiers tests.

Les outils pour débugger ont été les suivants:

-Activation des logs mysql pour tracer les requêtes. Ne pas oublier de les désactiver car les performances de mysql sont très impactées par l’activation des logs.

-/var/log/auth.log où les erreurs de libnss-mysql m’ont permis de naviguer à plusieurs reprises dans le fichier shadow.c de celle-ci.

  • Dernier point, après les tests, je change le shell par défaut de mes users en /bin/false, car je rappelle que ce sont des utilisateurs virtuels qui ne se loggeront pas.

A bientôt pour l’étape 2.

PS:
Mes références pour ce sujet (et je les en remercie)
-http://www.spencerstirling.com/computergeek/mysqluser.html

-http://www.cavecanen.org/linux/nssmysql.php

-http://wiki.druidesmetal.org/doku.php?id=pam-mysql (Que j’ai trouvé bien trop tard, malheureusement…)

Posted in admin, mysql, samba | Leave a comment

En recherche d’une solution d’administration décente pour un serveur samba

Dans la suite de mon article précédent, je suis confronté à un problème d’administration d’un serveur samba que je vous présente ici.

J’utilise plusieurs bases mysql qui gèrent des comptes utilisateurs de différentes applications. Les utilisateurs étant communs aux différents projets, j’utilise donc des triggers mysql pour modifier les comptes de l’une à l’autre des bases. A l’ensemble de ce projet, je cherche à installer un serveur samba pour lequel, dans le même esprit, je veux pouvoir provisionner les utilisateurs samba depuis la base mysql de mon application centrale.

Il y a bien longtemps que le monde du libre ne m’offre pas de solutions servies sur un plateau, mais là, je dois reconnaître que je tourne un peu en rond:

-Samba a supprimé son backend mysql, en raison du manque de mainteneur. Cela m’aurait permis de synchroniser les bases de la même façon.

-La synchronisation des comptes unix (que je pourrais gérer en mysql) et samba, comme expliquée dans mon post précédent, n’est pas satisfaisante pour être “industrialisée”, puisqu’elle nécessite que l’utilisateur se logge après avoir changé son mot de passe unix pour qu’il soit pris en compte dans la base smb.

A moins que google ait gardé un secret, je n’ai pas l’impression de pouvoir trouver une solution intéressante, qui ne soit pas un bricolage immonde et j’en arrive à la conclusion que samba, malgré le large spectre de fonctionnalités et de paramétrage, n’est pas un outil particulièrement bien adapté à un univers de production administré en souplesse.

Si quelqu’un lit ces lignes et a une solution, je suis preneur…

Posted in admin, mysql, samba | 3 Comments

Swedish Greys - a WordPress theme from Nordic Themepark.