rsyslog 8.34.0 (v8-stable) released
Today, we release rsyslog 8.34.0. Most notably is the large refactoring of the imfile module as well as the new module mmkubernetes (contributed). Additionaly, a lot of improvements and fixes have been added to the current release, too many to list them all. So please take a look at the changelog for all the details.
https://github.com/rsyslog/rsyslog/blob/v8-stable/ChangeLog
Download:
http://www.rsyslog.com/downloads/download-v8-stable/
As always, feedback is appreciated.
Best regards,
Florian Riedl
rsyslog 8.33.1 (v8-stable) released
Today, we release rsyslog 8.33.1. The 8.33.0 tarball release was actually pre-8.33.0. Thus it did not contain all features. This alone made a re-release
necessary.
https://github.com/rsyslog/rsyslog/blob/v8-stable/ChangeLog
Download:
http://www.rsyslog.com/downloads/download-v8-stable/
As always, feedback is appreciated.
Best regards,
Florian Riedl
rsyslog 8.33.0 (v8-stable) released
Today, we release rsyslog 8.33.0. This release has a number of changes, but most of these are under the hood. Some of the more obivous changes are the new include() script object and template json container. Also, rsyslog now has better support for running in a container environment. The full list of changes to rsyslog can be reviewed in the Changelog.
https://github.com/rsyslog/rsyslog/blob/v8-stable/ChangeLog
Download:
http://www.rsyslog.com/downloads/download-v8-stable/
As always, feedback is appreciated.
Best regards,
Florian Riedl
New Logo Selected
The logo was originally contributed in 2014 by “robert s”, whom unfortunately I am no longer able to contact. While before we never officially adopted it, it went into widespread use and is already often used to represent rsyslog. So in a sense the now-official selection let’s us keep consistent.
We are glad to have the community decision. I am right now implementing the new logo all over rsyslog web spaces. It will also be available via the rsyslog website github project (PR just created).
Many thanks to all who voted. It was a pleasant experience for us. This may have also set stage for future polls on different topics.
What are your thoughts regarding current and potential rsyslog support channels?
Overview
Traditionally the rsyslog community has sought and provided support through three main channels:
- mailing list
- forums
- ticketing system (at one time Bugzilla, now GitHub)
Over the years, the community support options have shifted to the point that we are considering retiring the forums in order to best direct users that post there to other, more current options that better fit their needs. It would appear that aside from specific cases, the time of the web forum has passed.
That said, we would like to get your feedback to best determine the way to move forward. What follows are some initial ideas to get the conversation started. Please feel free to respond here, via Twitter, the mailing list or on GitHub. Thank you for your time.
Potential Support options
The following items are all “whiteboard” topics, listed in no real order in an effort to start discussion. Neither the order or presence in the list indicates that a decision has already been made by the team to pursue the support option. Please feel free to suggest your own entries.
Keep the forums, send notifications of new posts made on the forums to the mailing list
- Note: Attempts to respond to those notifications would not result in the replies being posted to the original topic on the forums.
- Would this truly result in any additional responses to those forum posts than are currently being provided now?
Set forums to read-only, direct visitors to GitHub for support
Set forums to read-only, direct visitors to StackOverflow
It would appear there is already solid participation there for questions tagged with rsyslog:
https://stackoverflow.com/questions/tagged/rsyslog
Official Twitter presence
followers are encouraged to retweet rsyslog related questions, guides, etc to their followers.
This is actually a “trick” entry of sorts! We already have a Twitter account that you can follow and interact with: @rsyslog
- Do you already follow that account?
- Would you retweet content from others?
- Would you respond to help requests that are retweeted
- If links to active GitHub issues are posted, will you take the time to go view them?
Official Facebook presence
Would you participate in discussions and support requests made there?
IRC, XMPP, Slack, …
- Would you participate?
- Do you feel this could replace the forums?
- Would this be more useful to you than the mailing list?
Help select a logo…
We need a new, a real logo. We have some candidates. Note that logo 1 was originally contributed in 2014 by “robert s” (whom I no longer able to contact…). Unfortunately, we did never officially adopt it, primarily due to failure on my part. Nevertheless it got pretty popular on the Internet and is often associated with rsyslog.
Please let us know what you like by leaving either a comment here or posting to the mailing list. Alternatively, you can also cast your ballot via this online vote form.
We are of course open for any additional suggestions. We are also not upset if you let us know that we are not great logo designers – we know we are not ;-)
In order to avoid past errors, I ask anyone to provide feedback within one week, so we will draw a “winner” by Feb, 8th 2018. To help facilitate the decision I will experimentally put logo 1 into some places tomorrow if there is no strong objection in doing so.
If you want to have a look at our old old ugly logo have a look at e.g. https://hub.docker.com/u/rsyslog/)
My personal 2cts: I as rsyslog maintainer (@rgerhards) have to admit that I have a strong preference for either logo 1 or logo 2. Pro-logo 1 speaks IMHO that it is already associated with rsyslog. Together with its stylish simplicity, this makes it an excellent choice. I also need to say that I am a bit skeptic in regard to logo 6, simply because it breaks “r” and “syslog”.
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 |
|
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 |
|
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.
https://github.com/rsyslog/rsyslog/blob/v8-stable/ChangeLog
Download:
http://www.rsyslog.com/downloads/download-v8-stable/
As always, feedback is appreciated.
Best regards,
Florian Riedl
[1] https://lists.ubuntu.com/
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