installation Arch

loadkey fr-latin1
iwctl
station wlan0 scan
station wlan0 get-networks
station wlan0 connect SSID
station wlan0 show
quit
timedatectl

mkfs.fat -F32 /dev/sda1
mkfs.ext4 /dev/sda2
mkfs.ext4 /dev/sdb1
mkswap /dev/sda3
swapon /dev/sda3

mount /dev/sda2 /mnt
mkdir /mnt/home
mount /dev/sdb1 /mnt/home

reflector –country France –age 12 –protocol https –sort rate –save /etc/pacman.d/mirrorlist

pacstrap -i /mnt base linux linux-headers

genfstab -U -p /mnt >> /mnt/etc/fstab

arch-chroot /mnt

ln -sf /usr/share/zoneinfo/Europe/Paris /etc/localtime

hwclock --systohc

pacman -S grub efibootmgr dosfstools openssh os-prober mtools linux-headers linux-lts linux-lts-headers vim iwd linux-firmware reflector dhclient

sed -i 's/#en_US.UTF-8/en_US.UTF-8/g' /etc/locale.gen
sed -i 's/#fr_FR.UTF-8/fr_FR.UTF-8/g' /etc/locale.gen
locale-gen

sed -i 's/#PermitRootLogin prohibit-password/PermitRootLogin yes/g' /etc/ssh/sshd_config
systemctl enable sshd.service
passwd

mkdir /boot/EFI
mount /dev/sda1 /boot/EFI
grub-install --target=x86_64-efi --bootloader-id=grub_uefi --recheck
cp /usr/share/locale/en\@quot/LC_MESSAGES/grub.mo /boot/grub/locale/en.mo
grub-mkconfig -o /boot/grub/grub.cfg

exit
umount -a
reboot

Publié dans linux, Uncategorized | Marqué avec | Laisser un commentaire

CoreOS : (re)configuration réseau

Je monte un cluster Kubernetes en mode « bare metal ».
En faite des VMs.
Pour monter le cluster je vais utiliser RKE de Rancher.
Pour les nodes du cluster, je veux partir sur CoreOS.
L’installation des VMs se fait sans problème.

sudo coreos-installer install /dev/xvda \
--ignition-url https://lepesant.com/coreos.ign

Une fois la VM rebootée elle affiche une adresse IP attribuée par DHCP.
Or je veux que mes nodes aient des IP fixes.
La configuration de l’interface enX0 est modifiée à l’aide de nmcli :

sudo nmcli connection modify Wired\ connection\ 1    \
ipv4.method manual \
ipv4.gateway 192.168.0.254 \
ipv4.dns 192.168.0.1 \
ipv4.addresses 192.168.0.41

Heureusement que l’auto-complétion fonctionne à merveille.

On reparlera du fichier coreos.ign (aka ignition plus tard)

Publié dans coreos, kubernetes | Laisser un commentaire

Renouvellement des certificats SSL fournit par LetsEncryt

Ce script test le délai avant expiration de vos certificats SSL.
Le renouvellement est demandé si l’expiration intervient dans les 10 jours (par défaut).

Votre serveur web est nginx….dans cet exemple.

#!/bin/sh

#DEBUG=true
DEBUG=false

SSL_CHECK=/usr/bin/ssl-cert-check
CERBOT=/usr/bin/certbot
AWK=/usr/bin/awk

MIN_EXP=${1:-10}
MUST_RENEW=false

# Test and install ssl-cert-check if needed
if [[ ! -f ${SSL_CHECK} ]]; then
        if ${DEBUG} ; then echo -e "\e[93m INFO : Installing ssl-cert-check \e[0m" ; fi
		apt-get -qq update
        apt-get -qq -y install ssl-cert-check
fi

