Bonjour à tous,
Je souhaiterais savoir dans quel fichier log je peux voir les commandes faites sur mon serveur s’il vous plaît.
Je suis sous debian.
Merci,
Bonjour,
Je ne comprends pas vraiment ce que tu veux faire.
Pour les commandes exécutées par le service de tâches planifiées (cron), tu peux voir ça dans le fichier de journalisation /var/log/syslog.
Si tu veux les commandes exécutées dans l’interpréteur de commande, tu peux aller voir dans son historique (la commande history te donnera son contenu), mais il faut prendre en compte que ce fichier est modifiable par l’utilisateur auquel appartient le fichier.
Je pense qu’il serait bien de connaître le cas d’usage afin de pouvoir t’aider de façon plus pertinente.
En fait, j’ai un souci sur le service mysqld et on me demande de voir les commandes ou configuration que j’ai fait dernièrement.
Du coup, je ne sais pas où je peux voir ça et je ne me souviens pas exactement les configurations que j’ai déjà fait.
Ah, d’accord, si tu n’as pas un système qui les journalise, tu n’auras que l’historique de ton interpréteur de commande. Debian n’est pas le genre de système à faire des trucs si on ne lui demande pas de les faire.
Quant aux modifications de configuration, si tu as une sauvegarde de la configuration, tu peux naviguer dans les incréments de la sauvegarde.
Merci Almtesh,
Avec la commande history, je peux voir la liste des commande que j’ai fait sur le serveur.
Reste à savoir d’où vient mon problème sur mysql.
Bonjour,
Quels sont les logs que tu as? ou messages d’erreurs?
C’est résolu par un responsable réseau.
En fait, il semble que j’ai fait une modification au niveau de postfix, ce que j’ignore complètement.
Et ça avait un rapport avec mysql, du coup le service n’est pas lancé.
Et là, je ne sais pas où voir pour retrouver quelle modification sur postfix ai-je fait pour que mysql ne se lance pas.
Il doit y avoir un log pour postfix?
Des logs des modifications de configuration ? non, tu as ton historique à la limite mais rien de plus si tu ne versionnes pas les modifications sur un git ou autre.
D’accord, merci pour ton retour.
sudo apt install etckeeper
Que dire de plus sur un système Debian ?
Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة
F. Petitjean
Ingénieur civil du Génie Maritime.
« On ne perd pas son temps en aiguisant ses outils. »
Proverbe français
« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)
A moins quer tu ne déclenche toi me^me avant chaque modification je ne vois pas comment tu aura l’ensemble de tes modifications … le versionnage est la seule solution pour voir l’enemble des modifications successives.
Par contre c’est une bonne solution pour mettre de côté les fichiers de configurations de son serveur.
Justement, etckeeper est appelé à chaque modification due au lancement de apt ou aptitude et un commit igt est généré.
fp2@debpacha:/etc$ sudo git log
commit 5ec4f419ab210c6d990a24391c190b329e3c7bf5 (HEAD -> master)
Author: François Petitjean <littlejohn75@laposte.net>
Date: Sat Mar 18 15:31:25 2023 +0100
saving uncommitted changes in /etc prior to apt run
commit 8eb253e106ed113f5d8d294370c9e1732677e59f
Author: François Petitjean <littlejohn75@laposte.net>
Date: Thu Mar 9 14:14:01 2023 +0100
committing changes in /etc made by "aptitude purge xscreensaver"
Package changes:
-xscreensaver 5.45+dfsg1-2 amd64
commit 37d845f44910ebcb81a8b1c3fcdc8d30c6d7f12d
Author: François Petitjean <littlejohn75@laposte.net>
Date: Wed Mar 8 19:01:46 2023 +0100
committing changes in /etc made by "aptitude purge magnus"
Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة
F. Petitjean
Ingénieur civil du Génie Maritime (retraité).
« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)
« Celui qui, parti de rien, n’est arrivé nulle part n’a de merci à dire à personne !! »
Pierre Dac
Oui via un appel du gestionnaire de paquet mais pas pour des modifications réalisées comme dans le cas présent par quelqu’un.
Si je modifie le socket d’un service et le relance, la modification n’est pas versionnée 
et mise à part une ligne dans l’historique nous ne pouvons pas savoir quelle a été la modification (plus complexe encore lors d’édition de multiples valeurs à plusieurs reprises).
Il y a une raie incompréhension sur l’utilisation du paquet etckeeper Dans le cadre d’un historique des actions sur un serveur" 'titre de ce fil de discussion) je ne vois vraiment pas ce qui empêcherait un utilisateur qui voudrait documenter une action sur un serveur de faire
cd /etc
sudo git status
et s’il n’y a pas de fichiers dans la hiérarchie /etc modifiés par l’action (importante) en cours de créer délibérément un fichier de type readme documentant ce qui a été fait (quelque part dans /etc ) et de procéder ensuite un commit git dudit fichier, avec un message de commit détaillé si besoin.
Si le git status retourne des fichiers c’est encore plus simple : git add + git commit
Pour suivre les modifications faites sur le serveur, je vous conseille de lancer les lignes de commandes uniquement dans une session tmux (sur le serveur). Ceci suppose que tmux soit installé sur le serveur (et éventuellement keychain).
ssh user@serveur
tmux list-sessions
suivi de
tmux attach-session -t XX
ou
tmux new-session
Vous avez un historique des commandes passées et des réponses du système que vous pouvez retrouver à tout moment et sauvegarder dans un fichier via tmux capture-pane.
Notez que l’émulateur de terminal sur votre poste client n’a même pas besoin de gérer une barre de défilement pour naviguer dans l’historique des fenêtres de la session tmux, st (simple terminal) du paquet stterm convient très bien.
Le gros avantage de tmux c’est pouvoir se déconnecter et se reconnecter à une session. L’inconvénient est la perte de la session tmux si on fait redémarrer le serveur.
Il me semble qu’en combinat les outils tmux etckeeper et git vous devriez pouvoir gérer l’historique d’administration… Un dépôt git autre que /etc/.git de etckeeper est envisageable avec les responsables réseau
Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة
F. Petitjean
Ingénieur civil du Génie Maritime.
« On ne perd pas son temps en aiguisant ses outils. »
Proverbe français
« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)
Bon, moralité du sujet, tu n’auras pas plus d’information pour cette fois, mais tu as des outils pour éviter (ou limiter fortement) le risque de te retrouver dans cette situation.
Je l’utilise régulièrement sur les infrastructure que je gère …
Donc on n’en reviens à ce que je disais passer par un outil de versionnage manuellement, car hormis l’utilisation de APT etckeeper ne va pas deviner que le moldu utilisant son éditeur préféré sur un fichier de conf ne va pas faire de sauvegarde du dit fichier ensuite et donc la faire à sa place
PS : au passage on fait aussi le bon vieux .bak .bak1 .bak2 etc lorsque l’on est pas inspiré ou que l’on a pas d’outil installable.