techblog 

Background
In many ways, name servers are standardised: the format of queries and responses are defined by standards, as are the ways of transferring zone information into and out of them (zone files, dynamic updates, AXFR, IXFR). This is not the case of the commands and files used to configure and control them, which are specific to each type of server.

Having a common means of interacting with servers would stimulate the development of a common management client, so simplifying operations. Although particularly benefiting users of multiple name servers, good management software should make it easier for occasional users to securely configure and manage their systems.

We have been investigating the idea of a common management interface, as have the IETF, who set up the DCOMA (DNS Configuration Management) committee to consider the problem. We have contributed to the DCOMA discussions, the result of which has been the publication of an Internet Draft containing the requirements for the system.

Implementation
Our approach has to define a protocol (NSCP - Name Server Control Protocol) layered on top of NETCONF, an XML-based protocol for the configuration and control of network devices. In NETCONF, a data model is defined for a network device, with configuration commands being framed in terms of it. NSCP defines a generic object model for a name server, and extends the NETCONF command set with name server-specific ones.

Although the long-term aim is to get NSCP understood by name server implementations, a more pragmatic approach is to put the control into server-specific wrappers, so avoiding the need for changes to the server software. The wrapper accepts NSCP commands and, on the basis of them, modifies the configuration file (and zone files), and causes the server to reload the data. The way this operates is shown in the figure below:

The first step is to create an XML version of the server configuration file. Name server configuration files tend to map into XML quite well as they usually have a hierarchical structure. In our tests, this was accomplished for BIND and NSD by modifying the parser module to emit XML as the configuration file was processed. Although this required a modification to the server software, the modification is a small, localised, change and does not otherwise affect its operation.

Next, an XSL transformation is used to convert the server-specific XML into NSCP, a process that involves mapping server-specific objects and attributes into NSCP objects and attributes. A two-step approach is used to keep changes to the name server software to a minimum: the parser module only needs to create XML that is isomorphic to the configuration file, something that is relatively simple to do. The intelligence needed to convert the representation into an NSCP is held in an (external) XSLT.

Once the NSCP representation of the configuration file is obtained, it can be manipulated with NETCONF commands. “Listing” commands (such as “get-config”) extract the relevant part of the configuration from the representation and send it back to the client. “Modification” commands (e.g. “edit-config”) are applied to the NSCP representation of the configuration file (again using an XSLT) to obtain NSCP describing the updated configuration: this is converted back into the configuration file format. As before, the conversion is a two-stage process to separate out the logic of the object model mapping from the mechanical process of creating the configuration file.

Once the configuration file has been updated, the wrapper forces the server to reload it to apply the changes.

Current Work
A small proof of concept project has shown that this approach is both feasible and practical. Effort is now being put into a pilot implementation.

We have just purchased a 40 port Avocent Mergepoint device for remote server console access management. This saves us using up valuable switch ports and separates these devices from the main network which results in a much more secure console access lan. This device can be managed through Avocent’s DSView3 software, but we are currently running it as a standalone device for testing. The DSView software will also manage their ACS console servers, presenting us with a single solution for console access whether they use a network or serial method of console access.

It is basically a switch that can run DHCP on its ports, and (Linux flash based) software to access and configure everything. It all sounded great so we deployed it out into the field for further testing at a site that was running out of switch ports. At under £3k it is probably cheaper than an enterprise level switch to manage these devices. Using it we connected up 21 remote servers and freed up 20 valuable switch ports. It has dual power, redundant network connections and a serial port for when all that fails.

All well and good so far. Next thing was to configure the web interface and create a new SSL certificate signed by our Nominet CA. This is where it all started to go wrong. The manual linked to on the Avocent website is wrong in so many ways. Firstly the web interface is completely different. Our Mergepoint came with firmware version 4, but the manuals (linked to from the product page) seem to be a previous version. I can cope with a different GUI, but the instructions for creating the certificate used the command line - and were wrong. They said to use

openssl req -new -nodes -keyout private.key -out public.csr

but of course you also need a config file, so the command should be

openssl req -new -nodes -keyout private.key -out public.csr -config /path/to/openssl.conf

with openssl.conf containing (for example) this:

[ req ]
default_bits            = 1024
default_keyfile         = privkey.pem
distinguished_name     = req_distinguished_name

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code)
countryName_default             = GB

stateOrProvinceName             = State or Province Name (full name)
stateOrProvinceName_default     = Oxfordshire

localityName                    = Oxford
localityName_default            = Oxford