# Test each cert.pem find in /etc/letsencrypt
for FOLDER in `find /etc/letsencrypt/archive/ -maxdepth 1 -mindepth 1 -type d`
do
        CERTIFICAT=${FOLDER##*/}
        day_before_expiry=$(${SSL_CHECK} -b -c /etc/letsencrypt/live/${CERTIFICAT}/cert.pem | ${AWK} '{print $NF}')

        if ${DEBUG} ; then echo "${CERTIFICAT} expire in ${day_before_expiry} days" ; fi

        if [[ "${MIN_EXP}" -gt "${day_before_expiry}" ]]
        then
                MUST_RENEW=true
        fi
done

# Run certbot renew if at least one certificat is going to expire soon
if ${MUST_RENEW} ; then
        if ${DEBUG} ; then
                echo -e "\e[93m INFO : Renewing certificats in DRY RUN MODE \e[0m"
                ${CERBOT} --nginx renew --dry-run
                exit 0
        fi

        ${CERBOT} --nginx renew
        service nginx restart
        exit 0
fi

if ${DEBUG} ; then echo -e "\e[32m No need to renew \e[0m" ; fi

exit 0
Publié dans Uncategorized | Laisser un commentaire

Oracle XE sur Debian 9

Installation d’Oracle Express sur une Debian 9

Sur une Debian 9 fraîchement installée, avec Alien.

Installation de quelques dépendances

apt install unzip libaio1 bc initscripts net-tools openssl dnsutils alien

Télécharger Oracle Database Express Edition 11g Release 2

C’est par ici.

Décompresser l’archive

unzip oracle-xe-11.2.0-1.0.x86_64.rpm.zip

Convertir le RPM en DEB

alien --scripts Disk1/oracle-xe-11.2.0-1.0.x86_64.rpm

L’option « –scripts » permet de conserver les scripts de pre/post installation et désinstallation.
Ceux-ci vont créer l’utilisateur et les répertoires nécessaires au bon fonctionnement de l’application.

Gruger le script d’install

free() { echo "Swap: 2048 0 2048"; } && export -f free

Parce que bon. 2G de SWAP c’est bien.

Installer le paquet

dpkg -i oracle-xe_11.2.0-2_amd64.deb

Modifier le script « /etc/init.d/oracle-xe »

--- oracle-xe	2018-07-31 22:54:06.574880947 +0200
+++ oracle-xe	2018-07-31 22:54:44.948982205 +0200
@@ -50,7 +50,7 @@
 if [ -z "$GREP" ]; then GREP=/usr/bin/grep; fi
 if [ ! -f "$GREP" ]; then GREP=/bin/grep; fi
 if [ -z "$SED" ]; then SED=/bin/sed; fi
-if [ -z "$AWK" ]; then AWK=/bin/awk; fi
+if [ -z "$AWK" ]; then AWK=/usr/bin/awk; fi
 if [ -z "$SU" ];then SU=/bin/su; fi
 
 export LC_ALL=C

Lancer la configuration

# /etc/init.d/oracle-xe configure

Oracle Database 11g Express Edition Configuration
-------------------------------------------------
This will configure on-boot properties of Oracle Database 11g Express 
Edition.  The following questions will determine whether the database should 
be starting upon system boot, the ports it will use, and the passwords that 
will be used for database accounts.  Press <Enter> to accept the defaults. 
Ctrl-C will abort.

Specify the HTTP port that will be used for Oracle Application Express [8080]:

Specify a port that will be used for the database listener [1521]:

Specify a password to be used for database accounts.  Note that the same
password will be used for SYS and SYSTEM.  Oracle recommends the use of 
different passwords for each database account.  This can be done after 
initial configuration:
Confirm the password:

Do you want Oracle Database 11g Express Edition to be started on boot (y/n) [y]:

Starting Oracle Net Listener...Done
Configuring database...Done
Starting Oracle Database 11g Express Edition instance...Done
Installation completed successfully.
root@www:/home/hugues#

Unset de la fonction free

unset -f free

Setting de l’environnement Oracle

Ce qui est pénible avec Oracle c’est qu’il y a un paquet de variable d’environnement à définir avant de pouvoir jouer avec.
Heureusement il y a deux scripts dans le répertoire « /u01/app/oracle/product/11.2.0/xe/bin/ » :

  1. oracle_env.csh
  2. oracle_env.sh

Comme j’utilise bash comme shell, je place la ligne suivante en fin de « ~/.bashrc »

. /u01/app/oracle/product/11.2.0/xe/bin/oracle_env.sh

Je me déconnecte/reconnecte, et je lance la commande « env » :

ORACLE_SID=XE
ORACLE_HOME=/u01/app/oracle/product/11.2.0/xe
PATH=/u01/app/oracle/product/11.2.0/xe/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Voilà maintenant je peux lancer SQLPlus.

$ sqlplus system@localhost

SQL*Plus: Release 11.2.0.2.0 Production on Tue Jul 31 23:58:44 2018

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Enter password: 

Connected to:
Oracle Database 11g Express Edition Release 11.2.0.2.0 - 64bit Production

SQL> Disconnected from Oracle Database 11g Express Edition Release 11.2.0.2.0 - 64bit Production

Dans un prochain article on verra la création d’un tablespace, et celui d’un user/schema.
Et enfin l’import d’un dump oracle dans notre instance XE.

Publié dans databases, j'aime me faire du mal, linux | Laisser un commentaire

systemctl

Bon on va y aller franchement, je déteste ce truc.
Il m’apporte plus d’emmerde qu’il m’en solutionne.

Donc voici quelques astuces pour :

  • Supprimer un service proprement

  • systemctl list-units |grep <nom du service>
    systemctl disable <le service à supprimer>
    systemctl daemon-reload
    systemctl list-units |grep redis

Publié dans Humeur, Mes docs, Uncategorized | Laisser un commentaire

Installation Solr sur Debian 8

Solr_Logo_on_whiteInstallation de Java8


echo "deb http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main" | tee /etc/apt/sources.list.d/webupd8team-java.list
echo "deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main" | tee -a /etc/apt/sources.list.d/webupd8team-java.list
apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys EEA14886
apt-get update
apt-get install oracle-java8-installer
apt-get install oracle-java8-set-default
java -version

 

Installation de Solr 5.x

wget http://apache.crihan.fr/dist/lucene/solr/5.4.0/solr-5.4.0.tgz
tar xzf solr-5.4.0.tgz solr-5.4.0/bin/install_solr_service.sh --strip-components=2
bash ./install_solr_service.sh solr-5.4.0.tgz 

 

Quelques modifications

service solr status
service solr stop
chown -R solr:solr /var/solr
service solr start

 

Création d’une Collection

su - solr -c "/opt/solr/bin/solr create -c drupal"

 

Il vous reste à vérifier dans votre navigateur : http://localhost:8983/solr

 

Sources :

  • https://www.drupal.org/node/2502221
  • https://www.digitalocean.com/community/tutorials/how-to-install-solr-5-2-1-on-ubuntu-14-04
Publié dans linux, Mes docs | Marqué avec , , | Laisser un commentaire

Dans ma cave, cave, cave

Cela fait quelques années que je suis en home hosting pour ce blog mais aussi ma messagerie perso. Ce n’est pas de la paranoïa anti-patriotAct mais l’envie de tout maîtriser.

Ceci est d’autant plus possible que ma connexion ADSL Free bénéficie d’une IP fixe.

Afin de valider la pertinence de la solution j’avais mis en place un « monitoring » ultra light par l’intermédiaire de Pingdom.

Pingdom_perso

Voici le dernier report.

C’est la première fois, et j’en suis pas peu fier 😉

Publié dans Non classé, Uncategorized | Laisser un commentaire

Firewall transparent en haute-disponibilité avec PfSense

pfSense est une distribution basée sur FreeBSD, qui permet de transformer n’importe quel PC x86 en firewall.

Je me suis mis en tête d’installer et de configurer deux serveurs Dell PowerEdge R200 avec chacun 8Go de RAM et 4 cartes réseaux en firewall transparent redondant.

Ca doit ressembler à ça.

pfSense_bridge_ha

Dans ma configuration, et pour plus de clareté les interfaces pfSense sont renommées:

  • wan = WAN : connectée sur des switchs « backbone »
  • lan = MGMT : connectée sur un switch d’administration
  • opt1 = SYNC : connectée à l’autre firewall par un câble croisé
  • opt2 = DMZ : connectée aux switchs sur lesquels se trouvent les serveurs de vos clients
  • opt3 = BRIDGE (non représentée sur le schéma)

L’avantage d’un firewall en mode transparent c’est qu’il permet de fournir un adressage public à vos clients, mais il peut aussi s’intercaler dans un réseau existant sans avoir à renuméroter toutes les machines du client comme dans un NAT.

L’installation de pfSense est des plus simples à partir de l’ISO (download here).

Ensuite il faut procéder par étapes :

1. Définitions de l’IP de l’interface « lan » de pfSense

Opération réalisée à travers la console une fois l’installation terminée.
Option 1 : attribution des cartes réseaux
Option 2 : définition des IP des cartes réseaux

Je ne configure que la patte « lan » pour accéder à l’interface d’administration.

2. Modification du comportement par défaut

pfSense est une firewall qui NAT. La configuration d’origine est faite en ce sens.
Il faut donc procéder à quelques modifications pour avoir un fonctionnement optimal en mode transparent.

Aller dans Firewall -> NAT -> Outbound, et cocher : Disable Outbound NAT rule generation (No Outbound NAT rules)

pfSense_bridge_ha_setup_01_1

3. Assignation et activation des autres cartes réseaux

Interfaces -> (assign)

Toutes les interfaces sont activées.
Seules les interfaces lan(MGMT) et opt1(SYNC) auront une adresse IP.
L’interface SYNC servira à synchroniser les 2 firewalls.

4. Mise en place de la redondance

Nous allons configurer CARP. Pour que CARP est un rôle à jouer dans notre plateforme cible, il faudra assigner une IP (VIP) à l’interface CARP. Ce sera le seul objectif car nous ne nous servirons pas de cette IP. Dans une configuration en mode bridge ce seront les interfaces MGMT qui porteront cette VIP.

4.1. Création de l’adresse IP virtuelle

Firewall -> Virtual IP Addresses

Créer une Virtual IP de type CARP, portée par l’interface MGMT et qui aura une IP en /32.

pfSense_bridge_ha_setup_01_2

pfSense_bridge_ha_setup_01_3

4.2. Configurer la synchronisation.

System: High Availability Sync ou cliquer sur « CARP Settings »

State Synchronization Settings (pfsync)

Synchronize States activé
Synchronize Interface SYNC
pfsync Synchronize Peer IP 10.10.10.2

Configuration Synchronization Settings (XMLRPC Sync)

Synchronize Config to IP 10.10.10.2
Remote System Username admin
Remote System Password *******
Synchronize Users and Groups coché
Synchronize rules coché
Synchronize Firewall Schedules coché
Synchronize aliases coché
Synchronize Static Routes coché
Synchronize Virtual IPs coché

Pour le firewall SLAVE, ne configurer que la section du haut en mettant l’IP du MASTER dans le champ « pfsync Synchronize Peer IP ».

5. Création du bridge

5.1 Création des interfaces WAN et DMZ

Nous allons activé ces interfaces sans leur donner d’adresse IP.

pfSense_bridge_ha_setup_01

5.2. Création du bridge

Le bridge va assembler 2 interfaces pour n’en faire qu’une seule.
Ainsi tout ce qui arrive sur l’interface WAN sera « reproduit » sur l’interface DMZ.

warning Dans notre installation il est très important de ne pas connecter physiquement l’interface WAN du deuxième firewall (SLAVE) sur le switch « backbone ».
Si vous connecter les 2 interfaces WAN sur le même switch, alors que les 2 interfaces DMZ sont connectées sur une autre switch vous aller créer une boucle de switching et déclencher une tempête de brodacast qui mettra votre réseau à terre.
Le plus vicieux dans les effets d’une boucle de switching peuvent mettre quelques secondes, voir minutes à se manifester après que vous ayez brancher le câble de trop.

Interfaces -> (assign) -> Bridges

Le bridge sera créé avec les interfaces WAN et DMZ.

pfSense_bridge_ha_setup_02

Cela donne ceci dans l’interface WEB.

pfSense_bridge_ha_setup_03

5.3. Activation de l’interface BRIDGE

Cette étape est important car elle nous permettra de configurer UP ou DOWN l’interface BRIDGE, et lutter contre les problèmes de « spanning tree » évoqués plus haut.

pfSense_bridge_ha_setup_04

On clique sur le « plus » pour créer puis activer l’interface.

pfSense_bridge_ha_setup_05

5.4. Activer le filtrage au niveau du bridge

System -> Advanced -> System Tunables

Par défaut le filtrage s’opérera sur les interfaces WAN et DMZ, et pas sur le bridge à proprement parlé.
Nous allons donc modifier les propriétés suivantes :

  • net.link.bridge.pfil_onlyip = 0
  • net.link.bridge.pfil_member = 1
  • net.link.bridge.pfil_bridge = 0

6. Quelques paramètres supplémentaires

System -> Advanced -> Firewall and NAT -> Firewall Advanced

Cocher ou choisir les options suivantes :

  1. Disable reply-to on WAN rules
  2. Clear invalid DF bits instead of dropping the packets
  3. Firewall Optimization Options : conservative
  4. Disables the PF scrubbing option which can sometimes interfere with NFS and PPTP traffic.

La première option s’entend car nous avons activé le en mode bridge.
Les suivantes nous préviennent des problèmes de fragmentation de paquets.

System -> Advanced -> Networking -> Network Interfaces

  1. Suppress ARP messages

7. Lutte contre le Spanning Tree

Dans notre configuration en mode bridge, si nous branchons les 4 interfaces WAN et DMZ, nous allons créer une boucle de switching et nous faire pourrir par notre admin réseau préféré.

En partant du principe que cet admin ne voudra par activer ni le Spanning Tree (SPT) ni le Rapid Spanning Tree (RSPT) sur les switchs, nous devons nous assurer que nous n’allond pas créer de boucle de switching en faisant tomber l’interface BRIDGE sur le firewall BACKUP, et en la remontant quand celui-ci devient MASTER suite à une défaillance du firewall MASTER.

Pour faire cela nous allons faire appel à devd

Ce daemon scrute ce qui se passe sur le système et en fonction d’événements va déclencher des actions.

En lançant devd en mode debug (/sbin/devd -d) sur le BACKUP, on observe les événements suivants quand le firewall MASTER est éteint.

setting system=CARP
setting subsystem=1@em2
setting type=MASTER
Processing notify event
Testing system=CARP against ^CARP$, invert=0
Testing type=MASTER against ^(MASTER|BACKUP)$, invert=0
Popping table

Nous allons donc créer le fichier /usr/local/etc/devd/carp.conf dans lequel nous allons décrire l’événement « l’interface CARP change d’état » et nous allons l’associer à un script.

#
# Processing event '!system=CARP subsystem=1@em2 type=BACKUP'
#
notify 200 {
    match "system" "CARP";
#   match "subsystem" "1@em2";
#   match "subsystem" "[0-9]+@[0-9a-z]+";
    match "type" "(MASTER|BACKUP)";
    action "/usr/local/bin/bridge-carp $type";
};

Le script « /usr/local/bin/bridge-carp »

#!/bin/sh

if [ $# -eq 0 ]
then
    echo "No arguments supplied"
    exit 0
fi

case "$1" in
    MASTER)
        /sbin/ifconfig bridge0 up
        ;;
    BACKUP)
        /sbin/ifconfig bridge0 down
        ;;
    *)
        /sbin/ifconfig bridge0 down
        ;;
