Search Results for: install

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.

AWS rsyslog – Message Drop Filter

The rsyslog message drop filter feature allows you to delete unwanted messages by hostname and tag. This filtering capability is always enabled and can be easily configured by updating a simple JSON file.

To modify the drop rules, follow these steps:

  1. Log in to the instance where the rsyslog application is installed.
  2. Navigate to the configuration folder located at /opt/rsyslog/config.
  3. Use your preferred text editor (such as nano) to open the file named “drop_by_host_tag.lt”. Note: You will need root permissions to edit this file (for example, you can use the command “sudo nano drop_by_host_tag.lt“).
  4. Make the necessary changes to the file based on your filtering requirements.

The sample file looks as follows:

{ "version" : 1,
  "nomatch" : "0",
  "type" : "string",
  "table" : [
    {"index" : "localhost dropme", "value" : "1" },
    {"index" : "localhost drop-me", "value" : "1" }
  ]
}

The parts in italics are the actual filters and the parts in bold are the data filtered against.

When configuring filters for the “message drop filter” class in rsyslog, it’s important to understand that each filter consists of two parts: the hostname and the tag.

The first part specifies the hostname to filter for (for example, “localhost”). It’s crucial to note that there should be exactly one space character separating the hostname and the tag. If no space character is given or more than one space is given, the filter will not match any messages.

The second part specifies the message’s syslog tag (for example, “dropme”). It’s essential to keep in mind that neither the hostname nor the tag can contain spaces or any other whitespace characters. This is because such characters are not permitted in hostnames and tags by the relevant RFC, and as such, they will never occur.

If spaces are included, the filter will not match any messages, rendering it ineffective. To ensure that your “message drop filter” class filters work properly, make sure to avoid using spaces or any other whitespace characters in your hostname or tag.

It’s important to note that neither the hostname nor tag can contain any spaces or other whitespace characters. This is because such chaspaces or any other whitespace characters in your hostname or tag.

When done editing the file, ensure that each “index” line except the last one ends with a comma. After saving, you can also do a check of the overall configuration by running “rsyslogd -N1” on the command line. Please note that rsyslogd must be sent a HUP to activate the changes.

In later stages of the beta build process, we will at least partly automate the post-edit check and activation procedures.

Back to aws rsyslog overview.

How to perform a mass rollout?

A mass rollout in the scope of this topic is any case where the product is rolled out to more than 5 to 10 machines and this rollout is to be automated. This is described first in this article. A special case may also be where remote offices shall receive exact same copies of the product (and configuration settings) but where some minimal operator intervention is acceptable. This is described in the second half of this article.

The common thing among mass rollouts is that the effort required to set up the files for unattended distribution of the configuration file and product executable is less than doing the tasks manually. For less than 5 systems, it is often more economical to repeat the configuration on each machine, but this depends on the number of rules and their complexity. Please note that you can also export and re-import configuration settings, so a hybrid solution may be the best when a lower number of machines is to be installed (normal interactive setup plus import of pre-created configuration settings).

Automated Rollout

The basic idea behind a mass rollout is to create the intended configuration on a master (or baseline) system. This system holds the complete configuration that is later to be applied to all other systems. Once that system is fully configured, the configuration will be transferred to all others.

The actual transfer is done with simple operating system tools. The complete configuration is stored in the the registry. Thus, it can be exported to a file. This can be done with the client. In the menu, select “Computer”, then select “Export Settings to Registry File”. A new dialog comes up where the file name can be specified. Once this is done, the specified file contains an exact snapshot of that machine’s configuration.

This snapshot can then be copied to all other machines and put into their registries with the help of regedit.exe.

An example batch file to install, configure and run the service on “other” servers might be:

copy \\servershare\rsyslogcl.exe c:\some-local-dir
copy \\servershare\rsyslogcl.pem c:\some-local-dir
cd \some-local-dir
rsyslogcl -i
regedit /s \server\share\configParms.reg
net start "RSyslog Windows Agent"

