So I bought a new 32GB iPhone 3G S this morning at a Rogers Plus store. Was painless and, since I give them so much money each month, I received the $299 pricing.
Different from last time is that the staff activated the phone before handing it over.
I plugged it into iTunes which offered to restore my previous unit’s backup and I’m good to go. Smooth!
I thought I’d let everyone know that I upgraded my iPhone 3G to iPhone OS 3.0 yesterday and tethering Just Works™ over both Bluetooth PAN and USB. In fact, it’s much simpler to use than I expected.
I have an original 6G data plan with Rogers and according to their FAQ, this is a supported feature and I am not going to get a multi-thousand dollar bill next month. 
Recently I have been building a few packages under an OpenSolaris Zone hosted by Joyent. Ran into a few issues with shared libraries, so here are my notes:
You will often get an error like ld.so.1: conftest: fatal: libreadline.so.5: open failed: No such file or directory. This simply means the linker can not find your library. The following command will tell the linker to append a new entry to the existing search path:
# crle -u /path/to/lib/dirYou can retrieve the current configuration by simply running
crle on it’s own, output should be something like this:
$ crle Configuration file [version 4]: /var/ld/ld.config Platform: 32-bit LSB 80386 Default Library Path (ELF): /opt/local/lib:/opt/csw/lib:/usr/lib:/lib Trusted Directories (ELF): /lib/secure:/usr/lib/secure (system default) Command line: crle -c /var/ld/ld.config -l /opt/local/lib:/opt/csw/lib:/usr/lib:/lib
You can easily get yourself into a situation where your system is a brick by having an incomplete search path for the linker. For example, if you run crle -l /foo/path/lib, you will no longer be able to run anything at all since the linker will not find basic libraries it needs. I found a great post on this topic which instructs you do use the LD_NOCONFIG environment variable to tell the linker to use a default configuration. You can then fix the issue:
$ sudo crle -l /opt/local/lib -l /opt/csw/lib -l /usr/lib -l /lib ld.so.1: sudo: fatal: libpam.so.1: open failed: No such file or directory Killed $ LD_NOCONFIG=yes sudo crle -l /opt/local/lib -l /opt/csw/lib -l /usr/lib -l /lib
Since I will eventually be implementing OpenID in a commercial project, I thought I would go ahead and set myself up properly.
There are now a few free OpenID providers and I have setup my own account with VeriSign Labs Personal Identity Provider beta. Of course, I do not wish to expose the actual provider as my OpenID: what if I lose trust in them or they simply stop offering the service one day?
The solution to this is actually quite simple and allows you to use your own domain as your personal OpenID, exactly what I needed. The technical term is delegation and is fully documented. To implement this trick using WordPress, simply edit your themes header.php and add two meta tags. Of course you can do this with your software of choice, or even plain vanilla HTML. This is what I added to my blog:
<link rel="openid.server" href="https://pip.verisignlabs.com/server"> <link rel="openid.delegate" href="https://adam.sherman.pip.verisignlabs.com">
The above indicates that my personal OpenID is being delegated to https://adam.sherman.pip.verisignlabs.com which is hosted by the server https://pip.verisignlabs.com/server. Since the page at http://sherman.ca/ contains the above tags, I can now go to any site supporting OpenID (look for the logo: 
) and simply use sherman.ca as my identifier.
I believe that OpenID’s time has come and I look forward to implementing it for some of my clients in order to give their users the ability to consume services without a registration page.
So Rogers (and their other brand, Fido) have Unlimited Data plans. And guess what? The fine print is so bad I do not know whether to laugh or cry. The Fido page says
The Unlimited surfing on your Fido option includes unlimited mobile surfing on your handset only and is only available on selected handsets (non-Fido certified handsets, WindowsMobile devices and PC cards are not eligible). Data usage incurred on ineligible handsets and devices, incurred while tethering (using a handset or device as a wireless modem or laptop) or incurred using non-Fido (third party) applications downloaded to your handset will be subject to pay-per-use charge of 5¢ per KB. Option applies within Canada only. While roaming outside Canada, data transmission charge of 5¢ per KB apply, except in the U.S. where data transmission charges of 1¢ per KB apply.
The Rogers page has a few good ones too, have a look.
This means that I can have unlimited data, but only on devices where I would likely not use much, right?
The Torontoist has an article on this subject.
Since I have run into problems similar this fellow, I thought I would link to the original page and reproduce the instructions here:
# dscacheutil -flushcache
Very useful tip.
As mentioned in a previous post, Leopard uses launchd to automatically launch ssh-agent when needed. I just noticed that it does exactly the same thing for X11!
Try it: type xeyes in a Terminal window and watch X11.app magically launch itself. Very smooth. Relevant configuration is quite simple:
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict> <key>Label</key><string>org.x.X11</string> <key>Program</key><string>/usr/X11/X11.app/Contents/MacOS/X11</string> <key>Sockets</key> <dict> <key>:0</key> <dict><key>SecureSocketWithKey</key><string>DISPLAY</string></dict> </dict> <key>ServiceIPC</key><true/></dict></plist>
For more information on launchd, see the following man pages: launchd(8), launchctl(1) and launchd.plist(5).
A nice feature I was not aware of is the ability to put user-specific agent definitions in ~/Library/LaunchAgents, very cool.
blog
Pharmacy blog
buy soma
buy viagra
buy viagra online
cheap generic viagra
buy cialis online
buy cialis
buy levitra online
buy levitra
buy trial packs
buy propecia
buy propecia online
buy voltaren
buy cialis soft
buy cialis soft online
buy viagra soft online
buy viagra soft
buy acomplia
buy acomplia online
A quick tip about using the qlmanage command to see the Quick Look preview of a file from the command line. Define this shell function:
ql(){
qlmanage -p $@ 2>/dev/null
}
Then you can invoke it as ql FILENAME when needed. Use C-c to exit.
Update: Scott left a great suggestion to use $@ instead of $1. This allows you to bring Quick Look up for multiple files. (It even provides a contact sheet view, nice.) Thanks Scott!
I received and installed Mac OS X 10.5 Leopard on Friday, now I’m getting used to it and will be posting a series of short notes about interesting features as they appear.
One of the first things I noticed is that Leopard seems to start ssh-agent at login. A little more digging reveals that this is due to a LaunchAgent provided by Apple:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN""http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>org.openbsd.ssh-agent</string>
<key>ProgramArguments</key>
<array>
<string>/usr/bin/ssh-agent</string>
<string>-l</string>
</array>
<key>ServiceIPC</key>
<true/>
<key>Sockets</key>
<dict>
<key>Listeners</key>
<dict>
<key>SecureSocketWithKey</key>
<string>SSH_AUTH_SOCK</string>
</dict>
</dict>
</dict>
</plist>
The above causes the agent to be dynamically launched only when you actually need it. That is really cool!
Updated: I just read this hint which mentions that there is also a nice Cocoa ssh-ask-pass in Leopard! Funny thing is that I had seen the dialog a few times without noticing it at all, it seems to just be a normal occurrence.
For the past couple of months, I’ve had an issue where Apple’s Mail would not set messages “read” flag on the IMAP server unless I used the “Mark as Read” menu.
Just now, I read the following:
http://discussions.apple.com/thread.jspa?messageID=3144247
Disabling GPGMail’s ability to automatically decrypt/verify messages caused the issue to go away. Fantastic!
UltraMonkey provides Debian packages for Heartbeat 2.0 (currently 2.0.4).
Recently, while trying to figure out why ssh is taking so long to connect to many systems under Mac OS X 10.4.1, I sniffed the DNS traffic. To my surprise, I see SSH is doing SRV lookups:
0.000000 10.100.0.23 -> 10.100.0.10 DNS Standard query SRV _telnet._tcp.mariesa.techsupport.local
0.001124 10.100.0.23 -> 10.100.0.10 DNS Standard query SRV _telnet._tcp.mariesa.techsupport.local
0.001272 10.100.0.10 -> 10.100.0.23 DNS Standard query response, No such name
0.001989 10.100.0.23 -> 10.100.0.10 DNS Standard query SRV _telnet._tcp.mariesa.techsupport.local
0.002321 10.100.0.10 -> 10.100.0.23 DNS Standard query response, No such name
0.002848 10.100.0.23 -> 10.100.0.10 DNS Standard query SRV _telnet._tcp.mariesa.techsupport.local
0.003176 10.100.0.10 -> 10.100.0.23 DNS Standard query response, No such name
0.003993 10.100.0.10 -> 10.100.0.23 DNS Standard query response, No such name
2.027353 10.100.0.23 -> 10.100.0.10 DNS Standard query SRV _telnet._tcp.mariesa.techsupport.local.techsupport.local
2.027840 10.100.0.23 -> 10.100.0.10 DNS Standard query SRV _telnet._tcp.mariesa.techsupport.local.techsupport.local
2.028764 10.100.0.10 -> 10.100.0.23 DNS Standard query response, No such name
2.029120 10.100.0.10 -> 10.100.0.23 DNS Standard query response, No such name
2.029562 10.100.0.23 -> 10.100.0.10 DNS Standard query SRV _telnet._tcp.mariesa.techsupport.local.techsupport.local
2.030249 10.100.0.23 -> 10.100.0.10 DNS Standard query SRV _telnet._tcp.mariesa.techsupport.local.techsupport.local
2.030829 10.100.0.10 -> 10.100.0.23 DNS Standard query response, No such name
2.031551 10.100.0.10 -> 10.100.0.23 DNS Standard query response, No such name
4.042563 10.100.0.23 -> 10.100.0.10 DNS Standard query A mariesa.techsupport.local
4.043651 10.100.0.10 -> 10.100.0.23 DNS Standard query response A 10.100.0.103
4.064124 10.100.0.23 -> 10.100.0.10 DNS Standard query A mariesa.techsupport.local
4.065093 10.100.0.10 -> 10.100.0.23 DNS Standard query response A 10.100.0.103
That is very aggravating, since I don’t see a way to turn it off. Some Googling reveals a post on the topic.
Update: Stany did a little digging, found lots of patches, but not what I was looking for:
Now, regarding SRV lookups…. I’ve not noticed anything magic in the source that causes that to happen. Maybe that’s part of GSSAPI stuff – I frankly weren’t looking too closely. Maybe it’s something that libSystem.B.dylib does on behalf of ssh. Further investigation is needed, as it didn’t jump out at me.
So I’m thinking that this must be a part of the resolver. Although, it is doing lookups for _telnet._tcp.
This afternoon I quickly setup enough infrastructure on my test server to enable it to use Multicast DNS to resolve local names and answer local queries. Multicast DNS is part of the Zeroconf specification, which Apple has implemented and refers to as Rendezvous.
In order for this to work, your system needs to both answer and perform multicast DNS queries. The two pieces you need for this are:
As of 0.3, nss-mdns is already Debian-ready, simply build a package executing fakeroot dpkg-buildpackage from the unpacked tarball. There is an mDNSResponder package in Sarge which is rumored to be removed shortly due to license problems with APSL, so grab a copy soon.
Once these are installed, simply add mdns to the hosts line of /etc/nsswitch.conf and you’re done.
You will now be able to resolve “.local” hosts from your Debian system and also resolve this system’s hostname on other local hosts. By editing /etc/mdnsresponder/mDNSResponder.conf, you can advertise any service you want.
Some days I wish I had way more energy in order to explore all the technology I’m interested in.
How does JXTA figure in relation to JINI?
Dan Creswell’s post about JINI not being RMI brought JINI back to the forefront of my technology todo list. This stuff is cool.
I just read Debian on Soekris HOWTO and was wondering if there are any additional steps one should take to ensure proper functioning of a Debian system running from a CompactFlash card. For example, would logging and other hammering reduce the life of the card in any significant fashion? Is it worth the hassle of going to a read-only root filesystem on the card?
Since my previous posts (1 & 2) about using IPsec in tunnel mode to securely connect multiple networks (I’m up to 17 on the same gateway.), I have needed to add support for “road warriors”.
While IPsec has low overhead, even in tunnel mode, it requires a lot of effort to configure for use by mobile clients. First, we must now assume NATs in the field; whether they are behind the now omnipresent home gateways or on public wireless networks. Secondly, it is my experience that using a VPN system based around bridging has many advantages:
I will elaborate on the routing issues. In our setup, our main gateway connects to 17 remote networks via IPsec. In order for a remote client to access a remote network, both the client and the remote gateway must have the correct routing table.
In light of the above, I decided to use OpenVPN. It fulfills my main objectives: simplicity and security. Correctly setup, OpenVPN will perform verification against both the client and server certificates and uses very strong crypto. To set this up you will need a PKI (Public Key Infrastructure).
My server-side configuration:
ca /etc/ssl/certs/ca.crt
ccd-exclusive
cert /etc/ssl/certs/gw.domain.ca.crt
client-config-dir ccd
client-to-client
dev tap0
dh /etc/ssl/dh2048.pem
float
group nogroup
keepalive 10 120
key /etc/ssl/private/gw.domain.ca.key # This file should be kept secret
local 66.46.199.130
passtos
persist-key
persist-tun
port 1194
proto udp
push "route 10.100.0.0 255.255.0.0"
server-bridge 10.100.0.1 255.255.255.0 10.100.0.90 10.100.0.100
status openvpn-status.log
user nobody
verb 4
My client-side configuration:
dev tap0
remote gw.domain.ca
tls-remote gw.domain.ca
pull
nobind
passtos
float
tls-client
ca ts-ca.crt
cert adam.crt
key adam.key
keepalive 15 45
persist-tun
persist-key
verb 2
Note the tls-remote directive. This is critical to ensuring that the client verifies the identity of the server.
My previous post promised some information about how firewall rules interact with IPsec under Linux 2.6, well here it is.
The Shoreline Firewall has full support for declaratively defining IPsec tunnels and hosts under the new IPsec support. To do this however, you will need the policy match netfilter extension from the Patch-o-Matic NG and also 4 other patches:
While these patches are in the POM-NG, they will not cleanly apply to linux 2.6.9. Ronald Moesbergen was nice enough to port the patches are are available from the list archive.
To apply the patches, simply run patch -p1 < ipsec-* from the top of our kernel source tree. Also copy the policy match extension’s files from the POM-NG directory into your kernel tree and insert the contents of the two .ladd files into the relevant Makefile and Kconfig file. Then reconfigure, enabling the policy match, and rebuild. Then follow the documentation.
If I have time, I’ll try and add some more information here.
Martian Software was talking about NailGun way back in January of 2003 when I emailed them asking about it. I received a message today from Marty Lamb:
If you are receiving this, you have expressed an interest at some point
in a notification when NailGun is available.
Well, it's available.
If it's been so long that you don't remember what it is, NailGun is a
client, server, and protocol for running Java programs within a
persistent JVM, eliminating the JVM startup time. I appreciate your
patience with the project as I have been swamped with other priorities
for some time now.
Although there are no known issues, there is still some work to be
done. Most importantly, I need to compile Windows and OSX binaries for
the client. If you can provide any assistance with this I'd be most
grateful.
More information, a quick start manual, javadocs, and downloads are
available from http://www.martiansoftware.com/nailgun. There's also
information for joining the NailGun mailing list. The fact that you are
receiving this message does NOT mean you have been added to the list.
This is a one-time mailing. If it's unwelcome, you have my sincere
apologies.
- Marty
--
Marty Lamb
Martian Software, Inc.
mlamb at martiansoftware dot com
I’m quite excited about NailGun for use in writing trivial command-line Unix scripts in Java. Going to download it and build a Mac OS X binary while I’m at it too.
Update: Runs nicely on my system, now to explore a bit.
Update: Howtoforge has a good tutorial about setting up “roadwarrior” VPNs using IPsec & KAME.
Since I was unable to find a clear description of setting up an IPSec-based VPN using the native IPSec stack from USAGI and KAME userland tools that are part of Linux 2.6.x, I thought I would post a short explanation.
Software
Network Topology
I am going to explain a very straightforward topology often found in the field. You have two networks, network A (10.0.0.0/24) and network B (10.0.1.0/24). Each network has router/gateway/firewall system, gateway A (10.0.0.1) and gateway B (10.0.1.1). Each of these gateway systems as an external, public, IP address: 3.3.3.3 & 2.2.2.2.
In this topology, our end goal is to allow a hosts on network A, say 10.0.0.123, to securely contact a host on network B, say 10.0.1.158, via an IPSec tunnel.
Note: In many cases, I will provide only a single example. You must ensure the other gateway is configured similarly, often by reversing the configuration. This is left as an exercise to the reader.
IPSec
Setting up IPSec involves two steps: keying and policy. Normally, you use racoon to provide keying and setkey to establish policy. I will instead use racoon-tool as convenient shortcut. This tool was written by the Debian Maintainer of the racoon package in order to emulate some of the nice configuration syntaxt of the FreeS/WAN, an older IPSec implementation for Linux. It dynamically generates a racoon.conf (/var/lib/racoon/racoon.con) and also sets up the policy based on a single configuration file.
First, we simply state that racoon should use the notify priority when sending messages to syslogd:
global:
log: notify
It is helpful to create a %default peer and connection in order to avoid duplication of configuration directives:
peer(%default):
verify_identifier: on
hash_algorithm[0]: sha1
encryption_algorithm[0]: aes
connection(%default):
src_ip: 3.3.3.3
The above src_ip directive simply says that our connections will be using our public IP.
Next, we define our peer, gatewayB, identifying it by address:
peer(2.2.2.2):
peers_identifier: address
Finally, we define a policy so that packets from networkA to networkB are encrypted via gatewayB:
connection(to-gatewayB):
dst_ip: 2.2.2.2
src_range: 10.0.0.0/24
dst_range: 10.0.1.0/24
admin_status: enabled
Unfortunately, I have no idea what the admin_status: enabled directive does, or even whether it is required.
You must also add a key to /etc/racoon/psk.txt for the remote gateway:
# Entry for gatewayB
2.2.2.2 0x2eba016ffc2314869ae9f9a3b8901a173242f0c8
A randomly generated key is best, and can be created with the following command:
$ dd if=/dev/random count=20 bs=1 | xxd -ps
(The xxd command is part of the vim package.)
Make sure that you can the racoon package configured to use racoon-tool by either editing /etc/defaults/racoon or reconfiguring the package. Also, you should probably reload the tool by executing /etc/init.d/racoon reload. You can then check that your policy is in effect by running setkey -DP. You should get something like the following, followed by a bunch of default policies:
10.0.1.0/24[any] 10.0.0.0/24[any] any
in ipsec
esp/tunnel/2.2.2.2-3.3.3.3/unique#16385
created: Nov 18 23:01:24 2004 lastused:
lifetime: 0(s) validtime: 0(s)
spid=1512 seq=9 pid=9800
refcnt=1
10.0.0.0/24[any] 10.0.1.0/24[any] any
out ipsec
esp/tunnel/3.3.3.3-2.2.2.2/unique#16384
created: Nov 18 23:01:24 2004 lastused: Nov 18 23:05:31 2004
lifetime: 0(s) validtime: 0(s)
spid=1505 seq=8 pid=9800
refcnt=1
Now that the policy is in effect, the kernel will ask the racoon daemon for a security association (SA), when it needs to deal with a packet matching the policy. Racoon will negotiate an SA with the remote gateway on the fly. (This will not happen until after we’ve setup the routing, below, but you can see it by using the setkey -D command.)
Routing
In order for a packet to match the policy we have setup, and also be forwarded to the remove gateway, we must adjust the routing table using the ip command (Provided by the Debian iproute2 package.).
The policy we have setup, says that packets coming from 10.0.0.0/24 and going to 10.0.1.0/24 must be encrypted and authenticated. This is achieved by adding a slightly weird entry to the routing table on gatewayA:
$ ip route add 10.0.1.0/24 via 2.2.2.2 src 10.0.0.1
And on gatewayB:
$ ip route add 10.0.0.0/24 via 3.3.3.3 src 10.0.1.1
Once you have added the new entries to the routing tables on both gateways, we test the tunnel. If you ping 10.0.1.0 from gatewayA, and then execute setkey -D, you will see the new SA that has been automatically created.
This is the routing table you should have on gateway “A”:
root@gatewayA:/tmp# ip route show
3.3.3.0/24 dev eth1 proto kernel scope link src 3.3.3.3
10.0.1.0/24 via 3.3.3.1 dev eth1 src 10.0.0.1
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.1
default via 3.3.3.3 dev eth1
Followed by the routing table present on gateway “B”:
root@gatewayB:/tmp# ip route show
2.2.2.0/24 dev eth1 proto kernel scope link src 2.2.2.2
10.0.1.0/24 dev eth0 proto kernel scope link src 10.0.1.1
10.0.0.0/24 via 2.2.2.1 dev eth1 src 10.0.0.1.1
default via 2.2.2.1 dev eth1
In the above examples, 2.2.2.1 & 3.3.3.1 are the default gateways that connect your public networks. (The routers usually provided by your ISP.)
Note: if you have any firewall rules enabled, you are going to have hassles. Notice that the IPSec tunnel doesn’t have it’s own device: the encrypted packets are going through a public interface. This will confuse any firewall rules that expect to be able to categorize packets by interface. I intend to figure out a good solution and post it at a later date.
Update: I now have a fully working IPsec gateway/router/firewall. See this other post.
Update: It seems that when the external addresses of the gateways on are different subnets, which was not the case during my testing, you must add a route like ip route add OTHER_NETWORK via LOCAL_DEFAULT_GW src INTERNAL_IP. Otherwise, you will get an error: RTNETLINK answers: Network is unreachable. Please leave a comment if you can clarify this.
A fantastic quote from Frank Herbert:
Above all else, the [architect] must be a generalist, not a specialist. Experts and specialists lead you quickly into chaos. They are a source of useless nit-picking, the ferocious quibble over a comma. The [architect] on the other hand, should bring to decision-making a healthy common sense. He must not cut himself off from the broad sweep of what is happening in his [application]. He must remain capable of saying “There’s no real mystery about this at the moment. This is what we want now. It may prove wrong later, but we’ll correct that when we come to it.” The [architect]-generalist must understand that anything which we can identify as our [application] is merely part of a larger phenomena. But the expert looks backward; he looks into the narrow standards of his own specialty. The generalist looks outward; he looks for living principles, knowing full well that such principles change, that they develop. It is to the characteristics of change itself that the [architect]-generalist must look. There can be no permanent catalogue of such change, no handbook or manual. You must look at it with as few preconceptions as possible, asking yourself: “Now what is this thing doing?” – From Children of Dune by Frank Herbert (1976)
I love it. Something to keep thinking about. Thanks Grant.