Blog of Annoying Technical Details

So I am here trying to get all of the libs that pidip requires to automatically be included in the Pd-extended.app. Then Pd users on the Mac will be able to stream audio and video out-of-box. I am running into a wall with this lovely tidbit, which seems to be barely documented (hence this blog post of annoyingness):


install_name_tool: changing install names can't be redone for: /Applications/Pd-0.39.2-extended-rc2.app/Contents/Resources/extra/pidip.pd_darwin (for architecture ppc) because larger updated load commands do not fit (the program must be relinked)


Yup, the subject says it all… um, yeah, what the hell does that mean, and why doesn’t it just work? install_name_tool has so far proven to be a wonderful tool for bundling all of the needed dylibs into the .app wrapper. But it looks like this time I have hit a wall.

It looks like the man page holds the key!! For this tool to work when the install names are larger the binary should be built with the ld(1) -headerpad_max_install_names option. Sounds too good to be true, let’s see if it works…

Yup, worked. Nice. Sometimes I think Apple does good work, must be all the NeXT guys they got.

I am trying to break out if good ol’ crappy bourne shell scripting so I am trying a few scripting languages that people are obsessed with. I briefly tried Python, but it was too unfamiliar to me and I wasn’t getting anything done. Now I am trying Ruby.

At Polytechnic, the course scheduling is done using using Excel spreadsheets that are emailed around. This… um… leaves a lot to be desired. So I figure the best way to shed some light on this process is to start scripting the existing ways of working to show people that computers and make things better.

Since I am working with Excel spreadsheets, I should be directly scripting Excel directly. But I am on a Mac, and the required win32ole lib is not there by default. So I have converted the Excel doc to Comma-Separated Value (CSV) format, since it’s a widely understood format.

But it wasn’t that easy. Apparently, Excel considers commas within double quotes to be escaped, while Ruby’s CSV lib freaks out when it encounters this. Here’s an example:

DM ,6043,A,4,,MEDIA ORGANIZATION,”Skelton, Carl”,,3:00 PM

I got this lovely stacktrace from Ruby:

/usr/lib/ruby/1.8/csv.rb:639:in `get_row’: CSV::IllegalFormatError (CSV::IllegalFormatError)
from /usr/lib/ruby/1.8/csv.rb:556:in `each’
from /usr/lib/ruby/1.8/csv.rb:531:in `parse’
from /usr/lib/ruby/1.8/csv.rb:311:in `open_reader’
from /usr/lib/ruby/1.8/csv.rb:85:in `open’
from /Users/hans/scripts/csv-to-ical.rb:27

Removing the ” double quotes fixed that:

DM ,6043,A,4,,MEDIA ORGANIZATION,Skelton, Carl,,3:00 PM

But that leaves a unpleasant taste in my mouth. I thought Ruby was supposed to be amazingly easy and productive. This is not a good sign… Unfortunately, the fun is not over. I removed all ” double quotes, yet I still get the same stacktrace error. Hmm…

it seems to be related to the text format, but that’s strange. As far as I can tell, the text files are in Mac format. It would naturally be better as a UNIX format. But this doesn’t strike me as something that should trip up a CSV parser. Marg… so I converted the Mac OS X linefeeds to UNIX style, and it works. Here’s the line of perl I used:

perl -p -e ’s/\r/\n/g’ unix.csv

Another option is to tell Ruby to expect Mac linefeeds (\r):

CSV.open(‘macosx.csv’, ‘r’, ‘\r’) do |row|

From what I read, Ruby automatically deals with UNIX linefeeds (\n) and Windows linefeeds (\r\n), but apparently not Mac linefeeds (\r). This blog post covers the issue and has some example code snippets:

http://railsforum.com/viewtopic.php?pid=13154

Actually, after all this, I was wrong about the ” quotes. Ruby handles them fine. It was all about the linefeeds \r crap…

What are these mystery ports doing on my Mac OS X server? Hmm… I like to run firewalls with a default allow policy, then only block services that are known to have troubles. That’s how the internet is intended to work, it just that there is a lot of shoddy code out there, so you have all these security issues that can be ameliorated using firewalls.

The only thing I could find about port 9010 is something called Communigate Pro. I don’t know what that is. Port 9010 does seem to understand HTTP… ah ha! It’s part of Apple’s Apache config, listed in /etc/httpd/httpd.conf:


## The default server is used for status on a special port
##
#ServerName www.example.com
Port 9010
Listen 9010


Apache is trustworthy, so I can leave that one open. So back to 1013. Back to the lovely lsof | grep 1013, and that gives me: /usr/sbin/mountd. My guess is that this is related to NFS, so that’ll definitely get firewalled.

Now I look at my other Mac OS X server, and there are more mystery ports. I think this is bad form on Apple’s part:

1010/tcp open unknown
1012/tcp open unknown
1013/tcp open unknown
3659/tcp open unknown
9010/tcp open unknown

Anyway, enough on that topic.

I spent hours and hours trying to find out how to allow multiple users to be able to log into a server and use their automounted home directories. Normally, home dirs are automounted using AFP (rather than SMB or NFS). When one user logs in, it successfully automounts their home dir using AFP. But then the next person who logs in can only get guest access to their home dir, even tho the AFP automount has mounted the whole home root.

The answer was this: using normal logins, the AFP automount will only be accessible to the user who mounted it (by logging in). In order to allow multiple network users to be logged in at the same time, there are two options: NFS and AFP+Kerberos.

NFS is not very secure, and there isn’t a simple GUI way to set it up. But I did that and it works well. The better route in the long run is to get Kerberos working. But that is a massive undertaking on its own.