Un monde d'octets

To disable tracker3 on ubuntu, do this :

systemctl --user mask tracker-extract-3.service tracker-miner-fs-3.service tracker-miner-rss-3.service tracker-writeback-3.service tracker-xdg-portal-3.service tracker-miner-fs-control-3.service
tracker3 reset -s -r

puis pour controler :

tracker3 daemon

et vos devez obtenir quelque chose comme ca :

Miners:
25 avril 2022, 21:16:25:  ✗     File System          - Not running or is a disabled plugin

Les axes de questions

• Installation
• Architecture
• MAJ
• Backup/Restore
• Configuration
• Développement supplémentaire - shell / python / ansible
• Intégration dans le SI - Quand ? OU ? Comment ?
• PCA / PRA

Exemples

• Avez vous des plans d'architecture ?
• Pourriez vous expliciter cette partie du plan ?
• Comment est ce installé ? Docker ? Ansible ? Scripts ? Copie de VM Template ?
• Et dans ce cas, ou est stocké la configuration ? Dossier ? Http ? Git ?
• Comment distribuez vous vos configurations ? (script, puppet, ansible ?)
• Utilisez vous des certificats ssl ? quel type ? si letsencrypt, la configuration est faite via api (.well-known) ou par DNS (IN TXT). Le renouvellement est automatisé avec acme ?
• Avez vous des pages décrivant, pour chaque pan d'architecture, les configurations principales (et secondaires)
• Quel est votre process de MAJ ? Sur quelle base de temps ?
• Utiliser vous ces outils pour autre chose ? (script, puppet, ansible)
• Quelle est votre politique de sauvegarde (image de vm, sauvegarde de fichiers, sauvgarde bdd)
• Faites vous des tests de restauration périodiques ?
• Comment assurez vous le monitoring ? la réponse aux alertes ?
• Avez vous une haute disponibilité sur ce service ? de quel type ?
• Votre architecture est elle redondante ?

openssl s_client -starttls smtp \
                 -crlf -CAfile ca-certificates.crt \
                 -connect smtp.server.fr:25

ca-certificates.crt est l'autorité de certification du serveur distant, en cas de self-signed.

Depuis 4 jours j'ai accidentelement fait mes commits sur la mauvais branche.

Par chance, personne n'a commité en même temps que moi, j'ai donc pu procéder au nettoyage comme suit :

git reset --hard <sha>
git clean -f -d
git push -f

Et voila, la branch est revenue à l'état du <sha> spécifiée, tout propre !

Pour installer le node exporter de prometheus sur osx, faites confiance a homebrew :

brew install node_exporter

puis ajoutez les lignes suivantes a /usr/local/etc/node_exporter.args

--web.listen-adress :9101

Et démarrez le service :

brew services start node_exporter

Votre exporter est maintenant fonctionnel

Filter certwatch alert in audit.log and process it to audit2allow to build a corrective pp :

grep certwatch /var/log/audit/audit.log | audit2allow -M mycertwatch2

make the policy active :

semodule -i mycertwatch2.pp

Nous utilons la requete json suivante :

{
  "query": {
     "math_phrase" : {
	"text_entry" : "to be or not to be" 
     }
  }
}

puis vous pouvez interroger votre ES avec la requete suivante :

curl -H "content-type: application/json" <url> -d @<file.json>

Ayant mis les logs de container docker en json, j'ai installé filebeat pour shipper directement ceux-ci à elasticsearch. Seul bémol, c'est que filebeat met comme timestamp source, l'heure à laquelle il à récolté (harvest) les logs.

Pour corriger ceci, il faut passer par un process d'ingest spécifique qui modifiera le document.

Nous créons notre ingest avec la commande suivante :

curl -XPUT pvalois:xxxxxxxxx@10.10.31.60:9200/_ingest/pipeline/json_timestamp \
-H "Content-type: application/json" \
-d '{
    "processors": [
      {
        "set": {
          "field": "_source.@timestamp",
          "value": "{{json.time}}",
	  "ignore_failure": true
        }
      }
    ]
}'

Comme ou le voir celle-ci crée un ingest préprocesseur nommé "json_timestamp" qui copie le content de json.time dans _source.@timestamp, corrigeant ainsi l'heure de réception du message.

