How to mount cifs [ansible]

Simple ansible play too mount samba/cifs share using credential file.

- name: "mount share"
    mount:
     state: "mounted"
     fstype: "cifs"
     name: /mnt/win/
     src: "//192.168.1.86/instshare"
     opts: "credentials=/root/.smb_passwords,file_mode=0644,dir_mode=0755,gid=root,uid=root"

Credential file looks like

# cat /root/.smb_passwords
username=my_name
password=strong_password

It’s also usefull to umount folder

  - name: Unmount
    mount:
     path: /mnt/win/
     state: unmounted

How to configure DNSSEC with BIND

DNSSEC
DNSSEC jednoducho povedané zabraňuje podvrhnutiu falošných informácií v rámci doménovej infraštruktúry internetu, a teda zabraňuje spojeniu Vášho prehliadača s falošnou webstránkou s inou skutočnou IP adresou. Takáto by od vás na princípe phishingu mohla vylákať osobné, prihlasovacie či iné citlivé údaje (napr. sa bude tváriť ako webstránka vašej banky). DNSSEC poskytuje dodatočnú úroveň bezpečnosti, vďaka ktorej si webový prehliadač môže overiť, či je odpoveď na jeho DNS dopyt správna a teda či nebola niekde po ceste útočníkom pozmenená. Používateľ si viditeľnosť tohto overenia môže do všetkých najpoužívanejších webových prehliadačov buď pridať alebo ju už rovno priamo podporujú.

DNSSEC Resource Records
DNSSEC vyžaduje niekoľko RR.

• DNSKEY Drží verejný kľúč, ktorý prekladatelia používajú na overenie.
• RRSIG Existuje pre každý RR a obsahuje digitálny podpis záznamu.
• DS – Delegation Signer – tento záznam existuje v nameserveroch TLD. Ak je doménou sitel.sk názov domény, TLD je „sk“ a jej menné servery sú a.gtld-servers.net., B.gtld-servers.net. až do m.gtld-servers.net . Účelom tohto záznamu je overiť pravosť samotného DNSKEY.

 

Ako prvé zapneme DNSSEC v konfiguračnom súbore /etc/named.conf v sekcii Options

dnssec-enable yes;
dnssec-validation yes;

Vytvoríme Zone Signing Key(ZSK)

#dnssec-keygen -a NSEC3RSASHA1 -b 2048 -n ZONE dubnik.sk

Vytvorime Key Signing Key(KSK)

#dnssec-keygen -f KSK -a NSEC3RSASHA1 -b 4096 -n ZONE dubnik.sk

V adresári v ktorom sme generovali kľúče budeme mať teraz 4 súbory. Privátny/verejný pár kľúčov ZSK a KSK. Teraz pridáme verejné kľúče do zónového súboru.

for key in `ls Kdubnik.sk*.key`
do
echo "\$INCLUDE $key">> /var/named/data/external/dubnik.sk.zone
done

Teraz môzeme podpísať zónu. Ako prvé si pripravíme salt pre crypto sifry. Vygenerovaný salt následne použijeme pri podpisovaní zónového súboru.

# head -c 1000 /dev/random | sha1sum | cut -b 1-16
a40157365d69a80d

Ako posledny krok vramci konfiguracie DNSSECU je podpísanie našej domeny.

# dnssec-signzone -A -3 a40157365d69a80d -N INCREMENT -o dubnik.sk -t /var/named/data/external/dubnik.sk.zone 

Výsledkom podpisania zóny je nový zónový súbor sitel.sk.zone.signed. Upravíme teda konfiguračný súbor bindu aby používal tento podpísaný zonový súbor.

zone "dubnik.sk" IN {
                 type master;
                 file "data/external/dubnik.sk.zone.signed";
                 also-notify { 192.168.200.66; };
                 allow-transfer { 192.168.200.66; };
                 allow-update { none; };};

A reloadneme bind server.

#rndc reload

Pre konfiguráciu slave servera stačí zapnúť dnssec v súbpre named.conf a zmeniť pôvodný zónový súbor na signed súbor a reloadnúť bind. Slave si potiahne config z mastra a DNSSEC bude funkčný aj na slave servery.

Posledným krokom je konfigurácia na strane registrátora. Je potrebné pridať DS záznamy. Záznamy sa nám vygenerujú pri podpisovaní zóny do aktuálneho adresára a stači ich len pridať na stránke SK-NIC. DS záznamy si pozrem následovne.

