Deleting hundereds of thousand of files in Linux.

So, it turns out that in Linux the rm command can't handle deleting huge numbers of files.  In my case, I wanted to delete 400,000 files from a directory because said directory had used up all the available inodes on that drive.

Trying to do an rm -rf * would produce an "argument list too long" error.  So I searched around and found that you can do this from within the offending directory:

find . -name '*' | xargs rm

Which essentially finds and deletes each file individually, running rm over and over again.  It didn't even take THAT long to run (5-10 minutes or so).

Remember to change to the offending directory first though, this can be pretty destructive if run on the wrong directory.

DHCP Broadcast Flag Problem with DHCP Helpers

Explanation

DHCP helpers are used to allow a machine in subnet A to get a DHCP lease from a DHCP server in subnet B. Because DHCP requests are sent as a broadcast, and broadcasts aren't allowed out of their original subnet they require the DHCP helper to pass on their DHCP request to a different subnet. The reply to this broadcast comes from the DHCP server, back to the client in either one of two ways - unicast, or broadcast - which of the two is used is determined by the client in it's DHCP request.

By default Windows 7 requests the reply to be sent as a unicast response, however during startup Windows Firewall rejects unicast packets from outside it's own subnet, this results in the response being dropped. DHCP may timeout, and/or re-send the request, this time asking for a response to be sent as a broadcast packet, which will result in DHCP assignment succeeding, albeit too slowly. This can manifest itself by producing NETLOGON 5719 errors during startup in the system log and/or assorted group policy errors during startup.


Workaround

Microsoft have identified the problem, but at the time of writing no hotfix is available, nor does one appear to be included in SP1 for Windows 7. A number of workarounds have been suggested, but in testing only one works consistently. This involves telling Windows 7 to request a response from the DHCP server be sent as a broadcast

This is achieved by setting two registry entries, as follows:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID}\DhcpConnForceBroadcastFlag

Should be set to 1 (0 for unicast, 1 for broadcast).

and

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID}\DhcpConnEnableBcastFlagToggle

Create a 32bit DWORD value, and set it to 0, this prevents Windows from changing the DhcpConnForceBroadcastFlag back to 0 (the default).

Both registry values may need to be set/created for every adapter on the machine if multiple adapters are in use (wired, and wireless for example), DhcpConnForceBroadcastFlag can be set globally, however given you cannot do this for DhcpConnEnableBcastFlagToggle there is little point in doing this.

Locating the Network Adapter GUID

In the above registry entry, "{GUID}" is the "Globally Unique Identifier" for a given network interface. Each wired and wireless NIC will have one of these assigned to it, as will virtual adapters. To locate the GUID for a given adapter navigate to the following registry entry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\NetworkCards\(adapter #)

The adapters are named by the Description value in the adapter # registry key.


Additional References

• MS Technet Blog on the issue
• My post in Technet Forums on the resulting Group Policy Problems.
• How to find NIC GUID

Getmac and collecting MAC addresses

As in, getmac, the command, not Get Mac, something you should do if you a) Need a computer, and b) Have too much money to spend on one.

Anyway, I recently found a new command line command in Windows, called getmac, which rather unsurprisingly, returns the machine's MAC address for all available adaptors. The usage for getmac is as follows:

GETMAC [/S system [/U username [/P [password]]]] [/FO format] [/NH] [/V]

Description:
This tool enables an administrator to display the MAC address
for network adapters on a system.

Parameter List:
/S system Specifies the remote system to connect to.

/U [domain\]user Specifies the user context under
which the command should execute.

/P [password] Specifies the password for the given
user context. Prompts for input if omitted.

/FO format Specifies the format in which the output
is to be displayed.
Valid values: "TABLE", "LIST", "CSV".

/NH Specifies that the "Column Header" should
not be displayed in the output.
Valid only for TABLE and CSV formats.

/V Specifies that verbose output is displayed.

/? Displays this help message.

Examples:
GETMAC /?
GETMAC /FO csv
GETMAC /S system /NH /V
GETMAC /S system /U user
GETMAC /S system /U domain\user /P password /FO list /V
GETMAC /S system /U domain\user /P password /FO table /NH


Getmac is supposedly able to get the MAC from a remote computer as well as the local computer, although I haven't used that functionality. I've used it in a batchfile deployed and executed on a bunch of machines using Symantec Ghost to gather MAC addresses from new machines on our network. This is helpful because we need the MAC's for our wireless MAC filtering. For reference, the batchfile is as follows:

@echo off
net use X: \\server.domain.com\MACs /USER:DOMAIN\username password
REM Get Mac and Computer Name and store in CSV
getmac /v /fo csv | find "Wireless" >%TEMP%\mactemp.txt
set /p macoutput=<%TEMP%\mactemp.txt
del /Q %TEMP%\mactemp.txt
echo %macoutput%,%computername% >>X:\MAClist.csv
net use X: /DELETE
pause

As you can see, getmac is capable of grabbing the MAC and other details in CSV format, this tiny batch takes that info and adds the computers NETBIOS name in as an identifier, resulting in a CSV file written to a network share that contains each machines MAC and computer name, one per line. You can substitute the find "Wireless" for find "Local" if you need the wired MAC of a machine. You can also remove the pause at the end, I just used that in testing so I could see any error output before the DOS windows disappeared.