esac

Si l’interface CARP est en état MASTER, je monte le bridge.
Si l’interface CARP est en état BACKUP, je descend le bridge.

Dans les logs on verra :

setting system=CARP
setting subsystem=1@em2
setting type=MASTER
Processing notify event
Testing system=CARP against ^CARP$, invert=0
Testing type=MASTER against ^(MASTER|BACKUP)$, invert=0
Executing '/usr/local/bin/bridge-carp MASTER'
Popping table

Ainsi on espère ne pas créer de boucle de switching.

A noter les options de carp dans le sysctl du système.
L’option « net.inet.carp.preempt » nous assure que toutes les cartes tombent en cas de défaillance d’une interface.
Mais aussi du retour au mode nominale lorsque que le MASTER revient.

# sysctl -a|grep net.inet.carp
net.inet.carp.allow: 1
net.inet.carp.preempt: 1
net.inet.carp.log: 1
net.inet.carp.demotion: 0
net.inet.carp.senderr_demotion_factor: 0
net.inet.carp.ifdown_demotion_factor: 240

7. Inspiration

Publié dans FreeBSD, Mes docs | Marqué avec , , | Laisser un commentaire

Redis haute-disponibilité

Dans le cadre d’un projet de centralisation des logs avec Ossec + LogStash + ElasticSearch + Kibana, nous avons eu recours à Redis pour faire le tampon entre Ossec et Logstash.

