Cet article ouvre la série S01 — Boîte à outils Linux du dev Odoo, cinq épisodes consacrés aux fondamentaux Linux, Git, Bash, odoo-bin shell et PostgreSQL appliqués à un environnement Odoo 19. Le présent épisode pose la base système. Les suivants empilent les couches outillage et données.

sudo apt install tree      # arborescence visuelle (section 1)
sudo apt install plocate   # fournit locate + updatedb (section 3)
sudo apt install htop      # moniteur de processus interactif (section 4)

1. Naviguer et inspecter une arborescence Odoo

Toute sandbox Odoo se résume à trois répertoires clés : les sources du moteur (./odoo/), les addons custom (./addons/), et le filestore par utilisateur système (~/.local/share/Odoo/filestore/). Cinq commandes suffisent à s'y déplacer sans hésitation.

# Se déplacer dans la sandbox
cd ~/odoo-dev

# Lister le contenu avec tailles humaines et fichiers cachés
ls -lah

# Afficher le chemin courant (utile dans les scripts)
pwd

# Afficher l'arborescence sur 2 niveaux
tree -L 2 addons/

# Suivre un fichier de log et naviguer dans le flux
less +F /var/log/odoo/odoo.log

L'option +F de less ouvre le fichier en mode follow, équivalent visuel de tail -f, mais avec la possibilité d'appuyer sur Ctrl+C pour reculer dans l'historique, puis F pour reprendre la lecture. Un gain net quand le log défile vite pendant une install de module volumineux.

2. Suivre les logs Odoo en temps réel

Le diagnostic d'une installation de module ratée passe presque toujours par la lecture du log Odoo pendant son exécution. Quatre commandes couvrent l'essentiel des cas, selon que le serveur tourne en service systemd ou en mode dev direct.

# Suivre le log Odoo en temps réel
tail -f /var/log/odoo/odoo.log

# Filtrer ERROR et WARNING à la volée (--line-buffered force le flush ligne par ligne)
tail -f /var/log/odoo/odoo.log | grep --line-buffered "ERROR\|WARNING"

# Suivre via systemd-journal quand Odoo tourne comme service
journalctl -fu odoo.service

# Naviguer librement dans le flux (avant/arrière) avec less
less +F /var/log/odoo/odoo.log

L'option --line-buffered de grep est essentielle : sans elle, la sortie est mise en buffer par bloc de 4 ko et les erreurs apparaissent avec plusieurs secondes de retard. Côté Odoo 19, les options --logfile, --log-web (DEBUG sur odoo.http) et --log-sql (DEBUG sur odoo.sql_db) restent inchangées par rapport à la v18. Activer --log-sql ponctuellement permet de voir chaque requête SQL générée par l'ORM — précieux pour traquer un N+1 dans un compute lent.

3. Trouver fichiers et chaînes de caractères

Sur une sandbox qui héberge plusieurs dizaines de modules custom et plusieurs centaines de modules cœur Odoo, retrouver le fichier qui définit un champ ou hérite d'un modèle natif demande une routine de recherche fiable. Quatre commandes y suffisent.

# Chercher tous les XML modifiés depuis un marqueur temporel
find . -name "*.xml" -newer /tmp/marker

# Chercher une chaîne récursivement dans les addons (numéro de ligne + nom de fichier)
grep -rn "_inherit = 'res.partner'" addons/

# Chercher un fichier dans toute la machine via la base mlocate
locate odoo.conf

# Trouver le binaire actif dans le PATH
which odoo-bin

La commande grep -rn est le réflexe à acquérir : -r recursive, -n ajoute le numéro de ligne. L'ajout de --include="*.py" limite la recherche aux fichiers Python et accélère sur les gros dépôts. Pour locate, sa base est mise à jour par sudo updatedb, exécuté typiquement une fois par jour via cron — un fichier créé il y a cinq minutes ne sera donc pas trouvé tant que la base n'est pas régénérée. Sur Ubuntu 24.04, le paquet est plocate.

4. Processus et ports — diagnostiquer un worker bloqué

Quand l'interface web ne répond plus, deux pistes à dérouler systématiquement : un worker Python figé, ou le port HTTP occupé par un processus fantôme issu d'un précédent crash. Cinq commandes ouvrent toutes les portes du diagnostic.

# Lister tous les processus liés à Odoo
ps aux | grep odoo

# Vue interactive triée CPU/RAM, filtrable par utilisateur
htop -u odoo

# Tuer proprement un PID (SIGTERM laisse le worker terminer sa transaction)
kill -SIGTERM <PID>

# Trouver le processus qui occupe le port 8069
lsof -i :8069

# Alternative moderne à netstat pour lister les ports en écoute
ss -tulpn | grep 8069

L'ordre des signaux compte. SIGTERM (15) demande au processus de s'arrêter proprement : le worker termine sa requête HTTP, ferme la transaction PostgreSQL, libère les ressources. SIGKILL (9) tue brutalement et laisse derrière des connexions PostgreSQL orphelines (idle in transaction) — à n'utiliser qu'en dernier recours, après un SIGTERM resté sans effet pendant plus de dix secondes. Sur Ubuntu 24.04, ss -tulpn est dix à cinquante fois plus rapide que lsof -i pour la même information utile (PID, processus, port) — préférer ss dans les scripts d'audit.

