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:
@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:
Well, in 6.5 it is located at /etc/syslog.conf.
You sure? That goes against what we had determined.
Determined where? All we determined was that the article was from 6.2 and in 7 they changed everything.
No, we determined that it was 6.2 and that all evidence said that the change was in 6.5. We know 100% that things had changed by 7, and there is zero reason to not think that it changed in 6.5 and everything in that thread showed that it had indeed changed in 6.5.
Right - it's like the GPO example given above. XS has a script (like GPO) that it runs that edits /etc/syslog.conf so editing /etc/syslog.conf directly is pointless, like editing a windows machine registry is pointless because they will be over written by the script/GPO
The other file ALSO got overwritten.
@DustinB3403 can check and confirm or deny this, as well.
What is the other one? And did you check that there is no GUI running?
/etc/syslog.conf
and
/var/lib/syslog.conf
Those don't seem right.
-
@BRRABill said in Final Call ... XenServer Boot Media:
@scottalanmiller said in Final Call ... XenServer Boot Media:
@BRRABill 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:
Well, in 6.5 it is located at /etc/syslog.conf.
You sure? That goes against what we had determined.
Determined where? All we determined was that the article was from 6.2 and in 7 they changed everything.
No, we determined that it was 6.2 and that all evidence said that the change was in 6.5. We know 100% that things had changed by 7, and there is zero reason to not think that it changed in 6.5 and everything in that thread showed that it had indeed changed in 6.5.
Right - it's like the GPO example given above. XS has a script (like GPO) that it runs that edits /etc/syslog.conf so editing /etc/syslog.conf directly is pointless, like editing a windows machine registry is pointless because they will be over written by the script/GPO
The other file ALSO got overwritten.
@DustinB3403 can check and confirm or deny this, as well.
What is the other one? And did you check that there is no GUI running?
Do not know about the GUI. What would that affect?
Well a GUI obviously has to overwrite the master configuration file to do its job. The GUI is a form of a text editor to that file. So if you make a change by hand, then let the GUI control it and the GUI thinks you want something else, obviously the GUI has to change it, too. Too many cooks in the kitchen.
-
BTW, here is the directory this morning.
Apparently it CREATES the files each day, but does nothing with them.
There is still that 38M lastlog file, but I think that is a bug in XS7. (Or Linux itself.)
https://bugs.xenserver.org/browse/XSO-534From what I have read, that file maintains a DB of logins, and can be deleted.
drwxr-xr-x 2 root root 4096 Sep 7 10:10 blktap -rw-r--r-- 1 root root 38273316 Sep 7 09:36 lastlog -rw-rw-r-- 1 root utmp 44544 Sep 7 09:36 wtmp -rw------- 1 root utmp 1152 Sep 7 09:36 btmp -rw-r--r-- 1 root root 0 Sep 7 04:02 boot.log -rw------- 1 root root 0 Sep 7 04:02 cron -rw------- 1 root root 0 Sep 7 04:02 daemon.log -rw------- 1 root root 0 Sep 7 04:02 kern.log -rw------- 1 root root 0 Sep 7 04:02 maillog -rw------- 1 root root 0 Sep 7 04:02 messages -rw------- 1 root root 0 Sep 7 04:02 secure -rw------- 1 root root 0 Sep 7 04:02 SMlog -rw------- 1 root root 0 Sep 7 04:02 spooler -rw------- 1 root root 0 Sep 7 04:02 user.log -rw------- 1 root root 0 Sep 7 04:02 xcp-rrdd-plugins.log drwxr-xr-x 2 root root 4096 Sep 7 04:02 xen -rw------- 1 root root 0 Sep 7 04:02 xenstored-access.log -rw------- 1 root root 0 Sep 7 04:02 audit.log -rw-r--r-- 1 root root 0 Sep 7 04:02 interface-rename.log -rw------- 1 root root 0 Sep 7 00:40 xensource.log drwxr-xr-x 2 root root 4096 Sep 7 00:00 sa -
du says it is really 48K
-
@BRRABill said in Final Call ... XenServer Boot Media:
There is still that 38M lastlog file, but I think that is a bug in XS7. (Or Linux itself.)
https://bugs.xenserver.org/browse/XSO-534From what I have read, that file maintains a DB of logins, and can be deleted.
Yes, lastlog is a security mechanism, it is tiny and it is not part of syslogging. It's not likely 38M, that's enormous. Check that again.
-
@BRRABill said in Final Call ... XenServer Boot Media:
du says it is really 48K
Yes, it is a sparse file. Very small.
-
@scottalanmiller said in Final Call ... XenServer Boot Media:
@BRRABill said in Final Call ... XenServer Boot Media:
du says it is really 48K
Yes, it is a sparse file. Very small.
As I mentioned it is a bug of some sort, somewhere.
Seems like it happens across platforms.
-
@BRRABill said in Final Call ... XenServer Boot Media:
@scottalanmiller said in Final Call ... XenServer Boot Media:
@BRRABill said in Final Call ... XenServer Boot Media:
du says it is really 48K
Yes, it is a sparse file. Very small.
As I mentioned it is a bug of some sort, somewhere.
Seems like it happens across platforms.
What is a bug?
-
lastlog is not a bug, it's exactly as intended.
-
@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:
du says it is really 48K
Yes, it is a sparse file. Very small.
As I mentioned it is a bug of some sort, somewhere.
Seems like it happens across platforms.
What is a bug?
" On several versions of RedHat Enterprise Linux and Fedora, corruption in this file can cause the size to be misrepresented. This has no effect on the real space used by the file, as reported by the du command."
-
@Dashrender said in Final Call ... XenServer Boot Media:
@scottalanmiller said in Final Call ... XenServer Boot Media:
@BRRABill said in Final Call ... XenServer Boot Media:
If you are trying to tell me that this ONE system that is set up like this is the norm, and all the others are incorrect or just plain dumb, well, then, fine.
General good practice (rule of thumb, NOT best practice) is to "always" use UTC for all service based systems (servers and similar devices.) End users set time for the user, not the system, so this does not normally apply to end users. But we've always set all servers to UTC since the late 1990s. It protects against time bugs from the 1990s, it makes logs way clearer, it keeps people like @Minion-Queen from causing time problems from getting confused on time zones, it lets teams in different regions work together seamlessly. Yes, UTC on everything for IT.
Huh, first time I've ever heard this - even being in SW for better than 5 years.
It is not common at all in the SMB because the SMB rarely does logging. When you get into logging it is almost always done in UTC on the backend. and the user can select their own timezone for their GUI to report if desired.
-
@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:
du says it is really 48K
Yes, it is a sparse file. Very small.
As I mentioned it is a bug of some sort, somewhere.
Seems like it happens across platforms.
What is a bug?
" On several versions of RedHat Enterprise Linux and Fedora, corruption in this file can cause the size to be misrepresented. This has no effect on the real space used by the file, as reported by the du command."
Who said that? That's totally wrong. It's space is not misrepresented, it's not a bug. Someone is confused. ls and du show different things, both are correct.
-
@JaredBusch 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:
If you are trying to tell me that this ONE system that is set up like this is the norm, and all the others are incorrect or just plain dumb, well, then, fine.
General good practice (rule of thumb, NOT best practice) is to "always" use UTC for all service based systems (servers and similar devices.) End users set time for the user, not the system, so this does not normally apply to end users. But we've always set all servers to UTC since the late 1990s. It protects against time bugs from the 1990s, it makes logs way clearer, it keeps people like @Minion-Queen from causing time problems from getting confused on time zones, it lets teams in different regions work together seamlessly. Yes, UTC on everything for IT.
Huh, first time I've ever heard this - even being in SW for better than 5 years.
It is not common at all in the SMB because the SMB rarely does logging. When you get into logging it is almost always done in UTC on the backend. and the user can select their own timezone for their GUI to report if desired.
Yeah, it's not common. Sadly. But even without logging, it's useful. If you have multiple time zones to support, deal with remote access, etc. Logging really pushes it, but it is hardly the only thing. We did it more than a decade before we did central logging. It's a good practice (for most companies, again not a best practice, but should be considered for your use case) but not at all a common one.
-
@scottalanmiller said
" On several versions of RedHat Enterprise Linux and Fedora, corruption in this file can cause the size to be misrepresented. This has no effect on the real space used by the file, as reported by the du command."
Who said that? That's totally wrong. It's space is not misrepresented, it's not a bug. Someone is confused. ls and du show different things, both are correct.
Also, in the XS bug link I posted above.
-
A good definition of why it is not a bug:
http://www.noah.org/wiki/Lastlog_is_gigantic -
@BRRABill said in Final Call ... XenServer Boot Media:
@scottalanmiller said
" On several versions of RedHat Enterprise Linux and Fedora, corruption in this file can cause the size to be misrepresented. This has no effect on the real space used by the file, as reported by the du command."
Who said that? That's totally wrong. It's space is not misrepresented, it's not a bug. Someone is confused. ls and du show different things, both are correct.
Also, in the XS bug link I posted above.
I feel that that bug report is in error. This is not a bug, it is intentional and purposeful. It's well known to Linux admins, if they both showed the same size, it would be a bug.
-
@scottalanmiller said in Final Call ... XenServer Boot Media:
@BRRABill said in Final Call ... XenServer Boot Media:
@scottalanmiller said
" On several versions of RedHat Enterprise Linux and Fedora, corruption in this file can cause the size to be misrepresented. This has no effect on the real space used by the file, as reported by the du command."
Who said that? That's totally wrong. It's space is not misrepresented, it's not a bug. Someone is confused. ls and du show different things, both are correct.
Also, in the XS bug link I posted above.
I feel that that bug report is in error. This is not a bug, it is intentional and purposeful. It's well known to Linux admins, if they both showed the same size, it would be a bug.
Stupid Internet.
-
@BRRABill said in Final Call ... XenServer Boot Media:
BTW, here is the directory this morning.
Apparently it CREATES the files each day, but does nothing with them.
There is still that 38M lastlog file, but I think that is a bug in XS7. (Or Linux itself.)
https://bugs.xenserver.org/browse/XSO-534That's just a fake bug report from someone who didn't know Linux logging a bug because they were confused. The first comment answers why the reporter is confused. The bug is not assigned because there isn't any bug.
-
@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
" On several versions of RedHat Enterprise Linux and Fedora, corruption in this file can cause the size to be misrepresented. This has no effect on the real space used by the file, as reported by the du command."
Who said that? That's totally wrong. It's space is not misrepresented, it's not a bug. Someone is confused. ls and du show different things, both are correct.
Also, in the XS bug link I posted above.
I feel that that bug report is in error. This is not a bug, it is intentional and purposeful. It's well known to Linux admins, if they both showed the same size, it would be a bug.
Stupid Internet.
This is one of those "searching on it isn't useful, you have to study it in a structured way" to learn about it properly.
-
@scottalanmiller said
That's just a fake bug report from someone who didn't know Linux logging a bug because they were confused. The first comment answers why the reporter is confused. The bug is not assigned because there isn't any bug.
Ahhh, you have to log in to read comments.