Des contraintes de disponibilité m’ont conduit à mettre en place une plateforme Redis hautement disponible et tolérante….la routine habituelle ;-).

Le schéma de l’architecture mise en place ressemble à ça (merci 1Q77 pour l’inspiration) :Redis-HA-haproxy-sentinel

Contrairement à Yteraoka, j’ai opté pour 3 serveurs Redis (1 maitre, 2 esclaves).
En cas de défaillance du Redis Maitre, Sentinel (redis-sentinel) s’occupe de promouvoir un des esclaves en maitre.
Le fidèle Ha-proxy redirigera sur le flux sur le nouveau maitre.
Tandis que KeepAlived s’occupe de présenter toujours la même (V)IP aux clients Redis.

Voici le plan d’adressage des machines et leur rôle :

Nom IP Rôle
VIP 192.168.0.1 VIP
haproxy-01 192.168.0.2 haproxy + keepalied
haproxy-02 192.168.0.3 haproxy + keepalied
redis-01 192.168.0.4 Redis maître
redis-02 192.168.0.5 Redis esclave
redis-03 192.168.0.6 Redis esclave

Ha-Proxy

Installation

apt-get install software-properties-common
add-apt-repository ppa:vbernat/haproxy-1.5
apt-get install haproxy hatop

Configuration

