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.
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? -
BTW, there was a post on the XenServer forums about running off of USB today, and this was the response (from a user with almost 6,000 posts there):
"Its technically possible, but frowned upon due to SD cards usually not being good quality that can handle the amount of read/writes. There are sites/link on the Internet where others have done such a thing. Citrix will likely not be of assistance if you need there support, you would be totally on your own."
-
@DustinB3403 said in Final Call ... XenServer Boot Media:
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?
No idea.
And I wonder if we really NEED those logs.
-
I also took a look at the /var/log directory. There is a ton of stuff in there. It appears that XS7 is now archiving previous day logs. If that is the case, it might be OK on USB because it would always be writing to new areas, no?
-rw------- 1 root root 11128337 Sep 6 11:00 xensource.log -rw------- 1 root root 1439756 Sep 6 11:00 audit.log -rw------- 1 root root 835573 Sep 6 11:00 SMlog -rw------- 1 root root 7792 Sep 6 11:00 cron -rw------- 1 root root 73125 Sep 6 11:00 daemon.log -rw------- 1 root root 28967 Sep 6 10:56 xcp-rrdd-plugins.log -rw------- 1 root root 4999 Sep 6 10:53 secure -rw-r--r-- 1 root root 38273316 Sep 6 10:36 lastlog -rw-rw-r-- 1 root utmp 38016 Sep 6 10:36 wtmp drwxr-xr-x 2 root root 4096 Sep 6 04:02 xen -rw------- 1 root root 0 Sep 6 04:02 xenstored-access.log -rw-r--r-- 1 root root 0 Sep 6 04:02 boot.log -rw-r--r-- 1 root root 0 Sep 6 04:02 interface-rename.log -rw------- 1 root root 0 Sep 6 04:02 kern.log -rw------- 1 root root 0 Sep 6 04:02 maillog -rw------- 1 root root 0 Sep 6 04:02 messages -rw------- 1 root root 0 Sep 6 04:02 spooler -rw------- 1 root root 0 Sep 6 04:02 user.log -rw------- 1 root root 28610 Sep 6 04:02 cron.1 -rw------- 1 root root 244847 Sep 6 04:02 daemon.log.1 -rw------- 1 root root 186 Sep 6 04:02 user.log.1 -rw------- 1 root root 4951616 Sep 6 04:01 audit.log.1 -rw------- 1 root root 2876101 Sep 6 04:01 SMlog.1 -rw------- 1 root root 100512 Sep 6 04:00 xcp-rrdd-plugins.log.1 -rw------- 1 root root 25827200 Sep 6 00:39 xensource.log.1 drwxr-xr-x 2 root root 4096 Sep 6 00:00 sa -rw-r--r-- 1 root root 0 Sep 5 04:02 boot.log.1 -rw------- 1 root root 0 Sep 5 04:02 kern.log.1 -rw------- 1 root root 0 Sep 5 04:02 maillog.1 -rw------- 1 root root 0 Sep 5 04:02 messages.1 -rw------- 1 root root 0 Sep 5 04:02 secure.1 -rw------- 1 root root 0 Sep 5 04:02 spooler.1 -rw------- 1 root root 0 Sep 5 04:02 xenstored-access.log.1 -rw------- 1 root root 2440 Sep 5 04:02 cron.2.gz -rw------- 1 root root 8110 Sep 5 04:02 daemon.log.2.gz -rw-r--r-- 1 root root 0 Sep 5 04:02 interface-rename.log.1 -rw------- 1 root root 132 Sep 5 04:02 user.log.2.gz -rw------- 1 root root 409473 Sep 5 04:01 audit.log.2.gz -rw------- 1 root root 323003 Sep 5 04:01 SMlog.2.gz -rw------- 1 root root 2189 Sep 5 04:00 xcp-rrdd-plugins.log.2.gz -rw------- 1 root root 2112543 Sep 5 00:39 xensource.log.2.gz -rw-r--r-- 1 root root 20 Sep 4 04:02 boot.log.2.gz -rw------- 1 root root 20 Sep 4 04:02 kern.log.2.gz -rw------- 1 root root 20 Sep 4 04:02 xenstored-access.log.2.gz -rw------- 1 root root 2417 Sep 4 04:02 cron.3.gz -rw------- 1 root root 7605 Sep 4 04:02 daemon.log.3.gz -rw-r--r-- 1 root root 20 Sep 4 04:02 interface-rename.log.2.gz -rw------- 1 root root 20 Sep 4 04:02 maillog.2.gz -rw------- 1 root root 20 Sep 4 04:02 messages.2.gz -rw------- 1 root root 20 Sep 4 04:02 secure.2.gz -rw------- 1 root root 20 Sep 4 04:02 spooler.2.gz -rw------- 1 root root 135 Sep 4 04:02 user.log.3.gz -rw------- 1 root root 409148 Sep 4 04:01 audit.log.3.gz -rw------- 1 root root 323042 Sep 4 04:01 SMlog.3.gz -rw------- 1 root root 2192 Sep 4 04:00 xcp-rrdd-plugins.log.3.gz -rw------- 1 root root 2112497 Sep 4 00:39 xensource.log.3.gz -rw------- 1 root root 20 Sep 3 04:02 xenstored-access.log.3.gz -rw-r--r-- 1 root root 20 Sep 3 04:02 boot.log.3.gz -rw-r--r-- 1 root root 20 Sep 3 04:02 interface-rename.log.3.gz -rw------- 1 root root 20 Sep 3 04:02 kern.log.3.gz -rw------- 1 root root 20 Sep 3 04:02 maillog.3.gz -rw------- 1 root root 20 Sep 3 04:02 messages.3.gz -rw------- 1 root root 20 Sep 3 04:02 secure.3.gz -rw------- 1 root root 20 Sep 3 04:02 spooler.3.gz -rw------- 1 root root 2386 Sep 3 04:02 cron.4.gz -rw------- 1 root root 7599 Sep 3 04:02 daemon.log.4.gz -rw------- 1 root root 132 Sep 3 04:02 user.log.4.gz -rw------- 1 root root 409287 Sep 3 04:01 audit.log.4.gz -rw------- 1 root root 323073 Sep 3 04:01 SMlog.4.gz -rw------- 1 root root 2195 Sep 3 03:59 xcp-rrdd-plugins.log.4.gz -rw------- 1 root root 2113429 Sep 3 00:39 xensource.log.4.gz -rw------- 1 root root 509 Sep 2 13:40 secure.4.gz -rw-r--r-- 1 root root 20 Sep 2 04:02 boot.log.4.gz -rw------- 1 root root 20 Sep 2 04:02 kern.log.4.gz -rw------- 1 root root 20 Sep 2 04:02 maillog.4.gz -rw------- 1 root root 20 Sep 2 04:02 messages.4.gz -rw------- 1 root root 20 Sep 2 04:02 spooler.4.gz -rw------- 1 root root 20 Sep 2 04:02 xenstored-access.log.4.gz -rw------- 1 root root 2415 Sep 2 04:02 cron.5.gz -rw------- 1 root root 7695 Sep 2 04:02 daemon.log.5.gz -rw-r--r-- 1 root root 20 Sep 2 04:02 interface-rename.log.4.gz -rw------- 1 root root 132 Sep 2 04:02 user.log.5.gz -rw------- 1 root root 409466 Sep 2 04:01 audit.log.5.gz -rw------- 1 root root 323045 Sep 2 04:01 SMlog.5.gz -rw------- 1 root root 2184 Sep 2 03:59 xcp-rrdd-plugins.log.5.gz -rw------- 1 root root 2113136 Sep 2 00:39 xensource.log.5.gz -rw------- 1 root root 684 Sep 1 15:18 secure.5.gz -rw------- 1 root root 128 Sep 1 15:18 kern.log.5.gz -rw------- 1 root utmp 384 Sep 1 11:27 btmp -rw------- 1 root root 20 Sep 1 04:02 xenstored-access.log.5.gz -rw-r--r-- 1 root root 20 Sep 1 04:02 boot.log.5.gz -rw-r--r-- 1 root root 20 Sep 1 04:02 interface-rename.log.5.gz -rw------- 1 root root 20 Sep 1 04:02 maillog.5.gz -rw------- 1 root root 20 Sep 1 04:02 messages.5.gz -rw------- 1 root root 20 Sep 1 04:02 spooler.5.gz -rw------- 1 root root 2406 Sep 1 04:02 cron.6.gz -rw------- 1 root root 8042 Sep 1 04:02 daemon.log.6.gz -rw------- 1 root root 132 Sep 1 04:02 user.log.6.gz -rw------- 1 root root 409421 Sep 1 04:01 audit.log.6.gz -rw------- 1 root root 323078 Sep 1 04:01 SMlog.6.gz -rw------- 1 root root 2208 Sep 1 03:58 xcp-rrdd-plugins.log.6.gz -rw------- 1 root root 2113430 Sep 1 00:39 xensource.log.6.gz -
Yeah, until you run out of space. Space is the bigger issue than running out of read/write ares on the flash.
-
@BRRABill said in Final Call ... XenServer Boot Media:
In 6.5, the configuration was located in /var/lib/syslong.conf, as stated in that article.
Actually the article said that it was NOT this for 6.5. The article never looked past 6.2 and didn't know where it had moved to.
