Apple wired USB keyboard with numeric pad - working drivers for Windows 7 on an ordinary PC

Overview of the Apple Ultra-thin USB Keyboard Problem

I have a full-width Apple keyboard of the newer flat aluminium type (Ultra–thin USB) that I use with an ordinary PC and a Mac via a KVM. It works with Windows without any special drivers - to some extent - but unless you do something you won't have any ability to type Print Screen, Scroll Lock, Pause/Break or Insert keys.

When I looked on the internet to see whether there was a proper PC driver file for it, I found a lot of outdated, confusing, contradictory and muddled information. Some references are to very old versions of OSX or Boot Camp Tools, others to older versions of Windows or the keyboard itself.

I decided to write down what I had to do to make this keyboard work 'as intended' with Windows 7 from an up to date copy of Boot Camp Tools for OSX 10.6 Snow Leopard or 10.7 Lion.

I don't know if these instructions will help you with a wireless keyboard as I don't have one to try, but at least the information about Boot Camp Tools is up to date.

This is the device I'm talking about on Amazon.

Your options are:

• Don't install new drivers, but use something like KeyTweak to remap scan codes manually for any keys you feel you are missing or hard to type. Insert and Print Screen are probably the most obvious annoyances, and you'll probably want Pause/Break too.
• Install the Apple drivers that are included in Boot Camp Tools. If you do this, you can still use KeyTweak to modify things more to your taste.
• Run a registry script that merges in scan code mappings for the missing keys - just doing what KeyTweak does but without the choice of what is what - I'm not going to say any more about this.
• Do nothing - this is tolerable - as long as you don't ever need to use Insert, Print Screen, Scroll Lock, and Pause/Break - but chances are you do.

The Apple keyboard maps a few keys strangely: there is no Insert key, and Print Screen, Scroll Lock, and Pause/Break are not labelled. Also, Num Lock is labelled 'Clear'. Apple have their own pages on this topic, but surprisingly, they are partially incorrect.

Apple's own descriptions of how to type Print Screen, Scroll Lock, and Pause/Break are wrong - in fact these keys are activated in the following way:

• Print Screen : F14
• Scroll Lock : F15
• Pause Break : F16
• Insert : Fn + numeric Enter (Apple describe this correctly)

I suspect they have confused the key presses required for these with the presses you must make on the compact wireless keyboard, which has no F13 .. F19 keys.

Why they didn't assign these to F13, F14 and F15 so they align to the three function-key grouping above Fn, Home and PageUp, as would normally occur on a PC keyboard is beyond me as F13 isn't assigned to anything special.

How to install Apple's own Windows drivers for the wired Apple keyboard

You need a copy of Apple's Boot Camp Tools to do this.

You can download the latest Boot Camp Tools via the Boot Camp Assistant in OSX: run Boot Camp Assistant and select the option to download the latest support tools. Once the download is complete it will help you write them to a CD, DVD or external drive.

Apple don't publish a link to download Boot Camp Tools or the keyboard driver directly on their support site I find this irksome, but Apple don't seem to want PC users who didn't buy a Mac using their keyboard drivers; it's the only conclusion I can draw from Apple's decision to make the drivers only downloadable via an OSX utility; they could easily have submitted the keyboard drivers to Microsoft so that they were distributed with Windows 7, or put them on their own site, or on a CD, or made them freely distributable but they do none of these things.

There are various Boot Camp Tools related downloads on their site, but none appear to be the actual disc image. (If you can find a link, please let me know). If you don't have an OSX install disc you may be able to locate a copy of the driver install file by other means - see below.

I made a CD of my Boot Camp Tools. I suggest you do likewise, as it's convenient when doing a Windows install, or when you want to put the keyboard drivers on a new PC. The Boot Camp assistant will ask if you want to burn a discs after you have downloaded them. With the Boot Camp Tools disc in your PC, navigate to the correct directory:

If you have OSX 10.6 and a 3.X version of Boot Camp Tools

