# shared object "libcrypto.so.7" not found



## Curt Winter (Feb 21, 2015)

Last night we installed a new UPS unit, which meant shutting down all our servers.

Our FTP server runs on FreeBSD and when it was brought back up we get shared object "libcrypto.so.7" not found message for the Proftpd, NTPD, SSHD, and SENDMAIL all fail to start because of this.  So the FTP server is now in a non-working state.

I did a locate libcrypto.so.7 the result was:
/usr/lib32/libcrypto.so.7

I tried to create a sym link to libcrypto.so.7 but when I tried to start the packages it said the file was not correct.

What do I need to do get the correct libcrypto.so.7 back in place and allow all the dependent programs to run again?

Any help would be greatly appreciated.

Curt Winter


----------



## free-and-bsd (Feb 21, 2015)

Should be /lib/libcrypto.so.7. The one you found is a 32-compatibility lib.

Anyway, more information about your system won't hurt.


----------



## Curt Winter (Feb 21, 2015)

What kind of information do you need?  I am new to the FreeBSD as a Certified Microsoft Professional I am a bit out of my zone.  Please let me know what I can provide to help the troubleshooting process.

Thank you.

Curt Winter


----------



## abishai (Feb 21, 2015)

Use `freebsd-version` to find out what version of FreeBSD you've got. After that get base.txz for your version ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/ here , unpack it somewhere and copy missing file to /lib.
I recommend to run `freebsd-update IDS` after that as files from `/lib` shouldn't be missing.


----------



## NewGuy (Feb 21, 2015)

It might help if we knew which version of FreeBSD you are running and which architecture you are running on. You can probably get most of the useful info that would help by running the command

```
uname -a
```
and pasting whatever output appears here on the forum.

