SEO: Getting into Google News – no longer Possible?

Many publishers love to get into the Google News index – it offers an extra source of traffic and can really boost a site. Unfortunately, getting into News is not as easy as it looks.

A Picture of Google News
Google News: many publisher would like use this as a source of extra traffic. However, the site must fit and offer journalistic content. (Screenshot done by Rainer Gerhards on 2020-08-10)
Continue reading “SEO: Getting into Google News – no longer Possible?”

rsyslog: integrating Windows Event Log (via UDP)

This tutorial tells how to integrate data from Windows event log into our rsyslog configuration. We will do this integration via the UDP syslog protocol so that we finally can show this in a real case. No advanced topics are covered. We use CentOS 7 and Windows Server 2012 (because it still is in more widespread use). This is part of a rsyslog tutorial series.

Continue reading “rsyslog: integrating Windows Event Log (via UDP)”

rsyslog: relay messages only (no local storage)

This tutorials tells how rsyslog is configured to accept syslog messages over the network via UDP. No advanced topics are covered. We use CentOS 7. This is part of a rsyslog tutorial series.

Scope

We will configure LC to only relay messages received via UDP but not store them locally.  Locally-generated messages will still be stored inside local log files. They, too, will be forwarded to LR. This is a very common use case. We still do not configure any sender to connect to LC.

To do all of this, we need to modify only LC local configuration. As such, our base lab scenario will remain in the following configuration:

Note that we still do not configure any system to actually send data to LC. This will be done the next tutorial. Note that if you did not complete the last tutorial, it may be wise to have a look at it. We will work with the configuration it generated. Continue reading “rsyslog: relay messages only (no local storage)”

rsyslog beginner’s tutorial series

This multi-step tutorial series targets rsyslog beginners. It covers typical configuration steps which are done with minimal effort. I found that for beginners it is often very important to provide precise instructions for their specific environment. As such, I focus on CentOS 7, which is quite popular in enterprise environments.

Final setup at end of basic tutorial set.

If you do not usually use CentOS 7, I still suggest to download and install it on two lab machines. This permits you to follow the tutorial in exact steps. Once you know what you do, it should be fairly easy to translate that to other distributions like Ubuntu.

Note: I am currently writing the tutorials, so they will grow for the time being. The basic set will have around 10 tutorials (I already have the full outline).

Available Tutorials

For best experience, read tutorials in given order:

  1. Overview of lab environment (not yet done)
  2. configure a TCP syslog server
  3. forward messages to remote server (via TCP syslog)
  4. configure a UDP syslog server
  5. rsyslog: relay messages only (no local storage)
  6. rsyslog: integrating Windows Event Log (via UDP)

Note that if you are interested in a specific topic, you can also pick tutorials out of the order. Be warned, though, that there is some inter-dependency between the tutorials. For example, for forwarding messages, a server is needed. The forwarding tutorial as such assumes that the server was properly created. In suggested sequence, this is ensured.

There exist also some utility tutorials to help you understand the operating environment. They are linked to from the appropriate places.

Additional Info

Why is this tutorial series created and hosted here? Find the answer in this article. If you are interested in contributing to the effort, please let me know. Feedback of any kind is also very welcome. You can also use the comment fields to provide it.

rsyslog: configure syslog UDP reception

This tutorials tells how rsyslog is configured to accept syslog messages over the network via UDP. No advanced topics are covered. We use CentOS 7. This is part of a rsyslog tutorial series.

Scope

We will configure the relay system to accept UDP based syslog from remote ends.  We do not, however, configure any sender to connect to it. We will use LC as UDP server, just so that we get some more variety into our lab with limited systems. In our base lab scenario, this will lead to the following configuration:

Note that we will accept incoming logs and store them into the same location as we do for local logs. Handling them different will be part of a later tutorial. Continue reading “rsyslog: configure syslog UDP reception”

How to start, stop and query the status of rsyslog (on a systemd system)

