As 2007 enters the final straight it’s time to

look back on the year in which I had three employers, two homes and only one flight.

(more…)

You may recall my terrible trinity of problems.

1. My Windows roaming profile won’t sync when I log out.

2. Windows tells me my password has expired (which it hasn’t) when I log in.

3. I can’t mount a Windows share from a UNIX machine when the Windows server is part of a domain. I can mount a non-domain Windows share, I can mount a Samba share and I can connect to a domain share with smbclient but not with mount.cifs, smbmount or mount_smbfs.

Problem 1 was fixed a while ago. Problem 2 is still a thorn in my side but problem 3 has now gone away.

I decided I’d have yet another look on Google for details of the problem. I got halfway through typing in my search query when I realised I couldn’t remember the error code mount.cifs gave when failing to mount a Windows machine. So I tried to mount from my Linux box.

And it worked.

Then I tried from my iMac. It worked again.

I have no idea why but it works. Maybe Microsoft patched something with a recent Windows fix. Maybe the Samba team patched something in Samba 3.0.28, to which I upgraded only yesterday. Maybe it was Solar flares.

Whatever the reason, I’m happy.

For now.

I finally got round to trying the iCal server again. Previously it was complaining that no virtual host could be found for iCal service. The solution is to create a Computer record in OpenDirectory whose name is the iCal server’s hostname followed by a dollar. For example ical$. It then all magically works despite there being nothing to do with iCal, virtual hosts or anything remotely resembling the error message in this new record.

And where have we seen hostnames followed by dollar signs before?

That’s right. Samba machine accounts.

And what attributes does Directory Utility.app allow us to map for Computer records?

Samba attributes.

Further research could prove interesting.

Oh and by the way the calendar still doesn’t work for reasons I’ll describe once I’ve fixed it.

It appears as though these don’t work.

(more…)

Fedora 8, which I’d installed on my new Mac Mini, ships with Pulse Audio, a network sound system which uses ALSA at the business end and which runs as a drop-in replacement for ESounD.

Unfortunately in true Fedora tradition the initial implementation is somewhat broken. There are no manpages. There’s no init script to launch the sound server as a system-wide service. Non-root users (and if you do enable the system service manually it runs as a non-root user) can’t actually access the hardware because the /dev entries have root-only permissions. And some of the configuration tools aren’t installed by default, though the word on the street is that this has been fixed.

Eventually I managed to get it working.

Device permissions

Running the sound server as a system-wide daemon, which I wanted to do, requires that the user pulse be able to write to /dev/snd/*, /dev/dsp and /dev/mixer. I gave up on a Fedora-approved way and put lines in /etc/rc.d/rc.local to make these 660 and owned by root with group pulse.

Local permissions

The sound daemon won’t allow connections from the local host (and hence won’t be much use) unless you change these lines in /etc/pulse/default.pa. The bits to add are in italics.

    ### Load several protocols
    load-module module-esound-protocol-unix auth-anonymous=1
    load-module module-native-protocol-unix auth-anonymous=1

Network permissions

You can have one sound server for the whole network. This is splendid for me as I can have my virtual machines and audio-less servers using it if necessary. But by default network access is denied. Once again /etc/pulse/default.pa is the file to change.

    ### Network access (may be configured with paprefs, so leave this commented
    ### here if you plan to use paprefs)
    load-module module-esound-protocol-tcp auth-ip-acl=192.168.1.0/24
    load-module module-native-protocol-tcp auth-ip-acl=192.168.1.0/24
    #load-module module-zeroconf-publish

Hardware support

The heavy lifting is done by ALSA. Fedora has nice hardware autodetection and everything Just Worked for me since my Mac Mini’s soundcard was recognised by the HAL module. One thing I did have to do was unmute everything using:

    # alsaunmute

And then save the settings with:

    # alsactl store

Most people probably wouldn’t have to do anything here.

Starting the sound daemon

With no init script (tsk tsk, Red Hat), I had to slap a line into /etc/rc.d/rc.local to start the server on a system-wide basis. It seems Red Hat want users to start the server on-demand. That isn’t what I want at all.

    pulseaudio -D --system

The daemon complained that the user pulse didn’t have /var/run/pulse as its home directory, so I changed that. I also commented out the line trying to load module-x11-publish in default.pa as the server refused to start without an X11 display. YMMV.

Connecting over the network

On other Pulse Audio-aware systems you simply need to edit /etc/pulse/client.conf to reference the sound-playing machine.

    default-server = macmini

Fedora 7 configuration

My Fedora 7 virtual machines don’t have Pulse Audio as Fedora 7 has ESounD. To get things working I had to:

    # rpm -e esound
    # yum install alsa-plugins-pulseaudio
    # yum install pulseaudio-esound-compat
    # yum install puleaudio-utils

With the client configuration mentioned above I was then able to play sounds through the Mac Mini from a virtual machine.

It’s fair to say that I’ve been disenchanted with my Leopard upgrades. My gripes are documented in these very pages. Recently, though, I’ve found some stuff in which Leopard is a real improvement over Tiger.

(more…)