Author : Adiscon Support

rsyslog on AWS – Update an existing CloudFormation stack

Welcome to this guide on updating an existing CloudFormation stack for the rsyslog server on AWS. In this tutorial, we will walk you through the steps necessary to ensure your rsyslog server is running the latest version with all the benefits of updated features and performance improvements. We will provide detailed instructions and screenshots to make the update process straightforward, ensuring minimal disruption to your logging setup. Whether you’re a seasoned AWS user or new to CloudFormation, this guide will help you achieve a smooth and efficient update.

Prerequisites

If changes were made to the rsyslog configuration, use the guide in this article to back up and restore configuration: AWS rsyslog Sync Configuration with S3.

Step 1: Select the CloudFormation Stack

To begin the update process for your rsyslog server on AWS, first, navigate to the AWS Management Console and go to the CloudFormation section. Here, locate the stack you wish to update.

  1. Visit AWS CloudFormation: Log in to your AWS Management Console and go to the CloudFormation service.
  2. Select Your Stack: Identify and select the CloudFormation stack for your rsyslog server. In this example, the stack is named “rsyslogtest”.
  3. Initiate Update: Click on the Update button, as highlighted in the screenshot above.

This will start the process to update your existing CloudFormation stack.
Click Update to proceed.

Step 2: Prepare the Template

After selecting the stack to update, the next step involves preparing the template for the update. Follow these instructions:

  1. Choose Template Option: In the “Prepare template” section, select the Replace existing template option.
  2. Specify Template Source: Under “Template source”, choose Amazon S3 URL.
  3. Enter S3 URL: Enter the following URL in the provided field:
   https://rsyslogpublic.s3.amazonaws.com/office_rsyslog_server.yaml

Alternatively, you can use the template URL provided on the AWS Marketplace product page for the rsyslog server.

This will prepare the new template to be applied to your existing stack.
Click Next to proceed.

Step 3: Specify Stack Details

After preparing the template, proceed to specify the stack details:

  1. Review Parameters: Ensure all parameters are correct. Adjust as necessary.
  2. Instance Settings:
  • Identifier Name: Change if necessary.
  • EC2 Instance Type: Change if necessary, as a new instance will be deployed.

Review all options carefully in case new features have been added.
Once all configurations are reviewed and adjusted, click Next to proceed.

Step 4: Configure Stack Options and Review

Review the stack options and make any necessary adjustments.

  1. Review Changes: Carefully review the list of changes in the “Change set preview”. Ensure all modifications align with your expectations.
  2. Submit: Once everything is reviewed and confirmed, click the Submit button to start the update process.

After clicking Submit, AWS will begin updating your CloudFormation stack. Monitor the progress to ensure the update completes successfully. If any issues arise, refer to the stack events for troubleshooting.

Step 5: Monitor the Update Process

  1. Monitor Progress: Check the events tab to monitor the progress of the update. The status should show “UPDATE_IN_PROGRESS” and various components being modified.
  2. Confirm Completion: When the update completes, ensure the status changes to “UPDATE_COMPLETE”.

Once the process is complete, verify that the CloudFormation stack was updated successfully by checking the final status and confirming that all intended changes were applied correctly.

Confirm EC2 Instance Running rsyslog Server

  1. Access the EC2 Instance: Use SSH to log in to your EC2 instance running the rsyslog server.
  2. Verify rsyslog: Once logged in, confirm that the rsyslog server is running properly. You should see the rsyslog welcome message, indicating that the application is installed and operational.

Check the rsyslog meta configuration located in /opt/rsyslog/config to ensure all settings are correct and the service is functioning as expected. This final verification confirms the successful update of your CloudFormation stack and the deployment of the new rsyslog server instance.

Back to aws rsyslog overview.

rsyslog on AWS – Version changelog

S2: v13 rsyslog

We are excited to announce the second public release of Rsyslog Server on AWS Marketplace. This version includes efficient logging, noise event filtering, and a streamlined web interface for system management. New features: Cloudwatch LogGroups, logfile compression, S3 log/config storage, enhanced CloudFormation support, and improved AWS region handling. Experience enhanced logging capabilities and simplified management with Rsyslog Server.

Key Features:

  • Cloudwatch LogGroups Integration: Now you can leverage AWS Cloudwatch LogGroups for better log management and analysis directly through our CloudFormation templates.
  • Logfile Compression: Enabled logfile compression to optimize storage and improve performance.
  • S3 Bucket Support: Added S3 support for both log storage and configuration backup, ensuring your data is safely stored and easily accessible.
  • Improved AWS Region Handling: Fixed issues with AWS_REGION in rsyslogctl to automatically use the correct region configuration.
  • Configuration Sync to S3: Fixed the sync_config_history_to_s3 feature, ensuring your configuration history is consistently backed up.
  • Enhanced CloudFormation Features: Added new features, including S3 support, access policies, and additional InstanceTypes, to our CloudFormation file for easier and more flexible deployments.
  • EFS Resource Management: Added Delete and Retain policies to EFS resources to ensure they survive a Stack Update.

S2: v12 rsyslog