This short tutorial explains everyday service management. While it claims to address management of rsyslog, it actually describes the tools for all services. The tutorial is written for CentOS 7, but should work equally well on other systemd-based systems like CentOS 8, recent Fedora, recent Debian and recent Ubuntu. Continue reading “How to start, stop and query the status of rsyslog (on a systemd system)”

rsyslog: forward messages to remote server

This tutorials tells how rsyslog is configured to send syslog messages over the network via TCP to a remote server. No advanced topics are covered. We use CentOS 7. This is part of a rsyslog tutorial series.

Scope

We will configure an end node (here: LR) to send messages via TCP to a remote syslog server. We do not apply local pre-filtering and we want to make only minimal changes to the CentOS 7 default configuration. In our base lab scenario, this will lead to the following configuration:

Continue reading “rsyslog: forward messages to remote server”

rsyslog: configure syslog TCP reception

This tutorials tells how rsyslog is configured to accept syslog messages over the network via TCP. No advanced topics are covered. We use CentOS 7. This is part of a rsyslog tutorial series.

Scope

We will configure the relay system to accept TCP based syslog from remote ends. We do not, however, configure any sender to connect to it. In our base lab scenario, this will lead to the following configuration:

Note that we will accept incoming logs and store them into the same location as we do for local logs. Handling them different will be part of a later tutorial. Continue reading “rsyslog: configure syslog TCP reception”

Tutorials for rsyslog

While I have been in Tallinn to give some lectures about syslog technology in general as well as rsyslog in specific I had the idea to use that opportunity to think about crafting rsyslog tutorials in general.

For the practical session at TALTECH IT-College I have identified a couple of typical configuration tasks. As experience shows, to carry them out successfully not only rsyslog knowledge is required but general sysadmin know-how as well. Continue reading “Tutorials for rsyslog”

rsyslog’s daily stable

Did you know? The rsyslog project offers a stable release every day! The world is changing and getting faster each time. Especially software. If a bug is fixed, you want to have the fix as soon as possible. Even more so if it is security related.

Development happens in active code. When we fix something, this is done in so-called “master branch”. If you use master branch, you are covered as soon as the fix is applied.

Traditionally there are “stable builds” which are released relatively infrequently. Sometimes many months. In rsyslog’s case, only 6 weeks. For bugfixes, someone needs to backport the fix to that “stable build”. Backporting comes with its own risks, as the code is integrated into a version it was never written for.

We have much more frequently updated versions as well. They are crafted each day and contain the current latest and greatest. Including all known fixes. These daily version are usually considered as experimental or development version. Quite honestly, this is no longer the case.

Before I continue, please consider that rsyslog is a relatively small project. What is true for it may not be true for much larger ones.

In rsyslog, we have two important policies:

  • new versions never break existing configurations (except for extremely important reasons) – this means you can always update to the latest version without risking that your config blows up
  • we rely on our CI – if a change passes the testbench, it basically is good to go.To complement, we also have manual reviews of critical changes. Only things we are pretty confident in go into master branch.

What does that mean? First of all, master branch actually is a stable version. The code passed all of our checks and safeguards. We do not question the stability and continue to work on new features or bug fixes. Note that the strong position here sometimes upsets contributors. We have and had PRs who take month to ripen before they are finally sufficiently good to be merged to master.

The second thing is that daily stable builds are built from master and so are also stable.

Now let’s consider what happens when it is time to create the 6-weekly stable release. Code-wise it’s pretty simple: as master is stable, we simply take master branch and declare it as the new stable version. It’s the same version as the daily build from that day. What is different is that the doc is consolidated and we prepare files nicely for package build. Then, packages are built and tested. Except for the doc, one could also have used the daily stable build.

Think about it. What it ultimately means is that the 6-week “stable” release is just a way to avoid doing more frequent updates. But the daily build is actually as stable as the stable release.

In a world of rapidly moving development, using the daily stable build has a lot of advantages. Most importantly, one gets fixes as soon as possible. Not to mention new features.

I understand that the scheduled release may be the better option for some environments. But for most, the daily stable is actually to be preferred.

Please note: daily stable builds are currently only available for Ubuntu. With our efforts towards OpenSuse Build Service we aim to make them available for a wider number of platforms.