Table des matières
- 2026:
- 2025:
1 billet(s) pour avril 2026
| Notes ping ICMP | 2026/04/03 23:01 | Jean-Baptiste |
GNU/Linux Avoir des infos sur le matériel
Voir :
Savoir si il y a du SAN :
lspci |egrep -i -e "emu|qlo"
Avoir plein d'infos avec dmidecode
#dmidecode |grep -e "Product" |head -1 dmidecode -s system-product-name
Product Name: PowerEdge R710
dmidecode -t1
Firmware version check for Dell server
| Type | Command |
| NIC firmware | ethtool -i eth3 |
| NIC driver | ethtool -i eth3 |
| OEM BIOS Rev | dmidecode -t bios |
| PERC H700 Controller | omreport storage controller |
| PERC Driver | omreport storage controller |
| Open Manage Software | omreport about |
# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.
Handle 0x0100, DMI type 1, 27 bytes
System Information
Manufacturer: Dell Inc.
Product Name: PowerEdge R530
Version: Not Specified
Serial Number: 5S25KF2
UUID: 4C4C4544-0053-3210-8035-B5C04F4B4632
Wake-up Type: Power Switch
SKU Number: SKU=NotProvided;ModelName=PowerEdge R530
Family: Not Specified
Tag Dell
dmidecode | grep -i serial dmidecode -t 1 dmidecode -s system-serial-number
# dmidecode -s baseboard-manufacturer TYAN # dmidecode -s baseboard-product-name S7053
cat /proc/bus/input/devices
Quelques commandes utiles :
- dmesg
lsusb -t,lsusb -v -d 1050:0120- lspci
lsscsi -H,lsscsi -g- lshw
- inxi
- lscpu
- lsblk
- dmseg
hwinfo --short- /sbin/discover
- lsdev procinfo (paquet procinfo)
- lsmod
numactl --hardware
Un lsmod peut également révéler beaucoup d'information sur le matériel
CPU
nproc lscpu lshw -c cpu dmidecode -t processor cpupower monitor
iucode_tool --scan-system iucode_tool: system has processor(s) with signature 0x000406f1
Disques
lsblk lsblk /dev/sda --bytes --nodeps --pairs --paths --output SIZE,ROTA,RO,TYPE,PKNAME,NAME fdisk -l parted -l hdparm -i /dev/sda systemctl list-units --type=device
Réseau
lshw -c network
Si UNCLAIM apparaît : probablement un problème de driver
lspci |grep -i net
Nombre de cores nombre de processeur physiques
cat /proc/cpuinfo
Nombre de core
nproc getconf _NPROCESSORS_CONF
GPU
# inxi -G
Graphics: Device-1: Intel driver: i915 v: kernel
Device-2: NVIDIA driver: nvidia v: 430.50
Device-3: NVIDIA driver: nvidia v: 430.50
Display: tty server: X.org 1.20.4 driver: none tty: 237x35
Message: Advanced graphics data unavailable in console for root.
Exemple
LANG=C lscpu | grep -i socket Core(s) per socket: 10 Socket(s): 2 grep -i "physical id" /proc/cpuinfo | sort -u | wc -l 2 nproc 40 Hyper-Threading ? grep -o -w -e '^flags.* ht' /proc/cpuinfo Si non : NBSockets * CoresPerSocket Si oui : NBSockets * CoresPerSocket * 2
Carte graphique
Identifier sa carte graphique
lspci -vnn | grep -A 12 '\''[030[02]\]' | grep -Ei "vga|3d|display|kernel" sudo lshw -enable pci -class display xrandr
Source https://doc.ubuntu-fr.org/carte_graphique#identifier_sa_carte_graphique
Serveur physique VM Conteneur Docker OpenVZ
Protection de l'espace exécutable
Contre buffer overflow
Voir : https://en.wikipedia.org/wiki/Executable_space_protection
Linux Address Space Layout Randomization (ASLR) et exec-shield
Liens :
Kernel arguments pour désactiver
exec-shield=0 norandmaps
Pour désactiver que pour un seul processus
setarch $(uname -i) -R /opt/plop
Pour Oracle
CAUSE
Recent linux kernels have a feature called Address Space Layout Randomization (ASLR). ASLR is a feature that is activated by default on some of the newer linux distributions. It is designed to load shared memory objects in random addresses. In Oracle, multiple processes map a shared memory object at the same address across the processes.
With ASLR turned on Oracle cannot guarantee the availability of this shared memory address. This conflict in the address space means that a process trying to attach a shared memory object to a specific address may not be able to do so, resulting in a failure in shmat subroutine.
However, on subsequent retry (using a new process) the shared memory attachment may work. The result is a “random” set of failures in the alert log.
SOLUTION
It should be noted that this problem has only been positively diagnosed in Redhat 5 and Oracle 11.2.0.2. It is also likely, as per unpublished BUG:8527473, that this issue will reproduce running on Generic Linux platforms running any Oracle 11.2.0.x. or 12.1.0.x on Redhat/OEL kernels which have ASLR.
This issue has been seen in both Single Instance and RAC environments.
ASLR also exists in SLES10 and SLES 11 kernels and by default ASLR is turned on. To date no problem has been seen on SuSE servers running Oracle but Novell confirm ASLR may cause problems. Please refer to
http://www.novell.com/support/kb/doc.php?id=7004855 mmap occasionally infringes on stack
You can verify whether ASLR is being used as follows:
# /sbin/sysctl -a | grep randomize kernel.randomize_va_space = 1
If the parameter is set to any value other than 0 then ASLR is in use.
On Redhat 5 to permanently disable ASLR.
add/modify this parameter in /etc/sysctl.conf
/etc/sysctl.conf
kernel.randomize_va_space=0 kernel.exec-shield=0
You need to reboot for kernel.exec-shield parameter to take effect.
Note that both kernel parameters are required for ASLR to be switched off.
There may be other reasons for a process failing to start, however, by switching ASLR off, you can quickly discount ASLR being the problem. More and more issues are being identified when ASLR is in operation.
Note: “In RHEL/OEL 7 exec-shield is not modifiable anymore, so changing the exec-shield parameter produces an error.”
Ansible uri - Tower API
Avec curl
curl -k -u username:'P@ssw0rd' -H 'Content-Type: application/json' -X GET https://tower.acme.fr/api/v2/job_templates/93/launch/ -d ' { "extra_vars": { "git_path": "/project/plop", "git_user": "gittoken" } }'
Via Ansible
#!/usr/bin/env ansible-playbook --- - hosts: localhost tasks: - name: call api register: plop uri: url: https://tower.acme.fr/api/v2/job_templates/93/launch/ method: POST force: true force_basic_auth: true user: username password: 'P@ssw0rd' validate_certs: false # body_format: form-urlencoded body_format: json headers: Content-Type: "application/json" body: | { "extra_vars": { "git_path": "/project/plop", "git_user": "gittoken" } } status_code: 201 - name: DEBUG 10 debug: var=plop
Ou encore
#!/usr/bin/env ansible-playbook --- - hosts: localhost tasks: - name: call api register: plop uri: url: https://tower.acme.fr/api/v2/job_templates/93/launch/ method: POST force: true force_basic_auth: true user: username password: 'P@ssw0rd' validate_certs: false body_format: json headers: Content-Type: "application/json" src: plop.json status_code: 201
plop.json
{ "extra_vars": { "git_path": "/project/plop", "git_user": "gittoken" } }
Pb
Pb de logs tronqués
Consulter la sortie : https:<tower-FQDN>/api/v2/job_templates/<job-template-id>/
Linux pile TCP/IP TIME_WAIT Apache
Voir
man netstat- mode Prefork Vs Worker
ps -efL |grep http | wc -l
netstat -nat |sed '2d' | awk '{print $6}' | sort | uniq -c | sort -n
1 Foreign
4 SYN_RECV
12 LISTEN
131 ESTABLISHED
191 CLOSE_WAIT
270 TIME_WAIT
Ou mieux
# ss -s Total: 281 (kernel 3060) TCP: 10 (estab 4, closed 0, orphaned 0, synrecv 0, timewait 0/0), ports 0 Transport Total IP IPv6 * 3060 - - RAW 0 0 0 UDP 2 2 0 TCP 10 7 3 INET 12 9 3 FRAG 0 0 0
Voir commande ss
ss -t4 state time-wait ss -t4 state established
Pile TCP/IP
cat /proc/sys/net/ipv4/tcp_fin_timeout 0 cat /proc/sys/net/ipv4/tcp_tw_recycle 0 cat /proc/sys/net/ipv4/tcp_tw_reuse 60
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
1 Foreign
1 SYN_RECV
12 LISTEN
29 CLOSE_WAIT
58 ESTABLISHED
217 TIME_WAIT