Change time zone for syslog messages in syslog-ng

When sending syslog packets to a remote server the time-zone of the current server may lead to problems because the syslog-ng program sets the time-zone with offset number according to the GMT. The remote server, especially if not a syslog-ng one, may interpret the offset as an offset to the UTC (Coordinated Universal Time), which leads times with an hour into the future.

main menu
configuration in syslog-ng

Note, this whole problem is because of the Daylight saving time and there are almost 6 months when the GMT is not equal to the UTC and it is an hour ahead. Probably it is not a good idea to offset according to the GMT, because of the Daylight saving time during the summer, but this is on the syslog-ng development side.
There is one option time-zone(“[time_zone_string]”), which allows to change the time-zone of the destination packets. To avoid misinterprets of the date and time in the message packets the best way is to use it with UTC, so the local system will do the all necessary to convert the local time to UTC properly.
The configuration below uses time-zone(“[time_zone_string]”) from the current local time to UTC, because the current local time zone is EEST (Eastern European Summer Time), which 3 hours ahead of UTC during the summer period and 2 during winter (Eastern European Time – EET).

Relay the local web server logs from the local UDP port to the remote server using reliable TCP connection and changing the local time to UTC of the packets.

#NGINX - web logs
source udp_local {
    network(ip( port(514) transport("udp") so_rcvbuf(67108864) log_fetch_limit(1000) max-connections(1000) log-iw-size(1000000));

filter filter_nginx_access_log { program(nginx); };
destination d_tcp_syslog {
         port(10514) transport("tcp") disk-buffer(mem-buf-length(10000) mem-buf-size(128M) disk-buf-size(1024M) reliable(yes) dir("/var/lib/syslog-ng"))
log { source(udp_local); filter(filter_nginx_access_log); destination(d_tcp_syslog); };

the time_zone(“UTC”) in destination rule will ensure the packets have proper time related to the local server’s time in UTC and the mistake of misinterpreted date time is unlikely on a remote server.
More articles with syslog-ng

Virtualbox machine boots from usb drive

First, at present, booting from USB is impossible with VirtualBox! But there is a really easy workaround to use VMDK, which is just a container file describing physical devices (or files) to use in virtual machines like VirtualBox or VMware.
Because the USB is just another physical device attached to the machine this article will help to attach the USB drive to a virtual machine – Add a raw disk to a virtualbox virtual machine. Then boot from the newly attached disk.

Here is the quick tip for the USB drive:

  1. Attach the USB drive and find its device path. Under Windows, it would be something like “\\.\PhysicalDrive3” (open “Disk Management” if not sure) and under Linux it would be /dev/sdc, for example. This is the third disk device (including USB disk devices) connected to the machine.
  2. Make the VMDK from the USB physical device.
    Under Windows:

    VBoxManage.exe internalcommands createrawvmdk -filename "c:\Users\homer\.VirtualBox\windows11pro-install-usb.vmdk" -rawdisk \\.\PhysicalDrive3

    Under Linux:

    VBoxManage internalcommands createrawvmdk -filename /home/myuser/.VirtualBox/windows11pro-install-usb.vmdk.vmdk -rawdisk /dev/sdc
  3. Attach it the virtual machine: Settings -> Storage -> Storage Devices.

    First, a click on “Adds hard disk” would show a menu to add a new hard disk and then a click on “Add” (“Add Disk Image”) shows a file browse dialog to locate the VMDK file.

    main menu
    Storage Devices
  4. Boot from this device by selecting it manually from the boot menu (F12 would boot in Boot menu) or set the VMKD disk to be on the Port 0 in the above step.

For more details (not just the commands to generate the VMDK container file) follow the above URL to the proposed article – Add a raw disk to a virtualbox virtual machine

Debug options for LXC and lxc-start when lxc container could not start

Setup and running LXC container is really easy, but sometimes it is unclear why the LXC container could not start. Most of the time, there is a generic error, which says nothing for the real reason:

root@srv ~ # lxc-start -n test-lxc
lxc-start: test-lxc: lxccontainer.c: wait_on_daemonized_start: 867 Received container state "ABORTING" instead of "RUNNING"
lxc-start: test-lxc: tools/lxc_start.c: main: 306 The container failed to start
lxc-start: test-lxc: tools/lxc_start.c: main: 309 To get more details, run the container in foreground mode
lxc-start: test-lxc: tools/lxc_start.c: main: 311 Additional information can be obtained by setting the --logfile and --logpriority options

No specific reason why the LXC container test-lxc can not be started and the lxc-start command failed. There is just an offer to use the logging options and here is how the administrator of the box may do it by including the following lxc-start options:

-l DEBUG –logfile=test-lxc.log –logpriority=9

Here is a real-world example of an old kernel trying to run LXC 4.0
Keep on reading!