Cependant la création de cet ingest ne suffit pas, il faut notifier a filebeat de l'utiliser lors de la communication avec elasticsearch. Pour cela, nous configurons le /etc/filebeat/filebeat.yml comme suit :

output.elasticsearch:
  hosts: [pvalois:xxxxxxxx@10.10.31.60:9200]
  pipeline: json_timestamp

Et voila, nos messages envoyés via filebeat seront maintenant livré à notre processor json.timestamp et tout sera propre à l'importation, même si celle-ci est faite à posteriori.

journalctl -u logstash --since "10 minutes ago" -o json | jq . | tail -60

Bon pour commencer avec ceph, il est bon de trouver les éléments le composant, pour cela :

ceph node ls all

Ensuite les operations de contrôle de l'état de votre cluster ceph :

ceph health
ceph status
ceph -w 

Pour les opérations courantes mais qui n'arrivenent quand même pas tout le temps, je renvoie à l'operation guide ceph

ceph -w
ceph health detail
ceph osd df
ceph osd find
ceph osd blocked-by
ceph osd pool ls detail
ceph osd pool get rbd all

ceph pg dump | grep pgid
ceph pg pgid
ceph osd primary-affinity 3 1.0
ceph osd map rbd obj

Enable/Disable osd

ceph osd out 0
ceph osd in 0

PG repair

ceph osd map rbd file
ceph pg 0.1a query
ceph pg 0.1a 
ceph pg scrub 0.1a #Checks file exists on OSDs
ceph pg deep-scrub 0.1a #Checks file integrity on OSDs
ceph pg repair 0.1a #Fix problems

Delete osd

ceph osd tree
ceph osd out osd.1
sudo systemctl stop ceph-osd@1.service
ceph osd crush remove osd.1
reph auth del osd.1
ceph osd rm osd.1

osd primary-affinity
ceph pg pgid mark_unfound_lost revert|delete
ceph osd liost osdid --yes-i-really-mean-it

Ceph control

ceph daemon osd.1 config get osd_scrub_min-interval

ceph --admin-daemon socket-file-path command
/var/run/ceph/$cluster-$type.$id.asok
perf dump
config show
dump_historic_ops
scrub_path

Version check

ceph tell mon.* version
ceph tell osd.* version

Updates

Update one mon at the time

/usr/share/ceph-ansible/infrastructure-playbooks/rolling_updates.yaml

Ceph cluster flags

ceph osd set

noup    #Do not auto mark osd as up state
nopdown #Do not auto mark OSD as down state
noout   # Do not remove any osds from crush map. Used when performinig maintenance os parts of the cluster. Prevents crush from auto reblancing the cluster when OSDs are stopped.
noin    # Mons will mark running OSDs with the in state. prevents data from beeing auto allocated to that specific OSD
norecover # Prevents any recovery operations. Used when performing maintenance or a cluster shutdown
nobackfill # Prevents any backfill operation. Used when performing maintenance of a cluster. 
noscrub # No scrubbing operations. Scrubbing has performance impact on a PG on the OSD. If a OSD is too slow it will be marked as down.
nodeep-scrub 
norebalance # Prevents rebalancing from runniung

Crush map

ceph osd getcrushmap -o map.bin
crushtool -d map.bin -o map.txt
crushtool -i map.bin --test --show-mapping --rule=5 --num-rep 3
crushtool -c map.txt -o map.bin
ceph osd setcrushmap -i map.bin

ceph osd crush class ls
ceph osd crush tree
ceph osd crush rule ls

ceph osd pool create fast_ssd 32 32 onssd
ceph pg dump pgs_brief
ceph pg dump pgs_brief | grep ^46 #Pool ID
ceph osd lspools
ceph df

Buckets

ceph osd crush add-bucket default-pool root
ceph osd crush add-bucket rack1 rack
ceph osd crush add-bucket rack2 rack
ceph osd crush add-bucket hosta host
ceph osd crush add-bucket hostb host
ceph osd crush move rack1 root=default-pool
ceph osd crush move rack2 root=default-pool
ceph osd crush move hosta rack=rack1
ceph osd crush move hostb rack=rack2

ceph osd crush tree

