Ramblings from MostlyChris

I have this problem. I am trying to send a SOAP request to a provider of information I need. In order to make this request correctly, I have to provide a value as a LONG. For whatever reason, they are not getting what I think I am sending. Therefore, I need a way to see what I am sending. Sure, I can use tcpdump to view the packets, but I can't decode this stuff. Wireshark comes to mind. The problem is, I am not doing this on a local box and Wireshark is GUI based. What to do…what to do? Here's how I am handling the issue.

First, I output my tcpdump results to a file:

I then import this file to a box that I have Wireshark running on and I can now view the conversation. Of course, this doesn't work if you want to follow something real-time but it at least works if you want to do some troubleshooting like I am.

Of course, if you have a better way a of doing this, leave a comment.

Since I am apparently unable to remember how to do a simple sort, I'm going to throw it into my blog so I can refer to it later.

In this particular case, I was attempting to pull out all of the "from=" entries in the server's mail logs. I won't go into the details of the awk command, but I will paste my entire command here anyway, including the sorts:

The summary of the above command is this:

I cat the mail log on the server and using awk I pull out the 6th column (columns separated by spaces) and then I apply the sort. The first sort does a general sort on that column. The 'uniq -c' does a count of the number of times a unique entry appears from the first sort. The final 'sort -n' sorts the output of the uniq command in numerical order so it is easier to read.

If you encounter the following error when running the Urchin stats update it can easily be corrected.

"Unable to open database for writing since it has been archived"

The error occurs whenever Urchin has archived its log tracking databases. The fix for this is pretty simple.

1. Navigate to /usr/local/urchin/data/reports/[profile]
2. Unznip the [date]-archive.zip files
3. Move the archived files out of the way (to another directory).
4. Change ownership of the unzipped files to the urchin user
5. Re-run the statistics and they should show up

That's it. Easy Fix.

Lets suppose you have a shared httpdocs directory on your server in which you would like to have your developers gain access. However, there is going to be more than one developer and each one will have their own login credentials. This becomes a problem because of file ownership permissions. If one developer has uploaded a file, the others are not going to be able to access it.

Along comes setfacl to the rescue.

Let's assume with have two users and the usernames they login as are john and jane. You want john and jane to both be able to upload files to the directory as well as access each others files.

Since there are different ways to approach this, I am going to use what I call the "per user" version. In this version, you add each user individually.

To add the username john:

To add the username jane:

If there are existing files in the httpdocs directory that you want them both to have access to, you would run this recursively with the -R flag.

So now that the files and the directory are set to allow john and jane access, you want to set the directory so that any new files that are created are set with default facls that allow john and jane access. This is similar to the above commands except you add the -d flag as well. It should look like this:

For john

For jane

You can see the results of the setfacl with getfacl. The output of getfacl httpdocs would look something similar to this:

That's it. John and Jane can access all files in the folder as well as create files that are then accessible by both of them.

I routinely deal with Read Only file systems and always have to remember the commands to remove the journal and run a file system check. Since some days I am better at remembering than others, I thought I'd just write it down in this post so I can find it later.

First, remove the journal:

If you run into errors due to 'needs_recovery', do this to remove the recovery flag and then remove the journal as shown above:

Run the file system check. See how bad things are first.

If it's not too bad, do the real fsck.

Once the rebuild is successful and complete, rebuild the journal.

Mount the filesystem and make sure it's happy and ready for action.

Reboot the server and put it back in the fray.