Bug #8418
open
Configuration files do not get updated when user has modified the stock ones
Description
Edit: the logrotate problem is linked to a configuration file not correctly updated during upgrade. That's why the title does not match the description.
Please have some kind of log-rotation enabled for non-compliant-reports.log, otherwise it might get veeery big:
ruddersrv:/var/log/rudder/compliance # ll -h non-compliant-reports.log -rw-r----- 1 root root 7.4G May 30 11:56 non-compliant-reports.log
Our for example currently holds the logs since [2015-10-16 04:39:20+0200].
Updated by Nicolas CHARLES over 8 years ago
- Category set to System integration
- Status changed from New to Discussion
- Assignee changed from Nicolas CHARLES to Janos Mattyasovszky
Hi Janos,
This file is already rotated, over 365 days, and compressed (configuration is in /opt/rudder/etc/logback.xml)
You should have the following entry in /opt/rudder/etc/logback.xml
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<fileNamePattern>${REPORT_DIR}/non-compliant-reports-%d{yyyy-MM-dd}.log.gz</fileNamePattern>
<maxHistory>365</maxHistory>
</rollingPolicy>
Could you confirm you do have this entry - or not ?
Updated by Nicolas CHARLES over 8 years ago
- Related to Bug #6381: File /var/log/rudder/{compliance/non-compliant-reports.log, core/rudder-webapp.log} are not correctly rotated added
Updated by Janos Mattyasovszky over 8 years ago
Hi
No, it is not in there (having rudder-webapp-3.0.13 on SLES11):
rudderserver:/var/rudder/configuration-repository # grep on-compliant-reports -C3 /opt/rudder/etc/logback.xml
A file log appender for exploitation logs about failure reports.
-->
<appender name="REPORTLOG" class="ch.qos.logback.core.FileAppender">
<file>${REPORT_DIR}/non-compliant-reports.log</file>
<append>true</append>
<encoder>
<pattern>%msg%n</pattern>
--
<!-- Here come non compliant reports logger -->
<logger name="non-compliant-reports" level="info" additivity="false">
<appender-ref ref="REPORTLOG" />
</logger>
Also having a 1yr-rotation is not well suited for bigger installations, it would make more sense to rotate it depending on the size, not on the age...
Updated by Nicolas CHARLES over 8 years ago
It definitively should be there - did you refuse the update of this file during an upgrade ?
As for the rotation, it is rotated every day, gzipped, and each gzip are keep for one year.
Obviously, you can change it in the log config file
Updated by Janos Mattyasovszky over 8 years ago
Nicolas CHARLES wrote:
It definitively should be there - did you refuse the update of this file during an upgrade ?
Where do I get the chance to refuse something like this? :-)
NB: Our updates are not user-interactive.
Updated by Janos Mattyasovszky over 8 years ago
This is related to the fact, that the spec file is:
%config(noreplace) %{rudderdir}/etc/logback.xml
Causing the logback.xml not to be modified if there is any modification done on the file.
Updated by Nicolas CHARLES over 8 years ago
- Status changed from Discussion to New
- Assignee changed from Janos Mattyasovszky to Benoît PECCATTE
Janos Mattyasovszky wrote:
Nicolas CHARLES wrote:
It definitively should be there - did you refuse the update of this file during an upgrade ?
Where do I get the chance to refuse something like this? :-)
NB: Our updates are not user-interactive.
Ha - on .deb systems, question is asked, and default is to take maintainer version.
So this sounds like a packaging issue, redirecting it to Benoît for proper investigation on why the file is not updated at update
Updated by Benoît PECCATTE over 8 years ago
- Assignee changed from Benoît PECCATTE to Nicolas CHARLES
On RPM systems, all our (pseudo-)configuration files are %config(noreplace) which mean we don't replace them, but a .rpmnew file is created instead.
@Janos Matya you should have a logback.xml.rpmnew that contains the expected configuration file
@Nicolas we should talk about this with everyone on a file by file basis, since either we have a %config and we always override user configuration or a %config(noreplace) and we never override it
Updated by Janos Mattyasovszky over 8 years ago
Yes, I missed the .rpmnew file, silly me.
Now I have to modify my rudder-customization script to always look for .rpmnew files, move them to overwrite the original and apply my modifications on the updated ones... yaay.
Updated by Benoît PECCATTE over 8 years ago
And do you think we should change this behaviour for some files that are seldom modified by the user ? like logback or the apache configuration ?
Updated by Janos Mattyasovszky over 8 years ago
- Subject changed from No logrotate for non-compliant-reports.log to Configuration files do not get updated when user has modified the stock ones
- Assignee changed from Nicolas CHARLES to Janos Mattyasovszky
Changed the topic since it is there in the .rpmnew file, so the actual question is if this is a desired outcome or not.
Updated by Janos Mattyasovszky over 8 years ago
- Assignee changed from Janos Mattyasovszky to Nicolas CHARLES
Updated by François ARMAND over 8 years ago
- Related to Bug #8172: Upgrade from 2.11 to 3.1 on sles does not preserve the rudder-jetty java parameters added
Updated by François ARMAND over 8 years ago
Adding the link to #8172 because it seems to be in the same topic and a generic solution must work for both.
Updated by Nicolas CHARLES about 8 years ago
- Assignee changed from Nicolas CHARLES to Benoît PECCATTE
Changing the assignee to a person who knows packaging, and understand the impact of the possible changes
Updated by Benoît PECCATTE over 7 years ago
- Severity set to Minor - inconvenience | misleading | easy workaround
- User visibility set to Operational - other Techniques | Technique editor | Rudder settings
Updated by Jonathan CLARKE
Updated by François ARMAND about 5 years ago
- Related to Bug #8643: Rudder apache config should be replaced on update added