Final Call ... XenServer Boot Media
-
@Dashrender said in Final Call ... XenServer Boot Media:
@scottalanmiller said in Final Call ... XenServer Boot Media:
Well it was getting overwritten. That's a pretty big give away. Something else was changing his configuration. So that wasn't the final configuration. When you look at the documents, they do tell you that that isn't the file in this case and that there is a separate master file that controls that one.
To which I reply - fraking OS. While it's not impossible so see something like this on Windows, I don't personally recall seeing a file that edits a file like this.
But now I'm just complaining! back to the issue at hand.
Ever seen a GPO on Windows? That does this too. Try making a local change then having GP overwrite it. Exactly the same.
-
@Dashrender said in Final Call ... XenServer Boot Media:
To which I reply - fraking OS. While it's not impossible so see something like this on Windows, I don't personally recall seeing a file that edits a file like this.
I have most certainly seen it many times on Windows.
-
@scottalanmiller said in Final Call ... XenServer Boot Media:
@Dashrender said in Final Call ... XenServer Boot Media:
@scottalanmiller said in Final Call ... XenServer Boot Media:
@BRRABill said in Final Call ... XenServer Boot Media:
@scottalanmiller said in Final Call ... XenServer Boot Media:
@BRRABill said in Final Call ... XenServer Boot Media:
@scottalanmiller said in Final Call ... XenServer Boot Media:
@BRRABill said in Final Call ... XenServer Boot Media:
@scottalanmiller said in Final Call ... XenServer Boot Media:
@BRRABill said in Final Call ... XenServer Boot Media:
XS rewrote the rsyslog.conf every time.
Ah, I never saw that mentioned and that means that you were addressing the wrong thing. You needed to stop it changing rsyslog.conf. What did you do to stop it from doing that?
Nothing. I followed the instructions in the above mentioned article.
If this article isn't for doing what you want, why expect it to do something different than it is intended to do?
I'm not.
I don't understand your question/comment.
Why were you following the instructions in that article? What was the end goal?
To prevent XS from logging locally when I have it set up to log externally.
But the files to do that were not yet modified, right? So we aren't up to step one yet. That's my point. There are config files that make this happen, but those were not changed. Only the ones that they change, were changed, but that won't do anything.
How was @BRRABill suppose to know that he's editing the wrong files? I guess it's called RTFM.
Well it was getting overwritten. That's a pretty big give away. Something else was changing his configuration. So that wasn't the final configuration. When you look at the documents, they do tell you that that isn't the file in this case and that there is a separate master file that controls that one.
What if he had just opened an editor and made his own file in /tmp/mychanges.txt and wrote in it "don't write logs locally?" That also would not work. But we might say "how was he supposed to know that he had to modify a specific file?"
It's clear that he tried and made a good guess. But it is also clear that the actual configuration was not done correctly and that the first step has to be identifying the right place to make the changes. Instead, changes were made and failure concluded before looking to see which file needed to be modified.
He was following some instructions he found. I do recall the thread on here last or the week before where it was discovered that the file wasn't keeping the changes through a reboot, but then I wasn't able to keep following it.
-
@Dashrender said in Final Call ... XenServer Boot Media:
He was following some instructions he found. I do recall the thread on here last or the week before where it was discovered that the file wasn't keeping the changes through a reboot, but then I wasn't able to keep following it.
And it was proven that those were bad instructions.
-
@Dashrender said in Final Call ... XenServer Boot Media:
He was following some instructions he found. I do recall the thread on here last or the week before where it was discovered that the file wasn't keeping the changes through a reboot, but then I wasn't able to keep following it.
They were rather random ones, though, that they themselves talked about how it didn't work and were resorting to things like trying to stop file writes rather than looking for the right file. So it sounded like they said right in it that the directions were wrong, right?
-
@Dashrender said in Final Call ... XenServer Boot Media:
He was following some instructions he found. I do recall the thread on here last or the week before where it was discovered that the file wasn't keeping the changes through a reboot, but then I wasn't able to keep following it.
I've been through the instructions and there are a few issues. One is that they are very old and predate the XS7 system, I think that they predate XS6.5 as well. And they dont address what he was wanting to do, they don't (that I can find) even talk about not writing the logs locally.
-
@scottalanmiller said in Final Call ... XenServer Boot Media:
@Dashrender said in Final Call ... XenServer Boot Media:
@scottalanmiller said in Final Call ... XenServer Boot Media:
Well it was getting overwritten. That's a pretty big give away. Something else was changing his configuration. So that wasn't the final configuration. When you look at the documents, they do tell you that that isn't the file in this case and that there is a separate master file that controls that one.
To which I reply - fraking OS. While it's not impossible so see something like this on Windows, I don't personally recall seeing a file that edits a file like this.
But now I'm just complaining! back to the issue at hand.
You see it ALL the time. That's what the entire GUI is! That's what every DevOps tools does, yes even on Windows.
OK I get the DevOps thing, but I don't agree with the GUI, the GUI doesn't load pre those files being ran and update the file. It's more like
@stacksofplates said -
This is a file that was added to overwrite changes made. Without looking at an XS system, I'm assuming it's a boot script.
So this is an XS thing, not a rsyslog thing?
-
@scottalanmiller said in Final Call ... XenServer Boot Media:
@Dashrender said in Final Call ... XenServer Boot Media:
@scottalanmiller said in Final Call ... XenServer Boot Media:
Well it was getting overwritten. That's a pretty big give away. Something else was changing his configuration. So that wasn't the final configuration. When you look at the documents, they do tell you that that isn't the file in this case and that there is a separate master file that controls that one.
To which I reply - fraking OS. While it's not impossible so see something like this on Windows, I don't personally recall seeing a file that edits a file like this.
But now I'm just complaining! back to the issue at hand.
Ever seen a GPO on Windows? That does this too. Try making a local change then having GP overwrite it. Exactly the same.
OK Fine I acquiesce, you're right.
-
@Dashrender said in Final Call ... XenServer Boot Media:
So this is an XS thing, not a rsyslog thing?
Yes. If you install CentOS 7, it will not do this.
-
@Dashrender said in Final Call ... XenServer Boot Media:
So this is an XS thing, not a rsyslog thing?
Yes, because he has to control things from the GUI. Some management component is making the changes here, not rsyslog.
As XenCenter can make the syslog changes, it is completely possible that the configuration issue is external with XC pushes the changes from there.
-
@JaredBusch said in Final Call ... XenServer Boot Media:
@Dashrender said in Final Call ... XenServer Boot Media:
He was following some instructions he found. I do recall the thread on here last or the week before where it was discovered that the file wasn't keeping the changes through a reboot, but then I wasn't able to keep following it.
And it was proven that those were bad instructions.
it was? oh? Well then I guess he forgot to mention that from the other thread (snark intended).
-
@Dashrender said in Final Call ... XenServer Boot Media:
@JaredBusch said in Final Call ... XenServer Boot Media:
@Dashrender said in Final Call ... XenServer Boot Media:
He was following some instructions he found. I do recall the thread on here last or the week before where it was discovered that the file wasn't keeping the changes through a reboot, but then I wasn't able to keep following it.
And it was proven that those were bad instructions.
it was? oh? Well then I guess he forgot to mention that from the other thread (snark intended).
I thought that he talked about it a lot in the other thread.
-
@Dashrender said in Final Call ... XenServer Boot Media:
@JaredBusch said in Final Call ... XenServer Boot Media:
@Dashrender said in Final Call ... XenServer Boot Media:
He was following some instructions he found. I do recall the thread on here last or the week before where it was discovered that the file wasn't keeping the changes through a reboot, but then I wasn't able to keep following it.
And it was proven that those were bad instructions.
it was? oh? Well then I guess he forgot to mention that from the other thread (snark intended).
The article itself, in the discussion, mentions that it is for 6.2 and that the author has not tested on 6.5 or later and there are several comments that it doesn't work after 6.2. The author was part of the comments, but only so far as to say that it was not tested after 6.5 and that he recommended double checking the GUI to see if that was what was overriding the configuration file.
Likely 6.5 and later has a master configuration file, this would make sense as we suspect that rsyslog was not in use until around then. So with a change in product would likely come a change in configuration tools. The article was likely spot on for 6.2, but doesn't work with the last few releases.
-
@scottalanmiller said in Final Call ... XenServer Boot Media:
@Dashrender said in Final Call ... XenServer Boot Media:
@JaredBusch said in Final Call ... XenServer Boot Media:
@Dashrender said in Final Call ... XenServer Boot Media:
He was following some instructions he found. I do recall the thread on here last or the week before where it was discovered that the file wasn't keeping the changes through a reboot, but then I wasn't able to keep following it.
And it was proven that those were bad instructions.
it was? oh? Well then I guess he forgot to mention that from the other thread (snark intended).
I thought that he talked about it a lot in the other thread.
LOL well I already mentioned I lost track of the thread. But it does seem kind of logical that he would have run that thread to it's full conclusion - but then it's seeming like perhaps like me, @BRRABill might not have finished the thread either. I think the thread was @DustinB3403 - I remember him having all kinds of troubles getting ELK and several other logging server solutions to work at all and accept logs from XS.
-
@Dashrender said in Final Call ... XenServer Boot Media:
@scottalanmiller said in Final Call ... XenServer Boot Media:
@Dashrender said in Final Call ... XenServer Boot Media:
@JaredBusch said in Final Call ... XenServer Boot Media:
@Dashrender said in Final Call ... XenServer Boot Media:
He was following some instructions he found. I do recall the thread on here last or the week before where it was discovered that the file wasn't keeping the changes through a reboot, but then I wasn't able to keep following it.
And it was proven that those were bad instructions.
it was? oh? Well then I guess he forgot to mention that from the other thread (snark intended).
I thought that he talked about it a lot in the other thread.
LOL well I already mentioned I lost track of the thread. But it does seem kind of logical that he would have run that thread to it's full conclusion - but then it's seeming like perhaps like me, @BRRABill might not have finished the thread either. I think the thread was @DustinB3403 - I remember him having all kinds of troubles getting ELK and several other logging server solutions to work at all and accept logs from XS.
I can't remember that bit. I mean I remember it being discussed, but I don't remember the final status. I thought that nothing was working and that in the end, the directions just didn't apply.
-
@scottalanmiller said in Final Call ... XenServer Boot Media:
@Dashrender said in Final Call ... XenServer Boot Media:
@scottalanmiller said in Final Call ... XenServer Boot Media:
@Dashrender said in Final Call ... XenServer Boot Media:
@JaredBusch said in Final Call ... XenServer Boot Media:
@Dashrender said in Final Call ... XenServer Boot Media:
He was following some instructions he found. I do recall the thread on here last or the week before where it was discovered that the file wasn't keeping the changes through a reboot, but then I wasn't able to keep following it.
And it was proven that those were bad instructions.
it was? oh? Well then I guess he forgot to mention that from the other thread (snark intended).
I thought that he talked about it a lot in the other thread.
LOL well I already mentioned I lost track of the thread. But it does seem kind of logical that he would have run that thread to it's full conclusion - but then it's seeming like perhaps like me, @BRRABill might not have finished the thread either. I think the thread was @DustinB3403 - I remember him having all kinds of troubles getting ELK and several other logging server solutions to work at all and accept logs from XS.
I can't remember that bit. I mean I remember it being discussed, but I don't remember the final status. I thought that nothing was working and that in the end, the directions just didn't apply.
I only remember that Dustin was pissed because even though there was so much fanfare for ELK here on ML he couldn't get it to work. and it seemed that a complete lack of understanding of the components lead to the inability to get help here.
-
Ok, wait wait wait a second here.
This all started because someone here said (I think it was @scottalanmiller ) that is was easy to send the logs from XS somewhere else. And it is. But they is still a bunch of local writing. Even though locations have changed in XS7, the concept is the same.
So, let's take this in steps.
In 6.5, the configuration was located in /var/lib/syslong.conf, as stated in that article.
Finally, select "OK" and the stand-alone XenServer (or pool) will update its Syslog configuration, or more specifically, /var/lib/syslog.conf. The reason for this is so Elastic Syslog can take over the normal duties of Syslog: forwarding messages to the Syslog aggregator accordingly. Certain logs will still continue to record Syslog on the host, so it may be desirable to edit /var/lib/syslog.conf and add comments to lines where a "-/var/log/some_filename" is specified as lines with "@x.x.x.x" dictate to forward to the Syslog aggregator. As an example, I have marked the lines in bold to show where comments should be added to prevent further logging to the local disk:In XS7, the config file appears to be saved in /etc/rsyslog.d/xenserver.conf
When local logging in on, it looks like this
# Suppress duplicate messages and report "Last line repeated n times" $RepeatedMsgReduction on # Don't rate-limit messages - this isn't the right way to go about # reducing log size! $IMUXSockRateLimitInterval 0 $SystemLogRateLimitInterval 0 # Ensure critical and higher level errors are logged synchronously. *.crit;mail.none;authpriv.none;cron.none /var/log/crit.log # Log by facility. kern.* -/var/log/kern.log daemon.* -/var/log/daemon.log user.* -/var/log/user.log # The authpriv file has restricted access. authpriv.* -/var/log/secure # Log all the mail messages in one place. mail.* -/var/log/maillog # Log cron stuff cron.* -/var/log/cron # Save boot messages also to boot.log local7.* /var/log/boot.log # Xapi rbac audit log echoes to syslog local6 local6.* -/var/log/audit.log # Xapi, xenopsd echo to syslog local5 local5.* -/var/log/xensource.log # V6d echo to syslog local4 local4.* -/var/log/v6d.log # xenstore access to syslog local3 local3.info -/var/log/xenstored-access.log # Storage Manager to syslog local2 local2.* -/var/log/SMlog # xcp-rrdd-plugins (info and above) to local0 local0.info -/var/log/xcp-rrdd-plugins.log # ignore default rules *.*When remote logging is turned on the file looks like this, which you can see is almost the same, with the exception of the remote IP address added of the logging server.
# Suppress duplicate messages and report "Last line repeated n times" $RepeatedMsgReduction on # Don't rate-limit messages - this isn't the right way to go about # reducing log size! $IMUXSockRateLimitInterval 0 $SystemLogRateLimitInterval 0 # Ensure critical and higher level errors are logged synchronously. *.crit;mail.none;authpriv.none;cron.none /var/log/crit.log # Log by facility. kern.* -/var/log/kern.log daemon.* -/var/log/daemon.log user.* -/var/log/user.log # The authpriv file has restricted access. authpriv.* -/var/log/secure # Log all the mail messages in one place. mail.* -/var/log/maillog # Log cron stuff cron.* -/var/log/cron # Save boot messages also to boot.log local7.* /var/log/boot.log # Xapi rbac audit log echoes to syslog local6 local6.* -/var/log/audit.log # Xapi, xenopsd echo to syslog local5 local5.* -/var/log/xensource.log # V6d echo to syslog local4 local4.* -/var/log/v6d.log # xenstore access to syslog local3 local3.info -/var/log/xenstored-access.log # Storage Manager to syslog local2 local2.* -/var/log/SMlog # xcp-rrdd-plugins (info and above) to local0 local0.info -/var/log/xcp-rrdd-plugins.log # ignore default rules *.* @10.0.4.31 *.* -
So seeing this, what would you think the next logical step would be to accomplish what I want.
And by association, what anyone running XS off USB would want?
-
And also, is that a good idea in the grand scheme of things.
-
I would still assume based on what you've presented that you need to comment out the local storage folders on both XS6.5 and XS7 to disable logging locally.
The
*.*(at the very end) what purpose does that server?
