The Holy Grail (3/3): Blind luck saves the day

Filed under: Geekiness — iain @ 11:53:35

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.

iCal server starts up now!

Filed under: Geekiness — iain @ 11:48:23

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.

LDAP netgroups in Leopard

Filed under: Geekiness — iain @ 11:43:42

It appears as though these don’t work.



Pulse Audio

Filed under: Geekiness — iain @ 15:30:32

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=
    load-module module-native-protocol-tcp auth-ip-acl=
    #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.


AutoFS and NFS improvements in Leopard

Filed under: Geekiness — iain @ 10:45:12

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.



The case of the missing GID

Filed under: Geekiness — iain @ 08:53:42

Cfengine crashed with a bus error on my now-rebuilt MacBook Pro. The exact same binaries used to work under Tiger and continue to work on the other Leopard Macs. Something was awry.

I ran cfagent under gdb and got a backtrace of the crash. The problem appeared to be in MakeGidList() which was called from a copy rule with parameters

    owner=root group=root mode=444

Stepping through the function I found that the GID returned from getgrnam("root") was not 0 as you would expect but some garbled number which caused the crash when it was processed further on.

This was a bit of headscratcher until I remembered another rule which cfagent runs.

      ActionSequence = ( shellcommands )

      dscl = ( "/usr/bin/dscl localhost" )
      dscl_local = ( "/Local/Default" )
      dscl_local = ( "/NetInfo" )

      HasRootGroup = ( ReturnsZeroShell(${dscl} -list ${dscl_local}/Groups/root &>/dev/null) )

      "$(dscl) -create $(dscl_local)/Groups/root" useshell=false
      "$(dscl) -create $(dscl_local)/Groups/root PrimaryGroupID 0" useshell=false
      "$(dscl) -create $(dscl_local)/Groups/root GroupMembership root" useshell=false   
      "$(dscl) -create $(dscl_local)/Groups/root Password \"*\"" useshell=false
      "$(dscl) -create $(dscl_local)/Groups/root RealName \"System Group\"" useshell=false
      "$(dscl) -create $(dscl_local)/Groups/root SMBSID S-1-5-21-100" useshell=false

On OS X the group with GID 0 is wheel. My cfengine rules assume that the group root exists with GID 0 and the above snippet will create it if it can’t be found. This then allows my copy rules to say group=root and have it work on multiple operating systems.

My problem was a typo in one of the lines. What I’d actually got was:

      "$(dscl) -create $(dscl_local)/Groups/root PrimaryGroupId 0" useshell=false

PrimaryGroupId is not a valid attribute in the eyes of DirectoryService. PrimaryGroupID is but that one typo had led to the root group being created with an undefined GID. Hence when cfagent tried to determine which GID to use for group root it got horribly confused and died.

cfagent is now working properly after I deleted the group and ran the corrected rule to replace it.


Well, arse

Filed under: Geekiness — iain @ 18:15:09

So the reason I couldn’t reinstall Tiger on my laptop was not because the failed Leopard upgrade had broken my filesystem but because I was using the DVD which came with my iMac and not the one from my MacBook Pro.

Which means I erased the filesystem and lost files for nothing.

How kind of Apple to explain why the installation couldn’t proceed. How nice of them to say "Sorry but this DVD can only be used to install OS X on an iMac."

Oh, wait. They didn’t say that.

They didn’t say anything at all. Just "bugger off; OS X not yours."

I am very, very upset about this.

Leopard installed

Filed under: Geekiness — iain @ 08:35:33

Rebecca’s Mini now has Leopard. The install went flawlessly, unlike that of my MacBook Pro (end result: dead laptop) and my iMac (two lockups and a bunch of trashed settings).

After the bad experience with LDAP on my iMac I half expected the Mini to refuse to allow me to log in.

I should have been fully expecting it.

Luckily I was able to ssh to the machine as I’d put a DSA key in /var/root/.ssh/authorized_keys. I was then able to create a local admin user so I could log on at the console and repair the LDAP settings with the GUI. Once again "repair" means delete and add again as there was nothing wrong with them.

If you’re wondering why I didn’t have a local account it’s simply because I had renamed it to maling some time ago when I was playing with NetInfo (now obsolete, of course) and then deleted it when the machine became LDAPped.

    dscl localhost -create /Local/Default/Users/admin
    dscl localhost -create /Local/Default/Users/admin PrimaryGroupID 20
    dscl localhost -create /Local/Default/Users/admin NFSHomeDirectory /Users/admin
    dscl localhost -create /Local/Default/Users/admin UniqueID 501
    dscl localhost -create /Local/Default/Users/admin UserShell /bin/bash
    dscl localhost -append /Local/Default/Groups/admin GroupMembership admin


More Leopard woes

Filed under: Geekiness — iain @ 23:23:21

The lustre is starting to wear off Apple for me.

In the past I used to absolutely despise Macs. This was in the pre-OS X days. I despised them for one simple reason. They were rubbish. Then with OS X they were suddenly pretty good. They look pretty, they’re stable and they’re easy to use. Hurrah for Macs.

Until they go wrong and you get stuck. Or until an OS upgrade breaks things in fundamental ways.

Mark arrived back from the US with the Mac Mini I’d asked him to bring me back. I wanted it for two reasons. One: to replace my Linux workstation which is a Pentium 4 with RAMBUS (cost price, adjusted for inflation, about £6.02×1023 in today’s money) and is way too hot and noisy for my front room. Two: to get the Leopard workstation CD as I only have the server install.

Installing Linux on the new Mini could wait. My first goal was to upgrade my MacBook Pro and Rebecca’s Mini to Leopard. The laptop was first.

I popped the Leopard upgrade DVD into the drive and booted the machine. Yes I want to do an upgrade install. Off we go.

"The install failed."

That’s what it said. Nothing at all in any way helpful about why the install failed or what could be done. It failed. That’s that. Have a nice day.

So I rebooted to try again. Then the installer said it couldn’t find OS X 10.4 and hence couldn’t start the upgrade.

Say what? It was there ten minutes ago. What did you do?

I rebooted again with the 10.4 installer.

"The software cannot be installed on this computer."


I erased the OS X partition. I know for a fact that there are files on that that don’t exist on the network because of the way profile syncing works. They’re gone now. And still the thing "cannot be installed" for no reason it would care to divulge.

I haven’t had this much fun installing an OS since NetBSD trashed my partition table and I spent an hour or two with a shell script for-loop guessing at fdisk commands to restore it.

At least I can still boot into Windows. Leopard is currently installing – quite happily – on Rebecca’s Mini. I’ll decide what to do with the MacBook Pro later.

All this comes after my iMac locked up … again … for no reason … again and, after rebooting, decided that it would ignore my LDAP bindings … again. It also wouldn’t mount my home directory but that turned out to be the NFS server’s fault, and then wiped out my Terminal preferences proplist, which didn’t.



The Holy Grail (1/3): Correlation does not imply causation

Filed under: Geekiness — iain @ 22:20:01

Don’t be in a hurry to read parts 2 and 3. This series is called the Holy Grail for a reason. I’ve been struggling with three Slightly Annoying Samba problems for what seems like forever; going on for a year in the case of this particular issue. The bugs were these:

  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.

Finally, today, I got to the bottom of the roaming profile sync.


Previous PageNext Page

Powered by WordPress