Table des matières
- 2026:
- 2025:
4 billet(s) pour septembre 2026
| Notes HTTP Strict Transport Security - HSTS | 2026/09/18 11:04 | Jean-Baptiste |
| Notes GNU Linux GPU carte graphiques | 2026/09/08 15:49 | Jean-Baptiste |
| Notes GNU Linux graphique | 2026/09/08 15:42 | Jean-Baptiste |
| Notes urlencoding - passer des mots de passe en HTTPS | 2026/09/03 17:58 | Jean-Baptiste |
Squid - NTLM auth
Voir : https://wiki.squid-cache.org/ConfigExamples/Authenticate/WindowsActiveDirectory
squid.conf
httpd_suppress_version_string on auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp --domain=aspaway.fr auth_param ntlm children 50 auth_param ntlm keep_alive off acl ntlm proxy_auth REQUIRED http_access allow localnet ntlm
wbinfo -t wbinfo --ping-dc ntlm_auth --diagnostics --username=jean --domain=acme.fr
Notes son-alsa
Voir :
Voir aussi PulseAudio
alsamixer #this sets the simplified Pulseaudio mixer controls alsamixer -c0 #this sets up the actual ALSA sound card levels
alsamixer -c 0
[F4] pour les entrées son (micros) Input Source Rear Mic
A tester
Si tout est ok en root :
alsactl store
Mettre “Rear Mic” en “Input Source” en ligne de commande
amixer -c0 cset iface=MIXER,name='Input Source',index=0 'Rear Mic'
http://thenerdshow.com/index30e5.html
Ca marche ! Mais j'ai rajoutée cette ligne partout pour la lancer au démarrage du PC, pas moyen. Visiblement qqch change ma config son.
En tapant mate-session-properties (idem que gnome-session-properties, mais pour mate)
Système de son PulseAudio start-pulseaudio-x11
C'est lui le coupable. Je ruse en remplaçant la ligne :
start-pulseaudio-x11; amixer -c0 cset iface=MIXER,name='Input Source',index=0 'Rear Mic'
Ça ne marche pas. Un autre process se lançant au démarrage modifie ma config.
Je ruse en créant un script :
/usr/local/bin/jitsi.sh
#! /bin/bash sleep 15 ; amixer -c0 cset iface=MIXER,name='Input Source',index=0 'Rear Mic' jitsi
C'est lui que j'appelle au démarrage du PC.
Couper le son HP (Mute)
amixer set Master mute
Rétablir le son HP
amixer set Master toggle
Couper le son du micro (Mute)
amixer set Capture nocap
Rétablir le son du micro
amixer set Capture cap
Réduire ou augmenter le son
amixer -D pulse sset Master 50% amixer set Master 5+
Désactiver le micro
$ cat /proc/asound/modules 0 snd_hda_intel 1 snd_hda_intel
echo 'blacklist snd_hda_intel' | sudo tee -a /etc/modprobe.d/blacklist.conf
Autres
Sur Raspbian
/usr/sbin/alsactl -E HOME=/run/alsa -s -n 19 -c rdaemon
Mix
Solutions Serverless
Voir aussi :
- SlimFaas
| Nom | Dépôt code | Serverless FWK | Langu | K8S |
|---|---|---|---|---|
| Knative | https://github.com/knative/ | oui | Go | oui |
| OpenFaaS | https://github.com/openfaas | non | Go | Opt |
| OpenWhisk | https://github.com/apache/openwhisk | oui | Scala | Opt |
| Fission | https://github.com/fission/fission | plugin ? | Go | oui |
| #Fn | https://github.com/fnproject/fn#top | oui | Go | non |
| #Kubeless | https://github.com/vmware-archive/kubeless | oui | Go | oui |
Voir :
Voir aussi :
- firecracker-microvm
Knative
Knative est utilisé pour OpenShift / OKD
Tutos :
OpenFaaS
- can be deployed to a variety of container orchestrators such as Kubernetes, OpenShift, Docker Swarm or to a single host with faasd.
- Hélas pas pris nativement en charge par Serverless.com Framework.
Tutos :
Fn
Script initV
: Doublon avec script_init_wrapper
Aujourd'hui au boulot : install d'un logiciel privateur sur une Debian. Cette solution install un script dans /etc/init.d/ Je vais l'appeler ici MACHINAgent
J'ai donc mon beau script /etc/init.d/MACHINAgent
Le pb c'est qu'il démarre le processus avec les privilèges root
Une solution serait d'utiliser crontab sous un compte utilisateur.
@reboot /etc/init.d/MACHINAgent start
Je crée un utilisateur système. Mais la crontab, ce n'est pas une bonne idée :
- Il ne ferme pas l'appli correctement
- Logiquement tous les scripts /etc/init.d/ doivent pouvoir être lancer en root et lancer les process avec un compte dedié.
Lancement du serveur MACHIN sous un compte utilisateur (non-root) sous Debian.
## 1) Création d’un nouvel utilisateur dédie au serveur MACHIN.
Dans notre exemple il s’agit de « machin »
2) Création du script
/etc/init.d/MACHINWrapper
#! /bin/bash # chkconfig: 35 85 15 # description: Startup script for MACHIN Agent Wrapper ### BEGIN INIT INFO # Provides: MACHINWrapper # Required-Start: $network $local_fs $remote_fs $time $syslog # Required-Stop: $network $local_fs $remote_fs $time $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Wrapper pour lancer les scripts sysVinit avec un compte utilisateur (non root) # Description: Wrapper pour lancer les scripts sysVinit avec un compte utilisateur (non root) ### END INIT INFO MACHIN_USER=machin MACHIN_INITSCRIPT=/etc/init.d/MACHINAgent su - $MACHIN_USER -c "$MACHIN_INITSCRIPT $*"
Explications
Les commentaires servent !
- Ligne 1 : c'est le Shebang
- Ligne 2 : chkconfig sert pour Redhat/CentOS
- Ligne 3 : description sert aussi pour chkconfig !?
- Ligne 4 à 12 : C'est la même chose que chkconfig, mais pour la plupart des distros. C'est une norme LSB Voir https://wiki.debian.org/LSBInitScripts
- Ligne 13 à FIN : C'est le code.
- Ligne 13 : Variable MACHIN_USER qui contient le nom du compte dédié au service.
- Ligne 14 : Variable MACHIN_INITSCRIPT qui contient le chemin complet de l'ancien script que nous avons déplacé
- Ligne 15 FIN: On utilise la commande su pour changer de compte. Puis $* représente tous les arguments. Dans le cas d'un script init : start, stop, status, restart et éventuellement d'autres.
Note : Les commentaires du scripts sont nécessaire. Voir https://wiki.debian.org/LSBInitScripts http://linux.die.net/man/8/chkconfig
3) Gestion des services
Placer les droits d’exec :
chmod +x /etc/init.d/MACHINWrapper
Désactivation du démarrage de l’ancien script.
update-rc.d MACHINAgent remove
Activation du nouveau script
update-rc.d MACHINWrapper defaults
On vérifie :
find /etc/rc* -iname "*MACHIN*"
4) Fin
Arrêt process lancé en root
/etc/init.d/MACHINAgent stop
Ici l’utilisateur machin devient le nouveau propriétaires des fichiers
chown machin: /opt/machin/ -R
On démarre MACHINWrapper
/etc/init.d/MACHINWrapper start
En cas de Pb :
Refaire point 3 et 4. Idem si application patch.
Notes
NB : il convient dans la supervision de s’assurer que le process tourne sous le bon compte.
Exemple :
pgrep -u machin nomDuProcess && echo OK || echo NOK
SNMPd - Configuration et ajout d'IODs perso
Voir aussi :
- pass (snmpd) example_snmpd_wrapper_script
Source : http://blog.gamb.fr/index.php?post/2012/10/23/Installation-et-configuration-de-snmpd
Quand la supervision doit récupérer des valeurs systèmes, il y a autant de solutions que d’administrateurs. On peut déployer un agent, ouvrir tous les ports, passer par une page web, faire du ssh, etc. Le moyen le plus simple et efficace est de passer par le protocole SNMP. Il est donc nécessaire d'installer et de configurer un démon SNMP sur vos serveurs. Nous allons rapidement configurer le démon puis nous allons nous attarder sur l'ajout d'OID perso.
Installation
Le démon SNMP est disponible pour quasiment toutes les distributions Linux, je l'avais même installé sur un Solaris 10. Sur un système Red Hat, il suffit de lancer une commande YUM.
yum install net-snmp
chkconfig snmpd on
service snmpd start
Si vous avez des iptables, pensez à ajouter une règle pour autoriser vos machines de supervision. Pour cela, éditer les règles Iptables :
vim /etc/sysconfig/iptables
Et ajouter la règle :
-A INPUT -p udp -s <ip_serveur_supervision> --dport 161 -j ACCEPT
Puis relancer Iptables :
service iptables restart
Configuration
Globalement, le fichier de configuration snmpd est constitué de quatre parties : Les machines autorisées à interroger SNMPd, les droits de lecture/écriture, les vues de la MIB et enfin les accès machines/vues. On édite le fichier :
vim /etc/snmp/snmpd.conf
Premièrement, on va autoriser notre serveur de supervision ainsi que localhost. On ne déclare qu'une seule communauté de sécurité (com2sec) :
com2sec supervision 127.0.0.1 public com2sec supervision <ip_serveur_supervision> public
On va donner des droits à cette communauté de sécurité sous forme de groupes, dans notre cas de la simple lecture :
group ReadOnly v2c supervision
J'ai pour habitude d'autoriser les requêtes en V1 et V2 du protocole SNMP mais vous pouvez activer seulement la V2.
On va ensuite déclarer des vues, c'est à dire des branches de la MIB qui seront consultables. Certains utilisent .1 pour rendre tout l'arbre consultable, pour ma part je préfère n'ouvrir que ce que j'ai besoin :
view systemInfo included .1.3.6.1.4.1.2021.10
Dans cet exemple, on expose que le load average de la machine. N'hésitez pas à faire un snmpwalk pour trouver l'OID des objets que vous souhaitez exposer. (Penser à tout autoriser pour le walk : view systemInfo all .1).
Pour conclure, on va associer les vues aux groupes d'accès (celui où on dit si c'est en lecture ou en écriture) :
access ReadOnly "" any noauth exact systemInfo none none
Voila de façon très macroscopique les points importants de la configuration. Plutôt que de m'attarder sur cette partie, je vous fourni un modèle de configuration minimale dans la suite.
Modèle de fichier de configuration
Voici un fichier de conf mini-minimale, je vous conseille de vous faire un fichier équivalent avec les OID communs à tous vos serveurs.
/etc/snmp/snmpd.conf
# # Fichier de conf minimale SNMPd # # Parametres globaux syslocation <mon_serveur>.<mon_domaine> syscontact <admin>@<mon_domaine> # Declaration des machines autorisees # Nom Source Communaute com2sec supervision 127.0.0.1 public com2sec supervision <ip_serveur_supervision> public # Declaration des groupes d'acces # Nom Version Com2sec group ReadOnly v2c supervision group ReadOnly v1 supervision # Declaration des vues # Nom Incl/Excl Subtree Masque (optionnel) view systemInfo included .1.3.6.1.4.1.2021.10 # Association Group et View # GroupName Contexte Version SecLevel Prefix Read Write Notif access ReadOnly "" any noauth exact systemInfo none none # OID perso
Vous constatez à la fin que j'ai prévu une zone pour les OID perso, et oui on peut étendre la MIB suivant nos besoins ! Très pratique pour monitorer des valeurs systèmes spécifiques.
Exécuter ses propres scripts
Il est possible d'étendre la MIB de plusieurs façons. Certains logiciels ajoutent leur OID via un agentx, par exemple cyrus-imap propose cela dans ses versions les plus récentes. Mais des fois, pour des besoins très spécifiques, on aimerait récupérer la sortie d'un script. La chose est faisable très simplement avec snmpd.
Plusieurs directives peuvent être utilisées dans le fichier de conf : pass, exec et extend. Visiblement, le net-snmp disponible sur les RHEL6, ne permet d’utiliser que extend, mais la syntaxe est identique à exec. Pass a un comportement différent, un script n'est pas égale à un OID mais à un ensemble, peut être pratique pour les scripts qui sortent plusieurs lignes de résultat.
Ici, on va mettre en œuvre extend pour exécuter un script sur le serveur supervisé et récupérer la valeur avec snmpget.
On édite le fichier de configuration principal :
vim /etc/snmp/snmpd.conf
A la fin de fichier, on ajoute un appel à notre script :
extend <oid_perso> <nom_script_friendlyuser> <chemin_script>/<script> <args>
Comment choisir un OID perso ? Il y a une branche de la MIB dédiée à cela, elle est préfixé ucdavis (un truc du genre) et son équivalent en numérique est : .1.3.6.1.4.1.2021
Il suffit donc de choisir un suffixe pour votre script. Sur vos nombreux serveurs, faites en sorte de ne pas avoir des scripts qui répondent sur le même OID alors qu'ils ne font pas la même chose, ça sera plus simple à gérer.
Exemple : Récupérer les infos d'un volume groupe LVM
Pour illustrer la puissance des OID perso, on va essayer de récupérer quelques infos concernant un volume group. Premièrement, dans un shell, essayons de trouver la commande qui va bien :
vgdisplay -s VolGroup00
Ce qui renvoi :
"VolGroup00" 136.12 GiB [75.97 GiB used / 60.16 GiB free]
Pour notre exemple, ça sera suffisant, on édite donc le fichier de conf snmp :
vim /etc/snmp/snmpd.conf
On ajoute une vue pour notre OID perso :
view systemInfo included .1.3.6.1.4.1.2021.900
Et on ajoute, à la fin du fichier, la ligne suivante :
extend .1.3.6.1.4.1.2021.900 stats_vg0 /sbin/vgdisplay -s
J'ai choisi l'OID de façon arbitraire et avec une grosse valeur pour éviter d'éventuels conflits. De même, ayez le réflexe de toujours mettre le chemin complet des binaires.
On redémarre notre snmpd :
service snmpd restart
Maintenant, on test avec snmpwalk le résultat :
snmpwalk -c public -v2c localhost .1.3.6.1.4.1.2021.900
Et voici le résultat :
UCD-SNMP-MIB::ucdavis.900.1.0 = INTEGER: 1 UCD-SNMP-MIB::ucdavis.900.2.1.2.9.115.116.97.116.115.95.118.103.48 = STRING: "/sbin/vgdisplay" UCD-SNMP-MIB::ucdavis.900.2.1.3.9.115.116.97.116.115.95.118.103.48 = STRING: "-s" UCD-SNMP-MIB::ucdavis.900.2.1.4.9.115.116.97.116.115.95.118.103.48 = "" UCD-SNMP-MIB::ucdavis.900.2.1.5.9.115.116.97.116.115.95.118.103.48 = INTEGER: 5 UCD-SNMP-MIB::ucdavis.900.2.1.6.9.115.116.97.116.115.95.118.103.48 = INTEGER: 1 UCD-SNMP-MIB::ucdavis.900.2.1.7.9.115.116.97.116.115.95.118.103.48 = INTEGER: 1 UCD-SNMP-MIB::ucdavis.900.2.1.20.9.115.116.97.116.115.95.118.103.48 = INTEGER: 4 UCD-SNMP-MIB::ucdavis.900.2.1.21.9.115.116.97.116.115.95.118.103.48 = INTEGER: 1 UCD-SNMP-MIB::ucdavis.900.3.1.1.9.115.116.97.116.115.95.118.103.48 = STRING: " \"VolGroup00\" 136.12 GiB [75.97 GiB used / 60.16 GiB free]" UCD-SNMP-MIB::ucdavis.900.3.1.2.9.115.116.97.116.115.95.118.103.48 = STRING: " \"VolGroup00\" 136.12 GiB [75.97 GiB used / 60.16 GiB free]" UCD-SNMP-MIB::ucdavis.900.3.1.3.9.115.116.97.116.115.95.118.103.48 = INTEGER: 1 UCD-SNMP-MIB::ucdavis.900.3.1.4.9.115.116.97.116.115.95.118.103.48 = INTEGER: 0 UCD-SNMP-MIB::ucdavis.900.4.1.2.9.115.116.97.116.115.95.118.103.48.1 = STRING: " \"VolGroup00\" 136.12 GiB [75.97 GiB used / 60.16 GiB free]"
On constate qu'il s'agit d'un arbre, votre outil de supervision n'a besoin que de la valeur de résultat, on modifie donc notre commande snmpwalk pour ne garder que le nécessaire :
snmpwalk -OQnv -c public -v2c localhost .1.3.6.1.4.1.2021.900.4.1.2.9.115.116.97.116.115.95.118.103.48.1 | tr -d "\""
Ce qui nous donne comme résultat :
\VolGroup00\ 136.12 GiB [75.97 GiB used / 60.16 GiB free]
Conclusion
SNMP peut servir pour toute la supervision, pas besoin d'ouvrir plus de port, d'installer des agents dédiés (nrpe, agent zabbix, etc). Pour les taches un peu plus complexes, déployer un script qui fait le boulot de collecte et de formatage sur votre serveur à superviser et récupérer simplement la valeur via SNMP. Pour info, dans les “data input methods” de Cacti, j'appelle directement une commande snmpget comme celle ci :
snmpget -OQnv -c <snmp_community> -v2c <hostname> <oid_perso> | tr -d "\""
