Alex Bligh's blog

Alex Bligh's personal blog

At Flexiant, we had a need for a general websocket to tcp proxy. A cute apache module to do extensible web-sockets programming has been developed by self.disconnect, and is available on github here. I’ve hacked around with this to produce a generic, apache licensed, websocket proxy. A websocket connection is made over HTTP or HTTPS to apache, this calls the websocket module, which in turn calls my module, which makes an outbound tcp connection.

Some features:

  • It supports base64 and text format sockets. So it will thus process (for instance) VNC which works using base64 encoding.
  • Configuration is supplied through normal apache directory based configuration (see details below).
  • It’s extensible (currently by changing the code, rather than calling additional modules)

The configuration section looks like this, in this case set up to proxy VNC using a novnc client:

<IfModule mod_websocket.c>
      <Location /vncproxy>
        SetHandler websocket-handler
        WebSocketHandler  /usr/lib/apache2/modules/mod_websocket_tcp_proxy.so tcp_proxy_init
        WebSocketTcpProxyBase64 on
        WebSocketTcpProxyHost 192.168.199.199
        WebSocketTcpProxyPort 5900
        WebSocketTcpProxyProtocol base64
      </Location>
 </IfModule>

Note that the parameter you specify for Location must not be a file or directory that exists with your docroot, or you will just get 404 or similar. So, in the above example you must not have a file or directory at ${DOCROOT}/vncproxy.

I discovered that on a default apache install, you may also want to change the RequestReadTimeout, i.e.

<IfModule reqtimeout_module>
  RequestReadTimeout body=300,minrate=1
</IfModule>

I’m going to try and persuade self.disconnect to stick this in the examples directory for apache-websocket, but in the mean time the source is available here. Put it in the examples directory of apache-websocket, then compile, install and enable it with it with:

sudo apxs2 -c -i -a -I.. mod_websocket_tcp_proxy.c

You may remember that around this time last year, Nominet announced a misguided proposal for a cosy relationship with law enforcement agencies. I’ve blogged several times before about this (here, here, here and here), but last week their issue group has come up with yet another revised set of draft recommendations that they will be proposing to the board for adoption.

Nominet unfortunately did not provide a version with tracked changes. I’ve highlighted the main differences in the document (and in my comments) in my response.

It won’t come as any great surprise to observers of this process that the same misguided principles remain. The changes from last time are mostly small incremental improvements. The main problem – and I find this somewhat difficult to believe given the number of iterations this document has been through now – is that it is not obvious how ‘connected’ your domain name has to be to an alleged criminal, in order to be subject to the policy; in simple terms there is nothing to stop an alleged criminal using a demon.co.uk address causing the suspension of demon.co.uk, or an employer having its domain suspended because of the unauthorised actions of an employee. On the positive side, the clause which apparently widened the process to include any crime at all has now gone, and they’ve made some further minor improvements to the process.

So, once again, they’ve improved the process and some of the safeguards, but have yet to address at least one key issue, together of course with the overarching point: why on earth should Nominet be doing this at all?

My full response is here.

This time we get eight days to reply (by 18 November) which I suppose is an improvement over three. I encourage you to submit your own response, by writing to policy@nominet.org.uk. I know some people have in the past just written ‘I agree with Alex’, which whilst better than nothing and mildly flattering, is probably not as effective as explaining why (at least in relation to the primary concerns). If, for instance, you were to state in your own words that you think the whole policy is a bad idea, but that you are particularly concerned that innocent registrants might be hit as the policy makes no express provision for minimising collateral damage (as in the demon.co.uk example above) , that would probably be useful.
 


 
A brief epilogue for those few people interested in the minutiae of Nominet governance rather than the substance of the issue at hand:

In my original blog post I said: “I think the paper is written by SOCA rather by than Nominet, though that’s not clear.” The issue group page now says “The policy process was started with a proposal submitted by Serious and Organised Crime Agency (SOCA) regarding domain names used in connection with criminal activity”. I’m pretty sure that wasn’t on the issue group page from the beginning, and it’s a welcome clarification. However, you have to wonder why:

  • the paper has no mention of SOCA as an author at all, cryptically referring to “we” which is easily read to mean Nominet, especially as it mentions SOCA as a potential interested party along with others who did not author the paper; and
  • the paper is written in Nominet’s house font, with an author attribute of “Tania” (who might just be Nominet’s ever helpful Tania Baumann, who is no doubt very bored of me by now).

Nominet got a bit of a hysterical pasting when the proposals first came out (e.g. here), because (quite reasonably) the proposals were attributed to Nominet rather than to SOCA. It looked like Nominet were recommending them in their original form, rather than SOCA recommending them. And Nominet were not exactly quick to deny this. As I wrote elsewhere at the time, I put this down to a rather bumpy introduction of the new policy development process, rather than any particular evil doing at Nominet Towers (is that link right? – Ed). A learning point here is that if you do not want your consultation to look like a fait-accompli (and, to be fair to Nominet, it wasn’t – a fair amount has changed since the original set of recommendations even though I remain opposed to the principle) then make it quite clear who authored the original proposals, and that you do not (yet) have a view on them.

