When I a few minutes ago checked mail, I watched the progress bar, and was chocked. If the number was correct, some people on a mailing list would have sent some trillions of email messages in just 30 minutes or so. Impressive. I did not know my mail server could handle that.
I am running some MacOSX Servers, and got a question from a friend whether I could terminate VPN connections that he was interested in. He runs Windows XP, and according to what one can find on the web, this should be no problems at all. Now I know that was really last famous words, but at least it works now. Let me tell you about the not so well documented issues. First of all, do activate the VPN service in Server Admin. As you can find with Google, Windows XP uses PPTP, so that is where the interesting stuff happens. Enable PPTP, and allow 40-bit encryption keys in addition to 128-bit, use MS-CHAPv2 as the PPP Authentication mechanism. First not very well documented issue is that the start and end IP addresses must indicate an interval of IP addresses the VPN terminating server see locally (that it can proxy arp for). I.e. IP addresses on the same subnet as the external interface on a host (like mine) that only have one IP address. Btw, I have always taken for granted this only works with IPv4. My host have IPv6 as well, but all of this is only IPv4. So, check for an interval of IP addresses on the same subnet as your VPN server itself, and indicate that interval in the PPTP settings. Getting the VPN termination box to also do NAT via the NAT service is something I have not succeeded with. I was hoping the VPN would end up as a virtual interface in the NAT settings, but no, that is not happening. Second thing that is not very well documented is that what happens part from starting the VPN service is that first time you launch VPN (or maybe when you activate the service), two (2) more things are happening:
An entry is added to your OD server
An entry is added to the System Keychain
I found I had to remove these, and add both with the terminal, i.e. manually. As many things (unfortunately) in the MacOSX Server automatic GUI settings, they take for granted the scenario one have is pretty simplistic. Because of this, before you start the VPN service (or after you stop it, as you of course have already started it when reading this), remove all users in OD that have the name of VPN MPPE Key Access User. Sometimes you might have managed to get more than one of these, so although you are doing “Delete” in Workgroup Manager, it might look like if nothing happens. Just do this until there is nothing visible there. You should also remove all keys in the System Keychain (that you can access via Keychain Access) that have the name ending with com.apple.ras. Just remove them. As far as I understand, they are used for exactly this and nothing else. When both OD entry and keys are removed, we have to create them again, and that is done with the command vpnaddkeyagentuser. The interesting thing here (that is not very well documented) is how to run the command. The manual page say you should do:
And the example given is:
To add the keyagent user to the Open LDAP master on the local machine: vpnaddkeyagentuser /LDAPv3/127.0.0.1
The key here is that if the LDAP master is not on the local machine, then you MUST include the hostname of the LDAP server in the path. Using IP address does NOT work. So if your LDAP server is ldap.example.com, your command is:
sudo /usr/sbin/vpnaddkeyagentuser /LDAPv3/ldap.example.com
You will then be prompted for the password that enable sudo, and then username and password for a user that has access to add users to the LDAP database. What is normally called the diradmin in other documentations. You can check with Keychain Access and Workgroup Manager afterwards that the key and the user was added. If you do not get explicitly a prompt for the username and password for a directory admin user, something went wrong. Start over, and ensure you give the command correctly. There is no error messages at all. That should do the trick, as long as you manage to configure XP correctly, something I leave as an exercise for the reader. […]
So I have this external USB/FW drive that I use for TimeMachine on my mac. I have (unfortunately) some other data on that as well. Day before yesterday it just stopped working, making the Finder unresponsible. I had to leave my hotel room in Hyderabad, so I yanked the cable. Bad thing, but what should I have done? I think the damage was done already. End result is that the drive is not visible. I see with USB Probe (part of Developer package) something on the USB bus that is suspended. Also, the drive does not turn off and stop spinning when the computer is turned to sleep. Indication that it might hopefully be a state problem in some machinery somewhere. Anyway, I then thought I could try FireWire access instead, if it is the USB driver on the disk that is confused. So I borrowed a FireWire cable of my friend Kurtis. Cool, if it was the case I had something to connect the cable to in the other end. Lesson learned: If you want to connect something via a cool interface, ensure you have not only the cable, but also something to connect the cable to in the other end. […]
The Foreign Minister of Sweden, Carl Bildt, writes in his blog that he has encountered A New World. One might think in these days of financial crisis and instable situations in many countries, that some new idea sprung up. But no, he in the post say he changed from using Windows to use a Mac.
Att säga att jag inte ångrar det steget är månadens stora understatement. Min enda kritik av mig själv är varför jag väntade så länge att ta steget.
Den nya världen är alldeles definitivt bättre än den gamla.
A new world indeed. […]
I had no idea that the latest update of the iPhone actually fixed the problem of exif data in pictures sent via email. Earlier tests I did (as you can see on my photos) did not have for example GPS information, but after the update, they do. This imply you can now on my moblog also keep track of where I am, and not only see pictures. I like this! […]
A security update to MacOSX is now released. Among other things it updates the DNS software Bind according to this notice you can see below. An update that is really important to install given that we just started to see effective attacks using this attack vector:
BIND CVE-ID: CVE-2008-1447 Available for: Mac OS X v10.4.11, Mac OS X Server v10.4.11, Mac OS X v10.5.4, Mac OS X Server v10.5.4 Impact: BIND is susceptible to DNS cache poisoning and may return forged information Description: The Berkeley Internet Name Domain (BIND) server is distributed with Mac OS X, and is not enabled by default. When enabled, the BIND server provides translation between host names and IP addresses. A weakness in the DNS protocol may allow remote attackers to perform DNS cache poisoning attacks. As a result, systems that rely on the BIND server for DNS may receive forged information. This update addresses the issue by implementing source port randomization to improve resilience against cache poisoning attacks. For Mac OS X v10.4.11 systems, BIND is updated to version 9.3.5-P1. For Mac OS X v10.5.4 systems, BIND is updated to version 9.4.2-P1. Credit to Dan Kaminsky of IOActive for reporting this issue.
There where some people in line in Malmö waiting for the release of the 3G iPhone at 00:00:01 local time. About 220 people in line, and they where open until 03:00. IDG wrote that people that wanted a phone should show up early. They where correct, but not for the reason they thought. Phones existed, but the service was slow. Not because of the people, but the computers and the many papers that had to be filled out. Telia staff made an excellent work. On top of that free coffee, hot dogs etc. But, I was number 52 in line (waiting from 19:40), and got my phone at 01:20 (i.e. one hour and twenty minutes after opening). The store was allowed to be open until 03:00 which implies maybe 120 could get a phone. Phew, I feel sorry for the one that is the first behind the cut at 03:00. And feel sorry for the Telia staff that had such a good event, they had phones, but could not serve. You can see a movie of the line below, and pictures here. […]
I have got ghost records in my addressbook. Records that have only an email address in them. The problem is that there are now and then thousands of those records. I have also, like many others, got problems with the updated format of images in the records in MacOSX 10.5.x. Many findings on the net suggest doing complete reset of the sync database on all computers (iPhone etc), but I do not want that. Why should I? Then rumors said the sync problem would go away in 10.5.3, but it did not. Or rather, the image syncing is better (but not resolved), but I get these bogus records. To remove all of those records, I could either select those (one can find them in the Address Book by searching), do select-all, and then delete. The problem is that the “select-all” operation was never succeeding with the 16k bogus records. I had to kill Addressbook application after 4-5 hours with 100% CPU load. I could mark about 50 records at a time, and do manual delete, confirm etc, but each one of those took 20-30 seconds. Not a good solution either. So I wrote an AppleScript. When running it, I could delete about 200 records every 25 minutes. Good enough. After running this, the 16k bogus records where gone. But, of course about 2k of them came back when syncing (again) with my iPhone that seems to have got some of them from my Mac. I am happy I wrote this script, as I now could run it again. Much faster when only having 2k bogus records. But still slow.
tell application "Address Book" set r to 0 set nr to 0 set pp to every person repeat with p in pp set ee to every email of p repeat with e in ee if (value of e) = "email@example.com" then set r to 1 end if end repeat if r = 1 then delete p set nr to nr + 1 if nr = 200 then save addressbook set nr to 0 end if end if set r to 0 end repeat save addressbook end tell
AppleScript that remove records with certain email address […]
It is not Tuesday, but a new version of MacOSX is out. Early reports from friends say the upgrade (although 420MByte on my MacBook Air) went flawlessly, so I am upgrading now. I saw early lists of the changes as a Developer, and the list was massive. The 420MB of course show that. Hope some bugs in Mail.App parsing of local messages are fixed. I also hope Spaces is better. And I hope some irritating bugs in MacOSX Server regarding how serveradmin is editing the configuration files for bind and apache is fixed. As it is now, it is hard to edit files manually as serveradmin is messing around with the files as well — in a way that is not according to the documentation (in the config files). I also hope they have in the user interface in the iCal client the ability to change permissions in the CalDav server on the server. As it is now (as I understand it), there are manny features there that one in reality can not use… Bummer. […]
At a meeting in Gothenburg today, four out of five people had MacBook Air. One had a PC. The PC did though have an IETF sticker on, so he is ok. ;-) Four out of five have MacBook Air […]