Ajouter une repository PPA derrière un proxy http

0

Voici le SLS que j’ai utilisé :

http_proxy:
  environ.setenv:
    - value: 'http://:3128'

https_proxy:
  environ.setenv:
    - value: 'http://:3128'

python-apt:
  pkg:
    - installed

debconf-utils:
  pkg:
    - installed

software-properties-common:
  pkg:
    - installed

webupd8-repo:
    cmd.run:
        - name: 'add-apt-repository ppa:webupd8team/java'
        - unless: /etc/apt/sources.list.d/webupd8team-java-trusty.list
        - require_in: oracle-java8-installer

oracle-java8-installer:
    debconf.set:
        - name: oracle-java8-installer
        - data:
            'shared/accepted-oracle-license-v1-1': {'type': 'boolean', 'value': True}
    pkg.installed:
        - refresh: True
        - require:
            - cmd: webupd8-repo

Solr_Logo_on_white

Installation Solr sur Debian 8

0

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
Pingdom_perso

Dans ma cave, cave, cave

0

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 😉

pfSense_bridge_ha

Firewall transparent en haute-disponibilité avec PfSense

0

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 Statesactivé
Synchronize InterfaceSYNC
pfsync Synchronize Peer IP10.10.10.2

Configuration Synchronization Settings (XMLRPC Sync)

Synchronize Config to IP10.10.10.2
Remote System Usernameadmin
Remote System Password*******
Synchronize Users and Groupscoché
Synchronize rulescoché
Synchronize Firewall Schedulescoché
Synchronize aliasescoché
Synchronize Static Routescoché
Synchronize Virtual IPscoché

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

Redis-HA-haproxy-sentinel

Redis haute-disponibilité

0

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.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

ElasticSearchSecured

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

1

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

Sécurisé un poil votre cluster Elasticsearch (round 1 : Nginx)

1

Mettre un cluster elasticsearch en public, c’est mal.
Et la sécurité c’est pas son truc à ES.

Heureusement nginx est là (pour le reste il y a iptables

apt-get install nginx apache2-utils

Par contre pour accéder au plugin head de votre cluster ES, c’est une page blanche.
Heureusement nginx est là.
Voici par exemple un bout de conf à coller dans un des sites nginx (dans /etc/nginx/site-enabled/).

upstream elasticnodes {
    server 192.168.0.11:9200;
    server 192.168.0.12:9200;
    server 192.168.0.13:9200;

    keepalive 15;
}

server {
    listen 443;
    server_name logs.secure.net;

    ssl on;
    ssl_certificate /etc/ssl/secure.net/logs.secure.net.pem;
    ssl_certificate_key /etc/ssl/secure.net/logs.secure.net.key;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!MD5;

    error_log   /var/log/nginx/elasticsearch-errors.log;
    access_log  /var/log/nginx/elasticsearch.log;

    location /_plugin/head/dist {
        root /usr/share/nginx/html;
    }

    location / {

        rewrite ^/(.*) /$1 break;

        proxy_ignore_client_abort on; 
        proxy_pass http://elasticnodes;
        proxy_redirect off;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header X-Real-IP   $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_pass_header Access-Control-Allow-Origin;
        proxy_pass_header Access-Control-Allow-Methods;
        proxy_hide_header Access-Control-Allow-Headers;
        add_header Access-Control-Allow-Headers 'X-Requested-With, Content-Type';
        add_header Access-Control-Allow-Credentials true;

        auth_basic  "Patte Blanche ?";
        auth_basic_user_file /etc/nginx/conf.d/search.htpasswd;
    }
}

server {
    listen 80;
    server_name logs.secure.net;
    return 301 https://$host$request_uri;
}

Ensuite il nous reste à installer le plugin head d’Elasticsearch sur tous les noeuds.

Pour la création du fichier de password :

htpasswd -c /etc/nginx/conf.d/search.htpasswd monuser

Installation des VMware Tools pour FreeBSD 10.x sous ESXi 5.1 et 5.5

0

Installer quelques paquets


pkg install perl5
pkg install wget
pkg install compat6x-amd64

Monter le CROM des VMware Tools


mount -t cd9660 /dev/cd0 /mnt/cd /home/infra/
tar xvfz /mnt/vmware-freebsd-tools.tar.gz
sync
umount /mnt/
cd vmware-tools-distrib/

Récupérer des patchs


cd /tmp
wget http://ogris.de/vmware/vmware-tools-distrib.diff
wget http://ogris.de/vmware/vmblock-only.diff
wget http://ogris.de/vmware/vmmemctl-only.diff

Appliquer les patch


cd /home/hugues/vmware-tools-distrib
patch -p 1 < /tmp/vmware-tools-distrib.diff

vmblock


cd lib/modules/source/vmblock
tar xvfz vmblock.tar
cd vmblock-only/patch -p 1 < /tmp/vmblock-only.diff make make install

vmmemctl


tar xvfz vmmemctl.tar
cd ../vmmemctl-only/patch -p 1 < /tmp/vmmemctl-only.diff make make install

Modification du path de perl

Au profit de /usr/local/bin/perl.


cd ../../../..
vim vmware-install.pl
vim /usr/local/bin/vmware-config-tools.pl

Installation des VMwareTools


./vmware-install.pl

Références

http://ogris.de/vmware/freebsd10.html
Aarchives des patchs : http://hugues.lepesant.com/stuff/freebsd/esxi5x/

Flumotion sur Ubuntu 14.04

0

Flumotion est un logiciel de streaming multi-format (i.e. audio et/ou vidéo) open source.

Afin de répondre à une problématique client – I Love Developpers ™ – je me suis penché sur son installation sous Ubuntu 14.04 LTS 64bits.

Je me suis basé sur l’article trouvé sur Serenux

Je rajoute juste 3 lignes de commande après l’installation pour prévenir de la mise à jour des 3 paquets anciens paquets Python.


# apt-mark hold python-twisted-bin
# apt-mark hold python-twisted-core
# apt-mark hold python-twisted-web

Et le tour est joué.

Installation de l’agent Nagios sur VCSA 5.5

0

Installation des repository

Se connecter en SSH sur la VCSA5.5


zypper addrepo -f http://download.opensuse.org/distribution/11.2/repo/oss/ opensuse

Vérifier la configuration des nouveaux repos

zypper repos -d

Rafraichir les sources

zypper refresh

Installer Nagios-NRPE

# zypper install nagios-nrpe-client

Activer le service

# chkconfig nrpe on

Configuration de l’agent Nagios

Editer les fichier /etc/nagios/

Lancer le service

# /etc/init.d/nrpe start

Autoriser l’accès distant à l’agent

Ajouter la ligne suivante à la fin du fichier « /etc/hosts.allow » pour autoriser votre serveur Nagios.

nrpe: 192.168.0.10 : ALLOW
Haut de page