Archive for January, 2007
Windows-to-*nix public key authentication
I’ve worked with lots of servers, most of which I cannot access directly, so I often use remote access: Remote Desktop Connection or Terminal Services in Windows, and ssh in *nix.
While I do have PasswordSafe to remember all those passwords, I’m the lazy admin type, so I often opt for password-less authentication using public keys. For this, I use PuTTY, et. al.
- First, I generate an RSA key using PuTTYgen. I don’t enter anything for the passphrase. Warning: NOT recommended for production servers!
- I save the public and secret keys (in .PPK format) in a directory. I also cut and paste the RSA string in a text file,
key.txt. - For now, the remote box is configured for “normal” ssh, that is, through password authentication. So, I copy over the RSA string file to the remote box:
C:\> pscp \path\to\key.txt user@remote-host:/home/user/.
- I also edit the SSHd config file,
/etc/ssh/sshd_config, with the following parameters:RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys PasswordAuthentication no PermitRootLogin no
- SSHd is then restarted.
- Back in Windows, I launch PuTTY, and enter the host name for the remote box. In the SSH/Auth category, I place the private key file saved earlier. I save the session, named
remote-nopass. - I then launch Pageant, drill down to Saved Sessions > remote-nopass. It will bring up the SSH login page, where I enter my login name, after which, I am authorized through the pubkey, and log in to the SSH session.
$ mkdir .ssh $ mv key.txt .ssh/authorized_keys $ chmod 700 .ssh; chmod 600 .ssh/authorized_keys
Seems tedious at first, but I can then export key.txt to other remote servers, and just save sessions for Pageant’s use. Pageant is conveniently located in the system tray within reach.
Using SVN for web development
Here at my new workplace, there are more than 20 web apps that are being developed in-house. They go through the following workflow: devs use development and staging servers for tests, and after QA, the new builds are pushed to the production servers.
They’ve employed a custom version control system for coding, but it’s not panning out. They need an automated way of pushing updates to the dev and staging servers for a quicker turn-around time.
Enter Subversion. I’ve used Subversion both in production and in personal projects. (I haven’t used CVS so I can’t compare the two.) The way I see it, the web apps can be pushed this way:
- Install SVN with WebDAV support.
- Create the repositories’ directory trees:
mkdir /path/to/repository/projectname
- Note that the repositories have to be owned and writeable by the
httpduser:chown -R httpd:httpd /path/to/repository/projectname; \\ chmod g+s /path/to/repository/projectname
- Create the SVN repositories:
svnadmin create /path/to/repository/projectname
- Import the current working directories for the projects:
svn import /path/to/working/project/dir \\ file:///path/to/repository/projectname
- Remove the working directories (backup first):
rm -rf /path/to/working/project/dir
- Check out directory trees from the repo:
svn co file:///path/to/repository/projectname
- Edit and commit changes:
svn ci
- Or, pull changes:
svn update /path/to/working/project/dir
Easy so far. I’ve also added an HTTP URL for the SVN repos using Apache’s WebDAV extensions. In httpd.conf, just add the following:
LoadModule dav_svn_module modules/mod_dav_svn.so <Location /repos> DAV svn SVNParentPath /path/to/repo/root </Location>
Restart the service. Now the repo can be accessed via http://reposerver/repos/projectname.
But I hit a snag: I can’t get the post-commit hook to run on commits! I’m leaning on problems with the permissions, but it’s eluding me right now. *sigh*
Productivity lesson
Never browse Google Reader feeds at work when you’re subscribed to Fleshbot.
‘Honya budo’
It’s an obscure martial art skill of visiting bookstores without buying anything. I’m a master at this, having achieved the “Path of the Randomly Hopping Rabbit”, in fact. (A Different Bookstore salespeople, in my experience, are the more knowledgeable lot.)
(Hey, I’m deep in tech pr0n and I still have time to browse through my Google Reader feeds. W00t!)
Way over my head?
I feel like I’m back in college! Here I am at my new desk, cramming docs on Solaris and AIX.
I just started here at the new workplace. The first impressions were great. The environment is a bit subdued, not like in my previous one, which was, uh, “colorful”. That’s not to say that the people here are drones, though.
I’ll be handling Unix servers that run mission-critical applications for this organization. The administrative tasks haven’t been formally turned over to me yet, so instead of just shifting my a** in my seat, I wallowed in tech pr0n — that’s tons of Unix admin guides.
Yesterday, I was able to prep several SAN LUNs on an EMC 8530, using AIX, for data migration later from a Symmetrix DMX. Here’s an AIX survival tip: Use smitty! (Learned that from a former colleague who’s now a sys ad at Globe.) Wonderful tool.
AIX LVM methods are very similar to that of RHEL. I just have to familiarize myself more with the (for me) quirky commands (chvg is to RHEL’s lvchange, for example). But the concepts are the same: prep the physical volumes; add them to a volume group; create logical volumes; create the file system and mount point.
I’ll also be going through several Jumpstart scripts. Jumpstart is Solaris’ Kickstart equivalent, on the surface, but is a lot more detailed (read: complicated). Instead of a single ks.cfg Anaconda script, Solaris uses rules and profile files. The rules file also has to be validated first. As I read more about it, I get this feeling that Jumpstart’s similarity to Kickstart ends with ’start’. Heh.
Considering that my background is mostly on Linux, with a little Solaris and spotty AIX, I’m thinking that maybe I’m in over my head here. Then again, they’re all Unix so the functional similarities remain. For now, I have to mentally map Solaris and AIX methods to their Linux equivalents. I’ll get the hang of it, for sure.