OSD tools

ceph osd set-full-ratio 0.97
ceph osd set-nearfull-ratio 0.9
ceph osd dump

ceph osd getmap -o ./map.bin
osdmaptool --print ./map.bin
osdmaptool --export-crush ./crush.bin ./map.bin
crushtool -d ./crush.bin -o ./crush.txt 
crushtool -c ./crush.txt -o crushnew.bin
osdmaptool --import-crush ./crushnew.bin ./map.bin
osdmaptool --test-map-pgs-dump ./map.bin

OSD files

/var/lib/ceph/osd/ceph-1/current/0.1a_head/

Moving an OSD journal to an SSD

ceph osd set noout
systemctl stop ceph-osd@3.service
ceph-osd -i 3 --flush-journal
rm -rf /var/lib/ceph/osd/ceph-3/journal
ln -s /dev/sdc1 /var/lib/ceph/osd/ceph-3/journal
ceph-osd -i 3 --mkjournal
systemctl start ceph-osd@3.service
ceph osd unset noout

Placement gorup calc

Total palcement grous = (OSDs * 100) / Number of replicas
Start between 100 to 200 - Never go above 300+

ceph osd pool get rbd pg_num #Total number of pgs in the pool 
ceph osd pool get rbd pgp_num #Total number of of pgs used for hasing in the pool

Rados

rados -p rbd put file /etc/ceph/ceph.conf

Performance

iostat -x

OS Tuning

systcl net.ipv4.tcp_mem
systcl net.ipv4.tcp_rmem
systcl net.ipv4.tcp_wmem
vm.dirty_background_ratio
vm.dirty_ratio
vm.dirty_background_bytes
vm.dirty_bytes
vm.zone_reclaim_node
vm.swappiness
vm.min_free_kbytes

tuned-adm list
tuned-adm active
tuned-adm profile network-latency
tuned-adm profile network-throughput

Enable jumboframes

cat /sys/block/device/queue/scheduler
noop deadline [cfq]
sudo sh -c "echo deadline" > /sys/block/sdb/queue/scheduler"
Schedulers: 
  noop      # noop elevator does nothing. Turns a disk queue in to a FIFO. Select when back-end storage device can also reorder and merge request. Default inside VMs. Useful for devices suchs as SSDs that respond more quickly to request than they are likely to arrive.
  deadline  # groups queued I/O requests together into a read/write batches. Tries to provide a guaranteed latency for requests and prioritizes read requests over writes. Ceph choice for SATA and SAS drives.
  cfq       # Completely Fair Queueing. Multiple I/O classes and priorities to admin can prioritize process ovetr others when it comes to disk access. Handled by ionice command. 
  blk-mq    # Designed for spinning drives. Designed to handle storage with latenfcies of microseconds and missions of IOPS and large internal paralellism. 

osd_mkfs_options_xfs -f -i  size=2048
use noatime,largeio,inode64,swalloc

Design scaling

No more than six OSD journals per SATA SSD device.
No more than 12 OSD journals per NVMe device.

Warning: When an SSD or NVMe device used ot a host joiurnal fails, every OSD using it to host its journal also becomes unavailable.

Votre .aws/config et .aws/credentials dument remplis, vous pouvez connaitre vos couts pour une période avec la commande :

aws ce get-cost-and-usage --metrics UsageQuantity --granularity DAILY --time-period '{"Start":"2021-09-25","End":"2021-09-27"}' 

mais seulement si votre compte aws le permet

gpg --export --armor pascal.valois@free.fr > ~/cle-publique.asc
gpg --export-secret-keys --armor --output cle-privee.asc

scp *.asc target: 
ssh target 

gpg --import ~/cle-publique.asc 
gpg --import ~/cle-privee.asc 

Pour annuler le dernier commit (si commit accidentel ou mal fait)

• git reset --soft HEAD~1
• git push -f

Cela annule le dernier commit, et vous permet de reprendre votre travail proprement.