The file “configParams.reg” would be the registry file that had been exported with the configuration client.

Of course, the batch file could also operate off a CD – a good example for DMZ systems which might not have Windows networking connectivity to a home server.

Please note that the above batch file fully installs the product – there is no need to run the setup program at all. All that is needed to distribute the service i.e. rsyslogcl.exe and its helper dlls, which are the core service. For a locked-down environment, this also means there is no need to allow incoming connections over Windows RPC or NETBIOS for an engine only install.

Please note that, in the example above, “c:\some-local-dir” actually is the directory where the product is being installed. The “rsyslogcl -i” does not copy any files – it assumes they are already at their final location. All “rsyslogcl -i” does is to create the necessary entries in the system registry so that the Rsyslog Windows Agent is a registered system service.

Branch Office Rollout with consistent Configuration

You can use engine-only install also if you would like to distribute a standardized installation to branch office administrators. Here, the goal is not to have everything done fully automatic, but to ensure that each local administrator can set up a consistent environment with minimal effort.

You can use the following procedure to do this:

  1. Do a complete install on one machine.
  2. Configure that installation the way you want it.
  3. Create a .reg file of this configuration (via the client program).
  4. Copy the rsyslogcl.exe, rsyslogcl.pem  and .reg file that you created to a CD (for example). Take these executable files from the install directory of the complete install done in step 1 (there is no specfic engine-only download available).
  5. Distribute the CD.
  6. Have the users create a directory where they copy all the files. This directory is where the product is installed in – it may be advisable to require a consistent name (from an admin point of view – the product does not require this).
  7. Have the users run “rsyslogcl -i” from that directory. It will create the necessary registry entries so that the product becomes a registered service.
  8. Have the users double-click on the .reg file to install the pre-configured parameters (step 3).
  9. Either reboot the machine (neither required nor recommended) or start the service (via the Windows “Servcies” manager or the “net start” command).

Important: The directory created in step 6 actually is the program directory. Do not delete this directory or the files contained in it once you are finished. If you would do, this would disable the product (no program files would be left on the system).

If you need to update an engine-only installation, you will probably only upgrade the master installation and then distribute the new exe files and configuration in the same way you distributed the original version. Please note that it is not necessary to uninstall the application first for an upgrade – at least not as long as the local install directory remains the same. It is, however, vital to stop the service, as otherwise the files can not be overwritten.

RSyslog Windows Agent license document – EULA

RSyslog Windows Agent
Version 8.1 Final Release
End User License Agreement
2025-07-14

This binary code license (“License”) contains rights and restrictions associated with use of the accompanying software and documentation (“Software”). Read the License carefully before installing the Software. By installing the Software you agree to the terms and conditions of this License.

1. Limited License Grant.
Adiscon grants you a non-exclusive License to use the software free of charge for 30 days for the purpose of evaluating whether to purchase a commercial license of RSyslog Windows Agent. After this period, users are required to purchase proper licenses if you continue to use it. If Customer has purchased RSyslog Windows Agent licenses, Customer is permitted to use the purchased product edition under the terms of this license agreement.

2. Copyright
The software is confidential copyrighted information of Adiscon GmbH, Germany. You shall not modify, decompile, disassemble, decrypt, extract, or otherwise reverse engineer the software. The software may not be leased, assigned, or sublicensed, in whole or in part. A separate license is required for each computer being monitored by the RSyslog Windows Agent.

3. Trademarks and logos
RSyslog Windows Agent is a trademark of Adiscon. Windows is a registered trademark of Microsoft Corporation. All other trademarks and service marks are the property of their respective owners.

