I’m not saying those were faked or anything… but they sure were misleading.

To bust apart your master lock, you’ll need a hammer, a flathead screwdriver, a strong pair of pliers, a good pounding surface, and 15 minutes.

Assuming your lock looks like mine, on the back you’ll find a nice little steel lip. Pound the flathead down under that.

Pound forward so that you can get the flathead under the front dial. It’ll pop right off.

Under the dial there’s a thicker piece of protective steel. Choose a good spot and pound through it using the flathead. Pry up a lip and pull it back with your pliers. The insides of the lock will kinda just dissolve and fall out. Give the lock a tug and bam! Your lock is open.

Here’s the edits I needed from a default install xorg.conf:

1. Make a backup of your current xorg.conf
2. Remove the “Generic Mouse” section. You don’t need it anymore.
3. Add a section for your touchpad like so:

   Section "InputDevice"
     Identifier  "Synaptics Touchpad"
     Driver      "synaptics"
     Option      "SendCoreEvents"  "true"
     Option      "Protocol"        "auto-dev"
     Option      "Device"          "/dev/psaux"
     Option      "SHMConfig"       "true"
   EndSection
   

4. And add a line in your “ServerLayout” section referencing your new synaptics section. I didn’t have a ServerLayout section so I had to add one, mine looks like this:

   Section "ServerLayout"
     Identifier  "Default Layout"
     Screen      "Default Screen"
     InputDevice "Generic Keyboard"
     InputDevice "Synaptics Touchpad"
   EndSection
   

Now save everything you’re doing and then restart X11 by hitting cntrl-alt-backspace. If X won’t start back up, you can hit cntrl-alt-f1 and log in at a command prompt, restore your xorg.conf from the backup you made earlier, then run /etc/init.d/gdm restart.

In the event that things just aren’t working, your friend is /var/log/Xorg.0.log. That log file contains the results of your x-server’s parsing of your xorg.conf.

You must create a password for your account. This means that your password:

• Must contain 7 to 14 characters.
• Must contain at least one lowercase letter.
• Must contain at least one uppercase letter.
• Must contain at least one number.
• Must begin with a letter.
• Cannot contain the user name.
• Cannot contain the following characters: question mark, space, caret, single quote, double quote, colon, backslash, dollar sign, ampersand, greater than, less than, tilde, semi-colon, or accent.

The result of these kind of password requirements is that your user has to come up with a new password, or a new variation on one of their existing passwords, just for your site.  Now in the perfect world, users would have a unique password for everywhere on the internet they have a login.  There are programs out there to help users do that.  But guess what.  People don’t use them.  For some good reasons too – like now a copy of your passwords, one way or another, are being stored somewhere that isn’t your brain.  Which is the whole idea – your password is something that only you can produce and you can do so anywhere anytime you need to.

So in reality, your users likely have somewhere between 10 and 100 logins across the internet. If they’re forced to try to remember a special username/password combo for your site – they won’t. They’ll write it down, and stick in their wallet. Or in the drawer next to their desk. Or in a plaintext file on their desktop. Which is about as secure as, well, putting something yummy in the snack room with a sign that says ‘yummy’.

When a hosting provider like GoDaddy does this kind of bad practice, it isn’t that big a deal. It just makes their FTP user base more likely to be compromised. Now when your bank does it (I believe all my banks do it at one level or another) it’s serious. This isn’t helping the security problem – it’s just passing the buck. Even though this makes the average user more vulnerable to attack, that’s no longer your bank’s fault. It was you who didn’t safely guard your 7 different usernames, 3 levels of passwords, and up to 5 variations on those different passwords for your various logins across the internet.  That’s what I’m up to: 7, 3 and 5. Now soon to be 6.

As a user, what do you guys use to manage all your usernames/passwords?  As a developer, what kind of restrictions do you apply for your users’ passwords and/or usernames?  Do you know of any standard set of password restrictions, or any standard algorithm for computing what constitutes a ‘good’ or a ‘weak’ password?

