Archive for the ‘linux’ Category

Quick and dirty upgrade Fedora Core via Yum

Thursday, December 18th, 2008

First off Fedora has an awesome FAQ for how to upgrade your OS with Yum. If you don’t care for all that reading and thinking, here is a quick and dirty set of notes I have been using to upgrade several servers.

This process is more likely to hose your config files, so make sure you have them backed up somewhere. (I use subversion for everything in /etc).

This also assumes you are runlevel 3. duh.

1. if you are connected via ssh, use screen. Screen will save your life during long running processes, and generally you should be using it all the time anyway.


2. run an update first:


3. check what you have installed:


4. remove anything you don’t need or use, it will just waste time and cause conflicts. For me, I often find things like OpenOffice or Audio Programs on headless servers. Sometimes I even remove stuff that I know is easy to add back later and isn’t required by the upgrade scripts. (firefox, cups, ImageMagick, crap like that)

yum remove

5. change your repository. The FAQ says you can do this with just installing the fedora-release-10-1.noarch.rpm. but that doesn’t seem to work for me. It gets a conflict that you also need the release notes. This seems to work better:

rpm -U *.rpm

6. clear out the old caches and files so it can detect that you need to update:

yum clean all

7. At this point you can just run “yum upgrade” and cross your fingers. I like to do smaller updates of packages with a lot of dependencies. I have had good results with combination of upgrades like this:


The last one of course upgrading anything not already touched by the others.

8. Depending on your configuration and what you have installed you will probably still have some dependency issues that will need to be resolved. It wouldn’t be life without some issues though right?

DNS Upgrades

Wednesday, July 23rd, 2008

I just spent the night updating all of my DNS servers because of the flaw that was released today. I had thought I could put it off for a few more days and have time to prepare, but that can never be the case.

One of my annoyances with patching Linux, and Bind in particular is that every time I do an upgrade it seems to break something, today is no exception. I patched three fedora core 9 systems, and some version of Cent OS without any problems.

Updating a FC6 system is where the fun came in — I immediately started getting this error on startup:


It took a few hours of googling to find a solution, but it turns out that somewhere between the previous version and this new one (31:9.3.4-8.P1.fc6) it defaults to a chroot configuration..

The fix was to simply copy all of my zone files from:

to the folder:

Postfix + Javamail = disagreement

Sunday, December 9th, 2007

I had a server die on me last week and I needed to reinstall it as quickly as possible. It was running Fedora Core 4. I only had install media for Fedora core 6. I knew it would be a bit of a pain to update all of the config files for everything running on the server, but I figured now is as good a time as any. I would have updated to 7 or 8, but I didn’t have time to download those on CDs (I have 8 on dvd but the server doesn’t have a dvd drive).

Anyway. I updated everything and it all seemed to run swimmingly. I didn’t even have to configure anything too drastically different. I switched from Courier IMAP to Dovecot, but that is another story.

The issue that got me pulling my hair out last night was that my tomcat log kept showing odd smtp related error messages in the stack trace:


After a lot of digging, it seems that javamail sends the RET parameter as described in RFC-1891, even if it is not set up in the config file. Since this is an optional parameter, you would think that leaving it out of your properties file would make javamail not send it to the mail server. It seems it sends “RET=” rather than leaving it out.

It also seems that postfix v2.2.2 ignores “RET=”, but v2.3.3 is a little more strict and expects your parameter to have a value.

I don’t know what application is behaving improperly here. My guess is that postfix is doing the right thing, and that javamail should probably not send the RET parameter, but I guess they could argue that I just need to always configure it in my settings to make sure I’m compliant. (I am using javamail 1.3.0 btw, so it may have changed in newer versions)

to fix the problem, all I had to do was add these two lines to my javamail config properties file:

I found I also had to set the mail.smtp.dns.notify value too, because if I don’t I get this error:


It looks like javamail sends that along as blank as well. weird.