# cat dsset-dubnik.sk. 
dubnik.sk.  IN DS 16248 7 1 6455A604C2F55D42649CD044171136277B43A2A3
dubnik.sk.  IN DS 16248 7 2 64C4E824E33DC65D0788CA93AEFA216F035FF354ED434EDAA4B77E57 0E26F397

 
Správnosť a dôveryhodnosť konfigurácie si môžem overiť na stránke https://dnssec-analyzer.verisignlabs.com/

Este nesmieme zabudnut ze dlzka platnosti podpisanej zony je 30 dni. Preto je vhodne imlpementovat skript na automaticke podpisovanie zony. Ja pouzivam ansible play v awx ktory podpisuje zonu kazdy den.

- hosts: ns-01
  remote_user: root
  vars:
    date: "{{ lookup('pipe', 'date +%Y%m%d') }}"
  tasks:

  - name: resign keys"
    command: /bin/bash /root/scripts/dnssec-resign.sh

  - name: update internal serial
    replace:
      dest: /var/named/data/external/{{ item  }}.zone
      regexp: '.*serial*'
      replace: '\t\t\t\t\t\t\t{{ date }}01 ; serial'
    with_items:
    - dubnik.sk
    - dubnik.com
    - dubnik.it
    
  - systemd:
       name: named
       state: reloaded


- hosts: ns-02
  remote_user: root
  tasks:

  - systemd:
       name: named
       state: reloaded

A samotny dnssec-resign.sh skript

#!/bin/bash
zones="$(ls /root/keys)"
for line in $zones; do
cd /root/keys/$line
/usr/sbin/dnssec-signzone -A -3 $(head -c 1000 /dev/urandom | sha1sum | cut -b 1-16) -N increment  -o $line -t /var/named/data/external/$line.zone;
done

How to copy multiple files (wildcard) [ansible]

Jednoduchy play na skopirovanie viacerych adresarov medzi servermi.

- hosts: {{ my_host}}
  user: root
  tasks:
  - name: copy certs
    copy:
       src: "{{ item }}"
       dest: "/etc/letsencrypt/live/dubnik.sk/"
    with_fileglob:
       - "/etc/ansible/files/dubnik/*.pem"

  - systemd:
       name: restart http service
       state: restarted

How to monitor nginx status

Na real-time monitoring stavu nginx je idealne pouzit tool ngxtop. Ak vsak chcem viest historicke statistiky o urovni zatazenia nginx servera je moznost pouzit stavany modul nginx http_stub_status.

Ako prve skontrolujeme ci je nas nginx skompilovany s podporou http_stub_status. Ak nam prikaz vrati nasledujuci riadok mozeme pokracovat v konfiguracii.

# nginx -V 2>&1 | grep -o with-http_stub_status_module
with-http_stub_status_module

Vytvorime noveho virtual hosta. Kedze mam rad poroiadok v konfguracii vytvorim si virtual hosta status.dubnik.sk a nastavim mu A-ckovy DNS zaznam. Nasledne vytvorim konfiguracny subor status.dubnik.sk.conf a ulozim ho do adresara /etc/nginx/conf.d/

# cat /etc/nginx/conf.d/status.conf 
server {
    listen       80;
    server_name  status.dubnik.sk;


    location /stub_status {
        stub_status on;
        access_log off;
        allow localhost;
        deny all;
    }
}

Skontrolujem konfiguracny subor a reloadnem sluzbu.

# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
# systemctl reload nginx

A mozem pouzit nastroj curl na ziskanie udajov z nginx serveru.

# curl http://status.dubnik.sk/stub_status
Active connections: 4 
server accepts handled requests
 1403 1403 2748 
Reading: 0 Writing: 2 Waiting: 2 

How to nginx reverse proxy cluster

V tomto navode sa pozreme na konfiuracie vysoko dostopneho reverzneho proxy postaveneho na NGINX. Na riesenie bude pouzity pacemaker stack a samotny nginx.

Pacemaker stack
V súčasnosti predstavuje najpouživanejší nástroj na realizáciu klastra s otvoreným zdrojovým kódom. Pacemaker stack spája dve samostatné služby Corosync a Pacemaker. Corosync je správcu klastra a je zodpovedný za členstvo uzlov v klastri. Pacemaker je správca zdrojov klastra a je mozog celého klastra, ktorý spracováva a reaguje na udalosti týkajúce sa klastra.