We are excited to announce the inaugural public release of the official Rsyslog Server product on AWS Marketplace. This release introduces an efficient logging solution right out of the box. Additionally, it empowers users with seamless configuration options to filter out noise events and includes a streamlined web interface for system operation management. Get ready for enhanced logging capabilities and simplified management with the Rsyslog Server.

Back to aws rsyslog overview.

rsyslog on AWS – Sync Configuration with S3

Ensuring the integrity and availability of your rsyslog configuration is crucial for maintaining a robust logging system. By syncing your rsyslog configuration to AWS S3, you create a reliable backup that can be easily restored when needed. This guide will walk you through the process of syncing your rsyslog configuration to S3 and restoring it when necessary.

Prerequisites

Before you begin, ensure you have the following:

Syncing Configuration History to S3

This command synchronizes the current rsyslog configuration history to a specified S3 bucket. It ensures all configuration changes are backed up, providing a reliable recovery solution.

sudo rsyslogctl sync-config-history-to-s3

When executed, this command uploads your rsyslog configuration history to the S3 bucket configured in your settings. Regular execution of this command, especially after making significant changes, ensures your backups are always current.

Restoring Configuration from S3

This command downloads the rsyslog configuration history from an S3 bucket to the local machine, facilitating configuration restoration.

sudo rsyslogctl sync-s3-to-config-history

Executing this command retrieves the configuration history from S3 and applies it to your local rsyslog setup.

Back to aws rsyslog overview.

RSyslog Windows Agent 4.3c Released

Adiscon is proud to announce the 4.3c release of Rsyslog Windows Agent.

This release contains some a minor bugfix.

Detailed information can be found in the version history below.

Build-IDs: Service 4.3.0.178, Client 4.3.0.255

Version 4.3c is a free download. Customers with existing 3.x keys can contact our Sales department for upgrade prices. If you have a valid Upgrade Insurance ID, you can request a free new key by sending your Upgrade Insurance ID to sales@adiscon.com. Please note that the download enables the free 30-day trial version if used without a key – so you can right now go ahead and evaluate it.

Bugfixes

  • Property Engine: Fixed a bug that caused the first dynamic property to be missing when using XML report format. This bug also affected the Syslog TCP File-Caching feature (%rawsyslogmsg% missing).

RSyslog Windows Agent 4.3b Released

Adiscon is proud to announce the 4.3b release of Rsyslog Windows Agent.

This release contains some a minor bugfix.

Detailed information can be found in the version history below.

Build-IDs: Service 4.3.0.177, Client 4.3.0.255

Features

Bugfixes

  • Property Engine: Fixed a bug related to the compressspace property replacer option that surfaced after recent stability changes. The bug stopped the option from working properly.

Version 4.3b is a free download. Customers with existing 3.x keys can contact our Sales department for upgrade prices. If you have a valid Upgrade Insurance ID, you can request a free new key by sending your Upgrade Insurance ID to sales@adiscon.com. Please note that the download enables the free 30-day trial version if used without a key – so you can right now go ahead and evaluate it.

rsyslog 8.32.0 (v8-stable) released

Today, we release rsyslog 8.32.0. This realease, again, sports a vast number of changes. E.g. there are a number of new or updated build requirements, namely: libfastjson 0.99.8, libczmq >= 3.0.2 and libcurl. Otherwise most notably is the major update that ompgsql has received through contribution. Other changes include modules like pmrfc3164, omhiredis, mmexternal, omprog, imfile, omfile, mmpstrucdata. The full list of changes to rsyslog can be reviewed in the Changelog.

We have also made some major changes to the RHEL/CentOS packages for rsyslog. We are now using a modified spec file from the CentOS base repository for building the EL7 release RPM. We decided to go this way out of several reasons. The major reason was a huge issue with the startup scripts that we used, which did not really work well on EL7 systems. More details are available here: http://www.rsyslog.com/major-centos7-rpm-changes/ and here: https://github.com/rsyslog/rsyslog/issues/2134#issuecomment-355483536

Another reason is, that we wanted to make our own RPMs more similar to those in the base repository to avoid major conflicts in the future. That also means, that some additional module packages are not available anymore, because they are now included in the base rsyslog package (mmanon, mmutf8fix, ommail and pmaixforwardedfrom). All other additional sub-packages are still available.

Because the Launchpad build environment [1] is currently unavailable, we cannot produce packages for Ubuntu at the moment. They will be published once the systems are available again.

ChangeLog:

[1] https://lists.ubuntu.com/archives/launchpad-announce/2018-January/000103.html

Major CentOS7 RPM changes

We made some major changes to the way the RPMs for CentOS7/RHEL7 are built. We have adapted the spec file definitions of the base repo to build our own RPMs after we detected some trouble with the last released version. That means, that some things will also change, so our RPMs are more like the official ones.

Stock CentOS 7 8.24.0 package to 8.32.0-1 package upgrade

The upgrade completes and the same functionality present before is present here. Because the syntax was obsolete legacy format before and the format is obsolete legacy format now the /etc/rsyslog.d/listen.conf file passes validation checks (rsyslogd -N6) without issue.

