Useful for migrating sites from one host to another before or during DNS propagation.

That said, I’m using Varnish and HAProxy an increasing amount for such plumbing.

1. Yep, still running 1.3 around the place

• Between firewall pair, LAN

  [ 3] 0.0-10.0 sec 1.00 GBytes 860 Mbits/sec
[ 3] 0.0-10.0 sec 1.00 GBytes 860 Mbits/sec
[ 3] 0.0-10.0 sec 1017 MBytes 853 Mbits/sec

• Firewall to firewall between DCs, outside VPN, no PF

  [ 3] 0.0-10.0 sec 1.02 GBytes 873 Mbits/sec
[ 3] 0.0-10.0 sec 992 MBytes 832 Mbits/sec
[ 3] 0.0-10.0 sec 986 MBytes 827 Mbits/sec

• Firewall to remote internal host, outside VPN, through PF NAT (rdr)

  [ 3] 0.0-10.0 sec 260 MBytes 218 Mbits/sec
[ 3] 0.0-10.0 sec 202 MBytes 170 Mbits/sec
[ 3] 0.0-12.3 sec 333 MBytes 228 Mbits/sec

• Internal host to internal host, over IPsec VPN (ESP), through PF
  

  [ 3] 0.0-10.1 sec 43.9 MBytes 36.4 Mbits/sec
[ 3] 0.0-10.1 sec 26.2 MBytes 21.8 Mbits/sec
[ 3] 0.0-11.3 sec 28.0 MBytes 20.8 Mbits/sec

• Internal host to internal host, over OpenVPN, through PF
  

  [ 3] 0.0-10.0 sec 161 MBytes 134 Mbits/sec
[ 3] 0.0-10.0 sec 144 MBytes 121 Mbits/sec
[ 3] 0.0-10.0 sec 145 MBytes 121 Mbits/sec

Care was taken to use optimal ciphers, appropriate MTU / MSS and the TCP stack was tuned throughout.

• IPsec really hurts without hardware acceleration
• There’s a surprisingly large hit for just NAT
• Neither VPN technologies can benefit from the multiple cores available to them
• OpenVPN’s speed is appealing, but it lacks the smooth route to high availability of CARP + pfsync + sasync of IPsec on OpenBSD

• S3Fox
• Elasticfox

There’s bound to be something that draws together all the foregin keys – AMI, volume, instance, reservation etc – but I’ve yet to find that. Been putting off writing it for a while…

The first firewalls were on trains. Coal-powered trains had a large furnace in the engine room, along with a pile of coal. The engineer would shovel coal into the engine. This process created coal dust, which was highly flammable. Occasionally the coal dust would catch fire, causing an engine fire that sometimes spread into the passenger cars. Since dead passengers reduced revenue, train engines were built with iron walls right behind the engine compartment. This stopped fires from spreading into the passenger cars, but didn’t protect the engineer between the coal pile and the furnace. (There’s a lesson for sysadmins in this somewhere.)

(My emphasis)

[root@two /usr/ports-work/distfiles ] 0 # curl --referer http://www.eyesbeyond.com/freebsddom/java/JDK15JRLConfirm.html -v -d"patchset=6" -d "accept=ACCEPT" -O http://www.eyesbeyond.com/freebsddom/java/download_patchset15_jrl.cgi

My long time response to this was *shrug* – Ruby seems fine. Until a weird production problem, unrepeatable on stage, where certain Rails stacks (those running in development mode to expose some aspect of the Globalize plugin to translators) crashed badly, with SIGBUS or SIGILL.

I came across this script:

$ ruby -e 'def d(x); p x; d x+1; end; d 0'

which exposes the problem perfectly. With a pthread‘d Ruby it dumps core, with a no-thread Ruby it gracefully raises stack level too deep (SystemStackError)

More here

Update:

I discussed this on the FreeBSD ports list, discussion here.

Seems like the problem is on its way out.

[root@ /var]# fsck /dev/ad1s1d
** /dev/ad1s1d
CANNOT READ BLK: 204735648
CONTINUE? [yn] y
THE FOLLOWING DISK SECTORS COULD NOT BE READ: 204735648, 204735649, 204735650, 204735651,
/dev/ad1s1d: INCOMPLETE LABEL: type 4.2BSD fsize 0, frag 0, cpg 0, size 205012094
[root@ /var]# mount -o ro /mnt/ark
WARNING: /mnt/ark was not properly dismounted
[root@ /var]# cd /mnt/ark
[root@ /mnt/ark]# ls
.snap home old
[root@ /mnt/ark]# ls -l
panic: vrele: negative ref cnt
Uptime: 28m42s
Cannot dump. No dump device defined.
Automatic reboot in 15 seconds - press a key on the console to abort


Is this the BIOS-y raid storing its metadata where it shouldn’t? Chipset is a Promise PDC20276.

Of course, there could be a genuine problem with this disk, but I won’t know till I’ve found a replacement CPU / mobo.

• snapshot filesystem
• dump filesystem to tape
• release snapshot
• check dump

kind of manner.

It does, however, have problems with realtime priority processes. If the executable of such a process resides on the filesystem being snapshotted, things don’t work:
snapshot error: File system could not be write locked

Quick solution: identify these processes and halt them across the snapshot:
# priocntl -d -i class RT
REAL TIME PROCESSES:
PID RTPRI TQNTM
577 0 0
In this case, pid 577 was xntpd(1M).

Perhaps a better attempt would be to temporarily jigger the priority away from realtime.

Getting the garage (who are cool and have never ripped me off) to diagnose the fault would cost at least two hour’s labour, plus a callout fee for the bloke with the expensive VW diagnostic computer. Actually removing the turbo unit from the engine would cost north of £300.

Thankfully, there are two (relatively) cheap and accessible components in the setup, the solenoid which tells the wastegate to operate, and the air mass sensor (aka MAF) that tells the car’s brain how much air there is to compress. Both of these aren’t in the turbo unit itself, but located just beneath the bonnet. I picked one, the latter, and replaced it for the small fee of £60 + VAT. The MAF sits immediately behind the air filter on the air intake pipe. Two Philips screws and a big clip later and the new part was in.

The fix was obviously working within seconds of driving – it’s like having an engine several times larger. Woo!

Technical info about MAF here.

A forum of VW turbo woe here.

mysql> grant all on "ti_%".* to ti@ti.jail.lemonia.org ;
ERROR 1064: You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near '"ti_%".* to ti@ti.jail.lemonia.org' at line 1

mysql> grant all on "ti\_%".* to ti@ti.jail.lemonia.org ;
ERROR 1064: You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near '"ti\_%".* to ti@ti.jail.lemonia.org' at line 1

mysql> grant all on 'ti\_%'.* to ti@ti.jail.lemonia.org ;
ERROR 1064: You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near ''ti\_%'.* to ti@ti.jail.lemonia.org' at line 1

Flail!