Corosync
Služba ktorá zabezpečuje základnú komunikáciu medzi uzlami klastra. Corosync používa protokol totem na sledovanie dostupnosti ostatných uzlov. Uzly si medzi sebou v stanovenom intervale posielajú token (uzol potvrdzuje prijatie tokenu a posiela nový), aby uzol vedel o dostupnosti zvyšných uzlov v klastri. Ak uzol po uplynutí stanoveného krátkeho časového intervalu nedostane naspäť token, uzol je vyhlásený za stratený. Akonáhle je uzol vyhlásený za stratený, zostávajúce uzly vytvárajú nový klaster. Ak zostane dostatočný počet uzlov na vytvorenie kvóra (nadpolovičná väčšina), nový klaster pokračuje v poskytovaní služieb. V prípade dvoj uzlového klastra je kvórum vypnuté a obidva uzly môžu pracovať samostatne. Samotný corosync sa stará iba o členstvo uzlov v klastri, posielaní správ (tokenov) medzi uzlami a kvórum. Čo sa stane po vytvorení nového klastra má na starosti správca zdrojov

Pacemaker
Pokročilý, škálovateľný správca zdrojov pre vysoko dostupné riešenia klastra. Pacemaker beží nad komunikačnou vrstvou klastru Corosync. Podporuje “N-uzlový” klaster s pokročilými možnosťami pre správu zdrojov. Pacemaker slúži na inicializáciu a správu služieb pri zmene stavu klastra. Umožňuje aj periodické monitorovanie zdrojov.

Instalacia
Ako prove nainstalujeme softver s oficialneho repo na obidva uzly.

# yum install pcsd corosync pacemaker pcs-snmp fence-agents-vmware-soap nginx

Vytvorenie klastra
Ako prve skontrolujeme ze obidva uzly maju nastaveny spravny cas, idealne pouzivat ntp client a skontrolujeme ze existuje spravny dns zaznam pripadne maju zaznal ulozeny v subore /etc/hosts
Nastavime heslo uzivalelovi hacluster na obidvoch uzloch. Tymto uctom konfigurejeme cluster pouzitim nastroja pcs

# passwd hacluster

Po nastaveni hesla na uzle z kotreho ideme konfigorovat klaster prevedieme autentifikaciu obidvoch uzlov.

# pcs cluster auth lb-01.dubnik.sk lb-02.dubnik.sk

Teraz mozeme vytvorit klaster. Tento prikaz vytvori konfiguracny subor /etc/corosync/corosync.conf. Ak potrebujeme nieco zmenit mozeme dat dolpnujuce parametre do prikazu, pripadne rucne zeditovat spominany conf subor.

# pcs cluster setup --name lb-cluster  lb-01.dubnik.sk lb-02.dubnik.sk

Teraz mozeme inicializovat a spustit cluster

# pcs cluster start --all

V tomto stadiu je vytvoreny klaster uzly spolu komikuju posielanum tokenov ale samotny kalster nic nerobi. Na to aby klaster plnil nejaku ulohu musim nakonfigurovat zdroje. V pripade vysoko dostupneho reverzenho proxy v rezime active/passive potrebujeme plavajucu ip adresu a sluzbu nginx. Oba zdroje budu aktivne vzdy iba na jednom uzle. Este predtym je vsak potrebne zabezpecit fencing teda ohradenie uzla. Ohradenie je súbor metód ako dočasne vylúčiť uzol z klastra a zabrániť tak poškodeniu
zdieľaných dát. Za normálnych okolnosti uzly spolu komunikujú a vymieňajú si medzi seboutoken a dávajú si vedieť že uzol je dostupný a zdravý. Ak však nastane výpadok uzla a uzol v klastri nedostane v dohodnutom čase odpoveď pokúsi sa neodpovedajúci uzol ohradiť.V momente keď uzol stratí token zostávajúci členovia klastra nevedia v akom stave je neodpovedajúci uzol a preto ho treba zastaviť. Najčastejším spôsobom je reštart systému. Na ohradenie existuje cela rada nastrojov ako iLO, IMM, APC atd. V mojom pripade bezia nginx servery v prostredi vsphere od vmware-u a preto pouzijem agent vmware-soap.
Vytvorime teda zdroje na ohradenie uzlov, pre kazdy uzol jeden zdroj.

pcs stonith create lb-01-vmware-fence fence_vmware_soap ipaddr=vcenter.dubnik.sk ipport=443 ssl=1 ssl_insecure=1 login=administrator@vcenter.dubnik.sk passwd=passw0rd pcmk_host_map="lb-01.dubnik:lb01"

