Read log files on 3.5

[gdesmo]

Since veeam has not released an update for fastscp 3.5 yet. How can I read files under /var/log. Withough using VI or SC. I am no unix guy. And I dont want to permit root login.

I can't su - from within winscp. So there is no way to copy them or open them from within winscp. Frustrating

[mike_laspina]

Hello,

You don't need to login as root to read the log files, add your non root ID to the root group and then you can use WinSCP to read and copy the logs.

[mike_laspina]

Actually I just checked the perms on the log dir it's 755. You can just use a non root ID as it is, no need to even add it to the root group.

[gdesmo]

I added the root group to my sshuser account and I still get permission denied when trying to open or copy a file.

The sshuser account contains only root and users group. It is also granted shell access.

[mike_laspina]

Apply the following at the console.

chgrp -R root /var/log

[petedr]

I believe most of the files under /var/log ( vmkernel, messages, vmkwarning ) are all 600, so you may need root to access them,

[gdesmo]

chgrp -R root /var/log did nothing to resolve my issue. Still get permision denied.

Is vi thru the service console my only hope? Scrolling down thru the log files takes hours. I can't hit end to goto the end of a log file. And tail does not give me enough of what im looking for.

[mike_laspina]

Yes, you are correct peterdr. The folder is 755 and the files are writen out as 600.

[petedr]

Thats why I think through the service console as root may be the only way that I know of. Maybe there are other ideas, don't know. I believe you can view the hostd logs from the VI3 client.

[mike_laspina]

The logs are controlled with the /etc/logrotate.d <files like vmkernel>

You can edit these and correct the behavior to suite your needs

nano /etc/logrotate.d/vmkernel

change the line with create 600 root root to create 660 root root

and you can do the same for any other logs you need.

[petedr]

Mike,

Good point, I totally forgot about that,

[gdesmo]

Wow I am having no luck. Am I the only one who doesn't know vi? How do others read or copy these logs? Only by enabling root access?

I made the create changes and I still get permision denied. Do I need to restart a service?

[mike_laspina]

I need to see the output of ls -l at the log directory.

[Texiwill]

Hello,

You really do not want to mess around with logfile permissions from a security perspective. Also, if you use nano or vi, they both have search functions. Or you can use the tail command to see the end of the file. I suggest perhaps using 'sudo' so that this type of access to the logfiles is captured. You should know WHO is looking at them.

But security aside, there is also the 'grep' command if you know for what you are looking, or even sed, awk, perl, etc. You can also redirect the logfiles to a logserver and use other tools to capture key elements.

Another tool I like to use is logcheck, properly configured, it will capture for you all the important bits and email you the rest. It is a very good tool for fighting the adnausium entries in logfiles.

Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education. As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

[mike_laspina]

Yes you are correct Edward, messing with log security has risks if implemented incorrectly.

In this case he is only extending the access to an already authorized user under the appropriate controls of the system.

It is very specific and only granting what is needed for the management of the system.

Therefore the risk is mitigated and not an issue.

Other tools are available and will also require access to the logs as well and has the same risk.

[Texiwill]

Hello,

I tend to err on the side of being more secure, however, how secure you are depends on the Security Policy, and as mike.laspina states, properly configured it is not a huge issue.

Given this, I still think SUDO is preferable to changing group permissions as you can lock down to what log files the user can read, as well as get an audit of when this happened. For a non-user approach, I implement logcheck, this way I get an email that shows me the major issues every hour. With logcheck parsing the logfiles and looking for issues, I can go for days or weeks without an email telling me something went wrong. However, logcheck does require a bit , well quite a lot, of tweaking to ignore the ignorable parts of the logfiles. I have mine look at /var/log/vmkernel, /var/log/vmware/hostd.log in addition to the standard logfiles it already parses. These options cover the possibility of an account being compromised...

Which approach you take, changing permissions, SUDO, or logcheck depends entirely on your Level of Trust and How Much Security/Auditing is necessary, required, or desired. Unfortunately, with Linux there is 1001 correct ways to dress the penguin with regards to security.

Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education. As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

[mike_laspina]

I was looking at the security detail on my system. I would suggest you change the 600 I suggested earlier to 650 which will grant readonly to the root group instead of readwrite.

I would also suggest your create a separate account for this role and use it exclusively for this function, e.g a user named logmanager with the root group assignment.

The sshuser is still ok but if you later need to separate the role you may grant to much access using the original configuration.