Editer /etc/haproxy/haproxy.cfg

global
    log /dev/log    local0
    log /dev/log    local1 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin
    stats timeout 30s
    user haproxy
    group haproxy
    daemon

defaults REDIS
    mode tcp
    timeout connect  4s
    timeout server  30s
    timeout client  30s

frontend ft_redis
    bind 192.168.0.1:6379 name redis
    default_backend bk_redis
 
backend bk_redis
    mode tcp
    option tcplog
    option tcp-check
    tcp-check send AUTH\ 7xJtpLugAyu6hgPbuB3hX4R\r\n
    tcp-check expect string +OK
    tcp-check send PING\r\n
    tcp-check expect string +PONG
    tcp-check send info\ replication\r\n
    tcp-check expect string role:master
    tcp-check send QUIT\r\n
    tcp-check expect string +OK
    server redis01 192.168.0.4:6379 check inter 1s
    server redis02 192.168.0.5:6379 check inter 1s
    server redis03 192.168.0.6:6379 check inter 1s

Toute l’intelligence se retrouve dans les lignes « tcp-check ».
Ici ha-proxy va simuler une connexion cliente sur les serveurs Redis en jouant le scénario suivant :

  1. Connexion et authentification avec envoie du mot de passe, en espérant avoir la réponse OK
  2. Demande d’information sur la réplication. Retourne un certain nombre de ligne dont celle indiquant le rôle du serveur. Ici on s’attend à avoir « role:master ».
  3. Déconnexion

