4

On this wiki they recommend tracking /var/log/dmesg using Mercurial. I wanted to set up a cron job on CentOS 6.4 like on this page to remind myself to make commit messages for such a repo. However, the output of hg diff on /var/log/dmesg is pretty long, and I don't really understand what it is I'd be looking for.

If you track this file yourself, why? What problems do you watch out for with it? How frequently does yours change?

streppel
  • 149
  • 1
  • 8
Kev
  • 1,729
  • 4
  • 27
  • 47

2 Answers2

2

On the links you posted about tracking /var/log/dmesg, it's only discussed on the first one, but I don't think this is really even the primary focus of these articles. They're primarily discussing how you'd track changes made to your /etc directory, which is something you'd definitely want to do, and it's pretty easy to do.

However, if you're interested in tracking changes for /etc, I would use a wrapper tool such as etckeeper, instead of doing it with vanilla git/mercurial (there are several reasons for this, the primary being that git and mercurial don't keep track of permissions that become important in /etc). Obviously for /etc, all your configuration information is kept there so it's valuable to track changes on these files over time.

As to whether you should track the changes made to /var/log/dmesg? I don't see any value in this and believe it would be a waste of time and resources to do so.

strugee
  • 14,723
  • 17
  • 73
  • 119
slm
  • 363,520
  • 117
  • 767
  • 871
  • 1
    That wiki page does recommend putting `/var/log/dmesg` under version control. I don't see the point. Logs are append-only and change automatically, which makes version control useless. – Gilles 'SO- stop being evil' Sep 04 '13 at 23:18
  • @Gilles - thanks I was searching in the page for "/var/log.." it shows up as "var/log/...". Still think it's a waste of time to log it though. – slm Sep 04 '13 at 23:23
  • Just a note, I accepted this answer for the last sentence only, since that's the only part that actually was what I was asking about. :) – Kev Sep 06 '13 at 15:26
  • @Kev - Sorry, if you haven't noticed by now I tend to ramble...was just trying to provide additional context, I'm not a big fan of one sentence answers. True they may answer your specific needs but I find them extremely annoying when I go to superuser and stackoverflow. They often times are worthless to others that come across them months/years later from google. I will try to be less wordy 8-) – slm Sep 06 '13 at 15:35
  • No worries, the same applies to Gilles' answer. To me the etckeeper recommendation is an okay aside, and the rest is off-topic, but to each their own. :) (I.e. to me, your and Gilles' answers, with regards to my question, are functionally the same: dmesg is not worth tracking, plus an etckeeper recommendation, plus some other stuff I didn't ask about. But I'm sure that to others it's a different story.) – Kev Sep 06 '13 at 17:29
0

Tracking configuration files such as most everything in /etc is a good idea. Rather than committing only a few files, simply commit everything. Managing /etc can be a little tricky (you have to be able to restore permissions and ownership of files, which version control software doesn't typically do), and it's really handy to have package managers perform commits automatically, so I don't recommend using version control software directly. Instead, use etckeeper, which takes care of managing permission and ownership, and has hooks for yum. Unlike Debian and Ubuntu, CentOS doesn't ship etckeeper out of the box but it can be installed.

Tracking /usr/local/bin and /usr/local/sbin can be a good idea, though it depends what you put there. If you write scripts for your system and put them there, these directories should be under version control. If you install third-party software, these directories probably should not be under version control. What I do is to write my local scripts in /etc/local/bin and /etc/local/sbin (which are in the etckeeper-managed area) and either add these directories to the system-wide default PATH or create symbolic links under /usr/local.

Putting log files such as /var/log/dmesg and /var/log/rpmpkgs under version control is pointless. Log files only ever grow under normal operation. They may be rotated, which shrinks the log file but does not remove any log data: it's just moved to a new file name. Since the log only grows, there is no point in reverting to an earlier version. The log won't be branched. The log is only ever modified automatically, no manually. Thus none of the benefits of version control come into play.

Worse, there may be a legal requirement to purge old logs for privacy. Putting the logs under version control makes it very difficult to purge old versions. Logs should be archived separately.

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175