0.organizationName              = Organization Name (eg, company)
0.organizationName_default      = Nominet

organizationalUnitName          = Organizational Unit Name (eg, section)
organizationalUnitName_default  = Tech

emailAddress                    = Email Address
emailAddress_default            = example@nominet.org.uk

commonName                      = Common Name (eg, YOUR name)
commonName_default              = MergePointDeviceName

After that you can use the CSR to created a new SSL certificate. The manual says the certificate should go into /etc/httpd/conf/ssl.key (it actually says use the command “cat cert.cert-/etc/httpd/conf/ssl.crt/server.crt” to do this. Does anyone every proof read manuals these days?). This is wrong and the private key and certificate should actually go into /etc/httpd as server.crt and server.key.

Next you should restart apache. Again the manual is wrong and says to use “daemon.sh restart APACHE”. Wrong - that’s the command that you would have used on an ACS console server. The Mergepoint is much more like standard unix here and a simple

/etc/init.d/apache2 restart

or

apachectl restart

is all that is required. All well and good and your new certificate is now in place and working. However, this is a flash based linux so you’ll need to ensure that these new files get saved to flash or they will be lost at the next reboot. There’s the handy manual that tells you to use the saveconf command (correct for once), but it is incorrect in telling you that all files listed in /etc/config_files get backed up. There is no /etc/config_files file (there is one on an ACS console server which is obviously what the manual was based on). The actual file to edit is backup_list.txt. Add these lines to the end:

/etc/openssl.conf
/etc/httpd

Finally if you want to add users to this device and allow ssh access via public key then add /home to the /backup_list.txt file. The users must be added through the web interface as this also updates a database allowing access to the web interface. Then add the users keys, update backup_list.txt and run saveconf. Optionally edit /etc/ssh/sshd_config - we remove root access and password access as we use non-root key based logins only.

I have voiced my concerns about the poor quality manuals to Avocent so that no-one else has to try and reverse engineer things. They originally said that creating a new CSR was impossible, but have since provided a draft of how to do it which was still missing some of the points above (specifically about getting the files saved to flash). A new firmware version is due out in July and hopefully the manuals will be better this time. They still maintain that public key ssh access is impossible without using the DSView software.

It seems I have done something I have been trying to do for years and achieved the impossible.

Background

OFCOM (the UK telecommunications regulator) recently mandated that any VoIP Service Provider that allows end users to make calls to the PSTN must also provide access to the Emergency Services number.

They also mandated that “to the extent technically feasible” the Emergency Handling Agencies (EHAs) must be supplied with the location of the caller. This speeds up the emergency response, and also helps in those cases where the caller is unable to provide their location.

This is already done by the existing PSTN and mobile telephone companies and is not a particularly difficult problem for them as they control all elements of the telephony service. However for VoIP the problem is substantially more difficult - VoIP users can connect to their VoIP service provider over any internet connection, from anywhere in the world.

In some parts of the world the customer is required to notify their VoIP service provider of their location. This isn’t feasible however for users who regularly use their VoIP service away from home, e.g. with a WiFi VoIP handset. Also, if this information is out of date then the consequences can be tragic as seen recently in Canada where the initial ambulance dispatch went to the customer’s previous address, 2500 miles away from where it was needed.

Proposed Solution

The proposed architecture currently being developed by NICC (the UK telecoms industry standards group) is to have the VoIP Providers, the Internet Service Providers, and the Access Network Providers all cooperate to provide location information in real-time.

The VoIP provider will know what the end user’s public IP address is, but they don’t know where it is. When they receive an emergency call they’ll pass the call over the PSTN to the EHA, but at the same time they’ll also send a separate message (using TCP/IP) containing that end user IP address.

The EHA will maintain a database derived from BGP4 real-time routeing data that maps from IP addresses to ISPs. Once they know the ISP, they’ll send the ISP’s “Location Information Service” a HELD protocol request containing the IP address as the lookup key (see IETF Draft geopriv-http-location-delivery). The response from the ISP is an XML document in PIDF-LO format (see RFC4119 and RFC5139) which contains either a “civic address” or a “geodetic location” (i.e. latitude/longitude).

A further complication is that many types of internet access run over a separate Access Network Service which is independent of the ISP. Most ADSL in the UK, for example, is provided using BT Wholesale’s “IPStream” access product which is then packaged up by hundreds of different ISPs.