4. Licensed syslog
A RSyslog Windows Agent license covers the installation of one system. RSyslog Windows Agent comes in several editions, only the Enterprise Version is permitting the Syslog Listener Service. The RSyslog Windows Agent Enterprise Edition permits you to receive messages from an unlimited number of devices. Please note that instances of Adiscon’s EventReporter and/or RSyslog Windows Agent do NOT count against the remote device count. So you may use a RSyslog Windows Agent Server Professional edition to receive data from 500 servers with Adiscon EventReporter installed on them.

5. Licensed remote file monitor Clients
RSyslog Windows Agent can be used to monitor text files on remote systems. This remote monitoring requires a proper license. RSyslog Windows Agent comes in several editions, each of them permitting remote file monitoring for a different number of remote systems, You must purchase the edition of RSyslog Windows Agent that reflects the number of different remote systems being monitored by RSyslog Windows Agent. The RSyslog Windows Agent Basic Edition does not permit you to monitor files locally or on remote systems. The RSyslog Windows Agent Professional Edition permits you to monitor files locally and on up to 10 remote systems. The RSyslog Windows Agent Enterprise Edition permits you to monitor files on an unlimited number of remote systems.

Please note that only the number of remote systems counts toward the license. So if you monitor 50 files on a single remote system, this counts as a single license. If you monitor a single file on each one of 50 remote systems, than this counts as 50 licenses.

6. Licensed remote event log monitor clients
RSyslog Windows Agent can be used to monitor Windows event logs on remote computers. A full RSyslog Windows Agent license is required for each remote computer on which Windows event logs are being monitored. Technically, the product might count licenses based on the number of remote event log monitors configured. In such cases, a license is required for each remote event log monitor configured.

7. Product Editions
A specific edition of the RSyslog Windows Agent product is licensed. Only the specifically licensed version may be used. For example, if a RSyslog Windows Agent Basic Edition is licensed, features of the Professional edition may not be used. The license keys are also technically different, that is a Basic edition license key is technically different from a Professional Edition license key. Thus, a Basic edition license key can not be used to unlock Professional features.

8. Evaluation period
The product comes with a free 30 day evaluation period. We strongly encourage all customers to evaluate the product’s fitness for their systems and environment during the evaluation period. Customer agrees to install the product on production systems only after it has proven to be acceptable on similar test systems.

9. Redistribution
Everybody is granted permission to redistribute the install set if the following criteria are meet:

– the install set, product and all documentation (including this license) are
supplied unaltered
– there is no registration key distributed along with the install set. REGISTRATION
KEYS ARE SOLE INTENDED FOR THE ORIGINAL CUSTOMER. IT IS COPYRIGHT
FRAUD TO DISTRIBUTE REGISTRATIONS KEYS.
– the redistributor is only allowed to charge a nominal fee if the product is included
into a commercial distribution set (e.g. shareware CD collection). For a CD collection,
we deem a fee of up to US$ 30 to be reasonable.
– redistribution as part of a book companion CD is OK, as long as the books purpose is
not only to cover a CD software collection in which case we deem a cost of US$ 50
for the book to be OK.

10. Disclaimer of warranty
The Software is provided “AS IS,” without a warranty of any kind. ALL EXPRESS OR IMPLIED REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED.

11. Limitation of liability
ADISCON SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY YOU OR ANY THIRD PARTY AS A RESULT OF USING OR DISTRIBUTING SOFTWARE. IN NO EVENT WILL ADISCON BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF ADISCON HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. IT IS THE CUSTOMERS RESPONSIBILITY, TO USE THE EVALUATION PERIOD TO MAKE SURE THE PRODUCT CAN RUN WITHOUT PROBLEMS IN CUSTOMERS ENVIRONMENT.

12. Severability
The user must assume the entire risk of using the program. IN NO EVENT WILL ADISCON BE LIABLE FOR ANY DAMAGES IN EXCESS OF THE AMOUNT ADISCON RECEIVED FROM YOU FOR A LICENSE TO THE SOFTWARE, EVEN IF ADISCON SHALL HAVE BEEN INFORMED OF THE POSSIBILITY OF SUCH DAMAGES, OR FOR ANY CLAIM BY ANY OTHER PARTY.