1. Set up a domain and directory. This where your Rails installation will live.  DreamHost’s preferred method of running Rails is now officially with Passenger (aka mod_rails) which they have on all their Apache 2 servers. You can use the DreamHost admin panel to set this up: go Domains->Manage Domains->Add New Domain/Sub-Domain and make sure to check off on “Ruby on Rails Passenger (mod_rails)”. If you plan on making ~/path/to/rails/root your root directory for your Rails installation, then you need set the web root directory to ~/path/to/rails/root/public when you add this domain using the DreamHost admin panel.

2. Set up a database. You can do this through DreamHost’s admin panel as well.  Goodies->Manage MySQL->Create a new MySQL database.

3. Set up Rails. Go to the directory you’re going to run your Rails installation out of (~/path/to/rails/root from step 1) and run:

   rails . -d mysql
   

   (Note the dot for ‘current directory’.)  This will create all the Rails directory structure and default starter files.

4. Set the permissions. I’m not sure what the exact minimum possible permissions are to run Rails on DreamHost, but this created an acceptable situation for me for now: (note that I ran step 3 with a umask of 0027)

   find ./ -type d -exec chmod o+x {} \;
   find ./ -type f -exec chmod o+r {} \;
   chmod o-r config/database.yml
   

   You would absolutely want to lock these permissions down further if your application involved any sensitive data or services whatsoever. Leaving all your scripts world-readable allows any other DreamHost user to potentially scan your code and look for vulnerabilities.

5. Do an intermediate test. At this point you should be able to navigate to your domain and see the Rails welcome page.  Note that the “About your application’s environment” link will not work in ‘production’ mode, DreamHost’s default. If things aren’t working, your friends are the logs in ~/logs/your.rails.domain.com/http and ~/path/to/rails/root/log.

6. Set up the database connection. This involves editing the file config/database.yml.  DreamHost has its Virtual Hosts set up to default your Rails installation to run as ‘production’, but you can change this by setting ENV['RAILS_ENV'] in config/environment.rb.  Here’s a good way to do this automagically once you have development/staging/production sites all set up. After editing any of your Rails config files, you need to do:

   touch tmp/restart.txt
   

   to make sure Apache reloads the Rails config files on the next HTTP request.

7. Test it. My test was to get the ’skeleton’ version of this project up and running by copying a few files into the Rails directory structure in the appropriate places.

Probability I find something wrong with these instructions in the next week or so?  ~80%.  I’ll update this post when I do.

Update:

Fyi, if you run the Webrick server in script/server, a DreamHost bot will auto email you telling you to please stop it:

From: DreamHost Policy Bot <support@dreamhost.com>
To: Michael Fogel <******@gmail.com>
Our automated system has come across the following activity under your account that is in violation of our Terms of Service.
We request that you take any necessary action to cease the activity as quickly as possible or we will be forced to take further action. If you were not aware of any such activity, please feel free to contact support and we can look into the issue further.

User **** running “ruby ./script/server”. This process is against our policies.

Please run ruby via cgi, not the built-in Webrick web server

They should add to this email a thinger about mod_rails being their preferred way to run Rails.

Update 2:

Ug, you can’t use HTTP Basic Auth with mod_rails (as of version 2.0.6). Note this is what DreamHost will set up for you if you use their web panel to set up authentication. Here’s a relatively simple if not elegant solution to the problem while we wait for mod_rails 2.1 to be released.

Trac 0.11 is out. And it’s awesome – both the usability in enhancements in 0.11 and Trac in general. Trac is one of those tools in my toolbox I use to up my productivity a few notches. For small projects, it’s a nice convenient time saver. For large projects, having the project management tools trac provides makes an astonishing difference in group productivity and allows for a significantly higher quality final product.

On my web host, DreamHost, Trac is non-trivial to install… until now! I’ve written a set of scripts that make it semi-trivial to set Trac 0.11 up on DreamHost. Original inspiration came from the ‘auto-install‘ on the DreamHost wiki, which is great that it’s there, but it was awkward for my configuration and, IMHO, suffers from backward compatibility and feature bloat issues.  So, I wrote up some scripts that work well with my configuration. The README explains how to use them.

You may also want to check out the dreamy-trac project. Both that code and these scripts were originally based off the same code on the DreamHost wiki, so you’ll see similarities. They both get you to a similar end result. I know in these scripts I’ve emphasized simplicity as much as possible at the expense of installing any extra plugins, or customization, or whatnot.

