ssh -L 9999:localhost:9999 host1 ssh -L 9999:localhost:1234 -N host2

Install iWatch

apt-get install iwatch

I’ve got this 1 liner in a [...]]]> iWatch is a perl script that uses inotify to monitor files directories. It’s similar to the watch tool, which can do all sorts of stuff if the files or directories it’s watching are modified or affected in pretty much any way at all.

Install iWatch

apt-get install iwatch

I’ve got this 1 liner in a file to quickly watch my directory and execute a PHP unit test .

#!/bin/bash
iwatch -c "phpunit $1" -t ‘.*php$’ -r -v -x ./.git -e modify .

I run this with a my argument (a unit test) and then sit there and code away. When I save, it detects the change and automatically runs my test. It’s pretty awesome.

Log into the ReadyNAS and turn on Rsync for your backup share. Optionally, set a username and password. Your ReadyNAS will start up it’s rsync daemon.

Replace the password and [...]]]> The NETGEAR ReadyNAS is a pretty sweet product if you’ve got a small team like I do. It’s inexpensive and easy to set up.

Log into the ReadyNAS and turn on Rsync for your backup share. Optionally, set a username and password. Your ReadyNAS will start up it’s rsync daemon.

Replace the password and IP below with the rsync password and IP of your NAS, and use the share name in the rsync command – mine was “backup”.


export RSYNC_PASSWORD="BACKUP_PASSWORD_GOES_HERE"
rsync -av /var/backups/ rsync://backup@192.168.1.1:/backup/

I threw that in a shell script and run it in a cron. Good to go.

I’ve asked a bunch of Linux sys admins how to fix this – and the answer is always “put the [...]]]> I’ve run into a ton of issues working with crons, mostly with the $PATH variable screwing things up. Scripts work when run manually on the command line, but fail when run in cron. Very annoying.

I’ve asked a bunch of Linux sys admins how to fix this – and the answer is always “put the full path in your scripts” which to me in unacceptable as it introduces the possibility of human error. Fixing the underlying problem is always preferred.

You can add a PATH variable to the top of your crontab that all scripts will use instead of the default one which doesn’t access /usr/local/bin or any other PATH variables you had set elsewhere.

At the top of your crontab, simply put something like this:

PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:.

This has been an issue for me for years. It also solves the issue of php shell_exec, exec, system, and passthru not having access to the PATH variable.

You’ll need to keep your PATH up to date, but it’s easier than manually editing every script, or messing around with hacks to get every script to work properly.

Enjoy!

Info found on tuxtraining.com

Here’s an example:

# chkconfig: 2345 64 36
# description: script for starting and stopping httpd

chkconfig –add httpd

These commands will now work:

service httpd start
service httpd stop

Additionally, apache will start when [...]]]> Copy apachectl (or symlink it) to /etc/init.d/httpd, and add these two lines at the end of the comment section:

# chkconfig: 2345 64 36
# description: script for starting and stopping httpd

chkconfig –add httpd

These commands will now work:

service httpd start
service httpd stop

Additionally, apache will start when the system boots. You can accomplish this by using rc.local too, if you prefer, but I think it’s more convenient to have everything be service based where you can use chkconfig to manage startup / shutdown.

~ jhaddad$ nmap localhost
Starting Nmap 5.00 ( http://nmap.org ) at 2010-01-05 11:06 PST
Interesting ports on localhost (127.0.0.1):
Not shown: 499 closed ports, 492 filtered ports
PORT STATE SERVICE
[...]]]> To get a quick idea of what ports you have open on your local box, you can use nmap.

~ jhaddad$ nmap localhost
Starting Nmap 5.00 ( http://nmap.org ) at 2010-01-05 11:06 PST
Interesting ports on localhost (127.0.0.1):
Not shown: 499 closed ports, 492 filtered ports
PORT STATE SERVICE
80/tcp open http
88/tcp open kerberos-sec
548/tcp open afp
631/tcp open ipp
3306/tcp open mysql
3325/tcp open unknown
5900/tcp open vnc
9000/tcp open cslistener
10000/tcp open snet-sensor-mgmt

For more detailed information, try netstat:

netstat -an

You’ll get a breakdown of every socket open on your machine – useful for figuring out who’s connected and from where.

The OSX version of netstat lacks a few options – such as the useful ‘-p’ option to display the process id (PID) – which can be useful combined with kill to get rid of unwanted connections – for instance,an SSH tunnel accidentally left open.

Virtualization is now a commodity with several free tools available from Sun, VMWare and Xen. If you’re like me, you like to create a new, clean VM for each experiment. However, this comes with a [...]]]> I’ve done this using CentOS, but I’m pretty sure the same thing will work with RedHat the exact same way.

Virtualization is now a commodity with several free tools available from Sun, VMWare and Xen. If you’re like me, you like to create a new, clean VM for each experiment. However, this comes with a drawback – the installation process, choosing your timezone, putting in the same password every time, etc… takes a while.

Fortunately, CentOS provides the means to automate the process via a kickstart file. The best part is, after you do an install, you’ll have a kickstart file to start working with – it’ll save all your options in /root/anaconda-ks.cfg. You can edit this file later to include other packages that you’d like to install, such as the GCC c++ libraries. You can also run other commands through yum, and customize the system-wide bashrc.

I’m only going to go over how I did the install – for the full details check out the CentOS kickstart guide

I’ve created a minimal kickstart file to do a base install without gnome, printing, and any tools I don’t find useful. I’ve disabled X completely – I have no need to boot to a GUI. I’ve also uncommented the lines to configure the drive settings, so I won’t be prompted for anything along the way; my VM should be completely ready to go once I reboot after the installation. Pretty awesome.

There’s a convenient way to run a kickstart file off a http connection, so I’ve put it the web server on my dev box. My dev box’s IP address is 192.168.1.5, and I copied the modified /root/anaconda-ds.cnf (which I’ve renamed to ks.cfg) to the server. At the installation boot prompt, I’d enter:

linux ks=http://192.168.1.5/ks.cfg

Then let it run. After a bit it’ll ready to reboot and be used. Just make sure to unmount the install DVD.

Obviously this has a lot more uses than just creating VMs, but I’m not a sysadmin, so I haven’t personally used it outside the desktop environment. There’s other tools for different distros, and third party tools for CentOS/RedHat.

For what I’ve done so far, one could argue it’s easier just to create an image of the VM and to just clone that whenever I want a new one. That’s a good solution if I was interested in always creating the same exact VM. However, using the kickstart method has several advantages. I could create a simple web app that generates new configs based on what I’ve checked off in a few lists, allowing me to quickly fire up new VMs with the right software for whatever I’m working on. I can also upgrade the version of the OS and run the same kickstart, so I don’t have to maintain some up to date starting image.

If I’ve made any mistakes, please don’t hesitate to point them out. I’m by no means a guru on the subject, I’ve just wanted to look into this topic for a while.

Some Other Useful resources

• Linux-Mag
• Red Hat Kickstart Guide