Si a une des commandes « send » le résultat retourné correspond à celui la ligne « expect » qui suite, le serveur est considéré comme L7OK, et il prendra les flux.
Sinon L7TOUT et il n’aura pas de flux.

KeepAlived

Installation

apt-get install keepalived

Configuration

Editer /etc/keepalived/keepalived.conf.
La configuration est identique les 2 machines haproxy-*, à la « priority » près.

# Settings for notifications
global_defs {
    notification_email {
        hugues@lepesant.com
    }
    notification_email_from haproxy01@lepesant.com
    smtp_server 212.27.48.4
    smtp_connect_timeout 15
    router_id haproxy01
}

vrrp_sync_group SyncGroup01 {
    group {
        VI_1
    }
}

vrrp_script chk_haproxy {
    script "/usr/bin/killall -0 haproxy"
    script "/usr/sbin/service haproxy restart"
    interval 9
    timeout 3
    weight 20
    rise 2
    fall 4
}

vrrp_instance VI_1 {
    interface eth0
    nopreempt
    virtual_router_id 51
    priority 101          # 101 on master, 100 on backup
    advert_int 5

    virtual_ipaddress {
        192.168.0.1/24 dev eth0
    }

    track_script {
        chk_haproxy
    }

    smtp_alert
}

Pour tester :

ip address show

Redis

Installation

Toutes les machines sont animées par des Ubuntu 14.04.
Les commandes sont exécutées après « sudo -i ».

  apt-get install software-properties-common
  add-apt-repository ppa:rwky/redis 
  apt-get update
  apt-get install redis-server

Configuration

Histoire de ne plus avoir d’alerte dans les log à propos de « Transparent Hugepage »

  echo never > /sys/kernel/mm/transparent_hugepage/enabled
  vim /etc/rc.local

