bosconet.org: chocolately writings

For about the past week I’ve been running into a problem where I create a nice tar’ed and gziped archive to using in the post install phase of a kickstart install I’ve been working on but it doesn’t get transferred over to the installed client and displays an HTTP error code of 403 when I look at the access.log.

My first though was permissions. I made sure the owner of the processe running lighttpd also owned the files in question and the read bit was set for anyone to access it. That didn’t do the trick. My work around was untar gzipping the archive and recreating it on the server. That worked until this afternoon. It was then that I did a little more testing and as it turned out lighttpd was not happy with tar gziped archives created using Fedora 12’s tar with the ‘z’ flag passed as an argument. So I decompressed all the tar files using gzip, then gzipped them again using gzip instead of the built in gzip functionality of tar. That did they trick.

Hopefully google will find this post, index it well and it can help someone else.

I recently encountered this on my Fedora 10 machine. I looked and looked and found a bunch of advice that did not work. Among that advice was rebuild the RPM database, and clean the yum repository.

The answer though was I had a bad yum repository that I found by disabling all the yum repositories I had and re-enabling them 1 by one.

If you find this page b/c of the error above I suggest the same methodology for finding the offending repository.

I mentioned recently that IMAPS is being shut off for my work email. Well they just sent out a 2nd notice with some justifications. The one that JUMPS out at me is that (and I’m paraphrasing): “in order to provide POP and IMAP services we use approximately 50 IPs on our DMZ. “

Can someone with some insight into the inner workings of exchange explain why so many IPs would be required to provide these services? Thanks.

Since I had a gift card and a want for a phone with a better web interface I bought a (ancient) unlocked Blackberry 7130. It cost me $2 out of pocket so I felt it was a justified impulsive purchase.

It arrive today, and tonight I set it up. I was frustrated for a long while because despite copying the exact network setting I had on my old phone (a Sony Ericsson K750i). Every time I would turn the wireless on the message “Data Connection Refused”. This was very frustrating, and I was beginning to think I might need to spend more and upgrade my T-Mobile service to one of the Blackberry options.

Thankfully I just ignored it and tried Opera Mini and it successfully loaded a web page.

Now I can go to bed happy. Tomorrow I need to figure out how to set up a personal email account which doesn’t seem to be an option at the moment.

For a while now I have been advising people to purchase their music through Amazon when ever it is available rather than the iTMS. Why? Because the Amazon tracks aren’t encumbered by any DRM.

Today that changed though. Apple announced that DRM is leaving the iTMS. I am thankful for that. Now the only reason to buy from Amazon over iTMS is price.

I gave up on my Eye-Fi card about a month ago when I pulled out my camera to a dead battery, yet again! Since then I had it on my desk at home. I tossed it in my bag for holiday travel just in case I wanted to use it as a last minute gift.

Here at my sister-in-law’s house I think it would make a great gift. Bother her and her husband have beter things to do with a new baby than deal with plugging the camera in to upload pictures to flickr. The Eye-Fi seems like a natural fit, it will automatically do it for them. EXCEPT for they idea you need to effectively disable the power saving auto shut off feature of the camera for it to reliably upload all your pictures. What this would mean, is that like in my case, their newborn would be doing something very photo worthy but the camera would be dead from the last time they took a picture of her.

So back in my bag it will go. And until the card is ’smarter’ about powering down a camera when it is done transfering pictures I can’t recommend this neat gadget to most people.

I’m currently away for the holidays. Both the ISPs my kind hosts use filter out port 25 traffic to mail servers other than their own. As someone who hates spam I can understand why they do this. This helps limit spammers from using the ISP to pump out their spam.

However I have noticed a couple things at my current location. One is related to incompetence on the part of ATT the other on my employer’s part. First ATT’s incompetence:

My in-laws have BellSouth DSL service back at their home in Florida. Their Outlook client is configured to use port 25 to send mail. This doesn’t work here in Chicago where the DSL provider is, ATT. Now just in case you don’t keep up with the acquisitions in the telecommunications field, ATT & BellSouth are the SAME company. So in effect they are filtering port 25 traffic to other ATT mail servers. I can certainly understand why this would have been the case for a period of time after the acquisition but it has now been 2 years. One should reasonably expect them to allow port 25 traffic to mail servers controlled by the same company. Sadly this isn’t the case so my in-laws are forced to use the less functional webmail client to send any emails.

Now my employer’s incompetence:

For remote access if you aren’t using Outlook (with its Exchange hooks) you set up your client to use IMAP to receive email and port 25 (with authentication) to send mail. Sadly as noted above many ISPs filter port 25 to combat spam. This means that you can’t effectively use non-Outlook client to send mail from outside the corp network. The incompetence here is that they haven’t opened up port 597 (mail submission) to accommodate these situations. Why is this the case? I don’t know for sure but it almost certainly is for 2 reasons: 1) Outlook with Exchange is the supported email client 2) the people in charge of running the mail servers aren’t competent enough to think of such situations and accommodate them.

We recently set up a TWiki install on a server that doesn’t have email nor is allowed to use port 25 to communicate out. This means that the normal way a user would reset a forgotten password won’t work.

Since the assumption by the Twiki community is that you will have email access no thought has been made to document how to do this in any other manner.

In my digging I found it to be fairly simple to do this.


cd $HTTPD_ROOT/twiki/data
htpasswd -b .htpasswd


tada all done. Oh you do need to either be root or have write access to the .htpasswd file.