I’ve blogged several times before (here, here and here) about Nominet’s misguided proposal for a cosy relationship with law enforcement agencies. Their issue group has come up with a revised set of draft recommendations that they will be proposing to the board for adoption.

As per last time, the same misguided principles remain. There has, however, been a fair amount of improvement, particularly in respect of transparency, process, and an appeals process. However, it’s still (rather startlingly) not obvious how ‘connected’ your domain name has to be to an alleged criminal, in order to be subject to the policy; in simple terms there is nothing to stop an alleged criminal using a demon.co.uk address causing the suspension of demon.co.uk, or an employer having its domain suspended because of the unauthorised actions of an employee. And the Issue Group seems still undecided as to what alleged crimes should be covered, wavering from those that create ‘a clear risk of imminent serious harm to individuals’ to any crime at all (beware your employee who sends an email when driving).

In short, they’ve improved the process and some of the safeguards, but not addressed at least two key issues, and the overarching point: why on earth should Nominet be doing this at all?

My full response is here.

The email to tell you all about this came out this afternoon (17 October) describing a meeting held on 21 September. They want responses by 20 October, which I have to say is not up to Nominet’s normal standards in terms of reasonable consultation periods, but if you want to submit your own response, write to policy@nominet.org.uk. You’ll need to type quickly.

Forgive the attention-seeking title. I’ve blogged before (here and here) about Nominet’s misguided proposal for a rather too cosy relationship with law enforcement agencies (I say “Nominet’s” proposal, though it’s never been entirely clear whether the proposal emanated from SOCA, Nominet or both). Now their issue group has come up with a set of principles that they will be proposing to the board for adoption. As feared, this principles remain misguided, though to be fair to the authors there has been an attempt (albeit very limited) to address some of the concerns raised. My full response is here, but for those not wanting to read a five page PDF, I have summarized below how my four main arguments that Nominet should not suspend domain names allegedly associated with criminal activity have been addressed.

Firstly, that there are already more effective ways of dealing with this, such as going to registrars and use of the ‘investigation lock’. The proposed principles do not set out why existing mechanisms are inadequate. There is some attempt at limiting the ambit of the proposals to situations where other routes have been exhausted, but bizarrely this is only proposed where no serious harm is being caused. Why Nominet should even consider suspending domain names where no serious harm is being caused is beyond me.

Secondly, collateral damage. The proposals appear not to address this point at all. There is no proposed linkage between registrant, alleged criminal and domain name, so nothing to stop an alleged criminal using a demon.co.uk address causing the suspension of demon.co.uk, or an employer having its domain suspended because of the unauthorised actions of an employee.

Thirdly, civil liberties and due process. I accept that civil liberties need to be balanced against protection of the public from serious crime, and that some attempt has been made to address this balance. However, protection ‘of the public’ from counterfeit Ugg Boots (for instance) does not seem to me a particularly significant altar on which to sacrifice civil liberties. The policy should concentrate on crimes more serious than these.

Fourthly, mission creep. The proposals do not address this. Indeed, disappointingly, the mission creep has already started, with an issue group tasked to look at criminal activity already recommending to the board that it look at ‘civil and third party’ complaints too.

Conspicuously absent from the proposals is any cogent explanation of why Nominet should be doing this in the first place.

Nominet is in general quite good at listening to feedback, so I encourage you to submit some, as detailed here. Thankfully, not every romance ends in marriage.

I blogged here about adding SQL support to dhcpd. I’ve fixed a couple of issues – mainly memory leaks. I have no idea how I missed these before (sigh). The good news is that the server ran for sufficiently long for the process to get to many gigabytes in size, and nothing crashed!

You can find a new patch, against dhcpd 4.2.0-P1 (but should work against dhcpd 4.2.1-RC1) here.

See the original post here for build instructions and documentation.

I wrote here about the dangers of Registry operators, particularly Nominet, allowing suspension of domain names outside the due process of courts, to make matters ‘easier’ for law enforcement. One of the many reasons why this is a bad idea is that innocent bystanders can get caught in the crossfire. Now, exactly that has happened in the US as described here.

The Register alleges that the domain name ‘mooo.com’ was suspended as it was ‘seized’ by  ’Immigration and Customs Enforcement, the main investigative arm of the US Department of Homeland Security‘ who then replaced the web sites hosted at ‘mooo.com’ with a banner including the text ‘Advertisement, distribution, transportation, receipt, and possession of child pornography constitute federal crimes that carry penalties for first time offenders of up to 30 years in federal prison, a $250,000 fine, forfeiture and restitution.’