Ajouter « echo never > /sys/kernel/mm/transparent_hugepage/enabled » dans /etc/rc.local, avant le « exit ».

Par habitude je ne modifie pas les fichiers de configuration si je peux le faire par un fichier dans un répertoire « conf.d/ » de l’application.
Donc :

vim /etc/redis/conf.d/local.conf

Avec les lignes suivantes :

Redis maître

Sur le maître. Enfin au démarrage, et tant qu’il ne rencontre pas de défaillance c’est le maître.

#slaveof 192.168.0.5 6379
masterauth 7xJtpLugAyu6hgPbuB3hX4R
requirepass 7xJtpLugAyu6hgPbuB3hX4R

La réplication est un peu sécurisée par la demande d’un mot de passe (masterauth).
Comme à n’importe quel moment le maître peut devenir esclave, il doit connaitre le mot de passe pour se connecter au maître (requirepass).

Redis esclave

Sur le 2 esclaves.

slaveof 192.168.0.4 6379
masterauth 7xJtpLugAyu6hgPbuB3hX4R
requirepass 7xJtpLugAyu6hgPbuB3hX4R

Sentinel

Création d’un script d’init

C’est balot y’en a pas

vim /etc/init.d/redis-sentinel
chmod +x /etc/init.d/redis-sentinel
update-rc.d redis-sentinel defaults

En voilà le contenu :

#!/bin/sh
### BEGIN INIT INFO
# Provides:          redis-sentinel
# Required-Start:
# Required-Stop:
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start daemon at boot time
# Description:       Enable service provided by daemon.
### END INIT INFO

NAME="redis-sentinel"
DAEMON="/usr/bin/redis-sentinel"

. /lib/lsb/init-functions
[ -f /etc/default/rcS ] && . /etc/default/rcS

test -x $DAEMON || exit 0

case "$1" in
    stop)
        log_begin_msg "Stoping Redis Sentinel..." "redis-sentinel"
        killall -9 redis-sentinel &> /dev/null
        log_end_msg $?
        ;;
    start)
        log_begin_msg "Starting Redis Sentinel..." "redis-sentinel"
        nohup $DAEMON /etc/redis/sentinel.conf >> /var/log/redis/sentinel.log &> /dev/null &
        log_end_msg 0
        ;;
        restart)
                $0 stop
                sleep 2
                $0 start
                ;;
        status)
                status_of_proc $DAEMON redis-sentinel
        ;;
    *)
        log_failure_msg "Usage: $0 <stop|start|restart|status>"
        exit 1
        ;;
esac

exit 0

Configuration

Création du fichier « /etc/redis/sentinel.conf » avec le contenu suivant :

port 26379
daemonize yes
logfile "/var/log/redis/sentinel.log"
pidfile "/var/run/redis/redis.pid"

sentinel monitor mymaster 192.168.0.4 6379 2
sentinel auth-pass mymaster 7xJtpLugAyu6hgPbuB3hX4R
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000

On dit à sentinel de surveiller le noeud « mymaster » qui à l’IP 192.168.0.4, sur le port 6379, et qui nécessite un quorum de 2 pour l’élection d’un master.
Sentinel se charge de détecter à la fois les autres serveurs sentinels et redis.
Il mettra à jour lui-même son fichier de configuration.

Start

service redis-server start
service redis-sentinel start

Pour monitorer tout ça

Keepalived

ip address show

Ha-Proxy

hatop -s /var/run/haproxy/admin.sock

Redis

redis-cli -a 7xJtpLugAyu6hgPbuB3hX4R monitor
redis-cli -a 7xJtpLugAyu6hgPbuB3hX4R info replication

Sentinel

tail -f /var/log/redis/sentinal le viagra en vente libre.log

Et avec le client Redis.

redis-cli -p 26379 -a 7xJtpLugAyu6hgPbuB3hX4R sentinel masters
redis-cli -p 26379 -a 7xJtpLugAyu6hgPbuB3hX4R sentinel master mymaster
redis-cli -p 26379 -a 7xJtpLugAyu6hgPbuB3hX4R sentinel slaves mymaster
redis-cli -p 26379 -a 7xJtpLugAyu6hgPbuB3hX4R sentinel sentinels mymaster

Si le maître plante

