wiredfool

I suspect that my Jaguar installation has some corrupt fonts, preferences, or both.

Chimera won’t display or choose about half the fonts in the list, sometimes crashing, sometimes just not displaying the choices. Font inspector panels won’t select some of them and keep reverting to Lucida.

An md5sum of all of the fonts in my /Library/Fonts directory compared with another Jaguar machine only shows some missing, but no sig changes. Some of the sigs are the same, leading me to believe that perhaps I’m not getting the sum of all of the items within folder/file structures.

Any Ideas?

***Update

Nicholas Riley writes in that: It’s probably the font cache, not the fonts themselves. Either reboot in OS 9 or in single-user mode and delete the font cache files (all files should include “FCache”).

This appears to have worked to allow all the fonts to be displayed, but it appears that there’s an additional problem in Chimera’s prefs writing system. But that can be fixed by editing the javascript prefs file. (~/Library/Application Support/Chimera/….)

No comments

***IN PROGRESS

Ipsec is now possible on OSX 10.2 with built in tools. It takes a little bit of digging to get it setup, as there’s no gui for it yet.

There are 3 reasonably interesting configurations for ipsec, at least for my use:

• Host to Host – This is mainly a test case, if this doesn’t work then it’s unlikely that any thing else will.
• Host to network – This is a common VPN situation where your machine is using ipsec over the net to communicate with an entire network on the other end. This is your typical connect to the office type of situation. Traffic to other hosts will not be secured.
• Host to gateway – This is for secure wireless connections. Ip traffic between a something just on the other side of an airport hub and my laptop will be encrypted. Essentially, ipsec will be the default transport to the rest of the world. This will allow actual security on the airport network, instead of the joke known as WEP.

Osx uses the KAME ipv6/ipsec stack like most other BSD implementations. Helpfully enough, other people have written some howtows on getting this up and running with FreeBSD, NetBSD, and OpenBSD. I addition to getting ipsec working between Osx hosts, I’d like to get interoperation going with FreeSWAN, the standard linux implementation. These are some good starting links:

• http://www.kame.net/newsletter/20001119/
• http://www.daemonnews.org/200101/ipsec-howto.html
• http://www.freebsddiary.org/ipsec-tunnel.php
• http://www.kame.net/newsletter/20001119b/

Racoon and setkey are the two main programs that will be of interest. Racoon is a daemon that negotiates keys and identity information for ipsec sessions. Config files are in /etc/racoon, and it must be run as root. Setkey deals with policy decisions about which packets are to be sent or recieved with ipsec and which are to be run through the normal ip stack. Setkey needs to be configured before racoon runs, or alternately, racoon needs to be restarted after configuration changes.

Host – host

A basic script for resetting and adding ipsec policies follows. This script requires that traffic between MYIP and REMOTEIP is run through ipsec using the ESP/transport option. It will encrypt the contents of the packets but not the headers. (??) This was slightly adapted from one of the KAME tutorials. Note that this script will need to be run on both ends of the connection, with the MYIP and REMOTEIP values reversed.

#!/bin/sh
MYIP=192.168.1.116
REMOTEIP=192.168.1.126
# These commands need to be run on node A
# The next 2 lines delete all existing entries from the SPD and SAD
setkey -FP
setkey -F
# Add the policy
setkey -c << EOF
        spdadd $MYIP/32 $REMOTEIP/32 any -P out ipsec esp/transport/$MYIP-$REMOTEIP/require;
        spdadd $REMOTEIP/32 $MYIP/32 any -P in ipsec esp/transport/$REMOTEIP-$MYIP/require;
EOF

Racoon’s config files are reasonably close to working as shipped. They will attempt to match identities using a fqdn and a preshared secret key. Since all Jaguar macs will have this shared ‘secret’, it’s a real good idea to change the secret/method to something a little more secure. Preshared keys are stored in /etc/racoon/psk.txt. You can either create them based on ip addresses or on user names. Note that this file needs to remain secret, so it should be root readable only. (chmod 600 psk.txt). If you change to address based shared secrets, you will need to change /etc/racoon/racoon.conf from username to address verification. Look for lines like:

	my_identifier user_fqdn "macuser@localhost";
	peers_identifier user_fqdn "macuser@localhost";

And change them to

	my_identifier address;
	peers_identifier address;

With these changes, ipsec should be ready to go between your two hosts. Run the shell script (as root) on both sides of the connection, then start racoon as root. You will probably want to have console access for this, as it’s possible to configure yourself out of a remote system.

Try pinging the remote machine. Pings should get through. You can verify that the systems are communicating through ipsec by using tcpdump from another machine on the same network segment. (ADD example).

Host – Network

Host – Gateway

FreeSWAN interop

No comments