5. Permissions et filestore

Les soucis de droits arrivent toujours par surprise — typiquement après un rsync entre poste dev et VPS, ou après une bascule de l'utilisateur système qui exécute Odoo. Quatre commandes ferment le sujet.

# Rendre odoo-bin exécutable (755 = rwxr-xr-x)
chmod 755 odoo-bin

# Réajuster le propriétaire du filestore (récursif)
sudo chown -R odoo:odoo ~/.local/share/Odoo/filestore

# Forcer la permission 644 sur tous les fichiers (pas les répertoires)
sudo find ~/.local/share/Odoo/filestore -type f -exec chmod 644 {} \;

# Mesurer la taille du filestore par sous-répertoire (= par base)
du -sh ~/.local/share/Odoo/filestore/*

Le couple 755 / 644 est la convention standard : 755 sur les répertoires et exécutables, 644 sur les fichiers de données. Toute permission plus permissive (par exemple 777) sur le filestore est un anti-pattern de sécurité. La commande du -sh */ dans le répertoire filestore donne en deux secondes la liste des bases triées par poids — utile pour identifier celle qui sature un disque avant qu'une alerte de monitoring ne se déclenche.

6. Service systemd Odoo

Sur Ubuntu 24.04, Odoo tourne typiquement comme service systemd nommé odoo ou odoo.service. Quatre commandes pilotent le cycle de vie complet.

# Vérifier l'état du service (running, failed, inactive)
sudo systemctl status odoo

# Démarrer, arrêter, redémarrer
sudo systemctl start odoo
sudo systemctl stop odoo
sudo systemctl restart odoo

# Activer le démarrage automatique au boot
sudo systemctl enable odoo

# Consulter les logs systemd-journal du service
sudo journalctl -u odoo --since "1 hour ago"

L'option --since de journalctl accepte des formes variées : "1 hour ago", "yesterday" ou date ISO 8601 ("2026-05-13 14:00"). Combinée à -u odoo, elle isole les événements du service sur une fenêtre précise pour reconstituer un incident a posteriori.

7. Transferts locaux et backup rapide

Le développeur Odoo synchronise régulièrement son poste local avec un VPS de staging ou de prod. Quatre commandes couvrent les usages quotidiens, du transfert ponctuel d'un fichier de config jusqu'à la sauvegarde compressée d'un filestore.

# Copier un fichier vers un VPS distant via SSH
scp odoo.conf user@vps:/etc/odoo/

# Synchroniser un répertoire d'addons (--delete supprime côté cible les fichiers absents source)
rsync -avz --delete ./addons/ root@vps:/opt/odoo/custom-addons/

# Compresser un filestore avec horodatage automatique
tar czf filestore-$(date +%Y%m%d).tgz -C ~/.local/share/Odoo filestore/

# Dump PostgreSQL au format custom (sans filestore)
pg_dump -Fc -f backup_$(date +%Y%m%d).dump nom_base

Le flag -avz de rsync est le combo standard : a archive (préserve permissions, timestamps, symlinks), v verbose, z compression à la volée. L'option --delete est puissante mais destructive — à n'activer que si la cible est un miroir intégral du dépôt source. Pour les dumps PostgreSQL, le format custom (-Fc) produit un fichier binaire compressé restaurable via pg_restore, plus compact que le SQL plain. L'épisode S05 détaille les patterns pg_dump / pg_restore spécifiques à Odoo.

8. Cinq alias .bashrc qui changent la vie

Aucune commande Linux ne remplace un alias bien placé dans le .bashrc du développeur. Cinq alias suffisent à transformer le confort quotidien sur une sandbox Odoo.

# Suivre les erreurs Odoo en un caractère
alias logodoo='tail -f /var/log/odoo/odoo.log | grep --line-buffered "ERROR\|WARNING"'

# Redémarrer Odoo et suivre les logs systemd dans la foulée
alias restartodoo='sudo systemctl restart odoo && sudo journalctl -fu odoo'

# Se connecter à PostgreSQL avec le bon user en une frappe
alias psqlme='psql -U odoo -h localhost'

# Sauter dans le venv Odoo en une commande
alias odoodev='cd ~/odoo-dev && source venv/bin/activate'

# Vérifier l'état Git des addons custom
alias addons='cd ~/odoo-dev/addons-custom && git status'

Ces alias se déclarent dans ~/.bashrc, puis source ~/.bashrc les active dans la session courante. Règle d'or : ne pas créer d'alias qui masque une commande système standard (par exemple alias ls='rm -rf' est un piège sécurité — préfixer toujours par un verbe métier).

9. Les 30 commandes en synthèse

La table ci-dessous reprend la totalité des trente commandes vues dans l'article. Mémoriser le cas d'usage permet de retrouver la commande sans hésiter, même sous pression.

Pour fixer ces commandes en mémoire musculaire : tester chacune au moins une fois sur une sandbox locale avant la première intervention sous pression, puis les ranger dans un fichier ~/odoo-cheatsheet.md consultable en Ctrl+F. Au bout de quelques semaines, les quinze plus utilisées passent en réflexe.