• All YAML files named with .yml extension
• Use 2 (two) spaces for each indent
• Use spaces around jinja variables (eg. var , not var)
• Variables that are internal to the role should be lowercase
• Keep roles self-contained. Roles should avoid including tasks from other roles whenever possible
• Plays should do nothing more than include a list of roles except where pre_tasks and post_tasks are required
• Use underscores as separators instead of dashes (e.g. my_role, not my-role)
• When defining paths (or concatenating them), do not include trailing slashes (e.g. my_path: /foo not my_path: /foo/, or my_path /bar not my_path bar)
• For variables that don't need to change or be overridden by the user, put them in vars/. For variables that would likely be overriden, put them in defaults/.

J'ai enfin écrit une configuration de docker qui me donne un résultat intéressant dans elasticsearch :

{
  "log-driver": "syslog",
  "log-opts":{
     "syslog-facility":"local6"
  },
  "live-restore": true,
  "metrics-addr" : "0.0.0.0:9323",
  "experimental" : true
}

Grace à cette configuration les logs des containers sont gratifié de la facility local6, et transittent par le syslog local. En paramétrant ce syslog avec la template json qu'il faut, et l'envoi a logstash, les logs seront envoyé a ES, et filtrable par la facilité. Mieux encore, il serait surement possible de passer par les mutate de logstash pour faire d'autres transformation, sur la simple reconnaissance de la facility.

Ansible est un outil génial, mais qui n'est pas non plus dépouvu de coquilles.

L'une des pires, est la transposition de stdout et stderr de la tâche exécutée sur le client, lors d'une remontée d'erreur. On obtient un paté ou les "\n" sont littéraux et cela donne une bouillie infame/.

Un truc connu, est de passer sa commande ansible dans un echo \-ne comme suit :

echo -ne "$(ansible-playbook .... )"

Mais cela reste pénible de toujours surcharger l'appel à ansible ainsi.

Récemment j'ai trouvé Ara, un outil génial qui se place en CALLBACK d'ansible, mais extrait tout une sommes de choses pertinentes ....

Et commencez a jouer :

pip3 install "ara[server]"
export ANSIBLE_CALLBACK_PLUGINS="$(python3 -m ara.setup.callback_plugins)"

ansible-playbook playbook.yaml

ara playbook list

Et pour la suite allez voir la doc

> ansible -m shell -a "host google.fr" all

proxy | CHANGED | rc=0 >>
google.fr has address 172.217.19.227
google.fr has IPv6 address 2a00:1450:4007:80c::2003
google.fr mail is handled by 30 alt2.aspmx.l.google.com.
google.fr mail is handled by 10 aspmx.l.google.com.
google.fr mail is handled by 40 alt3.aspmx.l.google.com.
google.fr mail is handled by 50 alt4.aspmx.l.google.com.
google.fr mail is handled by 20 alt1.aspmx.l.google.com.

openvas| CHANGED | rc=0 >>
google.fr has address 172.217.19.227
google.fr has IPv6 address 2a00:1450:4007:80c::2003
google.fr mail is handled by 40 alt3.aspmx.l.google.com.
google.fr mail is handled by 10 aspmx.l.google.com.
google.fr mail is handled by 20 alt1.aspmx.l.google.com.
google.fr mail is handled by 30 alt2.aspmx.l.google.com.
google.fr mail is handled by 50 alt4.aspmx.l.google.com.

nagios | CHANGED | rc=0 >>
google.fr has address 172.217.19.227
google.fr has IPv6 address 2a00:1450:4007:80c::2003
google.fr mail is handled by 30 alt2.aspmx.l.google.com.
google.fr mail is handled by 40 alt3.aspmx.l.google.com.
google.fr mail is handled by 20 alt1.aspmx.l.google.com.
google.fr mail is handled by 50 alt4.aspmx.l.google.com.
google.fr mail is handled by 10 aspmx.l.google.com.

Pour faire un paquet débian, il faut créer une arborescence qui répond a certaines règles :

timeofday-0.1-1.amd64/
timeofday-0.1-1.amd64/DEBIAN
timeofday-0.1-1.amd64/DEBIAN/postrm
timeofday-0.1-1.amd64/DEBIAN/preinst
timeofday-0.1-1.amd64/DEBIAN/prerm
timeofday-0.1-1.amd64/DEBIAN/control
timeofday-0.1-1.amd64/DEBIAN/postinst
timeofday-0.1-1.amd64/usr
timeofday-0.1-1.amd64/usr/local
timeofday-0.1-1.amd64/usr/local/bin
timeofday-0.1-1.amd64/usr/local/bin/tod