That said, the /etc/rsyslog.d/listen.conf file doesn’t really do anything because the /etc/rsyslog.conffile disables local logging and the /usr/lib/systemd/system/rsyslog.repo unit file doesn’t enable socket activation (basically the symlink from /etc/systemd/system/syslog.service to /usr/lib/systemd/system/rsyslog.service wasn’t created and systemd doesn’t create the /run/systemd/journal/syslog socket for rsyslog to read from).

Not a problem here because the conf file was stock before and is still stock (now upstream Adiscon copy), so imjournal is used to pull log messages (API?) instead of via a socket.

Adiscon repo 8.31.0-4 stable package (with unmodified Adiscon RPM config) to 8.32.0-1 package upgrade

After installing the 8.31.0-4 package (the last one), systemctl disable rsyslog; systemctl enable rsyslog and that workaround seemed to allow that version to function as expected (restart, start, stop). A now performed upgrade to the new package and rebooted. Prior to that, attempting to run systemctl status rsyslogwarned me that I should run systemctl daemon-reload (or restart) to sort things out.

After a restart, all stock settings appeared to function normally. The upgrade (yum install rsyslog) pulled in the needed libfastjson package version without my explicitly specifying to install that package. The /etc/rsyslog.conf file included in the previous stable version was replaced, but this was to be expected because I did not modify the previous conf file (thus the checksums match).

Adiscon repo 8.31.0-4 with custom config to 8.32.0-1 package upgrade

In short, the symlink from /etc/systemd/system/syslog.service to /usr/lib/systemd/system/rsyslog.service wasn’t created and systemd doesn’t create the /run/systemd/journal/syslog socket for rsyslog to read from. In a setup where imuxsock is used, not imjournal this means that rsyslog was not able to read from the socket. To restore this functionality, you have to create a drop-in to restore the socket activation.

Once you did that and either rebooted or ran systemctl daemon-reload, the /run/systemd/journal/syslogsocket was restored.

Addendum

Unmodified configurations should continue to work as before, so there is that.

Users of rsyslog who are using the Adiscon RPMs for a while now, may notice a change in the available module packages because the modules are now incorporated in the basic rsyslog package as in the RPM from the base repo. The affected module packages are (now no longer needed):

rsyslog-mmanon
rsyslog-mmutf8fix
rsyslog-mail
rsyslog-pmaixforwardedfrom

libfastjson 0.99.8 released

This is a new fork of the json-c library, which is optimized for liblognorm processing.

This release provides several fixes to libfastjson. Most notably is the bugfix for proper handling of constant key names. For more details, please refer to the changelog below.

Changelog:

0.99.8 2017-12-18
– make build under gcc7 with strict settings (warning==error)
– bugfix: constant key names not properly handled
if fjson_object_object_add_ex() is used with option
FJSON_OBJECT_KEY_IS_CONSTANT, fjson_object_object_del() will still
try to delete the key name. Depending on use, this can lead to
double-free, use-after-free or no problem.
see also https://github.com/rsyslog/rsyslog/issues/1839
closes https://github.com/rsyslog/libfastjson/issues/148
– fix potentially invalid return value of fjson_object_iter_begin
this could lead to callers doing improper opreations and thus
could lead to a segfault in callers
detected by Coverity scan, CID 198891
– fix small potential memory leak in json_tokener (unlinkely to occur)
detected by Coverity Scan, CID 198890

Download:

http://download.rsyslog.com/libfastjson/libfastjson-0.99.8.tar.gz

sha256sum: 3544c757668b4a257825b3cbc26f800f59ef3c1ff2a260f40f96b48ab1d59e07

As always, feedback is appreciated.

Best regards,
Florian Riedl

rsyslog 8.31.0 (v8-stable) released

Today, we release rsyslog 8.31. This is probably one of the biggest releases in the past couple of years. While it also offers great new functionality, what really important about it is the focus on further improved software quality. For a more detailed description, please read Rainer’s blog post. Detailed information about the huge list of changes is available in the changelog.

http://blog.gerhards.net/2017/11/rsyslog-831-important-release.html

The packages have received some notable changes as well. First off, we were able to implement the Redis output module as a separate package on Ubuntu 14.04 and newer. Also there was a dependency change for the ommongo module, thus it is now only available on Ubuntu 16.04 or newer, but not on CentOS/RHEL anymore. Platform restrictions are unavoidable right now due to dependency availability.

ChangeLog:

rsyslog 8.30.0 (v8-stable) released

We have released rsyslog 8.30.0.

This release features a large number of changes. First we should mention the new build requirements for libfastjson 0.99.7 and the build recommendation for imjournal being libsystemd-journal >= 234.

Notable changes are that (JSON) variables are now handled case-insensitive by default, imjournal being able to switch to persistent journal in runtime and the complete refactoring of mmanon. Also, a lot of improvements have been added to the error reporting as well as many bugfixes.

For a complete list of changes, fixes and enhancements, please visit the ChangeLog.

The packages will follow when they are finished.

ChangeLog:
Scroll to top