13. Termination
The License will terminate automatically if you fail to comply with the limitations described herein. On termination, you must destroy all copies of the Software.

14. Product Parts Not Covered by this License
RSyslog Windows Agent may include optional parts which are not covered by this license. For example, a free web-based interface for log access (phpLogCon) may be part of the RSyslog Windows Agent package. Any package not licensed under the term of this license will have prominent note as well as its own license document. If in doubt, the RSyslog Windows Agent service, the RSyslog Windows Agent configuration Program and the Interactive Syslog Server as well as accompanying documentation are licensed under this agreement.

14. High risk activities
The Software is not fault-tolerant and is not designed, manufactured or intended for use or resale as on-line control equipment in hazardous environments requiring fail-safe performance, such as in the operation of nuclear facilities, aircraft navigation or communication systems, air traffic control, direct life support machines, or weapons systems, in which the failure of the Software could lead directly to death, personal injury, or severe physical or environmental damage (“High Risk Activities”). Adiscon specifically disclaims any express or implied warranty of fitness for High Risk Activities.

15. General Provisions
This license agreement shall be governed and interpreted in accordance with the substantive law of Germany applicable to contracts made and performed there. The place of performance of the agreement is Germany, Grossrinderfeld notwithstanding where the Customer is situated or any servers are located.

If any provision of this license agreement shall be held void or unenforceable by a court of competent jurisdiction, it shall be severed from this agreement and shall not affect the remaining provisions. Void clauses are to be construed in such a way that the business purpose of said clauses as envisaged by both parties can be realized in a lawful manner. Except as expressly set forth in this agreement, the exercise by either party of any of its remedies under this agreement will be without prejudice to its other remedies under this agreement or otherwise.

rsyslog error 2291

Error in RELP processing.

If this message occurs:
imrelp: could not activate relp listner, code 10046

This means that the platform does not provide TLS auth support. In general, this means that GnuTLS is too old.

Here is the recommended solution:
Install a current version of GnuTLS on that system and rebuild librelp from source.

Alternatively you can try to use TLS in anonymous mode! Please note that this does not guard against man-in-the-middle attacks, it at least keeps message flow encrypted.

This is a stub entry: If you have questions please post a comment or visit the github issue tracker.

rsyslog error 2209

Module (config name) is unknown.

In almost all most cases, this message is caused by

  1. a typo in the module name
  2. module not being installed

Please note that rsyslog usually is packaged via a core package (usually called “rsyslog”) and feature packages (usually called “rsyslog-feature”). The core package contains only what is frequently needed. For extra functionality, you need to install the feature package. For example, omelasticseach is usually packaged in a package named along the lines of “rsyslog-omeleasticsearch” or “rsyslog-elasticsearch”. The actual package name depends on your distro and/or custom repository used (e.g. rsyslog’s package repositories).

Please note that not all modules are packaged. It depends on the distro and/or package maintainer. Especially some very infrequently modules are often not packaged in official distros. Some are inside the rsyslog repositories. The same holds true for contributed modules which are not officially supported by the rsyslog core team.

Check the rsyslog repositories to see if you can install a module from there if your distro does not provide it. If  you do not find the module there, you need to build it from source.

If you have further questions please post a comment or visit the github issue tracker.

rsyslog error 2066

Module could not be loaded – problem in dlopen().

A problem occurred during dlopen()ing a loadable module (e.g. an input or output plugin).

Most common causes for this are that the module either does not exist or has incorrect permission settings. Permission problems are less likely if rsyslogd runs as root, what it does by default.

Note that most packages only distribute a very limited set of plugins via the core rsyslog package. To use enhanced functionality (like the file input, database or mail outputs and many more), you need to install additional packages (there names are distro-specific, so they can not be given here).

