Background
I remember it was a beautiful winter evening, when it suddenly became clear that there was a problem with Kerio Control.
Kerio Control could not write the changes to the configuration and some kind of devilry was happening!
The diagnosis was quick and accurate - the Kerio Control system disk ran out of space.
The reason, the big old log.
There were several solutions:
- Clear logs
- Increase system disk space
- Add additional disk for logs
The latter seemed the most logical.
Indeed, we are not looking for easy ways, but we are trying to do the job conscientiously, so that this does not happen again and nothing could ruin another wonderful evening.
A sophisticated reader of the article will immediately say - but let Kerio itself be able to clean up the logs and store the logs in a well-defined time frame.
Yes, he can, but the log got out in volume from the time interval specified on the server. How to deal with this situation?
Decision
Kerio Control Virtual Appliance is a virtual machine that lives on one disk, the solution seemed very simple:
- Add an additional virtual disk in the hypervisor
- Make ext4 or ext3 markup
- Add new disk mount to fstab
- Find the Kerio config file and specify a new path for the logs.
BUT NO!
Starting with “Add new disk mount to fstab” something went wrong.
As it turned out, Kerio didn't care about fstab.
The disk was perfectly mounted manually, but the automatic one did not want something after starting.
After long wandering through the file directories in search of something unknown, my attention was attracted by the 05basefs file , namely, I really liked the following inscriptions - base and fs , but 05 was not at all interested. After examining its contents, I realized that the file system is mounted here.
Then everything seemed simple, for a long time there is a file winroute.CFG, all settings are stored there, you can also specify the path to the directory with logs there.
But as it turned out, I was wrong here, Kerio pays attention to new paths in the configuration file, but something does not work, the log after changing the paths brings down errors or does not display anything at all.
Well, okay, let's mount a new disk at the current location of the log!
Implementation
After all the above, the implementation is very simple.
First, we need to connect to the Kerio Control terminal, the easiest way to do this is using SSH.
Temporarily enable SSH access.
To do this, you need to log in to the admin panel and go to the "System status" section while holding down the Shift key.
If you did everything correctly, an SSH activation button will appear at the bottom next to the server restart button:
Temporarily activate SSH (do not forget to disable it after setting up!)
After enabling SSH, you can connect to the server using the SSH client.
It is better to use a client that can immediately copy files to the server, I will explain why later.
So what we have now:
- We created and connected a new disk to the server
- Marked it up in ext4 or ext3
- Activated SSH and connected to the server
Next, we need to fix the 05basefs file located in the following path . \ Etc \ boxrc.d \ 05basefs .
But before you edit it, you need to do two more things.
The first is to find out the dev of the new disk for logs.In
order to find out the name of the disk, execute lsblk and get something like
where:
- SDA - system disk
- sda1 - bootloader
- sda2 and sda3 - the current and apparently previous version of Kerio
- sda4 - Var here config and default logs
- SDB is our new disk
In the event that we need to save the current logs, we need to temporarily mount the sdb disk in any empty directory and transfer the contents of / var / winroute / logs to the mounted sdb.
After the transfer, unmount sdb.
The second is to allow the file system to modify system files
Kerio mounts the system disk where 05basefs is located with read-only rights.
to see what where and how we perform mount premoted
You can see that / dev / sda2 is in the RO state , and that is where the current version of Kerio is located and 05basefs is also there.Temporarily enable
writing to / dev / sda2 with the mount -o rw command , remount / dev / sda2
Now, you can fix the 05basefs file, I personally prefer to copy the already corrected file, this is convenient, since having done this once, you will have to repeat the file replacement procedure every time after updating the Kerio version, since the original 05basefs is restored with the new version.
You can also use the vi editor to change the file - it is in the system.
Change 05basefs as follows
#!/bin/sh
# $Revision: 1.13 $
case "$1" in
start)
grep -q /tmp /proc/mounts || mount -t tmpfs tmp /tmp
mkdir -p /tmp/run
root=$(grep " / " /proc/mounts | grep -v rootfs | sed 's/ .*//')
DATA=${root%[23]}4
BOOT=${root%[23]}1
modprobe ext3
mount -o ro -t ext3 $BOOT /boot
if [ ! -z "$DATA" ] && ! mount -o data=ordered $DATA /var 2>/dev/null; then
echo "Creating new data partition..."
#mkfs.nilfs2 -b 1024 $DATA
mkfs.ext3 -b 4096 -q $DATA 2>&1
tune2fs -c 0 -i 0 -r 0 -E stride=512,stripe-width=512 $DATA
fsck -p $DATA
mount -o data=ordered $DATA /var
[ -d /var.default ] && cp -a /var.default/* /var
elif [ -f "/var.default/update.list" ]; then
for i in `cat /var.default/update.list`; do
[ -e "/var.default/$i" -o -h "/var.default/$i" ] || continue
! [ -e "/var/$i" -o -h "/var/$i" ] || continue
mkdir -p $(dirname "/var/$i")
cp -a "/var.default/$i" "/var/$i"
done
fi
mount -t ext4 /dev/sdb /var/winroute/logs
exit 0
;;
stop)
echo "Umounting data partition..."
for i in $(seq 1 10); do
if fuser -sm /var; then
sleep 1
else
break
fi
done
fuser -kms /var/winroute/logs
umount /var/winroute/logs
fuser -kms /var
umount /var
;;
*)
echo "Usage: $0 {start|stop}"
exit 1
;;
esac
Explanations of changes in the file
mount -t ext4 / dev / sdb / var / winroute / logs
mounts sdb on the original log path / var / winroute / logs
fuser -kms / var / winroute / logs
umount / var / winroute / logs
Unmounts sdb for correct shutting down the server.
Now we will return sda2 to its original state with the command mount -o r, remount / dev / sda2
After the server reboots, Kerio will write logs to our dedicated SDB disk.
Crutch
(after all, one cannot do without a crutch)
As I stated earlier, if the Kerio version is updated, the 05basefs file will return to its original state, Kerio will start writing logs to sda4 again. Along the path / var / winroute / logs.
In order for Kerio to continue writing the log to SDB, you must repeat the file replacement procedure.