• If you have a 32-bit Windows install go into: [your DVD drive]:\Boot Camp\Drivers\Apple and run AppleKeyboardInstaller.exe
• If you have a 64-bit Windows install go into: [your DVD drive]:\Boot Camp\Drivers\Apple\x64 and run AppleKeyboardInstaller64.exe

If you have OSX 10.7 and a 4.X version of Boot Camp Tools

• If you have a 32-bit Windows install go into: [your DVD drive]:\Drivers\Apple and run AppleKeyboardInstaller.exe
• If you have a 64-bit Windows install go into: [your DVD drive]:\Drivers\Apple\x64 and run AppleKeyboardInstaller64.exe

Some guides will tell you that you need to run the main Boot Camp Tools setup (setup.exe) or the main driver installer (BootCamp.msi or BootCamp64.msi) - do not do this! The advice is wrong and in any event it's no longer possible. Apple have added a check to the main tools setup and main driver .msi to ensure that you're running on genuine Mac hardware, and if you aren't, you can't install. It used to be possible to run, but it is no longer an option. Even when it was possible it was a bad idea, as it could result in long delays on start-up. The keyboard driver installer doesn't contain such a check, so installing it standalone is still possible but I wouldn't be surprised if a future version of the driver will only work on Apple hardare - it would be obstructive in the extreme, but in line with other things Apple have done so far.

Making the top row of keys default to acting as function keys

