Updated openssl and now nothing works
 

Hay guys.
I've been googling around and have had a bit of a hard time trying to find help with this little issue.

Managed to install CouchDB on the server at work after doing some fiddling due to not having spidermonkey available.

Anyways, part of this involved updating openssl. After doing this however all hell broke loose.
It seems a lot of programs needed the old version-
I keep getting:
error while loading shared libraries: libssl.so.0.9.8: cannot open shared object file: No such file or directory

I did a search:
>locate libssl.so.0.9.8

And it returned:
/usr/lib/libssl.so.0.9.8

So apparently it exists still.

How can I fix this? It seems to have affected pacman too so this may need a manual install :(

Thanks guys

System info:
Arch Linux
Kernal: 2.6.32.6

:MAYBE: it still exists. You could have located the symbolic link, which is now broken. Do an "ls -l" on that, to see if it's a link, and then follow that link to see if the target is still valid.

Hay there
Quick update, it appears that version 1.0.0 is now showing up on locates.

There have been a number of other library files that have different versions to what a program was expecting. I ave been quick fixing these by copying them and renaming them to the versions needed by the programs. So far this seems to be fixing the issues but I am not entirely sure that this is a safe or responsible way of going about fixing this.

Is there just a way to do a full system update to bring everything up to the right versions?

Thanks again guys.

(I really need to convince my boss to put me on a training course XD)

Updates are dangerous things, in my opinion. The best way to 'update' from one version to another, is to back your data up, and do a fresh install of the latest version of your OS.

I'm assuming here that you mean you're going from something like Arch 2009.08 to 2010.05, not just updating a package. Updating one package is fine, but if you're updating a bunch of things, or run a system-upgrade from the install media, you're often left with a bunch of older packages hiding in places you don't want, which leads to 'interesting' results. Most systems have an updater applet that will contact the online repositories, and allow you to upgrade things. Not sure about Arch, but I'd be surprised if they didn't.

Hay there, I guess Ubuntu has spoiled me a bit there... Did a full OS update on that on my home laptop. The Arch setup we have at work is command line only due to a previous (and more linux savvy) employees aversion to all things shiny and GUI based.

A full reformat and reinstall, perhaps with Ubuntu or Fedora or something like that would be ideal but I can't fully guarantee we would have a fully working server by the end and nobody wants the server taken down for the few days it might take me D:


I'm babbling now. Thanks a lot for the advice.

If you're in a work environment, I can offer a possible path that may ease the transition.

If you have another box it's best, but if not, you can still do this. First, get a hard drive (either new, or one you don't mind blowing away). Put it in the test/development box, and do your clean install/load on it. Once it's on the network, copy over the data/config files/whatever from the old box. TEST the services, and make sure it's working. When upgrade day comes, shut them both down, and swap hard drives. Chances are, if it's the same architecture, etc., it'll come right up. You may have to edit the network configuration (unless you move NIC's over too), but that's a small thing.

If you DON'T have a test box, back up your data to something (other system on network, NFS, CD/DVD, etc.), then pull the existing drive from the box and set it aside. Put the new drive into that box, load/install, then restore data/test. You can do this over multiple days, too, if you work late/come in early, and have a maintenance window. When you need to have the box back up, you can swap drives, and reboot...nothing changed. When you've got things done to a point you feel comfortable with, keep the old drive in your desk for a while. If something horrible happens, you can take 10 minutes and swap drives back, with zero loss of data.

Either way...your old drive will be safe, unchanged, and available, and your production system won't be down for a day+ for the upgrade. If it's a server, consider loading a non-fasttrack distro, like CentOS, that doesn't do major upgrades often.

Hay, that's some pretty sound advice. I have a spare machine at home I can bring in and use as a test machine.

One thing might make it a little complicated: It does not use a single hard drive but 3 arranged in a RAID 5 array.

After talking with some folks it seems a mirror system might be best for quick disk recovery though. I am considering getting a 4th disk ordered and just having 2 sets of mirrored drives.

I don't know about that....RAID5 is my preferred way to go, but that's just me.

And you're right about the RAID making it complicated, but if it's for your office, and it's a production box, asking them to spring for some upgrade/test hardware isn't alot to ask.

Heh, I'll see what I can do about getting some more hardware. We are a small business so I am constantly conciouse about how much we spend on equipment.
I have an idea for backup and a temporary system, time to plan the system upgrade and reinstall and submit it for approval.

One final question
The machine is reasonably powerful and is mainly used for file storage, hosting a test version of our website and a test CouchDB database. Is there any reason why Ubuntu would not be a good choice of distro?

Not at all. Pretty much ANY distro would be good, but again, if this is a server/production box, think about the distro carefully. For example, openSUSE has gone from 10.3 to 11.3 VERY quickly, and Ubuntu climbs quick too. Major version updates means that EOL cycles for older ones come up quickly too.

A 'server' OS (CentOS, RedHat or SuSE enterprise), is designed to evolve slowly. Packages are updated, long life cycle, but major releases take a good while. Totally your call, and it'll work regardless, but CentOS and Ubuntu cost the same. :)