Handy if you’re trying to unmount volumename and it won’t unmount due to open files.

This command line will get you a list of what’s open, and by what process:

	# sudo lsof | grep /Volumes/volumename

TextMate has a Browser Preview window with the ability to pre-process the editor contents through a script before rendering.

The Sphinx standard input format is reStructuredText as handled by Docutils.

You can install docutils and Sphinx with:

	# sudo easy_install docutils sphinx

To get TextMate to pre-process the reStructuredText properly before display, check the “Pipe text through” checkbox in the Web Preview window and put the rst2html.py into the textbox for the name of the script.

There will be some issues with “Unknown interpreted text role ‘data’” type things but you’ll pretty well be able to see what it’ll look like.

I may explore making this more accurate and flexible but, for now, this’ll do.

Except I had no idea what to do to make a new one and I don’t seem to have written it down last time since it seemed so obvious at the time.

So, here’s the scoop…

To create new repositories:

• Add the project to the gitosis configuration
• Make them writable for the user you want to push as
• Push up the gitosis-admin configuration
• Create a new home for the project
• Initialize it as a git repository
• Copy all your project files into the new repository directory
• Add them all to the git repository
• Commit everything
• Push to the server

For example: let’s assume your username is ‘jdoe’ and you want to create a repository ‘myproject’.

In your clone of your server’s gitosis-admin, edit ‘gitosis.conf’ and add::

  [group exampleproject]
  members = jdoe
  writable = myproject

Commit that change and push the changed gitosis configuration.

    # git commit -a -m "Added new group 'exampleproject' and project 'myproject'"
    # git push

Then create the local repository:

    # mkdir myproject
    # cd mypyroject
    # git init
    # ...copy all your project files in...
    # git commit -a -m "First commit"

Set it up to push to the remote:

    # git remote add myserver gitosis_user@yourserver.com:myproject.git

Do some work, add, commit everything then push it up:

    # git commit -a -m "Putting away before first push to server"
    # git push myserver master:refs/heads/master

That’s it. You now have a new project up on your git server and every time you do a git push it’ll go up.

Quick Google search for:

unix command line tree view of directory contents

Got me to this page where I found this gem:

ls -R | grep ":$" | sed -e 's/:$//' -e 's/[^-][^\/]*\//--/g' -e 's/^/   /' -e 's/-/|/'

Unfortunately, it also includes the contents of the “.git” subdirectory which is less than useful.

Rather than frig around with “ls“ globulation, I decided to do a quick search. I cannot be the first person to need this particular result..

I hunted around for a few minutes and came upon this:

tree

Downloaded and unzipped, modified the makefile to comment out the Linux defaults and uncommented the OS X configuration.

Then a quick:

    # make
    # sudo cp tree /usr/local/bin

Now:

    # tree old-docs

Gives this:

/.../fabric/old-doc/
|-- samples
|   |-- depends
|   |   `-- fabfile.py
|   |-- fabfile.example
|   |-- roles
|   |   `-- fabfile.py
|   |-- simple
|   |   `-- fabfile.py
|   |-- transitives
|   |   `-- fabfile.py
|   `-- variables
|       `-- fabfile.py
`-- site
    |-- api.py
    |-- bin
    |   |-- generate.py
    |   |-- markdown2.py
    |   |-- textile.py
    |   `-- toc.py
    |-- common.css
    |-- community.md
    |-- documentation.md
    |-- download.txt
    |-- fabric-logo.svg
    |-- hacking.md
    |-- index.md
    |-- other-files
    |-- print.css
    |-- programmers_guide.txt
    |-- screen.css
    |-- source.txt
    |-- template.html
    `-- user_guide.md

Perfect!

Squaring The Circle

Squaring the circle is a problem proposed by ancient geometers. It is the challenge of constructing a square with the same area as a given circle by using only a finite number of steps with compass and straightedge. More abstractly and more precisely, it may be taken to ask whether specified axioms of Euclidean geometry concerning the existence of lines and circles entail the existence of such a square.

In 1882, the task was proven to be impossible, as a consequence of the Lindemann–Weierstrass theorem which proves that pi (π) is a transcendental, rather than an algebraic irrational number; that is, it is not the root of any polynomial with rational coefficients. It had been known for some decades before then that if π were transcendental then the construction would be impossible, but that π is transcendental was not proven until 1882. Approximate squaring to any given non-perfect accuracy, on the other hand, is possible in a finite number of steps, as a consequence of the fact that there are rational numbers arbitrarily close to π. The expression “squaring the circle” is sometimes used as a metaphor doing something logically or intuitively impossible.

Only thing is that, even if you clean up a hard drive so there’s less to backup, the .sparseimage files never shrink to reflect the reclaimed space.

To reclaim space, just make sure the image is not mounted, pull up a terminal window, and:

hdiutil compact /the/path/to/your.sparseimage

This will squish all the air out of the sparseimage bundle.
Make a backup first, obviously, and make sure there's enough room on the drive to make a copy of the image since I'm pretty sure it works by making a copy, then deleting the original.

Posted in OS X Tools         ]]>
			http://ssteiner.wordpress.com/2009/05/05/compress-sparseimages/feed/
		0
	
		
			ssteiner
		
	
		
		
		http://ssteiner.wordpress.com/2009/03/07/moving-a-gitosis-setup/
		http://ssteiner.wordpress.com/2009/03/07/moving-a-gitosis-setup/#comments
		Sat, 07 Mar 2009 23:41:35 +0000
		ssteiner
				
		
		

		http://ssteiner.wordpress.com/?p=126
		]]>
			We’ve done a server shuffle here and now that the dust has settled a bit, I’ve got to get out Gitosis repository back online.

To make things more interesting, I also changed the name of the user under which the whole setup is running.  Long story short; create a user in cPanel to be your Gitosis user rather than creating just a unix user with useradd so that the user can be moved etc. using the handy cPanel tools.  My original user almost got stranded on the old server since he didn’t show up in any of the cPanel tools I was using to move hosting accounts.
So, on the new server (as per the old post :
	# cd /usr/local/src
	# git clone git://eagain.net/gitosis.git
	# cd gitosis
	# python setup.py install
	Traceback (most recent call last):
	  File "setup.py", line 2, in
	    from setuptools import setup, find_packages
	ImportError: No module named setuptools

I downloaded ez_setup.py from the Peak website and than try to remember anything about how to set it up, I just took the two lines at the top of ez_setup.py and stuck’em into the gitosis setup.py per the instructions at the top of ez_setup.py and reran setup.py.

When I moved servers, I created a cPanel user with a new name, git_new, different from the one on the old server and copied all the Gitosis stuff into their home directory.

The trick is to get the gitosis setup to recognize everything in its new home and getting at it from my local machine.  I’m not comfortable manually twiddling any of the files in the git setup since I’m not 100% sure what’s what so I’ll start by trying to checkout the Gitosis configuration to my local work area.

Since I’ve already created the user in cPanel, I’ll have to figure out how to make sure they’re not able to login by password but for now, I’m just going to get gitosis installed and initialized.

Before I do anything crazy, I’m going to make a quick copy of my original repositories.  They’re in /home/git_new/repositories so I just quickly make a backup with:
	# cp -r /home/git_new/repositories /home/git_new/repositories.2009.03-06.bak


I always put the date in backups so that I know when I was messing with something.  File dates are unreliable since file changes change dates and it’s not easy to see when something was created.  This keeps things straight with very little effort.

I copied my id_rsa.pub key from my main machine up to the /tmp directory on the new server and ran:
	# sudo -H -u git gitosis-init < /tmp/id_rsa.pub


I got an error doing this because the /home/git_new/gitosis directory wasn’t owned by the git_new user but after fixing that up with:
	cd /home/git_new
	chown -R git_new:git_new gitosis repositories

everything went fine.  I fixed the user on /home/git_new/repositories while I was at it, btw.

Now rerunning the gitosis-init works just fine printing out the “Reinitializing…” message twice as documented.

Unfortunately, the original instructions used the –disabled-password switch on adduser which can’t be used here since the user was created through cPanel and neither cPanel’s Password Modification or the command line passwd utility can set a disabled password.

After poking around for a while, I finally just dumped the contents of /etc/shadow and saw that, for all the usually disabled accounts, the shadow password was set to !!.  I manually edited /etc/shadow, poked in that password, and off we went.

This leaves the user unable to login via password, but they can still login using an ssh key which is exactly what we want.  According to shadow(5),

If the password field contains some string that is not valid result of

crypt(3), for instance ! or *, the user will not be able to use a unix

password to log in, subject to pam(7).  There are some intricacies and stupidity in the exact configuration and who can login which way but we don’t need to go there for this purpose.

NOTE: You can also globally disable password authentication in the ssh server but that’s not what we needed here either.
The next step, following my own instructions, is to attempt to clone the configuration repository with: 
	# git clone git_new@my.hostname.com:gitosis-admin


resulting in:
	fatal: protocol error: bad line length character


Fooey.
Googling around lead to the Git FAQ entry on that error.

Following the instructions there, I just tried ssh’ing in as the user to execute a simple command with:
	# ssh git_new@my.hostname.com echo testing commands
	Shell access is not enabled on your account!


I had forgotten to enable shell access on the account (it’s off by default in my cPanel setup since it’s a security risk and so few hosting clients actually need it).  If I had gotten stucker I would have used ssh’s -v parameter to get verbose output to see where things were falling down.
I went into cPanel and enabled shell access for the account and voilà, out came my stuff!
Since I left my repositories in place in the /home/git_new/repositories directory I was hoping to just be able to check them out normally.
I always create a test repository, available to everyone who has any privileges on any repository, so that we can quickly establish connectivity to the server before messing around with specific privileges on any particular project.
So, the quickest test for a new repository is to just try:
	# git clone git_new@my.hostname.com:test


And, since it hadn’t clobbered any of my original settings when I reinitialized gitosis, I’m right back in business!
NOTE: Just for fun, I tried to use some of my checkouts from the old repositories, just to see how hard it would be.  A simple git pull or git push didn’t work and failed in a strange and not worth repeating sort of way.
Just edit the checkout’s .git/config and change the [remote "origin"] section’s url variable to the current user name and repository hostname and everything seems to work perfectly.

Posted in Git, Linux Server Stuff, Version Control         ]]>
			http://ssteiner.wordpress.com/2009/03/07/moving-a-gitosis-setup/feed/
		1
	
		
			ssteiner
		
	
		
		
		http://ssteiner.wordpress.com/2009/03/06/python-path-and-pth-files/
		http://ssteiner.wordpress.com/2009/03/06/python-path-and-pth-files/#comments
		Fri, 06 Mar 2009 16:59:53 +0000
		ssteiner
				
		

		http://ssteiner.wordpress.com/?p=124
		]]>
			So…I have a django app I’ve been running on one of our old servers for a while and it’s time to move the client off to one of the new servers.

cPanel’d the account over, no problem, application moved with it, no problem, only the app won’t run.
To make a long story short, couldn’t figure out why sys.path() wasn’t returning my current directory whereas it was on the old server.
Turns out I had added a .pth file to /usr/local/lib/python2.4/site-packages/. 
This time, however, I left myself a note here and in the application directory so I wouldn’t forget.
Oh, also remember to unblock the port in the firewall and restart the firewall.

Posted in Linux Server Stuff, Python         ]]>
			http://ssteiner.wordpress.com/2009/03/06/python-path-and-pth-files/feed/
		0
	
		
			ssteiner
		
	
		
		
		http://ssteiner.wordpress.com/2008/12/30/git-subprojects/
		http://ssteiner.wordpress.com/2008/12/30/git-subprojects/#comments
		Wed, 31 Dec 2008 03:27:40 +0000
		ssteiner
				
		
		

		http://ssteiner.wordpress.com/?p=120
		]]>
			Subprojects with Git
I’m working on a fairly complex piece of OS X software right now; lots of moving parts.
I also have several elves working on these various parts.  The parts are very well isolated from the main project in a plug-in-y sort of way.
The main project has some kinky dependencies that I really don’t want to have to help someone set up and there’s no real reason to.  In the final build, it’s all there.
I’m paying them to help with the parts they’re good at, not dick around with installation and configuration and such.
This also means that each independent piece has to have its own completely separate test application/suite that demonstrates the component’s functionality while remaining completely uncoupled from the main app.  
All is as it should be.
Except for the version control part.  
Each component has its own Git repository, and every developer working on the component can check out the whole component’s repository.  No problem.
Except that I’ve also got to be able to check out their work into my build tree to make the whole product.
Git Subprojects to the Rescue
I just picked up The Pragmatic Programmers’ Pragmatic Version Control Using Git.  Haven’t had much time to get into it yet but I did jump on the chance to celebrate their 5th anniversary with a 30% off coupon.  Congratulations to them, they really do publish some fine books and they deserve all their success.
Chapter 8, “Organizing Your Repository” has a section on using Git’s submodules feature to track external dependencies.  These will be familiar to Subversion users as svn:externals.
Creating a Submodule
To illustrate, let’s just create a whole new structure starting with the root of the project.
	# cd ~
	# mkdir projectRoot
	# cd projectRoot
	# git init

Pretty straightforward.  Make a subdirectory, initialize the git repository in it.
I’m going to follow the book here since there’s already a public repository out there and it’s not like a million people are going to read this drivel and rush out and knock github over.
	# git submodule add \
			git://github.com/tswicegood/hocus.git \
			hocus

This creates the submodule hocus under projectRoot.  What is not particularly clear is that this initializes the submodule to track the current HEAD of the external repository.  It stores the revision number of the head in a configuration file called .gitmodules which you’ll add and track with the repository.
Unlike subversion, the submodule is bound to a particular revision within the external repository and will not follow the repository when modifications are made to it
Running the git submodule command will give a hint of that but it’s not that obvious, especially if you’re used to Subversion’s behaviour.
	# git submodule
	-20cc9ddc65b5f3ea3b871480c1e6d8085db48457 hocus

This shows that there’s a single submodule and will show a ‘-’ sign next to it in the listing since it’s not been initialized.
To get it fired up:
	# git submodule init hocus

That will register the hocus submodule.  
To actually pull the contents of hocus, at the revision at which you ran submodule add, into the hocus subdirectory:
	# git submodule update hocus

It is possible to change the commit to which the submodule is bound but that’s for another day (or buy the book!).
There’s a really good (and fast!) overview of this process and the intricacies of checking out a new copy of a project with submodules at the Rubaidh Ltd. blog.

Posted in Git, Version Control         ]]>
			http://ssteiner.wordpress.com/2008/12/30/git-subprojects/feed/
		0
	
		
			ssteiner
		
	
		
		
		http://ssteiner.wordpress.com/2008/12/29/transmit-favorites/
		http://ssteiner.wordpress.com/2008/12/29/transmit-favorites/#comments
		Mon, 29 Dec 2008 15:53:49 +0000
		ssteiner
				
		

		http://ssteiner.wordpress.com/?p=114
		]]>
			I was working on syncing my laptop with my desktop in a ‘deeper’ sort of way this morning as things have gotten a bit random with all the new apps I’ve been installing (1Password rocks!).

I went into the .Mac sync panel (MobileMe just makes me want to puke) and the Transmit favorites weren’t there to sync.  
A quick visit to the Panic site yielded this:
I no longer use Transmit. How can I remove Transmit from my .Mac Sync preferences?

	 Awkwardly, Apple doesn’t provide a way to remove these items. But, if you’re running Transmit 3.5.1 or newer, type this into Terminal:
# ~/Library/Application\ Support/Transmit/TransmitSync.app/Contents/MacOS/TransmitSync --unregisterClient

That should remove Transmit from the list.
Well, I figured that, since I had the opposite problem, I should just remove the ‘un’ from the –unregister… and that’d do it.
Did.  Yay.

Posted in OS X Tools         ]]>
			http://ssteiner.wordpress.com/2008/12/29/transmit-favorites/feed/
		0
	
		
			ssteiner