Le nom du package

"timeofday - 0.1 - 1 _ amd64" répond à la nomenclature suivante :

• nom du programme : timeofday
• version du programme : 0.1
• version du packet debian : 1
• architecture du logicle : amd64

Contenu du dossier DEBIAN

ce dossier est appelé le dossier de contrôle. Il contient un fichier "control" qui décrit le paquet et quelques impératifs :

Package: timeofday
Version: 0.1
Architecture: amd64
Maintainer: Pascal Valois <pascal.valois@free.fr>
Description: A simple program that give you current time and date
Depends: libc6

Les dépendances peuvent inclure une version entre parenthèse, ex (>= 2.16), et sont séparées par des virgules.

Les fichiers preinst, postinst, prerm, et postrm, sont des scripts shell, qui sont exécutés aux moments opportuns des installation et suppressions.

Leurs droits doivent être 0755.

Il est possible d'utiliser des templates de questions d'installation et désinstallation, mais nous n'iront pas jusque la pour ce post.

Autres dossiers

Les autres dossiers sont une architecture LFS standard, ou nous copions les fichiers à inclure dans un paquets, comme ils le seraient dans un tar.

Le dossier "." qui précède cette architecture, sera copié dans le "/" de la machine installé.

Création du package

Une fois tout cela fait, nous pouvons créer un package debiant avec la commande

dpkg-deb --build --root-owner-group timeofday-0.1-1.amd64

Openldap stocke sa configuration sous forme de ldif internes, ce qui permet une modifications a chaud de ceux-ci, et nécessitant seulement de faire des requêtes ldap pour les lire/modifier :

Obtenir le niveau de logs actuel

Sur l'hôte qui exécute openldap, exécuter :

sudo ldapsearch -Y external -H ldapi:/// -b cn=config "(objectClass=olcGlobal)" olcLogLevel

Passer le logs au niveau "stats"

Créer le fichier log-stats.ldif content :

dn: cn=config
changeType: modify
replace: olcLogLevel
olcLogLevel: stats

et appliquez le comme suit :

sudo ldapmodify -Y external -H ldapi:/// -f log-stats.ldif

Et voila, vous pouvez maintenant tracer les requêtes faites à votre serveur ldap pour voir l'usage qu'il en est fait !

pour ajouter une ip statique manuelle en ligne de commande avec network manager, il faut passer par nmclin :

sudo nmcli con edit type ethernet con-name eth0

puis taper les commandes :

set ipv4.addresses 192.168.122.88/24
set ipv4.method manual
save
quit

et voila, le setting est permanent !

Voici une facon de supprimer l'output de certains blocs en python, avec la notion de context manager, et l'utilisation de with pour limiter la portée de l'action :

from contextlib import contextmanager
import sys, os

@contextmanager
def suppress_stdout():
    with open(os.devnull, "w") as devnull:
        old_stdout = sys.stdout
        sys.stdout = devnull
        try:  
            yield
        finally:
            sys.stdout = old_stdout

Et maintenant, en profitant du context management, nous pouvons supprimer les sorties quand nous le souhaitons :

print("Now you see it")
with suppress_stdout():
    print("Now you don't")

python3 -m http.server 8000

Python créera un serveur web dont la racine est le répertoire courant et servira l'arborescence, ce qui permet de télécharger des fichiers et de tuer ce micro serveur dans la foulée.

screen est un émulateur de terminal très utile pour garder une session détachée et rattachable à la volée.

De plus lors d'un accès via ssh, la fin de connexion détache automatiquement le screen, ce qui fait que l'on peut se reconnecter, rattacher la session, et reprendre ou nous en étions.

Cependant, screen nomme ses sessions "ésotériquement" :

{pid}-{pts}-{hostname}

Pour lancer une sesson avec un nom particulier, nous utilisons l'option -S :

screen -S foobar

Pour renommer une session, il faut préciser la session à renommer et le nouveau nom :

screen -S {pid} -X sessionname foobars

docker ps --filter status=exited | awk '{if (NR>1) print $1}' | xargs docker rm