Me again,
Another change to my Centos 7.2 system since my 'yum update' yesterday is that /var/log/dovecot is no longer written to.
If I do 'systemctl status dovecot' I can see log entries. How can I now do the equiv or 'tail -f <logfile>'
Also, why has this changed, and where is it documented?
On Thu, 5 May 2016, Gary Stainburn wrote:
Another change to my Centos 7.2 system since my 'yum update' yesterday is that /var/log/dovecot is no longer written to.
If I do 'systemctl status dovecot' I can see log entries. How can I now do the equiv or 'tail -f <logfile>'
Also, why has this changed, and where is it documented?
I'd take a stab at:
journalctl -fu dovecot
The full RHEL7 System Administrators Guide is well worth a read, but here's the bit you're probably after.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
Or maybe:
https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-vi...
jh
On Thursday 05 May 2016 15:19:47 John Hodrien wrote:
I'd take a stab at:
journalctl -fu dovecot
The full RHEL7 System Administrators Guide is well worth a read, but here's the bit you're probably after.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/ht ml/System_Administrators_Guide/s1-Using_the_Journal.html
Or maybe:
https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-v iew-and-manipulate-systemd-logs
jh
Thanks John. Another example of systemd project creep - AKA systemd's plan for world domination
On Thu, May 5, 2016 9:58 am, Gary Stainburn wrote:
On Thursday 05 May 2016 15:19:47 John Hodrien wrote:
I'd take a stab at: journalctl -fu dovecot The full RHEL7 System Administrators Guide is well worth a read, but
here's
the bit you're probably after. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/ht ml/System_Administrators_Guide/s1-Using_the_Journal.html Or maybe: https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-v iew-and-manipulate-systemd-logs jh
Thanks John. Another example of systemd project creep - AKA systemd's plan for world domination
There were several heated discussions on this list, and elsewhere. This is not intended to start the new one, but to help someone who missed them to define their statute.
People split into two groups:
Opponents of systemd (, firewqalld, etc.) who argue that from formerly Unix-like system Linux becomes Unix-unlike (or more MS Windows-like), and this is bad.
Proponents of systemd etc. who argue that the life goes on, systems evolve and you better keep up with changes.
Therefore, for new person who is about to, let's say, upgrade Linux system to the version with systemd, there is a decision that will define that person's future maintenance of this new system. And the decision has to be made before upgrade. Luckily for those who do decide to go with systemd, bugs (that always are present in new software) are being solved. Luckily for those who do not accept fundamental changes systemd brings (like binary logs or config files infested with XML garbage - sorry if I'm missing or misinterpreting something) there are Unix system one can migrate machine to.
Either way one has to read and estimate what making that step (upgrading to systemd, firewalld based Linux or switching to some flavor of Unix) will entail in a long run for that server and the server admin. Either way, as in one of Unix handbooks they stress: read carefully the upgrade notes!
I hope, this helps someone.
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Thursday 05 May 2016 17:16:17 Valeri Galtsev wrote:
There were several heated discussions on this list, and elsewhere. This is not intended to start the new one, but to help someone who missed them to define their statute.
People split into two groups:
Opponents of systemd (, firewqalld, etc.) who argue that from formerly Unix-like system Linux becomes Unix-unlike (or more MS Windows-like), and this is bad.
Proponents of systemd etc. who argue that the life goes on, systems evolve and you better keep up with changes.
Therefore, for new person who is about to, let's say, upgrade Linux system to the version with systemd, there is a decision that will define that person's future maintenance of this new system. And the decision has to be made before upgrade. Luckily for those who do decide to go with systemd, bugs (that always are present in new software) are being solved. Luckily for those who do not accept fundamental changes systemd brings (like binary logs or config files infested with XML garbage - sorry if I'm missing or misinterpreting something) there are Unix system one can migrate machine to.
Either way one has to read and estimate what making that step (upgrading to systemd, firewalld based Linux or switching to some flavor of Unix) will entail in a long run for that server and the server admin. Either way, as in one of Unix handbooks they stress: read carefully the upgrade notes!
I hope, this helps someone.
Valeri
I understand the arguments for the move to systemd - and I also understand the points of those arguments. Like most arguments, there are some valid and positive points and some not so.
There are times - such as the encompassing of the name resolver code - where it just seems a case of replacing old, mature code with new untested code for no reason.
Either way, I now have to manage both traditional and systemd based systems. Okay, it just means learning new toolsets, but it's something else I have to learn, and something else I have to cope with for my bespoke systems and services.
What I didn't expect, and what really threw me was that this has been implemented via a simply 'yum update' of an existing system, not at a major release level.
On Fri, 6 May 2016, Gary Stainburn wrote:
What I didn't expect, and what really threw me was that this has been implemented via a simply 'yum update' of an existing system, not at a major release level.
journald has been there since you installed C7.
You appear to have seen a change in logging behaviour as a result of an update. Whether that's due to an update of dovecot, systemd, or something else, I have no idea.
Something like RHEL is stuck in a trap here. Either they never change a default post-install (lots of rpmnew or deliberately not introducing new behaviours), or they bring in defaults as you update (to some extent doing things like rpmsave). Some people would complain whichever option they chose.
jh
On Fri, May 6, 2016 3:13 am, Gary Stainburn wrote:
On Thursday 05 May 2016 17:16:17 Valeri Galtsev wrote:
There were several heated discussions on this list, and elsewhere. This is not intended to start the new one, but to help someone who missed them to define their statute.
People split into two groups:
Opponents of systemd (, firewqalld, etc.) who argue that from formerly Unix-like system Linux becomes Unix-unlike (or more MS Windows-like), and this is bad.
Proponents of systemd etc. who argue that the life goes on, systems evolve and you better keep up with changes.
Therefore, for new person who is about to, let's say, upgrade Linux system to the version with systemd, there is a decision that will define that person's future maintenance of this new system. And the decision has to be made before upgrade. Luckily for those who do decide to go with systemd, bugs (that always are present in new software) are being solved. Luckily for those who do not accept fundamental changes systemd brings (like binary logs or config files infested with XML garbage - sorry if I'm missing or misinterpreting something) there are Unix system one can migrate machine to.
Either way one has to read and estimate what making that step (upgrading to systemd, firewalld based Linux or switching to some flavor of Unix) will entail in a long run for that server and the server admin. Either way, as in one of Unix handbooks they stress: read carefully the upgrade notes!
I hope, this helps someone.
Valeri
I understand the arguments for the move to systemd - and I also understand the points of those arguments. Like most arguments, there are some valid and positive points and some not so.
There are times - such as the encompassing of the name resolver code - where it just seems a case of replacing old, mature code with new untested code for no reason.
Either way, I now have to manage both traditional and systemd based systems. Okay, it just means learning new toolsets, but it's something else I have to learn, and something else I have to cope with for my bespoke systems and services.
I guess, I didn't stress it well enough: read the upgrade notes! In case of switching to systemd: read about what the change means.
In other words, at least in minds of those who decided to migrate to UNIX, this change it not just about learning new tools. It is about how the system works. I am not going to argue they (refugees to UNIX) are right, or proponents of systemd (and friends) are right. The important part is that each weighed the changed and will deal with the consequences of the decision made conscientiously. But for that (to make good decision), once again:
Read the "upgrade notes" [systemd documentation in this case]! This is the decision about your system and its future life.
Valeri
What I didn't expect, and what really threw me was that this has been implemented via a simply 'yum update' of an existing system, not at a major release level.
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On 05/06/2016 08:38 AM, Valeri Galtsev wrote:
On Fri, May 6, 2016 3:13 am, Gary Stainburn wrote:
On Thursday 05 May 2016 17:16:17 Valeri Galtsev wrote:
There were several heated discussions on this list, and elsewhere. This is not intended to start the new one, but to help someone who missed them to define their statute.
People split into two groups:
Opponents of systemd (, firewqalld, etc.) who argue that from formerly Unix-like system Linux becomes Unix-unlike (or more MS Windows-like), and this is bad.
Proponents of systemd etc. who argue that the life goes on, systems evolve and you better keep up with changes.
Therefore, for new person who is about to, let's say, upgrade Linux system to the version with systemd, there is a decision that will define that person's future maintenance of this new system. And the decision has to be made before upgrade. Luckily for those who do decide to go with systemd, bugs (that always are present in new software) are being solved. Luckily for those who do not accept fundamental changes systemd brings (like binary logs or config files infested with XML garbage - sorry if I'm missing or misinterpreting something) there are Unix system one can migrate machine to.
Either way one has to read and estimate what making that step (upgrading to systemd, firewalld based Linux or switching to some flavor of Unix) will entail in a long run for that server and the server admin. Either way, as in one of Unix handbooks they stress: read carefully the upgrade notes!
I hope, this helps someone.
Valeri
I understand the arguments for the move to systemd - and I also understand the points of those arguments. Like most arguments, there are some valid and positive points and some not so.
There are times - such as the encompassing of the name resolver code - where it just seems a case of replacing old, mature code with new untested code for no reason.
Either way, I now have to manage both traditional and systemd based systems. Okay, it just means learning new toolsets, but it's something else I have to learn, and something else I have to cope with for my bespoke systems and services.
I guess, I didn't stress it well enough: read the upgrade notes! In case of switching to systemd: read about what the change means.
In other words, at least in minds of those who decided to migrate to UNIX, this change it not just about learning new tools. It is about how the system works. I am not going to argue they (refugees to UNIX) are right, or proponents of systemd (and friends) are right. The important part is that each weighed the changed and will deal with the consequences of the decision made conscientiously. But for that (to make good decision), once again:
Read the "upgrade notes" [systemd documentation in this case]! This is the decision about your system and its future life.
Right. And I do want to point out, this list is really not the place to discuss the positives and negatives of systemd vs. upstart vs. SysV. The goal of CentOS is to build RHEL source code with the absolute minimum changes required for branding. So, we get the init system that is in the source code.
Having that kind of discussion on a Fedora list might be appropriate if you are not a RHEL customer or on a RHEL list if you are.
What I didn't expect, and what really threw me was that this has been implemented via a simply 'yum update' of an existing system, not at a major release level.
On Fri, May 6, 2016 8:46 am, Johnny Hughes wrote:
On 05/06/2016 08:38 AM, Valeri Galtsev wrote:
On Fri, May 6, 2016 3:13 am, Gary Stainburn wrote:
On Thursday 05 May 2016 17:16:17 Valeri Galtsev wrote:
There were several heated discussions on this list, and elsewhere. This is not intended to start the new one, but to help someone who missed them to define their statute.
People split into two groups:
Opponents of systemd (, firewqalld, etc.) who argue that from formerly Unix-like system Linux becomes Unix-unlike (or more MS Windows-like), and this is bad.
Proponents of systemd etc. who argue that the life goes on, systems evolve and you better keep up with changes.
Therefore, for new person who is about to, let's say, upgrade Linux system to the version with systemd, there is a decision that will define that person's future maintenance of this new system. And the decision has to be made before upgrade. Luckily for those who do decide to go with systemd, bugs (that always are present in new software) are being solved. Luckily for those who do not accept fundamental changes systemd brings (like binary logs or config files infested with XML garbage - sorry if I'm missing or misinterpreting something) there are Unix system one can migrate machine to.
Either way one has to read and estimate what making that step (upgrading to systemd, firewalld based Linux or switching to some flavor of Unix) will entail in a long run for that server and the server admin. Either way, as in one of Unix handbooks they stress: read carefully the upgrade notes!
I hope, this helps someone.
Valeri
I understand the arguments for the move to systemd - and I also understand the points of those arguments. Like most arguments, there are some valid and positive points and some not so.
There are times - such as the encompassing of the name resolver code - where it just seems a case of replacing old, mature code with new untested code for no reason.
Either way, I now have to manage both traditional and systemd based systems. Okay, it just means learning new toolsets, but it's something else I have to learn, and something else I have to cope with for my bespoke systems and services.
I guess, I didn't stress it well enough: read the upgrade notes! In case of switching to systemd: read about what the change means.
In other words, at least in minds of those who decided to migrate to UNIX, this change it not just about learning new tools. It is about how the system works. I am not going to argue they (refugees to UNIX) are right, or proponents of systemd (and friends) are right. The important part is that each weighed the changed and will deal with the consequences of the decision made conscientiously. But for that (to make good decision), once again:
Read the "upgrade notes" [systemd documentation in this case]! This is the decision about your system and its future life.
Right. And I do want to point out, this list is really not the place to discuss the positives and negatives of systemd vs. upstart vs. SysV. The goal of CentOS is to build RHEL source code with the absolute minimum changes required for branding. So, we get the init system that is in the source code.
Exactly. As I said in the first post (reply to which happened to hijack the thread - my apologies that was not intended by me), it was only intended to help those who are just about to make this step to really think about what it will entail. And thanks everybody who added their comments, they all do the same what I intended.
Valeri
Having that kind of discussion on a Fedora list might be appropriate if you are not a RHEL customer or on a RHEL list if you are.
What I didn't expect, and what really threw me was that this has been implemented via a simply 'yum update' of an existing system, not at a major release level.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Friday 06 May 2016 14:55:33 Valeri Galtsev wrote:
Exactly. As I said in the first post (reply to which happened to hijack the thread - my apologies that was not intended by me), it was only intended to help those who are just about to make this step to really think about what it will entail. And thanks everybody who added their comments, they all do the same what I intended.
Valeri
Unfortunately, the problem was that I didn't (know I) have a decision to make regarding systemd or SysV.
My decision was do I keep my system up to date (which it wasn't) or not. I am sure that I am no different to 90% of sysadmins who don't read all release notes before every 'yum update' run.
I do have to concede that the update did update a great deal of RPM's and probably some by a number of versions. This no doubt is the reason I now have a reasonable sized number of changes I need to deal with (including keep_environment in EXIM, and journals moving on Dovecot )
On Fri, May 06, 2016 at 03:18:03PM +0100, Gary Stainburn wrote:
I do have to concede that the update did update a great deal of RPM's and probably some by a number of versions. This no doubt is the reason I now have a reasonable sized number of changes I need to deal with (including keep_environment in EXIM, and journals moving on Dovecot )
Dovecot hasn't been updated since CentOS 7.2.1511 was released, as far as I can tell. Looking at the default configuration, /etc/dovecot/conf.d/10-logging.conf indicates the default is to log to syslog. Perhaps you had a custom configuration that was overwritten? The RPM shouldn't have overwritten anything in /etc/dovecot though.
As for Exim, that's packaged in EPEL, and the EPEL maintainer can bump the version mid-point-release.
For what its worth, I have some production services that rely on packages in EPEL, and I maintain a private mirror so I can push out changes after testing. I also watch the epel-package-announce list to keep on top of all the changes in EPEL.
One thing I noticed was that the latest EPEL release has this in its changelog:
https://lists.fedoraproject.org/archives/list/epel-package-announce@lists.fe...
[ 1 ] Bug #1323775 - Default /etc/exim/exim.conf does not have add_environment/keep_environment https://bugzilla.redhat.com/show_bug.cgi?id=1323775
On 05/06/2016 09:18 AM, Gary Stainburn wrote:
On Friday 06 May 2016 14:55:33 Valeri Galtsev wrote:
Exactly. As I said in the first post (reply to which happened to hijack the thread - my apologies that was not intended by me), it was only intended to help those who are just about to make this step to really think about what it will entail. And thanks everybody who added their comments, they all do the same what I intended.
Valeri
Unfortunately, the problem was that I didn't (know I) have a decision to make regarding systemd or SysV.
You made that decision when you installed CentOS-7 instead of CentOS-6. CentOS-7 has always used SystemD .. CentOS-6 has always used SysV.
My decision was do I keep my system up to date (which it wasn't) or not. I am sure that I am no different to 90% of sysadmins who don't read all release notes before every 'yum update' run.
Well, that might be true, but if you are going to do a major update you should. Especially an update that crosses 2 point releases. We do major release notes for point releases, as does Red Hat.
https://wiki.centos.org/Manuals/ReleaseNotes
(Release Notes, 7.1503 and 7.1511 {current set})
https://access.redhat.com/documentation/en/red-hat-enterprise-linux/
(Release Notes and Technical Notes, 7.1 and 7.2)
I scanned those for dovecot and did not see any known issues.
I do have to concede that the update did update a great deal of RPM's and probably some by a number of versions. This no doubt is the reason I now have a reasonable sized number of changes I need to deal with (including keep_environment in EXIM, and journals moving on Dovecot )
As I said before, EXIM is not even part of CentOS. It is part of EPEL.
EPEL is awesome, but it is not part of RHEL proper. While they make every effort to make it as stable/tested as they can, if it was something that they wanted to provide an SLA for in RHEL, it would be part of RHEL. Since its not, it (or any other package in EPEL and not RHEL) should be thought of as part of the base OS (either RHEL or CentOS).
Dovecot was last updated on 25 Nov 2015. The one before that was, to the best of my knowledge, 5 July 2014 Which was part of 7.0.1406 release). It would seem you did almost 2 years worth of updates at one time. That is likely not good {how many critical (even named updates, with their own website) have been done in the last 2 years}. Heartbleed, Shellshock, Poodle and Ghost come to mind right off the top of my head. Hopefully 90% of sysadmins don't do that (jump from through 2 point releases (almost 2 years worth of updates) on a production server without doing any kind if testing proir to the update. With 3rd party repos enabled.
I am sure some sysadmins do that though, you are correct.
As to your actual issue, how dovecot logging was changed, I have no idea unless it was a system wide change in logging. To really figure it out, one would need to perform an analysis of your individual setup. I also see no issues for dovecot reported concerning an upgrade from rhel7.0 to rhel7.2.
Johnny Hughes wrote: <SNIP>
Right. And I do want to point out, this list is really not the place to discuss the positives and negatives of systemd vs. upstart vs. SysV. The goal of CentOS is to build RHEL source code with the absolute minimum changes required for branding. So, we get the init system that is in the source code.
Having that kind of discussion on a Fedora list might be appropriate if you are not a RHEL customer or on a RHEL list if you are.
<snip> Sorry, I hadn't read this when I posted my followup to Valeri. At any rate, I *only* intended to make that one comment, and have no intention of following up. I think that most of us do *NOT* want another flamewar that buries actual question and answers related to what we're doing with CentOS - administering and running it.
mark
Valeri Galtsev wrote:
On Fri, May 6, 2016 3:13 am, Gary Stainburn wrote:
On Thursday 05 May 2016 17:16:17 Valeri Galtsev wrote:
There were several heated discussions on this list, and elsewhere. This is not intended to start the new one, but to help someone who missed them to define their statute.
People split into two groups:
Opponents of systemd (, firewqalld, etc.) who argue that from formerly Unix-like system Linux becomes Unix-unlike (or more MS Windows-like), and this is bad.
Proponents of systemd etc. who argue that the life goes on, systems evolve and you better keep up with changes.
Or.... https://www.redhat.com/en/about/press-releases/microsoft-and-red-hat-deliver-new-standard-enterprise-cloud-experiences <snip>
mark
-
Gary Stainburn -
John Hodrien -
Johnny Hughes -
Jonathan Billings -
m.roth＠5-cent.us -
Valeri Galtsev