In these networks it’s common for individual users not to be tied to a specific access line. Hence the Access Network needs to tell the ISP exactly which line is being used. In some cases that might be sufficient for the ISP to determine the address, but in many cases it’s expected that the ISP LIS will need to proxy the HELD request onwards to the Access Network where they should have the most accurate and up-to-date address information.

The diagram below is a simplified representation of how it’s expected to work.

Policy Issues

In my opinion the biggest problem with the architecture at the moment is that neither the ISPs nor the Access Networks actually operate Location Information Services. Partly this is because the relevant standards are still in development, but particularly because as yet there’s no regulation requiring them to do so.

All of the OFCOM regulatory changes so far have been focussed on the VoIP providers, without sufficient acknowledgment of the fact that it’s only the ISPs and the Access Networks that really know where any particular IP connection is being made from. However Ofcom are committed to revisit the regulations for the location issue very early next year, once technical standards (national and international) are clarified.

In my opinion most ISPs are at the moment completely unaware that they might need to do anything, and I hope that this article will stimulate further involvement from the ISP industry. I believe that regulation requiring ISPs and Access Networks to operate Location Information Services is inevitable and it would be better to work now towards a practical solution than to be stuck with an unworkable one later.

It should be noted that the implementation costs for this will be significant, and ISPs looking to recover their costs might start looking at how they could sell-on their customers’ location information to third parties. The potential market for location-based advertising is enormous, but so too are the privacy implications.

Ray Bellis - Senior Researcher

I use a MacBook Pro at work, but of course there are always one or two Windows applications that I need to run too.  Consequently, I recently installed Parallels to allow me to run these both in the office and at home.  I knew that others were using this method to run these apps, so I wasn’t too worried about getting it to work.

When I fired up Parallels for the first time though, the CPU usage shot right up and the whole OS X interface became incredibly sluggish for several minutes.  The strange thing was that this was just starting Parallels itself, not booting the virtual machine.  Once the application was started, sanity was restored.  The offending process was “WindowServer”, so it seemed to have something to do with the graphics processing.  There were reports of other folks having similar problems on the Parallels forum, but none of the solutions seemed to be definitive.

Then I tried starting Parallels while I was away from my desk.  It came straight up with no problem at all.  What was different?  It turned out to be a Good Way USB Display Adapter I am using to allow me to run 2 external monitors from my laptop.  Once this was disconnected the problem went away. So now if I’m at my desk, I unplug the USB cable, start Parallels, then reconnect.  I don’t understand what is going on here, but at least I have a workaround.

Need a quick way to decide who does something:

http://www.youdrawstraws.com/index.cfm

There are two modes:

1. An instant on-screen version, useful if everyone is in the same room.
2. A group session for use when working remotely. These sessions are time-limited.

We used the on-screen version to decide who would go to a remote site to install servers next week. It saved me the job of picking on someone! All it required was to give the session a name, enter how many people there are to choose from, name them, then let the application choose at random.

The group session is a bit more involved. Those involved in the draw can add categories, and options within categories. Once everyone has given input, or the deadline for choosing has been reached, the options are selected at random.

SJphone is a popular free VoIP client (or “softphone”), available for Windows, Linux, and MacOSX.

Most softphones have separate settings for the username and password used to authenticate the SIP REGISTER command, and another to set the SIP Address of Record. SJphone, by default, does not. It has the username and password fields, but it generates a default SIP AoR of username@domain.

There didn’t appear to be any way to support our configuration where the Authentication username is different to the left-hand side of the SIP AoR. After much digging a solution was finally found. In the “Profiles” dialog box there is an “Initialization” tab. On this tab there is a “Caller ID” setting and a tick box marked “Inquired”:

Ticking this box tells SJphone to prompt for the left-hand side of the SIP AoR along with the username and password fields. The other two tick boxes control whether the application remembers the supplied value, or prompts for it each time.

If necessary you can tick the “Full Address of Record” box instead, should you need to supply a SIP AoR with a different right-hand side.

I’ve been a vim user for many years.  More recently I have been mainly working on a Mac, but the version of vim for OS X was never very good.  It felt like a Linux application that had been ported to the Mac.  It didn’t support multiple windows, the standard Mac shortcut keys didn’t all work as expected and it just didn’t feel like it fitted in very well.  I was almost tempted to move to TextMate, but I missed all the regular expression commands I had grown used to.  Recently I have moved over to use Bjorn Winckler’s MacVim.  It is a proper Cocoa application which supports multiple windows etc and just looks and feels more Mac-like.  It even automatically updates when there is a new version.  It has got to the point where it is better than the old Carbon version in under a year.  I recommend you give it a try.