Dans ce cas :

  1. Sentinel va marquer le maître comme « down »
  2. Sentinel va promouvoir un esclave en maître, choisi parmi les esclaves
  3. Ha-Proxy va détecter que le maître a changé et va basculer les connexions sur lui

Si l’ancien maître revient à la vie, Ha-Proxy le détactera à nouveau comme « L7OK », mais n’enverra pas de connexion dessus car il n’y a pas de répartition de charge dessus.
Il nous faudra modifier ça configuration en précisant le nouveau maître.

Références

https://blog.1q77.com/2015/02/redis-ha/
http://engineering.bloomreach.com/the-evolution-of-fault-tolerant-redis-cluster/
http://qiita.com/wellflat/items/8935016fdee25d4866d9
http://bencane.com/2013/11/12/installing-redis-and-setting-up-master-slave-replication/
https://support.pivotal.io/hc/en-us/articles/205309388-How-to-setup-HAProxy-and-Redis-Sentinel-for-automatic-failover-between-Redis-Master-and-Slave-servers
http://www.101tech.net/2014/08/08/highly-available-redis-cluster/

ET bien sure :

http://redis.io/topics/replication
http://redis.io/topics/sentinel

Publié dans haproxy, keepalived, linux, Mes docs, redis, Uncategorized | Marqué avec | Laisser un commentaire

Sécurisé un poil votre cluster Elasticsearch (round 2 : iptables)

Elasticsearch ça roxe. Ave un défaut, la sécurité c’est pas son truc.
A vous de la faire.

Mon problème est le suivant :

  1. 1 cluster Elasticsearch composé de 3 noeuds
  2. Tous dans le même réseau
  3. Avec d’autres machines
  4. Comment sécuriser à minima le cluster ES ?

ElasticSearchSecured

Pour l’accès au plugin head, j’ai opté pour la solution nginx décrite ici.

Par contre pour m’assurer que seul les noeuds elasticsearch discutent entre eux, et qu’ils ne sont accessibles que par le serveur Nginx, je fais appel iptables (!!)

apt-get install iptables iptables-persistent
vim /etc/iptables/rules.v4 
# Generated by iptables-save v1.4.21 on Wed Jul 29 23:22:59 2015
*filter
# par defaut je DROP ce qui arrive
:INPUT DROP [0:0]
# je route pas !!
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [45:6396]
-A INPUT -i lo -j ACCEPT
# je me coupe pas les pattes
-A INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 22 -j ACCEPT
# les noeuds se parlent sur le port 9300
-A INPUT -s 192.168.0.11 -p tcp -m tcp --dport 9300 -j ACCEPT
-A INPUT -s 192.168.0.12 -p tcp -m tcp --dport 9300 -j ACCEPT
-A INPUT -s 192.168.0.13 -p tcp -m tcp --dport 9300 -j ACCEPT
# c'est bidirectionnelle
-A INPUT -s 192.168.0.11 -p tcp -m tcp --sport 9300 -j ACCEPT
-A INPUT -s 192.168.0.12 -p tcp -m tcp --sport 9300 -j ACCEPT
-A INPUT -s 192.168.0.13 -p tcp -m tcp --sport 9300 -j ACCEPT
# le discover en multicast
-A INPUT -s 192.168.0.11 -p udp -m pkttype --pkt-type multicast --sport 54328 --dport 54328 -j ACCEPT
-A INPUT -s 192.168.0.12 -p udp -m pkttype --pkt-type multicast --sport 54328 --dport 54328 -j ACCEPT
-A INPUT -s 192.168.0.13 -p udp -m pkttype --pkt-type multicast --sport 54328 --dport 54328 -j ACCEPT
# nginx lui peut causer sur le port 9200
-A INPUT -s 192.168.0.10 -p tcp -m tcp --dport 9200 -j ACCEPT
# dns dés fois que ....
-A INPUT -s 192.168.0.1 -p udp -m udp --sport 53 -m state --state ESTABLISHED -j ACCEPT
-A INPUT -s 192.168.0.2 -p udp -m udp --sport 53 -m state --state ESTABLISHED -j ACCEPT
# a la fin je log et je drop
-A INPUT -j LOG --log-prefix "MYLOG:" --log-level 7
-A INPUT -j DROP
COMMIT
# Completed on Wed Jul 29 23:22:59 2015
Publié dans elasticsearch, linux, Mes docs, sécurité | Un commentaire