If there’s a fair amount of traffic coming here and it looks like people are using these, I’ll set them up on a public repository for easier access and collaboration. In the meantime, keeping it simple… here they are.

README:

# AutoTracOnDreamHost: README
# Released under GLPv3. http://www.gnu.org/licenses/gpl-3.0.html
# Copyright 2008 Michael Fogel. http://fogel.ca

#################### LICENSE #####################

AutoTracOnDreamHost is free software: you can redistribute
it and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation, either
version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

http://www.gnu.org/licenses/gpl-3.0.html

#################### HowTo #######################

Preliminaries:

  1. Assuming you're going to use this with SVN, you need to already
     have an SVN repository setup and running.  The webserver needs
     to have at least read permissions to the repository.

  2. You need to have a complete domain/subdomain set up to use
     with trac or a subdirectory of an existing domain.

  3. A MySQL database ready to use with trac.  This doesn't have to
     be it's own database, but AFAIK, there is no good reason not
     to give each trac site it's own database.

Do once: 

  1. Edit the configure.inc:

     - you probably want the latest and greatest of Trac, Genshi,
       MySQLDB, and Pygments.  Minor version releases of these
       shouldn't break this script.

     - alter the trac directory structure to your liking, or just
       run with my setup.

  2. Run the backend.sh.  This will set up all the parts of trac that
     are shared between all your trac sites (even if you have only one).

Do once per trac site:

  1. Run the site.sh.  This script will query you for details about
     the configuration of your database, your directory structure,
     svn repository, an admin trac user etc.

  2. Test it! Go to your new trac url and log in, browse the svn
     repository, create a dummy ticket etc.

#################### Help Me! ####################

I'll post about any major updates or known bugs on my blog.
http://blog.fogel.ca  In event of enough interest in these
scripts, I'll set up a public repository for it so we can
all contribute.

If you find any major bugs or want to submit a patch, you can
email me which is my first name (mike) at my domain (fogel.ca).
Requests for personalized help will be answered in the limit
of infinite free time, which I don't have, so no promises.

Elsewise, the best conglomeration of information about Trac
on DreamHost AFAIK is currently at on the DreamHost wiki.
http://wiki.dreamhost.com/Trac

##################################################

configure.inc:

# AutoTracOnDreamHost: configure.inc
# Released under GLPv3. http://www.gnu.org/licenses/gpl-3.0.html
# Copyright 2008 Michael Fogel. http://fogel.ca

# Abort on any errors
set -e

TRAC_VERS=0.11.1
GENSHI_VERS=0.5.1
MYSQLDB_VERS=1.2.2
PYGMENTS_VERS=0.11.1

# trac dir structure
TRAC_ROOT="${HOME}/trac"
PKG=${TRAC_ROOT}/packages
EGG=${TRAC_ROOT}/egg_cache
INSTALL=${TRAC_ROOT}/install
SITES=${TRAC_ROOT}/sites
SVN=${HOME}/svn
TRAC_SITE_PACKAGES=${PKG}/lib/python2.3/site-packages
TRAC_HTDOCS=${TRAC_SITE_PACKAGES}/Trac-${TRAC_VERS}-py2.3.egg/trac/htdocs

EXP_CMD1="export PYTHONPATH=$TRAC_SITE_PACKAGES"
EXP_CMD2="export PYTHON_EGG_CACHE=$EGG"
EXP_CMD3="export LD_LIBRARY_PATH=$PKG/lib"
EXP_CMD4="export PATH=$PKG/bin:\$PATH"

cat <<OutputDreamTracInstallReminder

==== Put the following in your ~/.bash_profile ====
Where trac/packages=PKG
$EXP_CMD1
$EXP_CMD2
$EXP_CMD3
$EXP_CMD4
===================================================

OutputDreamTracInstallReminder

# modify those env vars for the duration of this script too.
$EXP_CMD1
$EXP_CMD2
$EXP_CMD3
if [[ "$PATH" != *"$PKG/bin"* ]]; then export PATH=$PKG/bin:$PATH; fi

# Update version information here and DIRs below.