As mentioned by Miquel in a previous article, we are using Coverity Prevent to look for possible defects in our code.  Today I realised that it had spotted a possible problem that is almost invisible to the naked eye.  Initially it flagged up some code that looked like this:

if (someObject.getErrorType() == SomeClass.MY_ERROR_TYPE) {
.....
}

The complaint was that getErrorType() could return a null value, so this comparison would throw an exception when the null pointer was dereferenced. That’s an easy one to fix I thought. I changed the code to look like this instead:

if (SomeClass.MY_ERROR_TYPE == someObject.getErrorType()) {
.....
}

But Coverity continued to complain about this line. It still complained that getErrorType() could return a null value and claimed that it was also being dereferenced. Both Miquel and I looked at this and decided that the tool was mistaken. But then today I suddenly realised what was going on. The left hand side of the comparison is a plain old int whereas the right hand side is an Integer. So there is an invisible call to intValue() happening to do the unboxing. Coverity picks this up, but if you just glance at the code you can’t see it. I guess this is the price you pay for auto-boxing - there is code being called that you can’t see…

UPDATE: For some reason I thought the == operator called a method on the left hand operand. It doesn’t, it merely compares the object references. So swapping the order of the operands would make no difference. I think I was fooled by being told that the left hand side was null and being dereferenced. That’s the problem you’d get with a.equals(b) where a could be null. In this case swapping the objects around would make all the difference.

I have a SE P990i - not a bad device if over the last 3 years you’ve been able to stomach the infinite software updates/bug fixes/patches and workarounds - mine’s actually now usable.

Running the bundled software ‘PC Suite’ is required for backups (amongst other things) - and backups are essential. But having changed to a x64 system (XP) it turns out that Sony Ericcson do not support x64 systems (except within Vista Ultimate x64 - but not confirmed) - ie. PC Suite won’t install - and that’s SE’s offical line and last word on the matter. They’re not replying to customer service emails on the matter, either. Not even an automated reply - just silence (I think this will be my last ‘phone from SE).

Some get round this by dual booting 64 and 32-bit Windows and running the software when necessary under 32-bit - but I’m not too confident in this area and wanted a more ‘familiar’ solution. There are other solutions (while staying within x64) for SE’s slackness kicking around the web - however all of them involve only partial sucess - ie. you can have the ‘phone recognised by the system as a mass storage device, have the drivers working so the USB cable can charge it, even update the OS via SE’s update service - but you still can’t get the PC Suite to synchronise and perform backups. After numerous attempts and tweaking I have however managed to get them all working correctly. This obviously was the result of sheer hard work and luck was not involved in any way. Cough. I can’t guarantee it will work for other SE models, though my P990 was very happy.

Needless to say, backup your ‘phone before messing with it - although this concerns the software on your PC, not your ‘phone, so you should be just fine.

First, here’s a summary of the current solutions and drawbacks, with links:

