tail -f findings.out

I have been experimenting with adding more color to my bash prompts of late. I find it easier to read when the fields are in distinct colors. The problem I always have is remembering what those wonderfully obscure ANSI escape sequences represent. I always have to look at a table to remind myself that “light red” maps to “1;31″.

In an interesting guide to configuring your bash prompt that I have been going through, there was a script listed that makes this much easier:

This is from the Bash Prompt HOWTO, from a script by Daniel Crisman. It produces the following when run:

Just add an alias like

, and you can be reminded whenever you like.

I am still experimenting with my prompt colors, but differentiating the fields I find useful has made things a lot easier:

Any linux distribution around these days will have compression and rotation in place for files in

(or wherever else they happen to go). So if you look in there, you will see one or two log files (current and the last one) for each process logged, as well as 3-7 compressed files for the same process. These then get rotated out.

In any case, say you want to look inside one of those compressed log files. You could write out an untar command and then view the file. Then have to delete the temporary file. Messy. There is a better way.

The first I found was interesting (from PuppyLinux): Simply run

. You view the contents of the file with the man file viewer. The annoying thing is that is does funny things with line breaks.

A much better way:

. You view the file in less, and when done, there is no temp file to delete. To make it faster, just add a simple alias:

. This makes viewing those compressed logfiles as painless as viewing the current ones.

It seems nearly every week, I find something amazingly handy in bash that I had not used before. This time: Loops. I would bet nearly everyone who has written more than a handful of shell scripts over a few lines in length has used one or more of the loops bash has to offer. But, what I realized (not sure why it did not bash me sooner) is that loops are also very effective timesavers as one-off commands in everyday shell usage.

I suppose the association came from first using the shell in a very simple way, of just giving commands singly, and only using constructs like loops in scripts I wrote out in files. But recently, I had several identical operations to perform on a series of files with consistent names, and a loop came to mind. The files were all mp4 videos, and I needed to convert them with ffmpeg, and send them through flvtool2. Instead of 2 commands typed out for each file, I ran:

To simply iterate over a list of strings, using each in a command:

You can use loops like this in any shell script, just write the whole loop on one line, separating the conditions, parts in the suite, and the termination with semicolons (these are mostly optional when using line breaks in scripts in files). Assorted resources:

• Post that inspired me, with lots of practical tips for loop usage.
• More advanced loop documentation from TLDP.
• Post with helpful examples

Fuser is a very handy command when you are trying to investigate what is listening on a box.

Consider the following case. You, being a diligent systems administrator, have been performing regular nmap scans against your boxes from remote hosts. You discover that something is listening on port 587 on a server. What you immediately need to know is: what program is actually listening on that port? The quickest way to find out is to simply run

on the box in question. This queries the kernel for what PID is listening on the specified port and reveals almost what you need:

The first column is the port you specified, the second is the PID using that port currently. This can be combined with ps to give you the desired output, such as via

:

I used echo in this case because I was unable to decipher the delimiter used between the two columns in the default output. The whole thing should be aliased such that you run the alias and pass a port, and the ps output is produced.

NOTE: fuser is generally found in /sbin or /usr/sbin, which you may have to add to your path.

My last post was on how I used Samba to share files from my central media server to other machines on my local network. Seemed great at first, but having used it for a little while, I was rather disappointed. I had Rhythmbox looking at the mounted drive as my library. It started scanning the files once the directory was mounted. I could play them, but after a few minutes, Rhythmbox would freeze scanning the files. In addition, I could not even list the directory that contained the mounted directory. Something was getting frozen. This kept happening more and more, and was quite frustrating.

I then tried of SSHFS for the same purpose, and it has been working much better. If you can SSH to the machine with the files you want to share, then you don’t have to make any changes to that computer. Just a few steps on the machine that will be accessing the remote store, and you are ready to go. From the top:

• Create the dir which to which the remote dir will be mounted (e.g. /home/myuser/Music)
• Make sure you have ssh access on remote machine from the local machine
• On the local machine:

  • 1	sudo apt-get install sshfs

  • 1	sudo modprobe fuse

  • 1	sudo usermod -G fuse -a youruser

  • 1	sudo chgrp fuse /dev/fuse

  • Logout of myuser on the local machine, then back in

  • 1	sshfs 192.168.1.6:/dir/on/remote/server LOCALDIR

will make sure you have that kernel module loaded. You have to be in the fuse group to perform the mount, sudo or not. I am not exactly sure why you have to change the group of the fuse device, but you definitely have to to get it to work.

At this point, you should be able to view all the files in /dir/on/remote/server from LOCALDIR. Performance wise, I had great success. Pointing Rhythmbox to the dir I mounted, it scanned all the files in a timely manner, and I was able to play them as if they were on the local machine without issue.

If you wish to unmount the share, run

. One problem that has been suggested for which I do not have a fix yet is how to handle if the remote machine has a problem, reboots, or the network connection is otherwise dropped. I am not sure how this would be handled, since the mount would no longer work. fuse being a kernel module, this may cause freezing. If I find this addressed somewhere, I will post it.

Additional information and links:

• General HowTo
• Good reference
• Post on changing /dev/fuse owner