TRAC=http://ftp.edgewall.com/pub/trac/Trac-${TRAC_VERS}.tar.gz
GENSHI=http://ftp.edgewall.com/pub/genshi/Genshi-${GENSHI_VERS}.tar.gz
SETUPTOOLS=http://peak.telecommunity.com/dist/ez_setup.py
MYSQLDB=http://switch.dl.sourceforge.net/sourceforge/mysql-python/MySQL-python-${MYSQLDB_VERS}.tar.gz
PYGMENTS=http://pypi.python.org/packages/source/P/Pygments/Pygments-${PYGMENTS_VERS}.tar.gz

TRACDIR=Trac-${TRAC_VERS}
GENSHIDIR=Genshi-${GENSHI_VERS}
MYSQLDBDIR=MySQL-python-${MYSQLDB_VERS}
PYGMENTSDIR=Pygments-${PYGMENTS_VERS}

#### function getInupt - used primarily in site.sh #####
# arg 1: message
# arg 2: initial value
function getInput {
	MES="$1"
	eval "VAL=\$$2"
	echo ""
	echo "Press enter to accept the current value, or input a new value."
	TMP="$VAL"
	while [[ -n "$TMP" ]]; do
		VAL="$TMP"
		echo "$MES: $VAL"
		read TMP
	done
	echo "Using $MES: $VAL"
	eval "$2=\"$VAL\""
}

backend.sh:

# AutoTracOnDreamHost: backend.sh
# Released under GLPv3. http://www.gnu.org/licenses/gpl-3.0.html
# Copyright 2008 Michael Fogel. http://fogel.ca

source ./configure.inc

echo -e "\n==== Creating need dir structure ===="
[ ! -d ${PKG} ] && mkdir -p ${PKG}
# the egg_cache dir must be writable by your apache cgi/python user
[ ! -d ${EGG} ] && mkdir -p ${EGG} && chmod 770 ${EGG}
[ ! -d ${INSTALL} ] && mkdir -p ${INSTALL}
[ ! -d ${SITES} ] && mkdir -p ${SITES}

echo -e "\n==== Retrieving installation files ===="
cd ${INSTALL}
[ ! -f ${TRACDIR}.tar.gz ] && wget ${TRAC}
[ ! -f ${GENSHIDIR}.tar.gz ] && wget ${GENSHI}
[ ! -f ${MYSQLDBDIR}.tar.gz ] && wget ${MYSQLDB}
[ ! -f ${PYGMENTSDIR}.tar.gz ] && wget ${PYGMENTS}
[ ! -f ez_setup.py ] && wget ${SETUPTOOLS}

echo -e "\n==== Installing Setup Tools ===="
#Create site-packages directory. Script will fail without it.
mkdir -p ${TRAC_SITE_PACKAGES}
[ -z `which easy_install` ] && cd ${INSTALL} && python ez_setup.py --prefix=${PKG}

echo -e "\n==== Installing Pygments ===="
cd ${INSTALL} && tar xzf ${PYGMENTSDIR}.tar.gz
cd ${PYGMENTSDIR} && python setup.py install --prefix=${PKG}

echo -e "\n==== Installing MYSQLdb ===="
cd ${INSTALL} && tar xzf ${MYSQLDBDIR}.tar.gz
cd ${MYSQLDBDIR} && python setup.py install --prefix=${PKG}

echo -e "\n==== Installing Genshi ===="
cd ${INSTALL} && tar xzf ${GENSHIDIR}.tar.gz
cd ${GENSHIDIR} && python setup.py install --prefix=${PKG}

echo -e "\n==== Installing Trac ===="
cd ${INSTALL} && tar xzf ${TRACDIR}.tar.gz
cd ${TRACDIR} && python setup.py install --prefix=${PKG}
mkdir -p ${PKG}/share/trac
cp -fr ${INSTALL}/${TRACDIR}/cgi-bin ${PKG}/share/trac

echo -e "\n==== Setting permissions for Trac htdocs ===="
DIR=${TRAC_HTDOCS}
while [ "$DIR" != "$HOME" ]; do
	chmod o+x $DIR
	DIR=`dirname $DIR`
done
find ${TRAC_HTDOCS} -type d -exec chmod 751 {} \;
find ${TRAC_HTDOCS} -type f -exec chmod 644 {} \;

echo -e "\n==== Backend install complete ===="

