After a short embarrassment with SSH I decided I needed a bit of xtermcontrol functionality. On the rest of my machines, I use it to automatically switch to a green background when in an SSH session among other things.

As a complete newb, AppleScript syntax is a bit confusing. The idea is clear, the implementation seems somewhat awkward (particularly since I saw no way to dynamically determine properties.) So I chose to use the rb-appscript abstraction, installed through Gems. It enables accessing a high-level AppleScript-equivalent in Ruby. With this, I created the initial frail and simple draft:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# ~/Scripts/iterm.rb

require 'rubygems'
require 'appscript'

include Appscript

# Map some values or just pass-through
def expand(property)
  case property
  when 'bg'
    'background_color'
  else
    property
  end
end

include Appscript
app('iTerm').current_terminal.current_session.send(expand(ARGV.first)).set(ARGV.last)

This allows, for example, changing the background color with `ruby ~/Scripts/iterm.rb bg blue` etc.

To hook it up, I set up a function in my ~/.bashrc.osx (which is sourced in ~/.bashrc obviously):

1
2
3
4
5
6

  ssh() {
    ruby ~/Scripts/iterm.rb bg blue
    command ssh "$@"
    ruby ~/Scripts/iterm.rb bg black
  }

Obviously a lot of room for improvement but it just wraps any ssh invocation by first changing the bg, then launching ssh itself with whatever arguments were given and then switching back when ssh exits (whether requested or through an error.)

Gives me a nice blue background to easily distinguish ssh sessions among my terminals. This is exceptionally handy to use for su sessions if you use those. It is much harder to accidentally leave a bright red terminal session running than a regular-looking one. (I always only use sudo anyway, but not everyone does.)

Spaces is nice to have on OS X—it is just the concept of workspaces moved to Aqua. The only problem with it is that it relies heavily on the mouse/GUI side of things. You can switch workspaces easily enough with Cmd + number but moving windows around is a bit trickier. The least inconvenient way of doing this is to click on the desired window and while keeping the mouse button pressed, use the Cmd + number for the desired workspace. Hopefully next update will allow something like Shift + Cmd + number to move the currently focused window.

If you need to add a secondary IP or an IP alias to a network interface on Mac, you are in the same situation I was just a moment ago. In the interest of posterity, I am documenting my exploration of Macistan when I encounter something that seems interesting or divergent.

Note that if you are setting up something using a second network interface, this does not apply. You can just set it up normally. My network is rather strange: I have it set up so that the normal operation is through an “intranet” LAN connecting through a router/DNS and firewall but there is also the option of connecting directly using ISP DHCP—still passing through the firewall of course. Because I want to have the internal IP available regardless of external mode, it is set as an alias on each interface for the latter times.

All respectable people would of course first want to just use `ifconfig` to accomplish aliasing but since on a Mac it is more of a wrapper, this task is best done through System Preferences’ Networking pane.

1. Unlock and authenticate. (You never leave those little locks open, do you?)
2. Select the current connection you want the alias for
3. Click the cogwheel and Duplicate Service
4. Give it a sensible name such as “Intranet IP ()”
5. Set Configure to Manual
6. Input the proper values for your setup (only the IP and Subnet Mask are really necessary)
7. Lock the pane

Hurray!

I managed to install OS X on my new ThinkPad x61! Full 10.5.2, I do need to install a couple other packages to get full power management and ethernet still, though, but that is a job for tomorrow.

Poor-quality pics: outside and with its big brother.

I have like, totally NOT added my notes about the installation to this excellent thread that got me started. So if you are planning something like this, you should probably not look there.

Anyone?

Seriously, anyone?

I can find internal DVD readers and external CD readers and external DVD/CD read/writers but not plain external DVD readers. It boggles the mind.

headius often kindly tries to get me to actually overcome my lingering Java allergies to try to run JRuby and now my excuse of FreeBSD amd64 not being Java-friendly has been stripped away.

In reality JRuby of course is a great project running a pretty impressive platform, the JVM, so this should be an interesting experiment. headius suggested using the SoyLatte version of JDK/JRE and looks like not without cause. It is an implementation of Java 6 based off the BSD port. So, steps taken:

1. Java
   1. Downloaded the amd64 binary from the Soylatte site (Intel Core 2 Duo is, oddly enough, kind_of? amd64—EM64T to be precise)
   2. The directory needs to be extracted somewhere, I chose /opt/local
      1. `cd /opt/local`
      2. `sudo tar xjvpf /path/to/tar.bz2`
      3. `sudo mv long_name soylatte16`
   3. Set the Java environment variables (these go in my ~/.bashrc)
      1. export JAVA_HOME=/opt/local/soylatte16
      2. export PATH=/opt/local/soylatte16/bin:$PATH (front to make sure it overrides system JREs)
      3. I wanted to try NetBeans which expects certain paths: `ln -s /opt/local/soylatte16 /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home`
2. JRuby
   1. Downloaded the 1.1b binary package
   2. Extracted in /opt/local again
      1. `cd /opt/local`
      2. `sudo tar xzvpf /path/to/tar.gz`
      3. `sudo mv long_name jruby`
   3. `export PATH=$PATH:/opt/local/jruby/bin` to make it visible, ~/.bashrc again
3. Pick up the new envs: `source ~/.bashrc`
4. Test: `jruby -v`
5. Hooray!

Now to see if I can come up with something sensible to use this for.

Looks like this may change in the future, but for now setting your hostname on Leopard is easiest with these two steps:

1. `sudo vim /etc/hostconfig`
   1. Add @HOSTNAME=”machine.domain.tld” somewhere
2. `sudo hostname machine.domain.tld` sets it for the current session so you do not need to restart etc.

The System Preferences > Sharing and Network have some options but I got tired of twiddling with them.

Colour me paranoid; at least based on my web searches OS X users do not seem to suffer from the same aversion to always running under the Administrator account. The first thing I did when I realised that this was in fact the case was to create myself a new Standard account and then assign a better password to the Administrator account that was so helpfully created for me.

OS X does a good job facilitating running as Standard to a point: any time I need admin privileges, I am asked to authenticate as any of the local Administrator users which works pretty well in the GUI. However, I cannot sudo at the terminal as a Standard user so I needed to fix that. By default, the root account is disabled which is frankly a rather silly precaution since any Administrator can use sudo anyway (at least it was not made NOPASSWD.) Here are the steps:

1. Enable root
   1. Run Directory Utility in /Applications/Utilities/ (or through Finder)
   2. Click the lock and authenticate if necessary
   3. Menu, Edit > Enable Root User
   4. Menu, Edit > Change Root Password (make this something long and different from your Administrator password)
   5. Click the lock to relinquish privileges
2. Configure sudo
   1. Open up a terminal session
   2. Switch to your Administrator account: login <admin unix name>
   3. To edit the sudoers configuration file, use visudo (despite the name, it does respect EDITOR): sudo visudo. You will already have a default file in place with commented sections.
   4. Look for the Defaults section and add yourself a few options by inserting a line like this (substitute ‘joe’ with your username): Defaults:joe runaspw, passwd_tries=3, timestamp_timeout=3. The first part specifies that the default only applies to that user (there are group etc. versions too), runaspw means whoever invokes sudo must enter the password for the user account being accessed (you could make this rootpw instead if you prefer) and the rest means that 3 invalid attempts terminate the sudo attempt and that any successful sudo@ authentication persists for 3 minutes without having to re-enter the password. Use the latter ones with normal caution and not at all on publically accessible machines.
   5. Under User Privileges (you already see root and %admin there), add a line for yourself: joe ALL=(ALL) ALL. The syntax may look a bit cryptic but the first ALL designates machine IPs this applies to, the (ALL) specifies the user the command can be run as (given with the -u@ flag or guessed) and the last ALL is the set of commands that the user can run with this particular privilege setting. If you are adding programs explicitly instead of giving the ALL privilege, make sure to use full paths to avoid using a fake location.
   6. Look at man sudoers for further details.
   7. Save and quit
3. Disable root login
   1. login <admin unix name> if you closed the session
   2. su
   3. chpass (Leopard correctly updates DirectoryService with chpass)
   4. Caution: double-check the paths before entering
      1. Change Home Directory to /var/empty
      2. Change Shell to /sbin/nologin
      3. Save and quit
   5. ^D
   6. In your sshd_config, PermitRootLogin no. Also consider just using key-based authentication
4. ^D
5. Test it: sudo echo 'hi'

If you ever should need to enable root logins, you can still do sudo chpass.

That should be all! Now you do not need to separately su or rely on the sudo capabilities of your Administrator user.