changing the default log rotate config for kerberos - kerberos

I notice that the default kerberos configuration to rotate the log files is monthly. I don't find any option to control this through the Kerberos config file - krb5.conf. If the configuration needs to be changed to, say, daily, do I need to overwrite the entries in /etc/logrotate.d/kadmind and /etc/logrotate.d/krb5kdc?
<Log Dir>/krb5kdc.log {
missingok
notifempty
monthly
rotate 12
postrotate
/bin/kill -HUP `cat /var/run/krb5kdc.pid 2>/dev/null` 2> /dev/null || true
endscript
}

One day, I found one of our Kerberos servers was out of space. I found Kerberos does not handle logs rotate by default. That’s why it ate a lot of space. So, here is the way to make Kerberos logs rotate.
Editing /etc/logrotate.d/krb5kdc file vi /etc/logrotate.d/krb5kdc
/var/log/krb5kdc.log {
missingok
notifempty
create 0640 root root
postrotate
/etc/init.d/krb5kdc condrestart >/dev/null 2>&1 || true
endscript
}
And editing /etc/logrotate.d/kadmin file
/var/log/kadmind.log {
missingok
notifempty
create 0640 root root
postrotate
/etc/init.d/kadmin condrestart >/dev/null 2>&1 || true
endscript
}
After you edited these two files, it will do the logs rotate by itself, weekly. If you would like to test logs rotate, you can use following command :
logrotate -f -v /etc/logrotate.conf

Related

Understand existing Postgres WAL archiving setup filling up the disk

New to a certain Postgres implementation done by someone else and need help figuring out an issue.
We have the following archive command configured, If I understand correctly then the archive command copies WAL files to a mounted storage /mnt/database:
archive_command = 'if { egrep -q " /mnt/database .* rw," /proc/mounts ;} && { ! pgrep test -u postgres ;} ; then test ! -f /mnt/database/%f && cp %p /mnt/database/%f ; else exit 1; fi'
We then have a cron job to move corrupted WALs out of the way:
find /mnt/database -type f -regextype posix-extended -regex ".*[A-Z0-9]{24}$" -mmin +60 -size -16777216c -exec logger "Trimming Postgres WAL Logs" \; -exec find /var/lib/pgsql/9.6/data/pg_xlog/{} -type f \; -exec mv {} {}.incomplete \;
The issue we are having is the /mnt/database keeps filling up and we need to extend the disk every few days. Is that because we have excessive WAL writing or too many corrupted WAL files ?
The live WAL in 'pg_wal' cleans itself up automatically. Your WAL archive, '/mnt/database/' here, does not. It is up to you to arrange for that to get cleaned up based on your organization's retention policy.
If your policy is to keep WAL forever, then you need to get enough storage space to do that. If you have some other policy, you would need to understand what it is (and describe it to us, if you want our help implementing it)
Neither of the commands you show seem to be related to retention.

Log rotate is not working in Centos 6.6 MongoDB 3.2.12