The downside to running the keyboard driver install without the rest of the Boot Camp Tools is that you need to edit the registry manually to change how function keys are handled. By default the driver sets the top row of keys to perform multimedia functions (most of which don't work anyway, despite their being legitimate windows key messagers for them, they produce special Apple codes instead); and so you have to press the Fn key to make the top row keys produce functions key codes. What most people want/need is for the keys to produce function key codes by default and the broken multimedia functions when you press Fn - as Windows and most PC applications tend to use the function keys for a lot of useful short-cuts. There is an option in the Boot Camp Tools applet to change this behaviour, but it's also possible to change it without the applet.

The way that the driver handles the top row of keys is controlled by a single registry entry, so it's not hard to change it so that you don't need to press Fn to have them act as function keys by default:

Once you have installed the keyboard driver, run regedit using Start Menu >> Run and then navigate to:
HKEYLOCALMACHINE\SYSTEM\ControlSet001\Services\KeyMagic\OSXFnBehavior

There will be a 'Binary' entry with the value 01
You need to set this to zero. Some people say you should change this to a DWORD entry, but that's not true. However, to cover all contingencies, I edited the value to 00 00 00 00 - which is four bytes of zero, equivalent to a DWORD 0. This is easier than changing the type of the value and has the exact same effect. As far as the registry access API is concerned, four bytes of 00 and a DWORD value of 0 are the same.

Whatever the driver is doing to read the entry, I found that setting OSXFnBehavior to 00 00 00 00 did the trick, and afterwards my function keys worked as function keys without having to press Fn. You may need plug and unplug the keyboard to make this work after editing - the driver doesn't seem to check this value continuously.

With this configuration, you still need to press Fn + Enter on the numeric pad to type an Insert. You can always use KeyTweak to map something else (such as F13) to Insert but you can't remap the Fn key as it does not produce a key code. As an aside, the location of the Fn key where Insert is normally found on a PC keyboard was a terrible one, it makes it very hard to use on a Mac or PC and it's probably the worst thing about this keyboard - especially when moving back and forth from a MacBook keyboard that puts Fn on the far left.

I found that the track-forward, play/pause and track-back multimedia keys work as expected in iTunes, but the mute/unmute and volume keys do not. Unsurprisingly, the other special functions don't do anything either. If you inspect the scan codes generated for these keys (which, apart from Eject you access via the Fn key once you have the registry change in effect), you'll see there aren't any, so they can't even be remapped in KeyTweak. The Exposé and Dashboard functions produce the standard F3 and F4 scan codes even if you press Fn so they don't do anything special either.

If you don't have a copy of Boot Camp Tools

Without any driver installed, the keyboard allows you to use the function keys normally, and 'Clear' still works as Num Lock, which is fine but there is no way to type Insert, Print Screen, Scroll Lock or Pause/Break.

If you don't have access to Boot Camp Tools, really the best thing to do is to use KeyTweak. It doesn't install any services or anything that has to run at startup. In fact the only time it consumes resources is when you are running it explicitly to edit your settings. This is because it relies on functionality already built into Windows. It's merely a nice way of creating/editing a registry entry that already exists in Windows to support remapping of scan codes for non-standard keyboards.

The only downside of this is that it doesn't play well if you swap keyboards around because you may not want those alternate mappings applied to your other keyboards. If you don't use the Apple keyboard all the time, you may want to make registry scripts to turn the scan code remappings on and off.

An alternative is to somehow obtain a copy of the Apple driver. Apple go out of their way not to distribute it; they also explicitly prohibit redistribution in their license terms for Boot Camp Tools! So, I'm not going to upload a copy here.

However, a search for AppleKeyboardInstaller.exe soon turns up lots of people who don't seem to care about their license terms :) and have uploaded the file.
Of course, some of these may have been tampered with to contain malware, or may simply be very old versions that don't support Windows 7, or may do something else strange, so I've put the MD5 hashes for the most recent versions below so you can at least check anything your download.

Apple Keyboard Installer MD5 Hashes

Driver file name	Boot Camp Tools Version	OS Version	MD5 Hash
AppleKeyboardInstaller.exe	3.2.2856	OSX 10.6	E5AE11C2AA0D9BCAF4A99EC55D0BD415
AppleKeyboardInstaller64.exe	3.2.2856	OSX 10.6	B4CDD38C5FC180A12C88371311039E8D
AppleKeyboardInstaller.exe	4.0.0.1	OSX 10.7	F0015AA3A67655A31417985B849E93D2
AppleKeyboardInstaller64.exe	4.0.0.1	OSX 10.7	5E41048519F031814E3FEF0B4948E80B

CentOS and RHEL Access and Permission Problems

Trying to configure mail systems and you're hitting mysterious 'access denied' or 'permission denied' issues, even though permissions allow access? This often happens when trying to get postfix and dovecot to talk to each other.

The problem is most likely SELinux. Most people cop out by disabling SELinux; and if you disable it, it might solve your problem. In some cases, SELinux appears to interfere with access even when disabled - do a full rebuild of the permissions if you seem to have this problem. Check out this guide to CentOS security for information on how to enable and disable SELinux, and how to fix your security without disabling it.

Here is a full guide on SELinux in CentOS.

This wiki on SELinux booleans may also be helpful for the serious SELinux user (e.g. people who don't simply want to turn it off) .

Use sestatus to check your SELinux status.

The setenforce command allows you to change between Enforcing and Permissive modes on the fly but such changes do not persist through reboot.

To make changes persistent through a system reboot, edit the SELINUX= line in /etc/selinux/config to either 'enforcing', 'permissive', or 'disabled'.
e.g. SELINUX=permissive.

To relabel the entire filesystem (this seems to fix some problems where you have changed SELinux status):

# touch /.autorelabel
# reboot 

Users of Ubuntu may experience similar problems due to AppArmor. Problems are usually resolved by setting the AppArmor properties correctly.

Network Services don't work

You've installed a package, configured it, started it up and it seems to be running fine, but nothing is happening.

Did you forget to add iptables rules for the ports used by your new service? Don't forget that bind9 uses UDP as well as TCP.

Edit /etc/sysconfig/iptables and add rules to open up the necessary ports. You can also use iptables -e commands, but this stops you putting useful comments in your iptables file because iptables gets auto-generated. OTOH, don't hand edit iptables unless you are confident you aren't going to save a broken one and lock yourself out of the system. Never run system-config-securitylevel unless you want to trash your hand-edited iptables file.

Don't forget to 'service iptables restart' after making updates to the file.

Use 'netstat' to debug ports and service issues. For example, netstat -l -t -u -p -e will give a nice display of listening tcp and udp ports. Add --numeric-ports to see port numbers instead of names. The man page for netstat is fairly comprehensible, unlike some.

What FTP daemon to use with CentOS or RHEL 5.X

What ftp daemon to use on CentOS or RHEL? I recommend vsftpd - you can install it through yum and it's very secure.

The set-up info on the vsftpd site could be better though. In particular, there is no explanation of how vsftpd uses pam to authenticate.

Look in /etc/pam.d/vsftpd and /etc/pam/ftp or whatever you've set in the pam_service_name option e.g. ftp=/etc/pam/ftp to see how pam is set up for this service.

After editing passwords for vsftpd use something like db_load -T -t hash -f accounts.tmp accounts.db

Where you have your users and passwords in accounts.tmp, with usernames and passwords on alternate lines. You might find some contradictory instructions about on the net, but they won't work for CentOS 5.X

Basic configuration of bind9 (named) on CentOS / RHEL 5

The basics:

sudo yum bind9
sudo chkconfig named on

OK, now you've installed bind but want to know where the examples are, or how to set up the configuration files. The bind configuration samples are in:

/usr/share/doc/bind-9.x.x/sample/etc/ and /usr/share/doc/bind-9.x.x/sample/var/

Copy the default configuration files above to /etc/ and /var/named/ respectively. If you are serving several local domains. In addition, I suggest you create a named.conf.local file or something similar that contains all the zones for your system, and include it into your main configuration file.

Comment out the example zone definitions in the internal view.

If you intend to be authoritative nameserver for a zone, add it to your external view using the format show in the example zones in the internal view. You will need to create a zone description file in /var/named, which is beyond the scope of this simple explanation.

The bind executable is in /usr/sbin/named ... to test your configuration before running properly as a service, run with -g to run in the foreground and dump to stdout, -d controls debug level

You should probably also add -u named to run as the 'named' user, because otherwise you will run as the current user, which is almost certainly going to cause problems, even if you are root :)

e.g. sudo named -g -u named

You can use dns-keygen to generate DNS TSIG keys (no, it doesn't need any complex parameters, it just spits out a key to the stdout, or wherever you pipe it).

You will need to edit /etc/named.conf to replace the note about this with a real key if you have a master/slave config. Otherwise comment out that whole key section because you don't need it.

This key (if you use it) is a 'secret', you need to get it to the other machines securely (you copy that key manually into a file on the other machine). It is not a certificate. Normally the key should be kept in a file with no read permission for group or others and included into the main config file, which (allegedly) needs to be globally readable (though I suspect this is not entirely true).

To check a bind config file for errors:

named-checkconf /etc/named.conf

named-checkzone domainname.tld /var/named/db.domainname.tld.zone

Assuming that you have called your zone file db.*.zone

When you've finished configuring, sudo service named start (or restart if you already started it).

Finally, you need to open up the ports for bind9. Traditionally, bind has used port 53, and doing anything else is more likely to cause trouble, despite the 'security benefits'. Ultimately, if you are running bind as anything other than a caching nameserver, then you want people to be able to find you.

You should probably open up both UDP and TCP on port 53. While some will say that UDP is enough, there are some servers that only use TCP, so again, you're asking for trouble if you try to avoid opening it for TCP as well. I can't see any realistic benefit of not opening it for both anyway. If bind has a vulnerability, it's probably not going to be restricted to TCP connections, and returning to the point of this, a bind that other people can't see doesn't need any open ports, and one that other people do need to see should be as conformant and interoperable as possible with other nameservers; if people can't find your servers, your service is useless.

Your iptables is going to need something like the following in it...

-A INPUT -p udp -m udp --dport 53 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -m state --state NEW -j ACCEPT

How you add these is up to you. I maintain my iptables file manually, but many people prefer to use the iptables administration tool.

Configure bind9 as master/slave pair on CentOS / RHEL 5

There are plenty of HOWTO documents on this and I've discovered that nearly all of them are full of unnecessary fluff that can be both confusing and misleading. It's probably because they are reworks of older HOWTOs from the bind8 era. Configuring bind9 in master/slave is far easier and requires far fewer configuration changes than the existing HOWTOs suggest.

You need to edit the named.conf files on both systems. I'm assuming that you begin with a functioning but otherwise default configuration on both machines.

• On the master machine, create a dns key and put it in a secure file that you can include.

  sudo dns-keygen > /etc/named-tsig-key.conf

  Then edit the output file: /etc/named-tsig-key.conf so it looks something like this:

  key ddns_key
  {
    algorithm hmac-md5;
    secret "lw8MPJFqapeAG3ehTuvDBPUhRWzX1hyz5Ov3UvIXhmGh4XkPKIcPNCsz5f8v";
  };
  

  Where the hex string is the one you just generated (not the one I've used as an example), which you should find in the file, because we just put it there.

  Fix up the permissions on the key file:

  sudo chmod og-rw /etc/named-tsig-key.conf
  sudo chown named:named /etc/named-tsig-key.conf
  

• Include the dns key file in your named.conf on both machines:

  In your named.conf, after the logging section in named.conf add:

  include "/etc/named-tsig-key.conf";

  You can call this key file whatever you like, and put it wherever you choose (think is most secure), but I've put mine in /etc/ and named it in a way that makes sense to me.

• Copy the key file you generated on the master to the slave machine. You will need to put it in the same place and ensure that the permissions and ownership are the same as used on the master. There are lots of ways you could copy the file, from sftp/scp to simple cut and paste from one putty session to another.
• Add server descriptions to both machines following the include directive:
  

  server 123.456.789.123 {
      keys {  ddns_key;
      };
  };
  

  The address here is the address of the other machine. If you are on the master, list the address of the slave. If you are on the slave, list the address of the master.

  You need to use an IP here, don't use the server's name.

  This directive tells bind that it should use the key we generated for communication with that server.

• Add the zones to the slave configuration:

  I'm going to assume you already know how to add zones to the master, and that they are already configured - there is no additional change required to the master. The master does not need any special configuration to serve zones to the slave. Setting up an ordinary master zone is nothing specific to the master-slave set-up, so no point going into it here, you can find info on it almost anywhere.

  There is already an example internal slave zone in the default config file in the internal view:

  //zone "my.slave.internal.zone" {
  //      type slave;
  //      file "slaves/my.slave.internal.zone.db";
  //      masters { // put master nameserver IPs here
  //      127.0.0.1;
  //    } ;
  // put slave zones in the slaves/ directory so named can update them
  

  However, if you are using your slave as a second nameserver of an authoritative pair (and this is probably the reason you want to set up master slave) you need to put your slave zones in the external view not the internal, or else your slave nameserver will not serve them to anyone else. You don't really need the zone in internal view at all on the slave, as internal look-ups on the name through localhost_resolver will do an external DNS lookup (which might end up eventually looking at our external view anyway) and then be cached - one external lookup, hardly a big overhead, and saves the complexity of adding the zone to different views.

  So for a typical zone, add something like this to the external view:

  zone "mydomain.tld" IN {
    type slave;
    file "slaves/db.mydomain.zone";
    masters { 123.456.789.122; }; // The IP of the master server
  };
  

So, that's all you really need to do to get master-slave working. Most of the HOWTO docs I found suggested making all kinds of pervasive changes to named.conf, particularly in the options section. When I looked at what those changes were intended to do, they either replicated default behaviour and were thus utterly pointless, or they were actually wrong and would only cause trouble.

You can do other stuff, like enabling zone transfers to the slave on the master, but there's really no need to do that.

All you need to get a working setup is the key declaration, a server declaration, and addition of the slave zones on the slave server (assuming the zones already exist on the master).

All the other changes that people suggest are simply not necessary to get a working master-slave pair under CentOS / RHEL 5.X using bind9, and are as likely to result in harm rather than any benefit. The defaults of bind9 are pretty much what you want, and I don't recommend changing any of them unless you really know why you are doing it.