When building from source, check the ./configure output on which modules are built. A summary is given at the end of the configure run. Use “./configure -help” to see which options enable which modules.

This is a stub entry: If you have questions please post a comment or visit the github issue tracker.

Data Privacy Policy

Our website may be used without entering personal information. Different rules may apply to certain services on our site, however, and are explained separately below. We collect personal information from you (e.g. name, address, email address, telephone number, etc.) in accordance with the provisions of German data protection statutes. Information is considered personal if it can be associated exclusively to a specific natural person. The legal framework for data protection may be found in the German Federal Data Protection Act (BDSG) and the Telemedia Act (TMG). The provisions below serve to provide information as to the manner, extent and purpose for collecting, using and processing personal information by the provider.

Adiscon GmbH
Mozartstr. 21
97950 Großrinderfeld
Germany
+49-9349-9298530
info@adiscon.com

Please be aware that data transfer via the internet is subject to security risks and, therefore, complete protection against third-party access to transferred data cannot be ensured.

Cookies

Our website makes use of so-called cookies in order to recognize repeat use of our website by the same user/internet connection subscriber. Cookies are small text files that your internet browser downloads and stores on your computer. They are used to improve our website and services. In most cases these are so-called “session cookies” that are deleted once you leave our website.

To an extent, however, these cookies also pass along information used to automatically recognize you. Recognition occurs through an IP address saved to the cookies. The information thereby obtained is used to improve our services and to expedite your access to the website.

You can prevent cookies from being installed by adjusting the settings on your browser software accordingly. You should be aware, however, that by doing so you may not be able to make full use of all the functions of our website.

Server Data

For technical reasons, data such as the following, which your internet browser transmits to us or to our web space provider (so called server log files), is collected:

– type and version of the browser you use
– operating system
– websites that linked you to our site (referrer URL)
– websites that you visit
– date and time of your visit
– your Internet Protocol (IP) address.

This anonymous data is stored separately from any personal information you may have provided, thereby making it impossible to connect it to any particular person. The data is used for statistical purposes in order to improve our website and services.

Contacting Us

On our website we offer you the opportunity to contact us, either by email and/or by using a contact form. In such event, information provided by the user is stored for the purpose of facilitating communications with the user. No data is transferred to third parties except as mentioned in this policy. Nor is any of this information matched to any information that may be collected by other components of our website.

Posting Comments

On our website we offer you the opportunity to post comments about individual articles. For this purpose, the IP address of the user/internet connection subscriber is stored, as well as the email address used. This information is stored for our security in the event the author through his/her comments infringes against third party rights and/or unlawful content is entered. Consequently, we have a direct interest in the author’s stored data, particularly since we may be potentially liable for such violations. Having some identifying information is also necessary if you wish to have all of your data removed – otherwise we could not find it. No data is transferred to third parties. Nor is any of this information matched to any information that may be collected by other components of our website.

Use of Google Analytics with anonymization

Our website uses Google Analytics, a web analysis service from Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043 USA, hereinafter referred to as “Google“. Google Analytics employs so-called “cookies“, text files that are stored to your computer in order to facilitate an analysis of your use of the site.

The information generated by these cookies, such as time, place and frequency of your visits to our site, including your IP address, is transmitted to Google’s location in the US and stored there.

We use Google Analytics with an IP anonymization feature on our website. In doing so, Google abbreviates and thereby anonymizes your IP address before transferring it from member states of the European Union or signatory states to the Agreement on the European Economic Area.

Google will use this information to evaluate your usage of our site, to compile reports on website activity for us, and to provide other services related to website- and internet usage. Google may also transfer this information to third parties if this is required by law or to the extent this data is processed by third parties on Google´s behalf.

Google states that it will in never associate your IP address with other data held by Google. You can prevent cookies from being installed by adjusting the settings on your browser software accordingly. You should be aware, however, that by doing so you may not be able to make full use of all the functions of our website.