My guess as to what happened is perhaps the services were upgraded, but for some reason the underlying dependencies were not updated at the same time. (This mailing list post talks about the possibility: http://lists.freebsd.org/pipermail/freebsd-current/2012-July/035535.html)

You might try backing up your configuration files and doing a re-install of the affected services.

By the way, welcome to the world of FreeBSD.


----------



## Curt Winter (Feb 22, 2015)

Version Info:
FreeBSD 10.0-RELEASE-p9

Ok in Windows I would use a browser to download the file to where I wanted it and explorer to launch it, so how do I accomplish this:



abishai said:


> After that get base.txz for your version ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/ here , unpack it somewhere and copy missing file to /lib.


...in FreeBSD?

Thanks again for all the help.

Curt Winter


----------



## tobik@ (Feb 22, 2015)

fetch(1) or ftp(1). For unpacking use tar(1).


----------



## NewGuy (Feb 22, 2015)

More specifically, from the FreeBSD command prompt, run the following to download the file.

```
fetch ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/10.0-RELEASE/base.txz
```
Using tar as follows will unpack it.

```
tar xzf base.txz
```


----------



## hukadan (Feb 22, 2015)

> Using tar as follows will unpack it.
> 
> ```
> tar xzf base.txz
> ```


I think the right command would be `[DEL]tar xfp base.txz -C / [/DEL]`.
The -z option, according to tar(1), is only valid with the -c option and is ignored on extract mode.
--- Edit ---
See bellow why it is a *bad idea*... Sorry for this bad advice. I used this command with lib32.txz and it worked fine. I should not have generalized.


----------



## diizzy (Feb 22, 2015)

I would be more concerned why this happened in the first place.
//Danne


----------



## kpa (Feb 22, 2015)

hukadan said:


> I think the right command would be `tar xfp base.txz -C /`. The `-z` option, according to tar(1) is only valid with the `-c` option and is ignored on extract mode.



Please don't do that or instruct anyone else to do that either! What this does is that it overwrites all /etc/* configuration files unconditionally including /etc/master.passwd which means you will lose all of you non-default user accounts and all passwords that are set.


----------



## NewGuy (Feb 22, 2015)

hukadan said:


> I think the right command would be `[DEL]tar xfp base.txz -C / [/DEL]`.
> The `-z` option, according to tar(1), is only valid with the `-c` option and is ignored on extract mode.
> --- Edit ---
> See bellow why it is a *bad idea*... Sorry for this bad advice. I used this command with lib32.txz and it worked fine. I should not have generalized.



The tar(1) command I posted above, `tar xzf`, does work, I use it all the time and the -z option does not require -c. If the manual page says so, then it is obvously wrong, I've been doing it this way for years.


----------



## chrbr (Feb 22, 2015)

I have just run a short test using two text files as below.

```
Script started on Sun Feb 22 16:08:39 2015
# ls
d.txt  r.txt
# tar -czf tmp.tgz *.txt
# rm *.txt
# ls
tmp.tgz
# tar -xzf tmp.tgz
# ls
d.txt  r.txt  tmp.tgz
# rm *.txt
# tar -cxzf tmp.tgz
tar: Can't specify both -x and -c
# tar -xf tmp.tgz
# ls
d.txt  r.txt  tmp.tgz
# exit
```
I think there is just a misunderstanding.


hukadan said:


> The -z option, according to tar(1), is only valid with the  -c option and is ignored on extract mode.


In my opinion the meaning is that -z is only possible when creating a new archive using -c. Updating compressed archives using the -u or -r option is not possible. The option -z is ignored on extract mode. This matches with the man page about option -z.


----------



## junovitch@ (Feb 22, 2015)

The first thing I would recommend is to check `freebsd-update IDS` and post the output here.  Files shouldn't just go missing on your hard drive for no reason.  You can exclude anything that command finds in the /etc/ directory as that's a given that configuration files in that directory would get picked up by `freebsd-update IDS` as changing from what was installed.

The second thing is to fix it.  As said above it's easy enough to grab the base.txz file and replace what went missing.  I would stick everything in the /tmp and only replace what's needed.
`fetch http://ftp.FreeBSD.org/pub/FreeBSD/releases/amd64/10.0-RELEASE/base.txz``tar xvzf base.txz -C /tmp`
`cp /tmp/lib/libcrypto.so.7 /lib/libcrypto.so.7`

Since you are a Microsoft Certified person you are likely familiar how things get done there with DLL libraries and how they get split between Windows\system32 and Windows\SysWOW64 on a Windows system.  FreeBSD is similar in concept as shared object, .so, libraries are split up in /lib and /lib32 directories.  There are actually in several places in the file system hierarchy depending on what they do.  See the hier(7) man page for more info on the file system layout.


----------



## Curt Winter (Feb 23, 2015)

Ok Ran `freebsd-update IDS`:

```
looking up update.freebsd.org mirrors . . . shared object "libcrypto.so.7" not found, required by "host"
none found.
Fetching public key from update.freebsd.org . . . failed.
no mirrors remaining, giving up.
```

Ok tried the fetch:

```
shared object "libcrypto.so.7" not found, required by "fetch"
```

rebooted into single user and tried again.

`freebsd-update IDS`

```
FreeBSD-update: Directory does not exist or is not writeable: var/db/FreeBSD-update
```

So I ran a `fsck -f -y`

```
File system is clean
file system was modified
```

Tried the `fetch`:

```
shared object "libcrypto.so.7" not found, required by "fetch"
```

How can these files suddenly disappear from turn off to turn on?

Frustrating

Curt


----------



## junovitch@ (Feb 23, 2015)

Alright, let's fix the missing libcrypto.so.7 first.  Same steps for that but use `ftp http://ftp.FreeBSD.org/pub/FreeBSD/releases/amd64/10.0-RELEASE/base.txz` instead as ftp(1) doesn't need libcrypto.so.7.


----------



## Curt Winter (Feb 23, 2015)

Ok the ftp worked it downloaded the base.txz, when I tried the tar command:

`tar xvzf base.txz -C /tmp`
It returned:

```
shared object "libcrypto.so.7" not found, required by "tar"
```


----------



## junovitch@ (Feb 23, 2015)

Use `/rescue/tar`.  The stuff in the /rescue is all statically linked and does not need external libraries.


----------



## Curt Winter (Feb 23, 2015)

YES! The `/rescue/tar` worked expanded all the files.  Then I was able to copy the file, reboot and now the FTP server is up and working again.

Thanks everyone for all the help and hand holding.

Have a great week.

Curt Winter


----------



## wblock@ (Feb 23, 2015)

This thread appears to be a train wreck I missed.  Symlinking libraries is a bad idea.  Overwriting existing libraries by extracting an archived tar file also seems like a bad idea, but there was a bug in freebsd-update(8) lately, and maybe that is related.

Many people try to avoid reboots, but that can be a mistake.  The problem with avoiding them is that when they happen after an unexpected power cycle, you won't know whether the software will all still work, as happened here.  Whatever method you use to upgrade the operating system, testing with a reboot afterwards is a good idea.


----------



## Curt Winter (Feb 23, 2015)

I did not upgrade anything, I `init 0` to shutdown the box, upgraded the UPS unit and when I turned it back on I had the errors.

Again thanks to the people who provided constructive posts which lead to the resolution of the issue.

Curt


----------



## wblock@ (Feb 23, 2015)

Something changed in the operating system.  Usually this is due to an upgrade, often with freebsd-update(8).

shutdown(8) is recommended rather than running init(8) directly.  It gives services a chance to do a clean stop.

Some people never encounter problems due to library symlinks or overwriting current binaries with old ones.  Those that do find them to be mysterious and often very difficult to diagnose.


----------



## Curt Winter (Feb 23, 2015)

Happy to use Shutdown in the future, thanks for the tip.

Curt


----------



## junovitch@ (Feb 23, 2015)

With the immediate problem fixed there still might be a bigger picture issue.  The libcrypto.so.7 should not have just gone missing.  It may change during upgrades as wblock@ implied and some folks do try to symlink shortcuts together to do what they believe is a "fix".  However, library versions change for a reason so if things do happen to work it's still a ticking time bomb before something breaks.

With that said, the steps you did should not have caused a file to go missing.  An upgrade while simultaneously pulling the power plug before the file was saved might do it.  A disk issue might be a cause but you would likely have more issues than one file.  Human error on the part of a prior admin might have done it.  It's hard to say.  If the system was maintained via binary updates or is a fresh install then `freebsd-update IDS` is the quickest thing you can do check the integrity of the system against what should be 10.0-RELEASE.  I would highly recommend you run that command and if any files outside of /etc show up then be proactive and ask for some help before any more problems are found in the future.


----------



## Curt Winter (Feb 24, 2015)

Do updates install themselves automatically like in Windows Update?

Should I run the `freebsd-update IDS` under Multi User or Single User Mode?  What is the difference?  I know in the past I had an issues that I needed to run `fsck` to fix, but that needed to be done in single mode.

I inherited the server and supporting it, so I have no idea how it was originally created, I have to reverse engineering everything I do with it.  I appreciate the input and tasks I should be doing to ensure proper running into the future.

Curt


----------



## NewGuy (Feb 24, 2015)

By default, updates do not install automatically. Usually you need to run

```
freebsd-update fetch
freebsd-update install
```

It is possible those commands are run automatically in the /etc/crontab file, set up by the previous admin, but otherwise the updates would be handled manually by the admin.


----------



## junovitch@ (Feb 24, 2015)

FreeBSD doesn't install updates by default.  Generally FreeBSD sticks to the idea of POLA, short for principle of least astonishment.  Since doing something you didn't ask for could be considered a surprise then it doesn't happen.

You'll want to take a a look at the Handbook chapter on FreeBSD Update.
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html

FreeBSD 10.0-RELEASE is also coming up on end of life soon.  The `freebsd-update fetch; freebsd-update install` process applies security patches without changing the release.  The `freebsd-update -r 10.1-RELEASE upgrade` command would do a version bump but has a bit more steps.  You'll most likely want to install 10.0-RELEASE in a VM and go through the steps before updating.  There is a bit of manual work to merge config files with a text editor to upgrade to 10.1-RELEASE.  It's a fairly easy process if you are used to it but if you aren't it can be a bit odd at first.
http://www.freebsd.org/security/security.html#sup

Once you update, FreeBSD 10.1-RELEASE is supported for security updates until Dec 31, 2016 so you things will be easier.  Generally you'll want to use the cron argument to download updates at night and install them on your own schedule.  Here is an example I use that I added using `crontab -e` to add it to my root user's schedule jobs.  Normally, that is preferred over adding it to the system /etc/crontab although a prior admin may have done so.

```
30      5       *       *       tue,sat /usr/sbin/freebsd-update cron
```

To answer your earlier question, `freebsd-update IDS` is good to run in multi user mode.  Mostly it's stuff dealing with disks where it's best to be in single user mode.


----------

