IT system | BigBigBang

Chef est un outil de management de configuration écris en Ruby et Erlang.

Il permet de maintenir/configurer des serveurs ou des postes de travail grâce à des "recettes" (recipes) stockées dans des « manuels de cuisine » (cookbooks) qui sont stockés par le composant bookshelf sur le serveur chef.

Les recettes sont écrites en ruby ou DSL(domain specific language).

Pour faciliter les modifications et restaurations, ces recettes sont "versionnées". Une première fois sur la machine workstation (git) , une seconde fois sur le serveur (bookshelf) et une troisième fois avec gitlab (git).

Chef est basé sur une idée maître : Vous pouvez modéliser votre infrastructure informatique ainsi que vos applications comme du code. L' infrastructure devient alors testable, versionnée et reproductible comme du code.

Voici l’architecture globale :

On distingue les principaux composants suivants :

bookshelf: composant qui versionne les recettes stockées sur le serveur

chef-expander: formate les messages des queues RabbitMQ

chef-server-webui: Application Ruby qui héberge l'interface web de chef-server chef-solr: Indexer

erchef: API chef (chef en Erlang)

nginx: Serveur web

postgresql: base de données

Installation des serveurs en mode failover :

chef-server.rpm est installé mais pas configuré

Configuration du fichier hosts:

Vérifiez les noms de vos serveurs

hostname

Configurez également /etc/hosts

Mise à jour RabbitMQ :

Nous allons maintenant mettre à jour la version de rabbitMQ utilisée par la version 3.1.4 (à partir de la branche 3, la gestion des clusters est largement améliorée)

Téléchargement :

cd /tmp/

wget http://www.rabbitmq.com/releases/rabbitmq-server/v3.1.4/rabbitmq-server-generic-unix-3.1.4.tar.gz

tar xvfz rabbitmq-server-generic-unix-3.1.4.tar.gz

Puis on supprime l'ancienne version :

rm -rf /opt/chef-server/embedded/service/rabbitmq/

on recréé le dossier :

mkdir -p /opt/chef-server/embedded/service/rabbitmq/

on copie la nouvelle version :

