Table des matières
- 2026:
- 2025:
4 billet(s) pour juillet 2026
| Procédure simple augmentation de la SWAP | 2026/07/17 15:49 | Jean-Baptiste |
| Exemple git clone avec Ansible | 2026/07/16 14:47 | Jean-Baptiste |
| Windows exe - Comparaison de fichiers binaires | 2026/07/16 10:25 | Jean-Baptiste |
| Pb git | 2026/07/01 17:36 | Jean-Baptiste |
Contrôle parental - Fermer la session après une certaine heure
Avec une crontab
A faire : Notification de l'utilisateur
export EDITOR=vim crontab -e
00 00 * * * /usr/bin/skill -TERM -u toto #00 00 * * * /sbin/shutdown now
Avec SystemD
/etc/systemd/system/safe-hours-for-kids.service
[Unit] Description=Safe hours for kids Service Wants=network.target After=network.target [Service] #ExecStart=bash -c '/usr/bin/date >> /tmp/plop.txt' ExecStart=/usr/sbin/shutdown -h now Type=oneshot RemainAfterExit=no [Install] WantedBy=multi-user.target
/etc/systemd/system/safe-hours-for-kids.timer
[Unit] Description=Run always between 23:00 and 23:59 [Timer] #OnBootSec=15min #OnUnitActiveSec=1w # DayOfWeek Year-Month-Day Hour:Minute:Second #OnCalendar=*-*-* 00,22..23:*:00 OnCalendar=*-*-* 23:00..23:59 [Install] WantedBy=timers.target
systemd-analyze calendar "23:00..03:00" systemd-analyze verify /etc/systemd/system/safe-hours-for-kids.service systemd-analyze verify /etc/systemd/system/safe-hours-for-kids.timer systemctl daemon-reload systemctl stop --now safe-hours-for-kids.timer systemctl enable --now safe-hours-for-kids.timer systemctl status safe-hours-for-kids.timer
Pb podman - network - netns namespace - duplicate default gateway
Voir :
Voir aussi :
J’ai constaté un bug sur Podman.
[root@srv1 ~]# lsns -t net | sed 1d | awk '{print $4}' | xargs -L1 -I% bash -c 'echo % ; time nsenter -t % -n host target'
1
target.acme.local has address 192.168.64.163
real 0m0.023s
user 0m0.004s
sys 0m0.003s
51826
target.acme.local has address 192.168.64.163
real 0m0.015s
user 0m0.003s
sys 0m0.003s
51812
target.acme.local has address 192.168.64.163
real 0m0.019s
user 0m0.003s
sys 0m0.003s
52103
target.acme.local has address 192.168.64.163
real 0m5.012s
user 0m0.003s
sys 0m0.005s
52376
target.acme.local has address 192.168.64.163
real 0m5.014s
user 0m0.006s
sys 0m0.002s
52579
target.acme.local has address 192.168.64.163
real 0m0.014s
user 0m0.005s
sys 0m0.002s
Ces délais élevés de trois voir cinq secondes surviennent aléatoirement, ce n’est pas systématique.
/usr/src/app # ping 10.131.18.1 PING 10.131.18.1 (10.131.18.1): 56 data bytes 64 bytes from 10.131.18.1: seq=1 ttl=254 time=2.925 ms 64 bytes from 10.131.18.1: seq=2 ttl=254 time=1.741 ms ^C --- 10.131.18.1 ping statistics --- 3 packets transmitted, 2 packets received, 33% packet loss round-trip min/avg/max = 1.741/2.333/2.925 ms
Alors que le ping de cette même adresse sur l’hôte est OK.
/usr/src/app # ip r default via 10.89.0.1 dev eth0 default via 10.89.1.1 dev eth1 10.89.0.0/24 dev eth0 scope link src 10.89.0.3 10.89.1.0/24 dev eth1 scope link src 10.89.1.2
La table de routage est étrange
Solution provisoire
[root@srv1 ~]# lsns -t net
NS TYPE NPROCS PID USER NETNSID NSFS COMMAND
4026531992 net 320 1 root unassigned /usr/lib/systemd/systemd --switched-root --system --deserialize 18
4026532530 net 1 51826 docker unassigned redis-server *:6379
4026532603 net 2 51812 docker unassigned /usr/sbin/dnsmasq -u root --conf-file=/run/user/1003457/containers/cni/dnsname/nginx-nodejs-redis_redisne
4026532668 net 3 52103 docker unassigned npm
4026532733 net 2 52376 docker unassigned npm
4026532799 net 4 52579 docker unassigned rootlessport
unshare -n /bin/bash nsenter -t 52103 -n bash ip route del 0.0.0.0/0 via 10.89.1.1
Comme il y avait deux passerelles par défaut (et que cela n’est pas cohérent) on en supprime une. Il convient de faire la même chose pour les autres containers.
Reste à trouver une solution parraine. Peut-être est-ce juste un problème de conf.
Autres
podman ps -p --ns
Notes SSOT - source unique de vérité
source unique de vérité / source unique de référence / système d'enregistrement principal
Voir - Vidéo :
- https://www.youtube.com/watch?v=NeqzPdjOELA Nautobot Next: Guided Video Series - SSoT Application
- SSOT en programmation https://www.youtube.com/watch?v=O-zPsGqbGkc
Voir :
Voir aussi :
- System of Record (SOR) https://en.wikipedia.org/wiki/System_of_record
- Master Data Management
Qu’est-ce qu’une source unique de vérité (SSOT) ?
Une source unique de vérité (en anglais, Single Source of Truth ou SSOT) est un concept de gestion des données où une organisation vise à centraliser toutes les données critiques dans un référentiel unique et fiable. Cela signifie que toutes les parties prenantes accèdent aux mêmes informations exactes et à jour, éliminant ainsi les disparités et les contradictions entre différentes versions de l’information. La source unique de vérité est essentielle pour assurer la cohérence, l’intégrité et la fiabilité des données au sein d’une entreprise.
It’s not a specific tool or software. It’s a state of being for your company’s information. In technical terms, SSOT architecture means that every data element is mastered (or edited) in only one place. If you want to update a customer’s email address, there’s exactly one place to do it. That change then propagates everywhere else that needs that information.
Souce : https://www.glitter.io/blog/knowledge-sharing/single-source-of-truth
Voir :
Voir :
- ERP
- CRM
- Customer Data Platform (CDP)
- CMDB
- Git / VCS
- Human resources management system (HRMS) ; human resources information system (HRIS) ; human capital management (HCM)
- Internal wiki
- Intranet
- Knowledge bases / knowledge repository
- Data Center Infrastructure Management, DCIM)
- Device Inventory
- IPAM
- Network Device Properties
- Config template ?
- Data silos
- Inconsistent terminology
- multiple technology instances
- Manual inputs
Avantages :
- Une même logique de lecture s'applique à tous les canaux
- Les écarts entre outils sont cadrés et compris
- Les budgets sont arbitrés sur une base commune et défendable
- Les équipes s'appuient sur le même centre de vérité
- Les chiffres sont lus avec les mêmes règles
- Les décisions reposent sur une lecture partagée de la performance
- Le marketing et les Sales parlent le même langage
- La qualité est lue sur des critères business partagés
- Les discussions portent enfin sur l'action à mener, pas sur qui a raison
- Le référentiel commun est clairement défini
- Les outils gravitent autour d'une SSOT centrale
- La stack reste lisible, exploitable et plus simple à faire évolue
1). Clarifier ce qui doit réellement devenir “la vérité”
Cette phase consiste à identifier quels indicateurs doivent être partagés, quels écarts vous empêchent aujourd'hui de décider, et quel niveau de fiabilité est réellement nécessaire pour avancer.
- Identifier les chiffres qui doivent être communs à toutes les équipes
- Comprendre d'où viennent les contradictions actuelles
- Définir la gouvernance des données qui servira de base au système
2). Cartographier les flux existants et les points de rupture
Une SSOT ne se décrète pas mais se construit à partir des actifs numériques qui existent déjà.
- Repasse de vos outils marketing, CRM, tableaux de bords et automatisations
- Identification des endroits où la donnée se duplique, se perd ou se contredit
- Validation de ce qui peut être conservé, simplifié ou renforcé
3). Choisir le bon système source de SSOT
C'est ici que la structure technique qui servira de référence commune se décide selon votre contexte, vos enjeux et vos outils.
- GA4 peut devenir un premier centre de vérité sur des écosystèmes plus légers si l'on y réinjecte les bonnes données clients etc.
- Le CRM est souvent l'option la plus pertinente quand il est déjà utilisé comme centre de vérité commercial, notamment avec l'intégration des données marketing en complément.
- Une CDP peut devenir le meilleur choix sur des environnements plus avancés (via des plateformes intégrées comme Eulerian ou l'utilisation de data warehouse) lorsque les normes de qualité des données sont plus élevées ou que la réconciliation doit être la plus neutre possible.
4). Documenter le système et le transmettre à vos équipes
Une source unique de vérité qui fonctionne mais que personne ne comprend reste fragile. Il est donc essentiel de la présenter à vos équipes afin qu'ils puissent l'intégrer à leurs routines quotidiennes.
- Formaliser la logique de lecture et les sources de données utilisées
- Documenter les flux, les règles et les dépendances
- Rendre le système compréhensible, documenté et maintenable en interne
Source : https://atracktio.fr/solutions/ssot-marketing/
Notes podman machine
podman machine init vm1 podman machine start vm1 podman machine status vm1
podman machine stop vm1
$ podman machine rm vm1 The following files will be deleted: /home/jibe/.config/containers/podman/machine/qemu/vm1.json /run/user/1000/podman/vm1.sock /run/user/1000/podman/vm1-gvproxy.sock /run/user/1000/podman/vm1-api.sock /run/user/1000/podman/vm1.log /run/user/1000/podman/vm1_vm.pid /run/user/1000/podman/qmp_vm1.sock Are you sure you want to continue? [y/N] y
Pb
Err - could not find "gvproxy"
$ podman machine start vm1 Starting machine "vm1" Error: could not find "gvproxy" in one of [/usr/local/libexec/podman /usr/local/lib/podman /usr/libexec/podman /usr/lib/podman]. To resolve this error, set the helper_binaries_dir key in the `[engine]` section of containers.conf to the directory containing your helper binaries.
Solution
sudo apt-get install gvproxy sudo ln -s $(which gvproxy) /usr/libexec/podman/
Err - "virtiofsd": executable file not found in $PATH
$ podman machine start vm1 Starting machine "vm1" ERRO[0000] process 28237 has not ended Error: failed to find virtiofsd: exec: "virtiofsd": executable file not found in $PATH
Solution
sudo apt-get install virtiofsd export PATH=$PATH:/usr/libexec/
$ podman machine start vm1
Starting machine "vm1"
This machine is currently configured in rootless mode. If your containers
require root permissions (e.g. ports < 1024), or if you run into compatibility
issues with non-podman clients, you can switch using the following command:
podman machine set --rootful vm1
Mounting volume... /home/jibe:/home/jibe
API forwarding listening on: /run/user/1000/podman/vm1-api.sock
You can connect Docker API clients by setting DOCKER_HOST using the
following command in your terminal session:
export DOCKER_HOST='unix:///run/user/1000/podman/vm1-api.sock'
Machine "vm1" started successfully