It appears, however, that mooo.com (which today reports ‘no web site configured’) was actually some sort of shared free web hosting service. I’m obviously not in a position to say whether one or more users had hosted unlawful material there, but even if this is the case, it seems likely that a large number of innocent users were affected too. There does not seem to be any suggestion the operators of mooo.com were involved. The solution to this problem is not for the domain name in question to be suspended (particularly on no notice), with consequent collateral damage, but rather to go after the publishers of the unlawful material. I am not in any way suggesting child pornography is not a serious crime. Rather, I am suggesting it is the perpetrators who should be targeted, impact on innocent parties should be minimised, and that the authorities pursuing them should be subject to the rule of law. Particularly worrying in this case, if the Register is correct about the notice appearing on web sites of innocent people, is the likely inference drawn by others that these people were somehow involved in child pornography.

I am sure it is not unheard of for people to upload unlawful material to Facebook, Myspace, or other services reliant on a single domain name; I do not believe these services should get special protection just because the law enforcement community is likely to be more familiar with them.

I should point out that in this case what The Register describes as a ‘secret court proceedings’ (in reality perhaps just an ex parte hearing) was involved. What Nominet and/or SOCA propose (it’s difficult to tell who is doing the proposing) is that even that safeguard would be dropped.

This is is a deeply scary article about a young autistic man trapped in what the author describes, without exaggeration, as an Orwellian nightmare. I can’t put it much better than the original author, so I encourage you to go and read it.

I blogged here about adding SQL support to dhcpd. I’m now reasonably happy with the patch, but have made a couple of tiny updates. These concern the documentation, and a bug which prevented the (probably useless) “name:” field from working.

You can find a new patch, again against dhcp 4.2.0, here.

See the original post here for build instructions and documentation.

I developed at Flexiant a utility called sparsecopy, which we use to copy around sparse files (and indeed to make non-sparse files sparse, and to copy sparse files to block devices). In essence, it’s a version of dd which supports sparse files better. It’s hidden deep within Flexiant’s web site, and as we released it under the GPLv2, I thought I’d put it up here too. That link will take you to a tarball, which which you can either do the normal make, make install on, or build a Debian / Ubuntu package using debuild. It’s pretty self-explanatory, but here are the options:

Usage

sparsecopy [OPTIONS] SOURCE DEST

Options

-o, --overlay

Overlay existing file DEST (rather than truncating)

-n, --nocheck

Skip blank check

-q, --quiet

Quiet

-m, --max SIZE

Copy SIZE bytes maximum from SOURCE

-b, --blocksize SIZE

Use SIZE blocksize in bytes (default 512)

-s, --seek POS

Start writing SOURCE at position POS in DEST

-f, --finalsize SIZE

Set size of DEST to SIZE when done (no effect on block devices)

-c, --check

Check the first block in the destination is zero, else abort

-p, --progress

Display progress indicator on stderr

-h, --help

Display usage

Notes

Sparsecopy copies from a source file (either sparse or non-sparse) to a destination file making the destination file sparse on the way. If the destination file already exists then the source file can be superimposed on top of it by using the -o switch (ignored if the destination file doesn’t exist); in this case sparsecopy will (unless -n is specified as well) check that any blocks to be overlayed with zero (i.e. made sparse) are already zero in the destination images. When used with block devices, sparsecopy will not affect the size of the device.

SOURCE can be "-" to indicate stdin. SOURCE or DEST can be raw devices if you wish. If you want to make a sparse file, either use /dev/zero for SOURCE and -m, or (quicker) use /dev/null for SOURCE and -f.

SIZE and POS can be specified in blocks (default), or use the following suffixes:

B: Bytes (2^0 bytes)
K: Kilobytes (2^10 bytes)
M: Megabytes (2^20 bytes)
G: Gigabtytes (2^30 bytes)
T: Terabytes (2^40 bytes)
P: Perabytes (2^50 bytes)
E: Exabytes (2^60 bytes)

Note that blocksize=1024 will set blocksize to 1024 512 byte blocks (use 1024B if this is not what you mean). Also note that disk capacity is often measured using decimal megabytes etc.; we do not adopt this convention for compatibility with dd.

I run Office 2004 on OS-X (the last one before the horrible ribbon update). Autoupdate has now been running for 10 minutes on a high performance Mac. It knows it has updates to install, but it is “Searching for programs to update”. The program to update is (unsurprisingly) Office 2004, and it is (unsurprisingly) installed in Applications. It’s presumably easy to detect that, as double clicking a Word file opens the right version of Word etc. But no, Microsoft has apparently determined it is necessary to search every folder on every volume which is a huge amount on my system. Even more amusingly (for those with time to spare), it has 4 updates to install, so searches the disk 4 times. No other updater is this brain-dead.

It’s a pity using Pages and Numbers is not a viable alternative for anyone wanting to exchange documents. Keynote is fantastic though.