site.sh:

# AutoTracOnDreamHost: site.sh
# Released under GLPv3. http://www.gnu.org/licenses/gpl-3.0.html
# Copyright 2008 Michael Fogel. http://fogel.ca

source ./configure.inc

# Defaults
PROJECT=somesvnproject
DOMAIN=trac.somedomain.com
DOMAINDIR=${HOME}/http/$DOMAIN  # default refreshed after sampling DOMAIN
TRACPATH=/trac
MYSQLHOST=mysql.$DOMAIN         # default refreshed after sampling DOMAIN
MYSQLUSER=trac_username
MYSQLPASSWD=trac_password
MYSQLDBNAME=trac_$PROJECT       # default refreshed after sampling PROJECT
TRAC_USER=admin
TRAC_PASSWORD=password

# Prompt on those defaults
getInput "Subversion Project ID"                 PROJECT
getInput "Domain for Trac"                       DOMAIN
DOMAINDIR=${HOME}/http/$DOMAIN
MYSQLHOST=mysql.$DOMAIN
getInput "Path for domain root"                  DOMAINDIR
getInput "Path for Trac relative to domain root" TRACPATH
getInput "MySQL hostname"                        MYSQLHOST
getInput "MySQL username"                        MYSQLUSER
getInput "MySQL password"                        MYSQLPASSWD
MYSQLDBNAME=trac_$PROJECT
getInput "MySQL DB name"                         MYSQLDBNAME
getInput "Trac Admin username"                   TRAC_USER
getInput "Trac Admin password"                   TRAC_PASSWORD

# using these values
echo "PROJECT:${PROJECT}"
echo "DOMAIN:${DOMAIN}"
echo "DOMAINDIR:${DOMAINDIR}"
echo "TRACPATH:${TRACPATH}"
echo "MYSQLHOST:${MYSQLHOST}"
echo "MYSQLUSER:${MYSQLUSER}"
echo "MYSQLPASSWD:${MYSQLPASSWD}"
echo "MYSQLDBNAME:${MYSQLDBNAME}"
echo "TRAC_USER:${TRAC_USER}"
echo "TRAC_PASSWORD:${TRAC_PASSWORD}"

# Vars for this site
WEBDIR=${DOMAINDIR}/${TRACPATH}
INDEX_CGI=${WEBDIR}/index.cgi
TRACINI=${SITES}/${PROJECT}/conf/trac.ini
HTACCESS=${WEBDIR}/.htaccess
HTPASSWD=${WEBDIR}/.htpasswd
NAME="Trac: ${DOMAIN}${TRACPATH}/"

echo "Setup site"
if [ ! -d ${SITES}/${PROJECT} ]; then

	#Setup Trac Environment for MySQL
	${PKG}/bin/trac-admin ${SITES}/${PROJECT} \
		initenv ${PROJECT} \
		"mysql://${MYSQLUSER}:${MYSQLPASSWD}@${MYSQLHOST}/${MYSQLDBNAME}" \
		svn \
		${SVN}/${PROJECT};

	# set admin user to premissions
	${PKG}/bin/trac-admin ${SITES}/${PROJECT} \
	permission add $TRAC_USER TRAC_ADMIN
fi

echo "Make Trac Web Accessible"
# Make Trac Web Accessible
mkdir -p ${WEBDIR}
chmod 751 ${WEBDIR}

if [ -f "${INDEX_CGI}" ]; then
	rm ${INDEX_CGI}
fi
echo "#!/bin/bash" >> ${INDEX_CGI}
echo "export HOME=\"/home/${USER}\"" >> ${INDEX_CGI}
echo "export TRAC_ENV=\"$SITES/${PROJECT}\"" >> ${INDEX_CGI}
echo "$EXP_CMD1" >> ${INDEX_CGI}
echo "$EXP_CMD2" >> ${INDEX_CGI}
echo "$EXP_CMD3" >> ${INDEX_CGI}
echo "$EXP_CMD4" >> ${INDEX_CGI}
echo "exec $PKG/share/trac/cgi-bin/trac.cgi" >> ${INDEX_CGI}
chmod 755 ${INDEX_CGI}