Until next time!

Windows KMS Setup Keys

Well, Microsoft's KMS is so simple that most think you don't need much documentation to get it going. The only problem with that theory is that with the absence of documentation (or the presence of documentation that assumes you've already been running Vista (yeah, right!) and have KMS already), you can make some incorrect assumptions.

We did that with our KMS rollout, and got ourselves into the position where our images had been setup using the wrong key, the KMS key, which made them all think they're KMS hosts, rather than clients. You can see what mode they're in using the slmgr.vbs /dlv command.

You can easily revert them to being a client by issuing the slmgr.vbs /ipk {setup key} (you may have to issue a slmgr.vbs /rearm first though). The only problem here is finding the setup key. If you have original media it might be included with that, but if you downloaded from the Volume Licensing Centre, it's not provided (or it wasn't in our case).

So, you can get these setup keys here:

http://technet.microsoft.com/en-us/library/ff793421.aspx

Once we got our machines back to being clients again, they found the KMS server no problems, and off we went, activating like clockwork! Running the slmgr /dlv command again showed the partial product key matched the setup key, and eventually the "License Status" section changed to "Licensed".

:)

Stopping spammers using old MX records with Postfix.

So, we had this problem with our new cloud-based anti-spam service. Well, not with the service as much as with the spammers (and who doesn't, right?).

With cloud based spam-scanning you make the anti-spam service MX for your domain, and they do the scanning and forward mail on to your server(s). Sounds simple enough, but spammers don't play by the rules, and they're quite happy to ignore your MX record (particularly if it changes to one of a large well-known anti-spam service) or use old cached ones if it suits them.
So, when we changed our MX a lot of spam just kept coming to our server - the old MX for the domain, even days after the change (even as I write this, spammers are still trying to send mail to that host).

We had a machine (the old MX) that was sitting in our DMZ handling email for the whole oganisation, which consisted of three separate mail domains (Domain A, Domain B and Domain C), only Domain A was using cloud-based scanning. This machine ran Postfix, and we needed Posfix to have a rule something along the lines of "If mail is delivered to Domain A from any host other than our Anti-Spam service, or hosts on our network, reject it".

That sounded complicated, but it really wasn't, with the help of the postfix-user mailing list we got it done easily. See the examples below:

We added the following two lines in red to the Postfix main.cf file:

smtpd_recipient_restrictions =
permit_mynetworks,
reject_unauth_destination,
check_client_access hash:/etc/postfix/cloudspamsubnets
check_recipient_access hash:/etc/postfix/restrictourdomain

The file /etc/postfix/cloudspamsubnets contained a list of subnets our spam scanning service uses to forward mail to us, in the format:

100.1.2 OK
100.3.4 OK
100.5.6 OK

You'll notice the subnet notation is a little odd. Apparently, 100.1.2.0/24 or 100.1.2.0/255.255.255.0 don't work.
Next, the file /etc/postfix/restrictourdomain was a simple list of our domain and any subdomains:

subdomain.domaina.com OK
anothersubdomain.domaina.com OK
domaina.com REJECT

Postfix will reject any subdomains of Domain A if it's responsible for those as well, so you need to list them with an OK to have them let through.

And apart from running postmap /etc/postfix/restrictourdomain and postmap /etc/postfix/cloudspamsubnets and restarting Postfix, that pretty much did the trick!

Seeya!

P.S. Thanks to Sahil Tandon for suggesting this bit of config.

Server Service Hanging on Windows 2008 Server

Here's one for you.

See the following atricle:

http://support.microsoft.com/kb/319127

It talks about Windows NT through to 2003 not starting the Server Service due to a port monitor from either Lexmark or HP.

However, what they neglect to mention is the problem still exists on 2008 Server, and the behaviour may be slightly different.

The article points to a problem where the Server service evetually fails with an event log message alerting you to this. I had the problem, however the Server Service hung indefinitely, and never ended up logging an error. I just logged into the server (as local admin, domain admins can't login if the Server service is still starting), and in the services mmc I notice the Server service is still listed as "Starting". This is under Server 2008 32bit edition. Not NT-2003 as the KB article would suggest.

The good news is, the fix in the KB article works fine. It turns out that one of the port monitors causes the Print Spooler to start too soon, and editing the Registry to make th Print Spooler dependant on the Server Service fixed things a treat.

I just thought I'd make a note of the whole thing here, in case someone is experiencing the same behaviour I had.

Filemaker printer thingy.

Thanks to Red400r for the contribution about Filemaker and default printers (see below). Here's an addition to that. If you don't want to rummage through the registry for every user who complains about this, here's a vbscript to delete the registry key (beware the text wrapping):

Const HKEY_CURRENT_USER = &H80000001

strComputer = "."

Set objRegistry=GetObject("winmgmts:\\" & _
strComputer & "\root\default:StdRegProv")

strKeyPath = "Software\FileMaker\FileMaker Pro\9.0\Preferences"
strValueName = "Printer"

objRegistry.DeleteValue HKEY_CURRENT_USER, strKeyPath, strValueName

That works for Filemaker Pro v9, just customise strKeyPath = "Software\FileMaker\FileMaker Pro\9.0\Preferences" for your version!

L8r.