Skip to content

quick MacOS VNC and Subversion fixes

Just a quick couple of notes in this post. Two problems sucked a few hours of time this week, so it seems reasonable that they get pushed somewhere more visible for those with the best of Google-fu... connecting to a Mac VNC server from Linux and a weird "authorization failed" bug/oddity in subversion.

Connecting to MacOS X VNC from Linux

VNC is pretty fun and useful for remote-connecting machines. One particular usage that has served its purpose is solving a "my computer is broken" call from parents or siblings, inspired by VNC over SSH and SSH port forwarding to avoid those pesky firewalls. Connecting as a client from a Mac, Chicken of the VNC seems to work with little/no fuss for every scenario I had tried. Sure, there are other packages out there, but why use a commercial one that requires installation if something else is open-source and works fine?

For some reason the "screen sharing" option in OSX seems to return some faulty version information or it just doesn't do a good job of negotiated color depth, etc. The result is that if you try to connect to a machine running the OSX version of VNC named Apple Remote Desktop or Screen Sharing in 10.5.7 (and earlier), the session you open will immediately close. Running VNC Viewer Free Edition 4.1.1 from a Debian distro, this error presented itself. No option on a GUI (i.e. the Terminal Server Client GUI) would work, as it requires the command-line option below (mandating the use of 32bit color).

vncviewer --FullColor=on

Of course, after you make this change and get VNC to work on your linux client, you may realized that it takes a *lot* of bandwidth to get a fluid response, which for me just wasn't worth it in the end.

Here's the original thread that eventually shed light on the subject... VNC Thread

I have to start vncviewer with --FullColour=on, else it terminates without showing the display. I think this means it's using 32 bpp, even though I've configured the Mac to use "thousands of colours" (i.e. 16 bpp) in its display settings dialog, so it is wasting half of its network bandwidth.

Subversion rejects check-in with "Authorization Failed"

Another second annoyance was the sudden rejection of SVN check-in actions. If you had a nice, healthy repository that permitted the check-in or update of your tree and suddenly you're getting rejection notices you might have the same problem:

localhost:cuzero quinone$ svn ci localtest 
emz@'s password: 
svn: Commit failed (details follow):
svn: Authorization failed
svn: Your commit message was left in a temporary file:
svn:    '/private/tmp/temp1/svn-commit.3.tmp'

Although the error itself is of no help, it's easy to confirm that you have this problem...

  • you're using ssh+svn:// to access your repository
  • you can ssh into your server without problems
  • you can 'checkout' or 'update' your local copy without problems
  • when you try to commit you get this ambiguous error.

Fortunately, there is a one line fix. Just add the line below to your "/your/repo/dir/conf/svnserve.conf" file.

anon-access = write

Assuming you already have unix permissions correctly configured to restrict access to that repo directory, you shouldn't need to have explicit users defined in your svnserve file. Thus, you can allow anonymous write access, which is granted with the above line. Here's a Subversion fix post that was found after a few hours of digging. It is still puzzling as to why this line was suddenly needed and all but the last possibility has been ruled out: change in SSH server, change in authorization technique (i.e. switch from NIS to Kerberos), upgrade to subversion (does this matter?), local changes on the client due to version/other repo action, a foreign hack, albeit fairly non-malicious.

Post a Comment

Your email is never published nor shared. Required fields are marked *