# logo in trac.ini
sed -i "s/^alt = .*$/alt = trac_banner.png/" ${TRACINI}
# some fancy sed to escape forward slashes... simplier patches are welcome.
TRACPATH_S=`echo ${TRACPATH} | sed -e "s/\/$//" -e "s/\//\\\\\\ \//g" -e "s/ \//\//g"`
sed -i "s/^src = .*$/src = ${TRACPATH_S}\/chrome\/common\/trac_banner.png/" ${TRACINI}

#Pretty URLs
mkdir -p ${WEBDIR}/chrome
chmod 751 ${WEBDIR}/chrome
ln -sf ${TRAC_HTDOCS} ${WEBDIR}/chrome/common

# .htaccess fun
if [ -f ${HTACCESS} ]; then
	rm ${HTACCESS}
fi

touch ${HTACCESS}
chmod 644 ${HTACCESS}

echo "AuthType Basic" >> ${HTACCESS}
echo "AuthUserFile ${HTPASSWD}" >> ${HTACCESS}
echo "AuthName '${NAME}'" >> ${HTACCESS}
echo "require valid-user" >> ${HTACCESS}
echo "" >> ${HTACCESS}
echo "DirectoryIndex index.cgi" >> ${HTACCESS}
echo "Options ExecCGI FollowSymLinks" >> ${HTACCESS}
echo "" >> ${HTACCESS}
echo "" >> ${HTACCESS}
echo "RewriteEngine On" >> ${HTACCESS}
echo "RewriteCond %{REQUEST_FILENAME} !-f" >> ${HTACCESS}
echo "RewriteCond %{REQUEST_FILENAME} !-d" >> ${HTACCESS}
echo "RewriteRule ^(.*)\$ ${TRACPATH}/index.cgi/\$1 [L]" >> ${HTACCESS}
echo "" >> ${HTACCESS}

#Create .htpasswd file for trac admin with password
htpasswd -bc ${HTPASSWD} $TRAC_USER "$TRAC_PASSWORD"

# Note: on DreamHost you avoid a world-readable htpasswd file by
# setting one up via panel.dreamhost.com->Goodies->Htaccess/WebDAV.
# This will make htpasswd and htaccess files (overwriting anything
# that's there) that has group dhapache, is group readable, and
# the apache user is in the dhapache group.  Baring this, you need
# to make your htpasswd file word-readable (or email support for
# some chgrp action as root)
chmod 644 ${HTPASSWD}

echo ---------- SITE INSTALL COMPLETE! ----------

Well, this comes up in /var/log/syslog and others:

iwl4965: iwlwifi-4965-1.ucode firmware file req failed: Reason -2
iwl4965: Could not read microcode: -2

As is explained here, the iwlwifi drivers require a binary firmware (aka microcode) image to function. The drivers themselves are free, both as in beer and as in freedom. However, the microcode images, in order to enforce end-user FCC compliance, are free as in beer but not freedom. Thus a default Debian install, which bends over backwards to be free as in beer and free as in freedom, does not include the microcode images.

Two options:

1. Install the firmware image yourself. Find the image you need here (as of August 2008 the version you want was 1.21), download it, extract it, and copy it to /lib/firmware/iwlwifi-4965-1.ucode.
2. Or, add the non-free repositories to your /etc/apt/sources.list, and do an

   apt-get install firmware-iwlwifi

Or, pretend you didn’t really want wireless if you can’t have it free as in freedom… and put it on your to-do list to reverse-engineer that binary firmware image. Buena suerte! ;p

I can’t remember if a reboot was necessary after installing the microcode image. But that should be it in terms of edits and installs… everything wifi, all the way out to the gnome GUI, should now just automagically work.

The key options in my T61p package:

39T4822 	VBB WWAN
42V9332 	SBB WAN:VERIZONSIERRACDMA2000
42V8603 	SBB INT.WWAN ANTENNA 15.4"
42V8659 	SBB CL.PLATE T61P WL WWAN
42W7002 	SBB FCC-ID/LABEL FOR WWAN
42V8675 	SBB VERIZON OPTION

That all translates to a slickly built-in Verizon card and antenna:

