Logrotate qui ignore le fichier '/etc/logrotate.d/rsyslog' modifié.
Bonjour à tous les utilisateurs et développeurs de Debian :
Ce vendredi 14/08/15, j'ai modifié le fichier '/etc/logrotate.d/rsyslog' en
ajoutant les paramètres dateyesterday et dateformat .%Y%m%d pour les
fichiers journaux '/var/log/syslog'.
D'ailleurs, je vous donne l'extrait du fichier '/etc/logrotate.d/rsyslog'
concernant les fichiers journaux '/var/log/syslog' (et après modification) :
/var/log/syslog
{
rotate 7
daily
dateyesterday
dateformat .%Y%m%d
missingok
notifempty
delaycompress
compress
postrotate
invoke-rc.d rsyslog rotate /dev/null
endscript
}
Je vous précise que je n'ai rien touché concernant les autres fichiers du
répertoire '/etc/logrotate.d' ainsi que le fichier '/etc/logrotate.conf'.
Et, par la suite et toujours ce 14/08/15, j'ai lancé - sous une session 'root'
- la commande 'logrotate -f /etc/logrotate.conf' afin de forcer l'application
Logrotate à tenir compte de mes modifications (telles que j'ai indiquées
précédemment), du moins ce que j'avais espéré...
Malheureusement, il semblerait que Logrotate les ait ignorées si j'en crois au
résultat de la commande 'ls -l /var/log/syslo*' (que j'ai lancée aujourd'hui)
:
-rw-r- 1 root adm 48390 août 17 07:10 /var/log/syslog
-rw-r- 1 root adm 195216 août 17 01:18 /var/log/syslog.1
-rw-r- 1 root adm 13242 août 16 01:17 /var/log/syslog.2.gz
-rw-r- 1 root adm2384 août 15 01:17 /var/log/syslog.3.gz
-rw-r- 1 root adm 11593 août 14 20:01 /var/log/syslog.4.gz
-rw-r- 1 root adm 11627 août 14 01:17 /var/log/syslog.5.gz
Alors que j'attendais plutôt à avoir (toujours dans le répertoire /var/log) :
syslog.20150816.gz, syslog.20150815.gz, syslog.20150814.gz, etc ou quelque
chose comme ça.
Aussi, qu'est-ce que je dois faire de plus pour que la commande logrotate
tienne compte de mes modifications pour les fichiers '/var/log/syslog' ?
Je dois aussi vous préciser que j'ai regardé les pages de manuel de Logrotate
sans que cela m'ait permis - apparemment - de m'avancer...
Je vous remercie d'avance de vos éventuels réponses, solutions, pistes... :-)
Pour terminer : peut-être que cela ne sert pas à grand chose (dans ce
contexte) mais je vous informe que j'utilise la version Oldstable donc Wheezy
GNU/Linux de notre distribution.
Cordialement et à bientôt,
Stéphane.
Re: Logrotate qui ignore le fichier '/etc/logrotate.d/rsyslog' modifié.
Salut,
Le 17/08/2015 13:03, Stéphane GARGOLY a écrit :
Bonjour à tous les utilisateurs et développeurs de Debian :
Ce vendredi 14/08/15, j'ai modifié le fichier '/etc/logrotate.d/rsyslog' en
ajoutant les paramètres dateyesterday et dateformat .%Y%m%d pour les
fichiers journaux '/var/log/syslog'.
D'ailleurs, je vous donne l'extrait du fichier '/etc/logrotate.d/rsyslog'
concernant les fichiers journaux '/var/log/syslog' (et après modification) :
/var/log/syslog
{
rotate 7
daily
dateyesterday
dateformat .%Y%m%d
missingok
notifempty
delaycompress
compress
postrotate
invoke-rc.d rsyslog rotate /dev/null
endscript
}
[…]
Malheureusement, il semblerait que Logrotate les ait ignorées si j'en crois au
résultat de la commande 'ls -l /var/log/syslo*' (que j'ai lancée aujourd'hui)
:
-rw-r- 1 root adm 48390 août 17 07:10 /var/log/syslog
-rw-r- 1 root adm 195216 août 17 01:18 /var/log/syslog.1
-rw-r- 1 root adm 13242 août 16 01:17 /var/log/syslog.2.gz
-rw-r- 1 root adm2384 août 15 01:17 /var/log/syslog.3.gz
-rw-r- 1 root adm 11593 août 14 20:01 /var/log/syslog.4.gz
-rw-r- 1 root adm 11627 août 14 01:17 /var/log/syslog.5.gz
Aussi, qu'est-ce que je dois faire de plus pour que la commande logrotate
tienne compte de mes modifications pour les fichiers '/var/log/syslog' ?
Je dois aussi vous préciser que j'ai regardé les pages de manuel de Logrotate
sans que cela m'ait permis - apparemment - de m'avancer...
Et bien il semblerait que tu ais raté quelque chose dans les pages de
man ;-)
Essaie de rajouter l'option « dateext » à ton fichier de conf.
dateformat permet de spécifier le format de la date lorsque dateext est
présent…
A+
Jean-Jacques
Re: Migration vers GCC5 laborieuse
Le 14/08/2015 16:20, Vincent Lefevre a écrit : On 2015-08-12 19:23:17 +0200, daniel huhardeaux wrote: Le 12/08/2015 17:38, C. Mourad Jaber a écrit : [...] Donc, ouais, il faut attendre… C'est violent tout de même, une phase experimentale, même longue aurait peut-être été préférable... Parce que là ça bloque tout SID pour longtemps ! [...] L'essence même de SID est unstable ! On sait donc à quoi s'attendre ;-) unstable, au sens où ça évolue. Là, c'est l'inverse: quasiment tout est bloqué! Dommage qu'il n'y ait pas un concept de branche pour les transitions, de manière à ce que sid soit affecté de manière atomique par une transition (pour le développement logiciel, on peut développer une fonctionnalité dans une branche et faire un merge dans le tronc à la fin). Rester en testing est la solution si l'on veut les dernières versions sans les ennuis possibles d'unstable. Ou le pinning comme proposé préalablement. Non, testing n'a pas les dernières versions. Par exemple pour iceweasel: iceweasel:amd64 38.1.0esr-3testing ftp.fr.debian.org iceweasel:amd64 38.1.1esr-1unstable ftp.fr.debian.org iceweasel:amd64 38.2.0esr-1~deb8u1 stable security.debian.org Tu peux avoir un Iceweasel à jour avec testing, il suffit d'ajouter cette ligne à ton fichier sources.list : deb http://mozilla.debian.net/ jessie-backports iceweasel-release $ apt-cache policy iceweasel iceweasel: Installé : 40.0-1~bpo80+1 Candidat : 40.0-1~bpo80+1 Table de version : *** 40.0-1~bpo80+1 0 500 http://mozilla.debian.net/ jessie-backports/iceweasel-release i386 Packages 100 /var/lib/dpkg/status 38.2.0esr-1~stretch 0 500 ftp://ftp.fr.debian.org/debian/ stretch/main i386 Packages 38.2.0esr-1~deb8u1 0 500 http://security.debian.org/ jessie/updates/main i386 Packages 31.6.0esr-1 0 500 ftp://ftp.fr.debian.org/debian/ jessie/main i386 Packages La page http://mozilla.debian.net propose un sélecteur de version pour Iceweasel et affiche la ligne qui va bien pour le sources.list. -- == | FRÉDÉRIC MASSOT | | http://www.juliana-multimedia.com | | mailto:frede...@juliana-multimedia.com | | +33.(0)2.97.54.77.94 +33.(0)6.67.19.95.69 | ===Debian=GNU/Linux===
Re: Wifi : connexion partielle (résolu)
J'ai installé wicd et mon wifi fonctionne correctement. me rappelle plus bien comment ça se goupille (il y a un moment que j'ai plus utilisé wicd) mais NetworkManager et Wicd font la même chose. Tu dois (de mémoire) pouvoir les installer tous les deux si tu veux, mais pas les utiliser en même temps (à supposer que ce soit possible de lancer les deux, ça risque d'être un sacré merdier). J'aurais donc tendance à te conseiller de désinstaller celui que tu n'utilises pas... dans un terminal $ systemctl | grep -i networkmanager $ systemctl | grep -i wicd te dira lequel des deux est lancé # systemctl | grep -i networkmanager NetworkManager.service loaded active running Network Manager # systemctl | grep -i wicd wicd.service loaded active running LSB: Starts and stops Wicd ce qui m'inquiete, c'est que si je veux enlever network-manager, il a l'air de vouloir enlever gnome et cinnamon # apt-get remove network-manager network-manager-gnome Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait Les paquets suivants seront ENLEVÉS : cinnamon gnome network-manager network-manager-gnome 0 mis à jour, 0 nouvellement installés, 4 à enlever et 1 non mis à jour. Après cette opération, 14,0 Mo d'espace disque seront libérés. Souhaitez-vous continuer ? [O/n] n avec aptitude, je ne suis pas sur de bien comprendre la question # aptitude remove network-manager network-manager-gnome Les paquets suivants seront ENLEVÉS : network-manager network-manager-gnome 0 paquets mis à jour, 0 nouvellement installés, 2 à enlever et 1 non mis à jour. Il est nécessaire de télécharger 0 o d'archives. Après dépaquetage, 13,0 Mo seront libérés. Les paquets suivants ont des dépendances non satisfaites : cinnamon : Dépend: network-manager-gnome mais il ne sera pas installé. gnome : Dépend: network-manager-gnome (= 0.9.10) mais il ne sera pas installé. Les actions suivantes permettront de résoudre ces dépendances : Supprimer les paquets suivants : 1) cinnamon 2) gnome Laisser les dépendances suivantes non satisfaites : 3) gnome-control-center recommande network-manager-gnome (= 0.9.8) 4) gnome-core recommande network-manager-gnome 5) task-gnome-desktop recommande gnome 6) task-gnome-desktop recommande network-manager-gnome Accepter cette solution ? [Y/n/q/?] si je réponds Y, il enleve QUE network-manager et network-manager-gnome et me prévient que gnome n'est pas complet ? ou il me l'enlève quand même ?
Re: Logrotate qui ignore le fichier '/etc/logrotate.d/rsyslog' modifié.
Bonjour à tous les utilisateurs et développeurs de Debian : Le lundi 17 août 2015 à 12:50, Jean-Jacques Doti b...@doti.fr a écrit : Le 17/08/2015 13:03, Stéphane GARGOLY a écrit : Ce vendredi 14/08/15, j'ai modifié le fichier '/etc/logrotate.d/rsyslog' en ajoutant les paramètres dateyesterday et dateformat .%Y%m%d pour les fichiers journaux '/var/log/syslog'. Malheureusement, il semblerait que Logrotate les ait ignorées si j'en crois au résultat de la commande 'ls -l /var/log/syslo*' (que j'ai lancée aujourd'hui) Aussi, qu'est-ce que je dois faire de plus pour que la commande logrotate tienne compte de mes modifications pour les fichiers '/var/log/syslog' ? Je dois aussi vous préciser que j'ai regardé les pages de manuel de Logrotate sans que cela m'ait permis - apparemment - de m'avancer... Et bien il semblerait que tu ais raté quelque chose dans les pages de man ;-) Essaie de rajouter l'option « dateext » à ton fichier de conf. dateformat permet de spécifier le format de la date lorsque dateext est présent… Je te remercie pour ta réponse, Jean-Jacques. ;-) A vrai dire, j'ai bien vu le paramètre dateext (dans les pages de manuel de Logrotate) mais, naïvement, je pensais que cela fait - quelque part - doublon ou superflu avec les deux autres paramètres dateyesterday et dateformat . %Y%m%d d'où mon omission tout à fait volontaire mais certainement erronée... Cependant et tout à l'heure, je compte ajouter dateext dans le fichier '/etc/logrotate.d/rsyslog'. Une dernière précision : dans mon précédent message, j'avais indiqué qu'après avoir apporté mes modifications, j'avais lancé la commande 'logrotate -f /etc/logrotate.conf'. Néanmoins, comme j'avais quelques doutes sur sa nécessité, j'avais posé la question en ce sens sur le canal IRC #debianfr (du serveur Freenode) et un des intervenants m'a assuré qu'on peut s'en passer car les modifications seront, de toute façon, prises en compte au prochain passage via Cron. Pour finir et pour peu que je n'aurai pas d'autre(s) surprise(s) concernant Logrotate, je vais passer ce fil de discussion en statut résolu - via un prochain message - dans quelques jours, après vérification par l'intermédiaire de la commande 'ls -l /var/log/syslo*'. :-) Cordialement et à bientôt, Stéphane.
Lenteur mailq et bizarrerie sudo + timeout
Bonjour, Je tente de superviser les mails systèmes que génèrent mes serveurs, pour cela j'ai un script qui tourne (en simple user) toutes les 5 minutes et qui fait en résumé : timeout 5s sudo mailq De temps en temps, j'ai un truc bizarre : - timeout ne semble pas faire son travail - mailq dure longtemps exemple time timeout 5s sudo mailq ; echo $? real0m12.246s user0m0.000s sys 0m0.000s 124 ~ 10secondes après == time timeout 5s sudo mailq ; echo $? real0m6.404s user0m0.004s sys 0m0.004s 124 plus tard (temps de générer ce mail) time timeout 5s sudo mailq ; echo $? real0m0.013s user0m0.000s sys 0m0.004s 0 un peu avant pour rigoler : = time mailq ; echo $? exim: permission denied real0m12.059s user0m0.000s sys 0m0.004s 1 La machine - passe son temps à ne rien faire (kimsuffi, 4cpu Intel(R) Xeon(R) CPU E3-1225 V2 @ 3.20GHz) - un top ou quasiment rien ne dépasse 1%CPU - ram 16G, avec un top tranquille (tri ascendant conso ram): top - 19:16:37 up 403 days, 4:45, 8 users, load average: 0,02, 0,07, 0,27 Tasks: 326 total, 1 running, 325 sleeping, 0 stopped, 0 zombie %Cpu(s): 0,1 us, 0,1 sy, 0,0 ni, 99,4 id, 0,4 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem: 16380392 total, 15832216 used, 548176 free, 1006832 buffers KiB Swap: 1050616 total,0 used, 1050616 free, 12696044 cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 9384 sshd 20 0 506m 215m 8696 S 0,3 1,3 24:59.68 mysqld 5411 root 20 0 96740 35m 3168 S 0,0 0,2 0:01.00 python2.7 5412 root 20 0 96748 35m 3168 S 0,0 0,2 0:00.86 python2.7 5410 root 20 0 96728 35m 3168 S 0,0 0,2 0:00.68 python2.7 1/ Pourquoi timeout ne semble pas efficace ? 2/ Pourquoi mailq dure aussi longtemps ? Merci de m'avoir lu :-)
Re: Re: ***SPAM***Re: Pilote propriétaire AMD Catalyst Legacy 13.1 sur Debian 8 Jessie
Parce que ce message a dû passer par une plateforme anti-spam placée chez vous ou dans votre réseau local/provider et elle a estimé ce message comme un SPAM... De même, le proxy/anti-virus/anti-spam de notre Ministère, rajoute [INTERNET] au sujet des messages extérieurs à l'administration autre que .gouv.fr) Il vous faut donc rechercher la raison de ***SPAM*** en interne. Cordialement. Pierre Le 16/08/2015 22:36, andre_deb...@numericable.fr a écrit : Pourquoi le sujet contient ***SPAM*** ? André -- Pro. Signature Pierre Touzeau -- Chargé de mission / Préfecture de region Basse-Normandie SGAR/rue Daniel HUET/14038 CAEN CEDEX/Tel: +33 231 306 306 pierre.touz...@basse-normandie.pref.gouv.fr / Fax: ... 564 --
Re: [1/2HS] modifier le nom d'un compte
On Sunday 16 August 2015 22:44:33 you wrote: On 08/14/2015 16:02, andre_deb...@numericable.fr wrote: Comment modifier le nom d'un compte sous Debian Jessie, en gardant intact son /home/user/ et ses données ? Il s'agit de modifier le compte ca en ca_ty. Une possibilité est de modifier les fichiers /etc/passwd /etc/shadow /etc/group si besoin. Remplacer la ligne qui commence par ca: en ca_ty: mais se documenter sur le format de ces fichiers. man 5 passwd man 5 shadow http://man7.org/linux/man-pages/man5/passwd.5.html http://man7.org/linux/man-pages/man5/shadow.5.html Il serait utile de s'assurer de pouvoir toujours se connecter en root et/ou via sudo (par exemple, créer un autre utilisateur de secours, au cas où...) J'avais déjà essayé, suite à une info via google (ou alphabet), et ça a été la cata, je suis vacciné... : L'option usermod -l ... me parait plus sûres, j'avais tenté via /etc/passwd et /etc/shadow = la cata ! Maintenant, je ne vois pas bien l'intérêt de modifier le user ca en ca_ty. librement Les noms de user ont leur raison que la raison ne connait pas... :-) André