pcs stonith create lb-02-vmware-fence fence_vmware_soap ipaddr=vcenter.dubnik.sk ipport=443 ssl=1 ssl_insecure=1 login=administrator@vcenter.dubnik.sk passwd=passw0rd pcmk_host_map="lb-02.dubnik.sk:lb02"

Konfiguracia je priamociara a jednotlive direktivy hovoria sami za seba. Direktiva pcmk_host_map mapuje hostname (ktory bol pouzity pri vytvoreni clustera) a meno VM vo vcentry. Po vytvoreni nastavime obmedzenia aby sa zdroje spustali primarne na uzloch ku ktorym patria.

#pcs constraint location lb-01-vmware-fence prefers lb-01.dubnik.sk INFINITY

#pcs constraint location lb-02-vmware-fence prefers lb-02.dubnik.sk INFINITY

Po vytvoreni skontrolujeme ci zdroje bezia a ci su na spravnom uzle

[root@lb-01 ~]# pcs status | grep -i fence
 lb-01-vmware-fence	(stonith:fence_vmware_soap):	Started lb-01.dubnik.sk
 lb-02-vmware-fence	(stonith:fence_vmware_soap):	Started lb-02.dubnik.sk

Ak zdroje na ohradenie uspesne bezia dporucujem vyskusat aj manunalne ohradenie oboch uzlov nasedujicim prikazom. Uzol bude ohradeny a dojde k restartu uzla.

pcs stonith fence lb-02.dubnik.sk
Node: lb-02.dubnik.sk fenced

A mozeme vidiet aj vo vcentry ze VM bola restartnuta na poziadanie.

Teraz je prvotna konfiguracia klastra pre spravne fungovanie dokoncena a mozeme pridat sluzby aby nas klaster aj realne nieco robil.Vysoká dostupnosť klastra je realizovaná plávajúcou virtuálnou adresou. Aktivny uzol ma priradenu tuto adresu a na tuto adresu je smerovana http/s komunikacia. V pripade vypadku aktivneho uzla si IP adresu prevezme povodne pasivny uzol a stane sa aktivnym. Vytvorime zdroj pre virtualnu IP adresu.

# pcs resource create lb_virtual_ip ocf:heartbeat:IPaddr2 ip=10.20.20.15 cidr_netmask=24 op monitor interval=20s

Ako dalsi zdroj vytvorime spustenie sluzby nginx

# pcs resource create lb_nginx_service systemd:nginx op monitor interval=20s

Teraz zostava nastavit obmedzenia aby sa zdroje spusali spolocne a vzdy iba na jednom uzle. Vyhodne je vytvorit skupinu zdrojov ktora definuje zdroje ktore maju bezat spolu a zabezpeci aj spravne poradie spustenia.

# pcs resource group add lb_resource_group lb_virtual_ip lb_nginx_service

A nastavime obmedzeie pre skupinu aby primarne bezala na uzle lb-01.

# pcs constraint location lb_resource_group prefers lb-01.dubnik.sk INFINITY

Tymto je konfiguracua klastra dokoncena a stav klastra mozeme skontrolovat oblubenym prikazom

Cluster name: lb-cluster
Stack: corosync
Current DC: metoo-ba-vmlx-lb-02.metoo.sk (version 1.1.19-8.el7_6.1-c3c624ea3d) - partition with quorum
Last updated: Mon Dec 24 00:19:02 2018
Last change: Thu Dec 20 23:17:10 2018 by hacluster via crmd on metoo-ba-vmlx-lb-02.metoo.sk

2 nodes configured
4 resources configured

Online: [ lb-01.dubnik.sk lb-02.dubnik.sk ]

Full list of resources:

 lb-01-vmware-fence	(stonith:fence_vmware_soap):	Started lb-01.dubnik.sk
 lb-02-vmware-fence	(stonith:fence_vmware_soap):	Started lb-02.dubnik.sk
 Resource Group: lb_resource_group
     lb_virtual_ip	(ocf::heartbeat:IPaddr2):	Started lb-01.dubnik.sk
     lb_nginx_service	(systemd:nginx):	Started lb-01.dubnik.sk

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

Na zaver doporucujem otestovat klaster nejakymi nahodnymi restartami uzlov aby sme mali prehlad o tom ako sa klaster sprava. V kazdom pripade by sa mal vzdy zotavit.