Even we have also similar configuration but it’s not working..
Our config file: /etc/logrotate.d/httpd24-httpd
/var/log/httpd24/*log {
daily
compress
missingok
notifempty
sharedscripts
delaycompress
rotate 90
postrotate
/sbin/service httpd24-httpd reload > /d
In this case, I switched over to apache 2.4 on RHEL6 because a couple
modules on some of our websites no longer supported the base php 5.3. When
I asked why, I was given "Why are you still using RHEL6?" as the reason
they would not be supporting my config. Since your question came up I
thought I
"why are you still using RHEL6?" --> It’s an client requirement to continue
with RHEL 6.
I don’t see such scenario you stated below for the rotation. Do we have any
other configuration files to update in RHEL 6 server to Apache log rotation?
Thanks & Regards
We have upgraded only Apache and I see the other OS related logs rotating fine
but the issue is only with Apache logs(access.log,error.log).
Thanks & Regards
--
Srikanth Pippari | V3OPS team.
Email ID : spipp...@vitechinc.com
--
We have a similar setup and the log actually **does** rotate, but instead
of archiving the active log to the next numbered log and renumbering them
down the line, it actually instead moves the active log to the next archive
number and moves the rest down the line. So for example, instead of
today'
On Tue, May 28, 2019 at 2:09 PM Srikanth Pippari
wrote:
>
> Hello,
>
>
>
> We have upgraded Apache 2.2 version to Apache 2.4.34 version on Red Hat
> Enterprise Linux Server release 6.10 (Santiago) server . After the upgrade
> the log is not rotating and we also check the log rotation file confi
Hello,
We have upgraded Apache 2.2 version to Apache 2.4.34 version on Red Hat
Enterprise Linux Server release 6.10 (Santiago) server . After the upgrade the
log is not rotating and we also check the log rotation file config looks good .
Can some one help me to figure out the issue..
Below is
Hi,
I'm looking for a way to track users who is using client certificate to log
in to Apache HTTPD. Especially, I wanted to know who is trying to use
revoked certificates to attempt login. Is there any possible way to log
some of the certificate information, such as the certificate's serial
number