I installed mongoDB 3.2.12 in my linux machine Centos 6.6, Log rotate is not working and i have placed my configuration files here below . Can anyone help me on that?
/etc/logrotate/mongodb
/var/log/mongodb/*.log {
daily
size 10K
rotate 1
compress
dateext
delaycompress
copytruncate
notifempty
postrotate
/bin/kill -SIGUSR1 `cat /var/lib/mongodb/mongod.lock 2> /dev/null` 2> /dev/null || true
endscript
}
mongod.conf
logAppend: true
logRotate: reopen
In my case my logrotate file was here /etc/logrotate.d/mongod with following:
/var/log/mongodb/*.log {
daily
missingok
rotate 5
compress
dateext
delaycompress
copytruncate
notifempty
}
So it appears that your path to logrotate config is incorrect. You listed /etc/logrotate/mongodb but I am pretty sure it should be /etc/logrotate.d/mongod. Your mongod.conf appear to be same as mine. Also i had to test that logs are rotated correctly by manually issuing logrotate command:
logrotate -f /etc/logrotate.d/mongod

postgresql can not start after change the data_directory

I use postgresql on Debian.
The postgresql service can not start after I edit the config file:
#data_directory = '/var/lib/postgresql/9.4/main' # use data in another directory
data_directory = '/opt/data/postgresql/data'
(yeah,I just use custom directory instead of the default data_directory)
I find the log in /var/log/syslog
Sep 14 10:22:17 thinkserver-ckd postgresql#9.4-main[11324]: Error: could not exec /usr/lib/postgresql/9.4/bin/pg_ctl /usr/lib/postgresql/9.4/bin/pg_ctl start -D /opt/data/postgresql/data -l /var/log/postgresql/postgresql-9.4-main.log -s -o -c config_file="/etc/postgresql/9.4/main/postgresql.conf" :
Sep 14 10:22:17 thinkserver-ckd systemd[1]: postgresql#9.4-main.service: control process exited, code=exited status=1
Sep 14 10:22:17 thinkserver-ckd systemd[1]: Failed to start PostgreSQL Cluster 9.4-main.
Sep 14 10:22:17 thinkserver-ckd systemd[1]: Unit postgresql#9.4-main.service entered failed state.
And nothing in /var/log/postgresql/postgresql-9.4-main.log
Thanks.
I finally got this answer:
What this error means in PostgreSQL?
#langton 's answer.
He said that
you should run pg_upgradecluster or similar, or just create a new cluster with pg_createcluster (these commands are for debian systems - you didn't specify your OS)
So I executed the command:
pg_createcluster -d /opt/data/postgresql/data -l /opt/data/postgresql/log 9.4 ckd
And then :
service postgresql restart
it started!
If downtime is allowed and you already have databases with data in the old cluster location you only need to physically copy the data to the new location.
This is a more or less common operation if you partition is out of space.
# Check that current data directory is the same that
# the one in the postgresql.conf config file
OLD_DATA_DIR=$(sudo -u postgres psql --no-psqlrc --no-align --tuples-only --quiet -c "SHOW data_directory;")
echo "${OLD_DATA_DIR}"
CONFIG_FILE=$(sudo -u postgres psql --no-psqlrc --no-align --tuples-only --quiet -c "SHOW config_file;")
echo "${CONFIG_FILE}"
# Stop PostgreSLQ
systemctl stop postgresql
# Change the data directory in the config
# Better to do it with an editor, instead of sed
NEW_DATA_DIR='/opt/data/postgresql/data'
sed -i "s%data_directory = '${OLD_DATA_DIR}'%data_directory = '${NEW_DATA_DIR}'%" "${CONFIG_FILE}"
# Move/Copy the data for example using rsync
rsync -av --dry-run "${OLD_DATA_DIR}" "${NEW_DATA_DIR}"
# Take care with the classical issues of rsync and end backslashes
rsync -av "${OLD_DATA_DIR}" "${NEW_DATA_DIR}"
# Rename the old dir, just to avoid missunderstandings and set
# check the permissions on the new one
# Start postgres
systemctl start postgresql
# Check that everything goes well and eventually drop the old data
# Make sure that the logs and everything else is where you want.

Problems with permissions for logrotate

I'm writing my own logrotate configuration for some web application:
/home/me/public_html/logs/*.log {
daily
missingok
rotate 15
compress
delaycompress
notifempty
create 0660 me www-data
nosharedscripts
}
But running logrotate for these files results in:
$ sudo logrotate -d -v *.log
Ignoring logfile1.log because of bad file mode.
Ignoring logfile2.log because of bad file mode.
Ignoring otherlogfile.log because of bad file mode.
Handling 0 logs
$ ls -l
-rw-rw---- 1 me www-data 893584 Jan 27 16:01 logfile1.log
-rw-rw---- 1 me www-data 395011 Jan 27 16:01 logfile2.log
-rw-rw---- 1 me www-data 4949115 Jan 27 16:01 otherlogfile.log
Is this related to the file permissions of the actual logfiles in the directory of to the permissions specified with create 0660 me www-data?
If I change the filepermissions to -rw-r----- and the create line to
create 0640 me www-data
I get
$ sudo logrotate -d -v *.log
Ignoring logfile1.log because the file owner is wrong (should be root).
Ignoring logfile2.log because the file owner is wrong (should be root).
Ignoring otherlogfile.log because the file owner is wrong (should be root).
Handling 0 logs
My system is a debian testing/jessie.
Ok, stupid situation. The logrotate command has to be executed on the configuration file instead of the log file.
$ sudo logrotate -d -v /etc/logrotate.d/my-app
It seems to be important that the parent directory of the logfile is not world writable (------rw-) and not writable by any non root group (---rw----). Otherwise, you will see:
error: skipping "/home/me/public_html/logs/logfile1.log" because parent
directory has insecure permissions (It's world writable or writable by
group which is not "root") Set "su" directive in config file to tell
logrotate which user/group should be used for rotation.

logrotate mail script on /var/spool/mail/*

Does it make sense to create a script like this or is it possible that the spool files can get corrupted?
I want to be able to control the maximum mail spool file size to 500MB or keep it for a month, archive the rest, whichever comes first:
/var/spool/mail/* {
monthly
size 500M
missingok
rotate 24
notifempty
sharedscripts
}
I didn't use logrotate for this. What I did instead was redirect the spool files to /dev/null to clean them out. I also stopped my email service before and started it after the cleanup. You can tailor this as you wish
echo "emailclean.sh starting on $(date)"
echo "Stopping fetchmail service"
#/sbin/initctl stop <service>
pkill fetchmail
sleep 10
echo "Cleaning up old mail"
cat /dev/null > /var/spool/mail/root
cat /dev/null > /var/spool/mail/webalert
sleep 10
echo "Starting fetchmail Service as user webalert"
sudo -u webalert /usr/bin/fetchmail
#/sbin/initctl start <service>
echo "Cleanup Complete! /var/spool/mail/root and webalert files sent to dev0"
echo "emailclean.sh finished cleanup on $(date)"