• http://webmotion87.googlepages.com/sonyericssonp990(i)undermicrosoftwindows Summary: Extract the .exe and 64-bit .msi file - modify and re-run. This will give access to the SE Update Service but not the PC Suite.
• http://www.planetamd64.com/lofiversion/index.php?t13052-50.html Summary: Extract the .exe and retrieve the .msi file. Mess about with the installation .msi and then re-run it. This solution nearly got me up and running - but failed - I got the same old “This operating system is not adequate..” error in the final stages.
• http://www.wilson-it.com/sony_ericsson_download.htm. Summary: Some clever people at Wilson-it rewrote the SE drivers; quote “Basically the DSS-25 has a USB to Serial converter chip in it made by FTDI Ltd that was slightly modified for SE. We modified a BETA x64 driver of that chip to work with the SE DSS-25. Why SE couldn’t do this I have no idea.”. This solution will, on it’s own, allow you to recognise the device (the ‘phone, not just the sync-station as claimed) on your system via USB so you can charge it. Allegedly the update service will work as well (needing just a USB connection) but I haven’t tested this bit (you’ll know why, if you own a P990 ;-). This is not a fix for the installation of PC Suite, mind -however some people have reported success.
• Do both. Install the drivers and then re-run the modified .msi. Summary: You can get a bit further but sadly, for me, it was the same old installation error in the end.
• Bluetooth only: Apparrently, “floAt’s Mobile Agent 2.1 beta 3 ( http://fma.sourceforge.net/ ) works great with Win x64 and my Z800i. Synchonizing and file transfers, no problem”. Summary: Not tested this as I’d like to stay with the OEM software, so cannot comment. And it’s Bluetooth only, as stated.

Tweaked version:

1. Download the Wilson-it drivers (http://www.wilson-it.com/sony_ericsson_download.htm) and install them (all of them - when one is finished, it will prompt another). This will enable USB charging.
2. Get the latest PC Suite (67mb) from SE’s site (http://www.sonyericsson.com/cws/support/softwaredownloads/p990i?cc=gb&lc=en) which is “PC Suite for Smartphones 1.5.8″ or use an existing (older) version - I used my older version that came with the original CD.
3. Download an .msi extraction tool such as Orca (I used this from http://www.technipages.com/download-orca-msi-editor.html) or other program (strangely the most ‘popular’ seems to be something called “Less MSIérables” - but their site is offline and still is so I have no idea what it’s like)
4. Use a program such as WinRar (http://www.rarlab.com/download.htm) to extract the PC Suite for Smartphones .exe package. Extract to a new folder where you can get at the resulting files.
5. From the resulting WinRar extracted files, run the “PCSuite.exe” (not the PCSuitex64.exe some solutions say “do” but that didn’t work for me) until you hit a wall (error report or such) - do not cancel or abort the installation just yet. Search your C:\WINDOWS\temp folder for the “still running but about to disappear when you abort the installation” .msi file - this will be called “PC Suite for Sony Ericsson.msi” or possibly “ah7v5gdo6.msi” or similar ‘random’ string. Tip: if you search for this before you begin and leave the window open, the window will update when you run the .exe showing you the right file.
6. Right click on this to edit within Orca (or drag and drop into Orca). Whilst open in Orca, locate the entry “LaunchCondition”, right-click and and “drop table”. So far, this is the standard solution which didn’t work (yet) for me.
7. My tweak - an additional error for me was “The current version of msxml6.0 is not compatible with…”. So, whilst still in Orca, locate (using the find tool) “msxml6″ in all entries (I found two) and choose “drop row”, thus deleting that call/check. I suspect the critical one is in the InstallExecuteSequence table.
8. Save the resulting file (note that’s Save and not Save as) - this will overwrite the .msi in memory. Still without having aborted the initial installation, double click and run this .msi file - this will bring up a new install window. Keep going and it should install the PC Suite. If it complains about drivers, decline Windows’ offer to search the web and locate the extracted Wilson-it drivers in the same directory as last time.
9. If you have no luck at this point with the installation of the PC Suite try the x64 version of the .exe and the subsequent .msi. I know I ran both or all variations before finally running the “PCSuite.exe” and resulting .msi which worked.
10. At this point, although PC Suite runs (hopefully) it wil still not recognise the ‘phone. I tried restarting the PC, as well as unplugging the ‘phone repeatedly. I swear this did not work - until around 48 hours later when I plugged my ‘phone in to charge - when suddenly Windows detected ‘new hardware’ and asked for “drivers”. Pointing Windows to the same extracted Wilson-it drivers as before (surely they’ve already been installed?) allowed PC Suite to recognise and connect to the ‘phone. Maybe it’s just a question of a few restarts and re-re-plugging in of the ‘phone. Not very technical this very last bit, but at least it worked.

In hindsight, I suspect that if you install the drivers last - after the “.msi PC Suite” part - you may have a quicker result than I did.

Useful links:

http://www.planetamd64.com/lofiversion/index.php?t13052-50.html
http://www.esato.com/board/viewtopic.php?topic=170665

Recently I’ve been running puppet a *lot* on Solaris 10 (Sparc). I would say consistently around 50% of the time the following happens:

bash-3.00# /usr/local/bin/puppetd -t
notice: Ignoring cache
/opt/ruby/lib/ruby/1.8/timeout.rb:52: [BUG] Segmentation fault
ruby 1.8.6 (2007-09-24) [sparc-solaris2.10]
Abort (core dumped)

Though this has been causing me to get very frustrated with puppet, and indeed it has made the adoption of puppet within the organisation more problematic than it should have been, I realise this is unfair on puppet as the problem seems to be with the ruby jvm. We have not seen this type of behaviour with puppet on Linux or indeed with the Solaris x86 port. Maybe ruby can’t handle the 32 cores of our T2000.

I’m hoping with the release of a later version, either 1.8.7 or the developer release of 1.8.9 that these problems disappear. So a question:

Has anyone else experienced this type of segmentation fault with ruby?