Or why at 22:00 on a Friday night I am fucked off.
I have spent all evening trying to get FFMPEG working on a Centos Server VPS, when it turned out it was there all along. (YUM: nothing to do. Fuck you YUM, I told you to do something, just do it!: YUM: nothing to do. YUM should have said; “it’s already here, mate – and up to date – perhaps your application is looking in the wrong place? eh – thought of that? (you fucker))
The solution to the above is add usr/bin to the paths of open_basedir in vhost.conf – security begone… or at least be aware, I suppose.
Anyways, I then get to the nitty gritty of the evening and start looking at some domain issues, some AD issues to be precise on a 2003 domain hosted on a clutch of 2008 R2 servers. Now I love 2008 R2 – I do, mostly. It’s mostly better.
Issues with inter site replication, I get this fantastical informative eventID:
During the past 4.02 hours there have been 1 connections to this Domain Controller from client machines whose IP addresses don’t map to any of the existing sites in the enterprise. Those clients, therefore, have undefined sites and may connect to any Domain Controller including those that are in far distant locations from the clients. A client’s site is determined by the mapping of its subnet to one of the existing sites. To move the above clients to one of the sites, please consider creating subnet object(s) covering the above IP addresses with mapping to one of the existing sites. The names and IP addresses of the clients in question have been logged on this computer in the following log file ‘%SystemRoot%\debug\netlogon.log’ and, potentially, in the log file ‘%SystemRoot%\debug\netlogon.bak’ created if the former log becomes full. The log(s) may contain additional unrelated debugging information. To filter out the needed information, please search for lines which contain text ‘NO_CLIENT_SITE:’. The first word after this string is the client name and the second word is the client IP address. The maximum size of the log(s) is controlled by the following registry DWORD value ‘HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\LogFileMaxSize’; the default is 20000000 bytes. The current maximum size is 20000000 bytes. To set a different maximum size, create the above registry value and set the desired maximum size in bytes.
Pretty much what all EventID should be like. Almost Perfect. Good warning, good explanation. A link to the log file, or, indeed the details OF the log file would be better, but I did say almost.
%SystemRoot%\debug\netlogon.log or bak doesn’t exist.
Unless you have previously enabled debug logging. So what this warning is actually saying is; “As the Event Service I will write hundreds of utterly pointless snipets to your hard drive and when something potentially important is happening, I’ll simply pontificate.”
Remind you of anyone? Anyone in power, perhaps ?
Ever useful MS gave me this advice:
The Net Logon Service maintains an activity log on the server in the directory, %systemroot%\debug\netlogon.log. By default, the log is empty.
No shit.
And then:
However, if one has a need to troubleshoot net logon activity, such as why user accounts keep locking out for no apparent reason, a debug value may be set in the registry of the domain controllers, to begin capturing net logon authentication data. We will use the debug log to track the intruder.
Eh ? Really ? The Intruder has already been and gone! Event ID 5807 mentioned he had been to visit.
OK – So how do I turn it on for future use ?
This DOC is quite good: http://download.microsoft.com/download/a/8/7/a87526d3-b794-4d93-865a-07c9c2b076e4/TrackNetLogDebug.doc
Mr Fix it might help too, who knows. : http://support.microsoft.com/kb/109626
Something happended, MS told me about it such a way to piss me off even more. I have no previous knowledge of this debug info being in any best practice guide – though looking at the logs, it seems better than the lame windows security Event Logs; far easier to parse and maintain in your own… idiom, anyway.
No reason.