Google also offers a disabling option for the most common browsers, thus providing you with greater control over the data which is collected and processed by Google. If you enable this option, no information regarding your website visit is transmitted to Google Analytics. However, the activation does not prevent the transmission of information to us or to any other web analytics services we may use. For more information about the disabling option provided by Google, and how to enable this option, visit https://tools.google.com/dlpage/gaoptout?hl=en

Use of Google AdSense

Our website employs Google AdSense. Google AdSense is a service of Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043 USA, for incorporating advertisements. Google-AdSense uses so-called “cookies“, text files, that are stored to your computer and which provide analysis of the use of our website. Furthermore, Google AdSense uses so-called “web beacons“. Web beacons allow Google to analyze information, such as visitor traffic to our website. This information, along with your IP address and the ad format displayed, is transmitted to Google in the US where it is stored and may be transferred by Google to contracting partners. However, Google does not merge your IP-address with other stored data on you. You can prevent cookies from being installed by adjusting the settings on your browser software accordingly. You should be aware, however, that by doing so you may not be able to make full use of all the functions of our website. By using our website you declare that you agree to the processing of data collected about you by Google in the manner previously described and for the purposes there specified.

Use of Google reCAPTCHA

Our website uses Google reCAPTCHA to fight SPAM. We would like to avoid doing this, but unfortunately the SPAM problem has become so bad that without reCAPTCHA we would need to turn off commenting (and we actually did so a couple of month in early 2018). We limit the use of reCAPTCHA to pages where it is absolutely needed, e.g. when you enter comments.  As reCAPTCHA is a Google service, it is subject to Google’s Privacy Policy and Terms of Use.

Information/Cancellation/Deletion

On the basis of the Federal Data Protection Act, you may contact us at no cost if you have questions relating to the collection, processing or use of your personal information, if you wish to request the correction, blocking or deletion of the same, or if you wish to cancel explicitly granted consent. Please note that you have the right to have incorrect data corrected or to have personal data deleted, where such claim is not barred by any legal obligation to retain this data.

YouTube

We use YouTube on our website. This is a video portal operated by YouTube LLC, 901 Cherry Ave, 94066 San Bruno, CA, USA, hereinafter referred to as “YouTube”.

YouTube is a subsidiary of Google LLC, 1600 Amphitheatre Parkway, Mountain View, CA 94043 USA, hereinafter referred to as “Google”.

Through certification according to the EU-US Privacy Shield

https://www.privacyshield.gov/participant?id=a2zt000000001L5AAI&status=Active

Google and its subsidiary YouTube guarantee that they will follow the EU’s data protection regulations when processing data in the United States.

We use YouTube in its advanced privacy mode to show you videos. The legal basis is Art. 6 Para. 1 lit. f) GDPR. Our legitimate interest lies in improving the quality of our website. According to YouTube, the advanced privacy mode means that the data specified below will only be transmitted to the YouTube server if you actually start a video.

Without this mode, a connection to the YouTube server in the USA will be established as soon as you access any of our webpages on which a YouTube video is embedded.

This connection is required in order to be able to display the respective video on our website within your browser. YouTube will record and process at a minimum your IP address, the date and time the video was displayed, as well as the website you visited. In addition, a connection to the DoubleClick advertising network of Google is established.

If you are logged in to YouTube when you access our site, YouTube will assign the connection information to your YouTube account. To prevent this, you must either log out of YouTube before visiting our site or make the appropriate settings in your YouTube account.

For the purpose of functionality and analysis of usage behavior, YouTube permanently stores cookies on your device via your browser. If you do not agree to this processing, you have the option of preventing the installation of cookies by making the appropriate settings in your browser. Further details can be found in the section about cookies above.

Further information about the collection and use of data as well as your rights and protection options in Google’s privacy policy found at

https://policies.google.com/privacy

Sample Data Privacy Policy Statement provided by the Law Offices of Weiß & Partner

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

Scroll to top