$ sudo lsusb -v | grep Sierra
Bus 006 Device 002: ID 1199:0220 Sierra Wireless, Inc.
  idVendor           0x1199 Sierra Wireless, Inc.
  iManufacturer           1 Sierra Wireless, Incorporated
  iProduct                2 Sierra Wireless MC5725 Modem

Here is the only officially unofficial official public documentation I could find for that card on Linux.

Before setting this up with Debian, I’d recommend getting it working with Windows if you haven’t reformatted over it yet. The card and connection pretty much ‘just works’ on Lenovo’s preinstalled Windows. This will mostly eliminate Verizon as the source of the problem if things don’t go right with Debian.

A default Debian install provides a number of tools you can use to configure and automate your connection. I like gnome-ppp (essentially a GUI frontend on wvdial) best. I’ve also set it up with gnome’s network-admin applet (System->Administration->Network), but it doesn’t provide good user feedback on the connection process or status. And by ‘good’, I mean ‘any’. Perhaps future versions will have better integration of dial-out connections, now that they’re coming back into style with EVDO and 3G networks. In any case, I will provide instructions for both these two tools here. (Note this is an either/or. There is no reason to bother setting this up with both tools, other than to test out the GUI’s.)

First, GUI configuration. Here’s your key points:

• Username: YOURPHONENUMBER@vzw3g.com
• Password: vzw
• Phone number to dial: #777

For gnome-ppp, you want to:

• Use the ‘Detect’ mechanism. It worked perfect for me. Try it.
• Under Options, enable ’stupid mode’ to speed up the connection process substantially. You’re also calling Verizon stupid, in a extremely passive aggressive manner… ummm, feels so good…. stupid stupid stupid.

For network-admin:

• Set the Modem port to /dev/ttyUSB0.
• Check the ‘Set modem as default route to Internet’ option or your machine will just drop your outbound packets on the floor.
• No remote authentication. In the file /etc/ppp/peers/ppp0, add a line ‘noauth’ to disable your authentication of the verizon servers. This means that if someone successfully hijacks Verizon’s ‘#777′ number, you will have no way of knowing, and they will have complete control over your traffic. (gnome-ppp does this ‘noauth’ for you automatically, for better or for worse.)
• Do not set the modem volume. In the file /etc/chatscripts/ppp0, comment out the line that has a command like ‘AT&FH0XX’ where XX are wildcards depending on your GUI settings. Issuing this command causes the modem error out, reporting ‘NO CARRIER’ on the ensuing ATDT (dial) command.

And that’s it! For debugging, your friends are tail, /var/log/syslog, /var/log/messages, gnome-ppp’s GUI log display, cat, echo, /dev/ttyUSB0, minicom and or course, good old google.

Vinegar!

First test the vinegar on a inseam or something to make sure it doesn’t discolor your pants.  If that’s ok, then…

Pour some vinegar on the gum.  Wait a few moments for the vinegar and gum to fight it out, then wipe it all with a towel.  Some little bits of the gum will come off.  Repeat this process a dozen times or so, throw the pants through the wash once to get the vinegar smell off, and you’re good to go.

1. Make a local copy of the full googlecode.com repository.

   svnadmin create local_repos
   echo -e "#\041/bin/sh" > local_repos/hooks/pre-revprop-change
   echo "exit 0" >> local_repos/hooks/pre-revprop-change
   chmod 755 local_repos/hooks/pre-revprop-change
   svnsync init file://`pwd`/local_repos https://urproject.googlecode.com/svn
   svnsync sync file://`pwd`/local_repos
   

2. Now, you can make a dump of that local repository.

   svnadmin dump ./local_repos > thedump
   

3. Copy that dumpfile over to wherever your preexisting destination repository is located. -C is for gzip compression during transfer, and is helpful if you have a big repository full of text.

   scp -C ./thedump yourhost.com:~/
   

4. Now, we load that dumpfile.

   ssh yourhost.com
   svn mkdir file://path/to/your/repos/dir_for_googlecode_copy
   svnadmin load /path/to/your/repos --parent-dir dir_for_googlecode_copy < thedump
   

Revision number will be incremented correctly (ending at the sum of the two previous repositories), all the commit logs and such are transfered intact, including the authors (even if they’re not users on the new system).  Pretty smooth.

Still, I’m watching songbird’s development closely and eagerly….