UNIX for Dummies Questions & Answers

is it possible to monitor log files that are on a windows server, from a linux/unix host?

i'm thinking that the directory that the files are located in on windows can be be mounted on the linux host, and then a script or tool can just monitor the log as though it were local?

any thing wrong with this thinking? please suggest to me other methods i can try.

That will work perfectly. Windows and Unix use different protocol stacks, so you need some software. In the TCP/IP-world there is NFS, which is used to mount remote (parts of) filesystems locally. The respective protocol in NetBIOS (the protocol stack Windows uses) is called SMB.

Either use a NFS server daemon for Windows to export the part with the log files and then NFS-mount it on the Unix system or install a SMB-client on the Unix system to mount the (SMB-)shared Windows drive. Example products for the former would be FreeNFS, an example for the latter would be SAMBA. I am sure there are other similar products for both options too.

I hope this helps.

bakunin

thank you so much. the one problem i foresee with this is, isn't it a bad idea to be reading files off NFS? considering it can cause network issues? I/O?

i remember a while ago reading a data file off NFS. i wondered why it was taking soo long to read the file. but when i moved the data file over from the nfs drive to the local server, the file was read very quickly.

if i'm going mount the windows log files on NFS or anything similar to it, what can i do to make sure i can read the log files just as fast as i would be able to do locally? are there other problems you experts can anticipate?

i presume reading files off NFS wouldn't/shouldn't be an issue on the right hardware. but then the question becomes, what is the right hardware?

Generally said, this is the problem with any complex thing: the more parts it consists of, the more opportunities are there for something to go wrong. Sledge hammers tend to have less operational errors than computers, so to say. ;-))

Of course, when you set up NFS (or any other file sharing system with a similar functionality) you have to make sure the network between the two systems works reliably. Furthermore, you have to make sure the DNS system is responding reliably and quickly, because name resolution is used heavily inside the NFS parts and the longer a single name resolution takes the (preceptibly) slower the observable speed of the file transfer is.

Of course, neither do i know your network nor your systems, so i cannot tell you what went wrong in your case. But my general experience is that misconfiguration and/or sloppy setup is the culprit much more often than failing hardware. To expand on what i said above: suddenly failing NFS mounts can often be traced back to network cards set to the wrong speed (like "100/Full Duplex" instead of "100/Half Duplex" or vice versa), unreliable DNS services, etc., etc.. You can't evade such problems with more hardware set up equally sloppy, only with a better work ethic.

Many problems stem from a tendence to confuse a problem without apparent symptoms with a problem solved: if a problem in some operation takes place and suddenly this problem is gone, you haven't solved it, you have just stopped to see the symptom. The problem is solved only once you understand fully why you do not experience any symptoms any more - not any sooner.

But i am digressing. Generally NFS is a quite reliable method. You should not use it for the distribution of high-security data, because it is prone to network sniffing and it won't support ACLs without some very complicated extra configuration. If you have such data i suggest using sftp, scp, NFS over a securified VPN or something such. Just to distribute logs it is good enough and the provisioning system on the Unix flavour i work most - AIX's NIM - is even bassed on it. IBM wouldn't have done that if it can't be brought to work reliably.

I hope this helps.

bakunin