Archive for mysql

Replication facile de base mysql master/slave

Comment effectuer simplement une replication mysql master slave? Quelques règles vont vous permettre d’atteindre l’objectif visé.

Dans la configuration des deux serveurs, tout d’abord, il faut avoir les mêmes fichiers de configuration my.cnf, à une différence près: dans la section mysqld, il faut un champs server_id, qui soit un entier, différents sur le master et le slave. Si vous avez plusieurs slave, ce champs doit aussi être différent d’un slave à l’autre.
Il faut aussi avoir activer les logs binaires afin de rejouer les opérations faites sur le master sur le slave
Par exemple, sur le master:

[mysqld]
log-bin=mysql-bin
server_id=1

Et sur le slave:

[mysqld]
log-bin=mysql-bin
server_id=2

Attention, il faut bien entendu que les process mysql écoutent sur le réseau ce qui n’est pas le cas par défaut…

On démarre les deux process mysql. Sur debian, par exemple:

/etc/init.d/mysql start

Si ce sont de nouvelles machines, avec une ancienne base, on importe le dump de la base. Attention, il faut avoir fait le dump de la base uniquement à répliquer, pas le dump de toutes les bases, car sinon au moment de l’import, vous allez écraser votre base mysql, ce qui pourrait être fâcheux.

La commande est la suivante, à passer sur le master et le slave.

mysql -uadmin -p < dump.sql

Dans le master, au moins, il faut créer un utilisateur qui va avoir le droit de se connecter, avec les droits de réplication, et les droits de réplication uniquement:

mysql> CREATE USER 'repluser'@'slave.example.com' IDENTIFIED BY 'replpassword';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repluser'@'slave.example.com';

où slave.example.com est le hostname (fqdn) du slave.
Je conseille de faire l'opération symétrique dans le slave afin de pouvoir inverser les rôles plus aisément.

Afin de synchroniser les opérations en master et slave, il faut interrompre les opérations d'écriture quelques instants sur le master, afin de connaître la position du master dans les logs binaires:

mysql> FLUSH TABLES WITH READ LOCK;

Puis on passe la commande qui indique cette position:

mysql> SHOW MASTER STATUS;

Cette commande donne un fichier de log en cours et une position. Noter ce résultat à garder précieusement. Attention à ne pas sortir de la session mysql, pour ne pas lever le lock tant que la réplication n'est pas en service côté slave

Démarrons la réplication sur le slave...
Il faut d'abord s'assurer qu'elle n'est pas déjà en cours:

mysql> STOP SLAVE;

Et configurons la replication avec les informations serveurs (user défini plus haut, fichiers de log en cours, et position) et la commande "CHANGE MASTER":

mysql> CHANGE MASTER TO MASTER_HOST='master.example.com', MASTER_USER='repluser', MASTER_PASSWORD='replpassword', MASTER_PORT=3306, MASTER_LOG_FILE="mysql-bin.000001", MASTER_LOG_POS=106;
mysql> START SLAVE;

où master_log_file et master_log_pos sont les résultats de la commande show master status.

La réplication est maintenant en oeuvre.
Sur le master, vous pouvez sortir de votre session mysql, ou passer la commande:

mysql> unlock tables;

N'oubliez pas de faire des tests d'insertion et de suppresion de donnée pour vérifier que cela fonctionne.

Posted in mysql, open-source | 2 Comments

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

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.