cp -rf /tmp/rabbitmq_server-3.1.4/* /opt/chef-server/embedded/service/rabbitmq/

Puis on va copier notre fichier de configuration de rabbitMQ.

On n'utilisera plus la recette fournie par Opscode pour "gérer" rabbitMQ .

copier ceci dans : /opt/chef-server/embedded/service/rabbitmq/etc/rabbitmq/rabbitmq-env.conf

#!/bin/sh

## The contents of this file are subject to the Mozilla Public License

## Version 1.1 (the "License"); you may not use this file except in

## compliance with the License. You may obtain a copy of the License at

## http://www.mozilla.org/MPL/

## Software distributed under the License is distributed on an "AS IS"

## basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the

## License for the specific language governing rights and limitations

## under the License.

## The Original Code is RabbitMQ.

## The Initial Developers of the Original Code are LShift Ltd,

## Cohesive Financial Technologies LLC, and Rabbit Technologies Ltd.

## Portions created before 22-Nov-2008 00:00:00 GMT by LShift Ltd,

## Cohesive Financial Technologies LLC, or Rabbit Technologies Ltd

## Technologies LLC, and Rabbit Technologies Ltd.

## Ltd. Portions created by Cohesive Financial Technologies LLC are

## LLC. Portions created by Rabbit Technologies Ltd are Copyright

## Contributor(s): __.

HOME="/var/opt/chef-server/rabbitmq"

RABBITMQ_MNESIA_BASE="/var/opt/chef-server/rabbitmq/db"

RABBITMQ_LOG_BASE="/var/log/chef-server/rabbitmq"

RABBITMQ_NODE_IP_ADDRESS="X.X.X.1"

RABBITMQ_NODE_PORT="5672"

RABBITMQ_NODENAME="rabbit@chef1-a"

Créer ensuite le fichier de configuration de rabbitmq :

nano /opt/chef-server/embedded/service/rabbitmq/etc/rabbitmq/rabbitmq.config

et rajouter l'option qui limite la mémoire utilisée :

[{rabbit, [{disk_free_limit, 1000000000}]}].

On modifie ensuite, les paramètres par défaut de rabbitmq :

nano /opt/chef-server/embedded/service/rabbitmq/sbin/rabbitmq-defaults

on change :

SYS_PREFIX=/opt/chef-server/embedded/service/rabbitmq/

on commente :

#LOG_BASE=${SYS_PREFIX}/var/log/rabbitmq

#MNESIA_BASE=${SYS_PREFIX}/var/lib/rabbitmq/mnesia

Puis on peut le lancer (une première fois en mode "normal"..):

export PATH=$PATH:/opt/chef-server/embedded/bin/:/opt/chef-server/embedded/service/rabbitmq/sbin/

rabbitmq-server

et si tout se passe bien :

(Starting broker... completed with 0 plugins.)

on le coupe (Ctrl+c).

Nous allons maintenant ajouter quelques plugins qui vont nous permettre de surveiller les queues rabbitMQ par une interface web:

rabbitmq-plugins list

va nous lister les plugins disponibles. Nous allons activer rabbitmq_management et mochiweb.

rabbitmq-plugins enable mochiweb

rabbitmq-plugins enable rabbitmq_management

Puis relancer le service :

rabbitmq-server

Cette fois-ci le message suivant apparaît :

Starting broker... completed with 6 plugins.

On l'éteint et on le lance en mode "daemon" :

rabbitmq-server -detached

Aller sur http://chef1-a:15672/ pour vérifier son fonctionnement.

Par défaut un compte guest//guest est créé.

Changement des recettes :

On va éditer les recettes afin qu'un des serveurs soit "maître" : on se place dans la recette :

cd /opt/chef-server/embedded/cookbooks/chef-server/

nano attributes/default.rb

###

# High level options

###

default['chef_server']['api_version'] = "11.0.2"

default['chef_server']['flavor'] = "osc" # Open Source Chef

default['chef_server']['notification_email'] = "test@company.com"

default['chef_server']['bootstrap']['enable'] = true

# RabbitMQ\\

default['chef_server']['rabbitmq']['node_ip_address'] = 'X.X.X.1'

default['chef_server']['rabbitmq']['node_port'] = '5672'

default['chef_server']['rabbitmq']['nodename'] = 'rabbit@chef1-a'

default['chef_server']['rabbitmq']['vip'] = 'X.X.X.1'

# Chef Solr

\\default['chef_server']['chef-solr']['ip_address'] = 'X.X.X.1'

default['chef_server']['chef-solr']['vip'] = 'X.X.X.1'

# Bookshelf

\\default['chef_server']['bookshelf']['vip'] = node['fqdn']

default['chef_server']['bookshelf']['url'] = "https://#{node['fqdn']}"

default['chef_server']['bookshelf']['listen'] = "X.X.X.1"

# Erlang Chef Server API

\\default['chef_server']['erchef']['vip'] = 'X.X.X.1'

default['chef_server']['erchef']['listen'] = 'X.X.X.1'

# Chef Server WebUI

\\default['chef_server']['chef-server-webui']['listen'] = 'X.X.X.1'

default['chef_server']['chef-server-webui']['vip'] = 'X.X.X.1'

###

# Estatsd

###

default['chef_server']['estatsd']['vip'] = "X.X.X.1"

###

# Load Balancer

###

default['chef_server']['lb']['vip'] = "X.X.X.1"

default['chef_server']['lb']['upstream']['erchef'] = [ "X.X.X.1" ]

default['chef_server']['lb']['upstream']['chef-server-webui'] = [ "X.X.X.1" ]

default['chef_server']['lb']['upstream']['bookshelf'] = [ "X.X.X.1" ]

###

# PostgreSQL

###

default['chef_server']['postgresql']['vip'] = "X.X.X.1"

default['chef_server']['postgresql']['listen_address'] = '*'

nano recipes/default.rb

commenter la partie rabbitMQ :

# Configure Services

[

#"rabbitmq",

&"postgresql",

Rajouter les droits "opscode" à sa configuration :

nano templates/default/pg_hba.conf.erb

host replication opscode-pgsql X.X.X.2/24 trust

host all opscode_chef X.X.X.2/24 trust

Créer le fichier de restauration pour Postgre :

nano templates/default/recovery.conf.erb

et copier ce contenu :

# ---

# PostgreSQL recovery config file

# ---

# Edit this file to provide the parameters that PostgreSQL needs to

# perform an archive recovery of a database, or to act as a replication

# standby.

# If "recovery.conf" is present in the PostgreSQL data directory, it is

# read on postmaster startup. After successful recovery, it is renamed

# to "recovery.done" to ensure that we do not accidentally re-enter

# archive recovery or standby mode.

# This file consists of lines of the form:

# name = value

# Comments are introduced with '#'.

# The complete list of option names and allowed values can be found

# in the PostgreSQL documentation.

#---

# ARCHIVE RECOVERY PARAMETERS

#---

# restore_command

# specifies the shell command that is executed to copy log files

# back from archival storage. The command string may contain %f,

# which is replaced by the name of the desired log file, and %p,

# which is replaced by the absolute path to copy the log file to.

# This parameter is *required* for an archive recovery, but optional

# for streaming replication.

# It is important that the command return nonzero exit status on failure.

# The command *will* be asked for log files that are not present in the

# archive; it must return nonzero when so asked.

# NOTE that the basename of %p will be different from %f; do not

# expect them to be interchangeable.

restore_command = 'cp /var/pg_xlog/%f "%p"' # e.g. 'cp /mnt/server/archivedir/%f %p'

# archive_cleanup_command

# specifies an optional shell command to execute at every restartpoint.

# This can be useful for cleaning up the archive of a standby server.

#archive_cleanup_command = ''

# recovery_end_command

# specifies an optional shell command to execute at completion of recovery.

# This can be useful for cleaning up after the restore_command.

#recovery_end_command = ''

#---

# RECOVERY TARGET PARAMETERS

#---

# By default, recovery will rollforward to the end of the WAL log.

# If you want to stop rollforward at a specific point, you

# must set a recovery target.

# You may set a recovery target either by transactionId, by name,

# or by timestamp. Recovery may either include or exclude the

# transaction(s) with the recovery target value (ie, stop either

# just after or just before the given target, respectively).

#recovery_target_name = '' # e.g. 'daily backup 2011-01-26'

#recovery_target_time = '' # e.g. '2004-07-14 22:39:00 EST'

#recovery_target_xid = ''

#recovery_target_inclusive = true

# If you want to recover into a timeline other than the "main line" shown in

# pg_control, specify the timeline number here, or write 'latest' to get

# the latest branch for which there's a history file.

recovery_target_timeline = 'latest'

# If pause_at_recovery_target is enabled, recovery will pause when

# the recovery target is reached. The pause state will continue until

# pg_xlog_replay_resume() is called. This setting has no effect if

# hot standby is not enabled, or if no recovery target is set.

#pause_at_recovery_target = true

#---

# STANDBY SERVER PARAMETERS

#---

# standby_mode

# When standby_mode is enabled, the PostgreSQL server will work as a

# standby. It will continuously wait for the additional XLOG records, using

# restore_command and/or primary_conninfo.

standby_mode = on

# primary_conninfo

# If set, the PostgreSQL server will try to connect to the primary using this

# connection string and receive XLOG records continuously.

primary_conninfo = 'host=X.X.X.1 port=5432' # e.g. 'host=localhost port=5432'

# By default, a standby server keeps restoring XLOG records from the

# primary indefinitely. If you want to stop the standby mode, finish recovery

# and open the system in read/write mode, specify path to a trigger file.

# The server will poll the trigger file path periodically and start as a

# primary server when it's found.

trigger_file = '/var/pg_failover'

#---

# HOT STANDBY PARAMETERS

#---

# Hot Standby related parameters are listed in postgresql.conf

#---

Editer :

nano recipes/postgresql.rb

et rajouter ceci :

#recovery = File.join(postgresql_data_dir, "recovery.conf")

#template recovery do

# source "recovery.conf.erb"

# owner node['chef_server']['postgresql']['username']

# mode "0644"

# notifies :restart, 'service[postgresql]' if OmnibusHelper.should_notify?("postgresql")

#end

Editer :

nano templates/default/postgresql.conf.erb

et modifier suivant :

#--

# WRITE AHEAD LOG

#--

# - Settings -

wal_level = hot_standby # minimal, archive, or hot_standby

# (change requires restart)

fsync = on # turns forced synchronization on or off

synchronous_commit = on # synchronization level; on, off, or local

wal_sync_method = fsync # the default is the first option

# supported by the operating system:

# open_datasync

# fdatasync (default on Linux)

# fsync

# fsync_writethrough

# open_sync

#full_page_writes = on # recover from partial page writes

#wal_buffers = -1 # min 32kB, -1 sets based on shared_buffers

# (change requires restart)

#wal_writer_delay = 200ms # 1-10000 milliseconds

#commit_delay = 0 # range 0-100000, in microseconds

#commit_siblings = 5 # range 1-1000

# - Archiving -

archive_mode = on # allows archiving to be done

# (change requires restart)

archive_command = 'cp %p /var/pg_xlog/%f' # command to use to archive a logfile segment

#archive_timeout = 0 # force a logfile segment switch after this

# number of seconds; 0 disables

#--

# REPLICATION

#--

# - Master Server -

# These settings are ignored on a standby server

max_wal_senders = 1 # max number of walsender processes

# (change requires restart)

#wal_sender_delay = 1s # walsender cycle time, 1-10000 milliseconds

wal_keep_segments = 50 # in logfile segments, 16MB each; 0 disables

#vacuum_defer_cleanup_age = 0 # number of xacts by which cleanup is delayed

#replication_timeout = 60s # in milliseconds; 0 disables

#synchronous_standby_names = '' # standby servers that provide sync rep

# comma-separated list of application_name

# from standby(s); '*' = all

# - Standby Servers -

# These settings are ignored on a master server

hot_standby = on # "on" allows queries during recovery

# (change requires restart)

#max_standby_archive_delay = 30s # max delay before canceling queries

# when reading WAL from archive;

# -1 allows indefinite delay

#max_standby_streaming_delay = 30s # max delay before canceling queries

# when reading streaming WAL;

# -1 allows indefinite delay

#wal_receiver_status_interval = 10s # send replies at least this often

# 0 disables

#hot_standby_feedback = off # send info from standby to prevent

# query conflicts

Synchronisation SOLR:

nano templates/default/solrconfig.xml.erb

Modifier :

true

startup

commit

optimize

schema.xml,stopwords.txt

false

http://X.X.X.1:8983/solr/replication

00:00:10

Configuration du maître :

chef-server-ctl reconfigure

Il va s’arrêter à ce moment :

execute[boostrap-chef-server] action run

Mais c'est normal, afin d'obtenir le hash du mot de passe de rabbitMQ qu'on avait pas encore configuré. On copie donc ce hash :

nano /etc/chef-server/chef-server-secrets.json

dans la section :

"rabbitmq": {

"password": XXXXXXXXXXXXXX

On va créer l'utilisateur chef, lui mettre ses droits..

rabbitmqctl add_vhost /chef

rabbitmqctl add_user chef COPIER ICI LE HASH

rabbitmqctl set_permissions -p /chef chef ".*" ".*" ".*"

et on relance la configuration de chef :

chef-server-ctl reconfigure

Pour s'assurer du bon fonctionnement on lance un test :

chef-server-ctl test

on compresse tout ça pour l' envoyer sur l'esclave (ça nous évite de devoir se retaper toutes les pass-phrases, les certificats..)

tar cvfP /tmp/master.tar /opt/chef-server/embedded/ /etc/chef-server/admin.pem /etc/chef-server/chef-server-secrets.json /etc/chef-server/chef-webui.pem /etc/chef-server/chef-validator.pem

backup bdd :

su - opscode-pgsql

psql -d opscode_chef -c "SELECT pg_start_backup('replbackup');"

tar cfP /tmp/db_file_backup.tar /var/opt/chef-server/postgresql/data

psql -d opscode_chef -c "SELECT pg_stop_backup();"

exit

on copie tout ca sur l'esclave :

cd /tmp/

scp master.tar db_file_backup.tar chef1-b:/tmp/

Configuration esclave :

on installe le rpm, on supprime le dossier rabbitMQ et on écrase avec nos tar

rpm -Uvh chef-server-11.0.8.rpm

rm -rf /opt/chef-server/embedded/service/rabbitmq/

cd /tmp/

tar xvfP master.tar

tar xvfP db_file_backup.tar

on supprime le pid de postgresql du maître

rm -rf /var/opt/chef-server/postgresql/data/postmaster.pid

puis on modifie nos recettes :

cd /opt/chef-server/embedded/cookbooks/chef-server/

on décommente la partie "recovery" {{code}}nano recipes/postgresql.rb

nano attributes/default.rb

On change les addresses IP et le nom du serveur rabbitMQ

Ne pas changer la partie :

default['chef_server']['postgresql']['vip'] = "X.X.X.1"

Editer :

nano templates/default/solrconfig.xml.erb

Inverser les valeurs "true / false"

true

startup

commit

optimize

schema.xml,stopwords.txt

false

http://X.X.X.1:8983/solr/replication

00:00:10

Puis on lance la configuration de chef :

chef-server-ctl reconfigure

Il va s'arreter à

execute[boostrap-chef-server] action run

Continuons :

Mise en place du cluster rabbitMQ :

Editer le fichier:

tail /var/opt/chef-server/rabbitmq/.erlang.cookie

puis

chown root:root /var/opt/chef-server/rabbitmq/.erlang.cookie && chmod 600 /var/opt/chef-server/rabbitmq/.erlang.cookie

on modifie la configuration (ip et nom) :

nano /opt/chef-server/embedded/service/rabbitmq/etc/rabbitmq/rabbitmq-env.conf

HOME="/var/opt/chef-server/rabbitmq"

RABBITMQ_MNESIA_BASE="/var/opt/chef-server/rabbitmq/db"

RABBITMQ_LOG_BASE="/var/log/chef-server/rabbitmq"

RABBITMQ_NODE_IP_ADDRESS="X.X.X.2"

RABBITMQ_NODE_PORT="5672"

RABBITMQ_NODENAME="rabbit@chef1-b"

on mets à jour notre environnement :

export PATH=$PATH:/opt/chef-server/embedded/bin/:/opt/chef-server/embedded/service/rabbitmq/sbin/

On vérifie que les plugins sont activés: Désactiver :

rabbitmq-plugins list

sinon :

rabbitmq-plugins enable mochiweb rabbitmq_management

On le lance une première fois :

rabbitmq-server

Si tout fonctionne :

rabbitmq-server -detached

On peut vérifier l'interface web : http://chef1-b:15672/

Puis on "clusterise" depuis l'esclave :

rabbitmqctl stop_app

rabbitmqctl join_cluster rabbit@chef1-a

rabbitmqctl start_app

pour verifier :

rabbitmqctl cluster_status

On peut relancer la configuration de chef :

chef-server-ctl reconfigure

Synchronisation du bookshelf :

On télécharge lsyncd

wget https://lsyncd.googlecode.com/files/lsyncd-2.1.5.tar.gz

On l'installe (besoin de lua, lua-devel , gcc, gcc++)

./configure

make

make install

On créé un fichier de configuration :

cd /etc/

nano lsyncd.conf

on y mets :

settings{

logfile = "/tmp/lsyncd.log",

statusFile = "/tmp/lsyncd.status",

nodaemon = false,

maxDelays = 30,

maxProcesses = 6,

}

sync{

default.rsyncssh,

source="/var/opt/chef-server/bookshelf/data/",

host="chef1-b",

targetdir="/var/opt/chef-server/bookshelf/data/"}

sync{

default.rsyncssh,

source="/var/pg_xlog/",

host="chef1-b",

targetdir="/var/pg_xlog/"}

et on le lance avec :

lsyncd /etc/lsyncd.conf

* On peut vérifier dans les logs que tout fonctionne :

tail /tmp/lsyncd.log

* la vérification de la synchronisation de l'index Solr se fait par chef-server-ctl (par défaut toutes les 10 secs )

* les logs de verification de la réplication de postgre (sur esclave) :

tail /var/log/chef-server/postgresql/current

* Page d'informations sur les cluster rabbitMQ:

http://chef1-a:15672/#/

* Page d'information sur PostgreSQL :

http://chef1-a:8080/phpPgAdmin/

* Page de status de chef-server :

https://chef1-a/_status/

Afin de valider les tests d'opscode, l'ordre de démarrage des serveurs est important , démarrer dans un premier temps le serveur A, puis le serveur B. (Ainsi les consumers de rabbit seront sur le serveur A)

Lancer les tests :

chef-server-ctl test

sur le maitre :

Finished in 47.71 seconds 70 examples, 0 failures

sur l'esclave :

Finished in 45.68 seconds 70 examples, 10 failures

Des tests plus complets peuvent être lancés avec la commande :

chef-server-ctl test all

FAILOVER

Je ne vais pas expliquer le basculement IP, seulement le basculement esclave -> maitre / maitre -> esclave .

Sur chef1-a (maître):

-couper l'instance de chef

chef-server-ctl stop

-couper lsyncd (synchronisation bookshelf et Wal postgres)

-basculement IP

Le reste des commandes se fait sur l'esclave.

Configuration :

BDD :

On précise à chef1-b de se servir de sa base de donnée.

nano /var/opt/chef-server/erchef/etc/app.config

%% The only database supported is Postgres

{db_type, pgsql},

%% Database connection parameters

{db_host, "X.X.X.2"},

{db_port, 5432},

{db_user, "opscode_chef"},

SOLR :

On inverse les valeurs maître/esclave et l'adresse du maître

true

startup

commit

optimize

schema.xml,stopwords.txt

false

http://X.X.X.1:8983/solr/replication

00:00:10

nano /var/opt/chef-server/chef-solr/home/conf/solrconfig.xml

PostgreSQL :

Il y a 2 méthodes :

* le trigger file

Créer le trigger file "pg_failover" dans /var/

cd /var

touch pg_failover

Le fichier /var/opt/chef-server/postgresql/data/recovery.conf devient recovery.done.

* commande promote

Passer sur l'utilisateur opscode-pgsql et lancer la commande

su - opscode-pgsql

pg_ctl promote -D /var/opt/chef-server/postgresql/data/ promote

exit

RabbitMQ :

Le cluster doit rester présent , il suffit de vérifier avec

rabbitmqctl cluster_status

sinon :

rabbitmqctl stop_app

rabbitmqctl join_cluster rabbit@chef1-b

rabbitmqctl start_app

Redemarrage :

chef-server-ctl restart

Reprise en mode "normal" :

Afin de rebasculer les serveurs dans leur rôle d'origine, le plus simple est de faire une backup totale de la base de donnée et de remettre les configurations d'origine.

On éteint l'instance de chef sur l'esclave (pas sur le maître)

chef-server-ctl stop

backup bdd :

su - opscode-pgsql

psql -d opscode_chef -c "SELECT pg_start_backup('replbackup');"

tar cfP /tmp/db_file_backup.tar /var/opt/chef-server/postgresql/data

psql -d opscode_chef -c "SELECT pg_stop_backup();"

exit

on copie tout ca sur le maître :

cd /tmp/

scp db_file_backup.tar chef1-a:/tmp/

Puis on peut éteindre l'instance de chef sur le maître.

Configuration :

Sur le maître (chef1-b):

recovery.done -> recovery.conf (et suppression du trigger file):

cd /var/opt/chef-server/postgresql/data/

mv recovery.done recovery.conf

rm /var/pg_failover

Solr On inverse les valeurs maître/esclave et l'adresse du maître

nano /var/opt/chef-server/chef-solr/home/conf/solrconfig.xml

Configuration erchef

nano /var/opt/chef-server/erchef/etc/app.config

%% The only database supported is Postgres

{db_type, pgsql},

%% Database connection parameters

{db_host, "X.X.X.1"},

{db_port, 5432},

{db_user, "opscode_chef"},

Lsyncd

On coupe l'instance lsyncd :

ps aux | grep lsyncd

et retenir le numéro du PID

kill - 9 "numéro PID"

Sur l'esclave (chef1-a) :

On supprime la base de donnée en cours :

rm -rf /var/opt/chef-server/postgresql/data/

On extrait la base de donnée récupérée précédemment :

tar xvfP /tmp/db_failover.tar

On supprime le fichier recovery.done et postmaster.pid

rm /var/opt/chef-server/postgresql/data/recovery.done /var/opt/chef-server/postgresql/data/postmaster.pid

Solr

On inverse les valeurs maître/esclave et l'adresse du maître

nano /var/opt/chef-server/chef-solr/home/conf/solrconfig.xml

Configuration erchef

nano /var/opt/chef-server/erchef/etc/app.config

%% The only database supported is Postgres

{db_type, pgsql},

%% Database connection parameters

{db_host, "X.X.X.1"},

{db_port, 5432},

{db_user, "opscode_chef"},

Sur les 2 serveurs :

supprimer les fichiers wal dans le dossier /var/pg_xlog

rm -f /var/pg_xlog/*

Relance lsyncd (chef1-a):

lsyncd /etc/lsyncd.conf

Relance Chef : Lancer l'instance en premier sur chef1-a, puis sur chef1-b.

IT system | BigBigBang

Pages

Rechercher dans ce blog

lundi 9 septembre 2013

Intégration GitLab | Chef 11 (OSC)

GitLab 6 sur scientific linux 6.3 (globalement EL6)

jeudi 22 août 2013

Mise à jour Gitlab 5.4 -> 6.0

mercredi 21 août 2013

Chef OSC Installation failover