Discussion:
[Dovecot] How Can I Tell How Dovecot Was Installed?
Blake Carver
2008-08-19 17:22:06 UTC
Permalink
I'm trying to help someone with Dovecot, and it looks like this one is
a few versions behind.

They say that they're not sure if it was installed Via an RPM or a
source tarball. Dovecot is use MySQL.

This is a RHEL5 server. There are RPMs listed as installed (rpm -qa)
but I don't know how I can tell what was used to install the currently
used set up. (also asking on the Postifix list)

Is there something in a conf file or something that shows me how it
was installed?

Thanks
Blake
mouss
2008-08-19 20:55:06 UTC
Permalink
Post by Blake Carver
I'm trying to help someone with Dovecot, and it looks like this one is
a few versions behind.
They say that they're not sure if it was installed Via an RPM or a
source tarball. Dovecot is use MySQL.
This is a RHEL5 server. There are RPMs listed as installed (rpm -qa)
but I don't know how I can tell what was used to install the currently
used set up. (also asking on the Postifix list)
Is there something in a conf file or something that shows me how it
was installed?
same method as for postfix :)

more generally,
# rpm -qa
lists all the installed packages

see the rpm man page for more options/functionalities (you can check
which package "owns" a file, and you can get the list of files installed
by a pckage, ... etc).
Roderick A. Anderson
2008-08-19 21:15:31 UTC
Permalink
Post by mouss
Post by Blake Carver
I'm trying to help someone with Dovecot, and it looks like this one is
a few versions behind.
They say that they're not sure if it was installed Via an RPM or a
source tarball. Dovecot is use MySQL.
This is a RHEL5 server. There are RPMs listed as installed (rpm -qa)
but I don't know how I can tell what was used to install the currently
used set up. (also asking on the Postifix list)
Is there something in a conf file or something that shows me how it
was installed?
same method as for postfix :)
more generally,
# rpm -qa
lists all the installed packages
Unless, like he said above it may have been installed via a tarball.

dovecot --version

works for my /really/ ancient version. (Yes, I am too embarrassed to say
which version.) You should and see if there is more than one installed
and if so at how dovecot is started at startup/boot to know which one is
used.

So try a 'which dovecot' to see if you have more than one installed.
And if there is more than one look in /etc/init.d (for SysV-type systems
- YMMV) for a dovecot file and see which one it is calling.


Rod
--
Post by mouss
see the rpm man page for more options/functionalities (you can check
which package "owns" a file, and you can get the list of files installed
by a pckage, ... etc).
Blake Carver
2008-08-20 11:32:30 UTC
Permalink
Thanks Rod,

So I guess my big question here is, how do I upgrade this sucker?
I'd love to just use an RPM, but if this was originally installed via
source will I mess it up?
When I do rpm -qa | grep dovecot I get dovecot-1.0-1.2.rc15.el5
BUT
dovecot --version shows me a different #
Post by Roderick A. Anderson
Unless, like he said above it may have been installed via a tarball.
dovecot --version
You should and see if there is more than one installed and
So --version shows just one version, 1.0.3 (pretty damn old)
Post by Roderick A. Anderson
So try a 'which dovecot' to see if you have more than one installed. And if
there is more than one look in /etc/init.d (for SysV-type systems - YMMV)
for a dovecot file and see which one it is calling.
'which dovecot' just gives me /usr/local/sbin/dovecot

Taking a look at /etc/init.d/dovecot shows me it's staring Dovecot
using /usr/local/sbin/dovecot
and
ps auxw | grep dovecot does show that's the one that's running
/usr/local/sbin/dovecot
Roderick A. Anderson
2008-08-20 14:54:43 UTC
Permalink
Post by Blake Carver
Thanks Rod,
So I guess my big question here is, how do I upgrade this sucker?
I'd love to just use an RPM, but if this was originally installed via
source will I mess it up?
When I do rpm -qa | grep dovecot I get dovecot-1.0-1.2.rc15.el5
I think the default for RHEL 5. CentOS 5, etc.
Post by Blake Carver
BUT
dovecot --version shows me a different #
Meaning your are not running the RPM installed version.
Post by Blake Carver
Post by Roderick A. Anderson
Unless, like he said above it may have been installed via a tarball.
dovecot --version
You should and see if there is more than one installed and
So --version shows just one version, 1.0.3 (pretty damn old)
Post by Roderick A. Anderson
So try a 'which dovecot' to see if you have more than one installed. And if
there is more than one look in /etc/init.d (for SysV-type systems - YMMV)
for a dovecot file and see which one it is calling.
'which dovecot' just gives me /usr/local/sbin/dovecot
Taking a look at /etc/init.d/dovecot shows me it's staring Dovecot
using /usr/local/sbin/dovecot
My guess (without know what "dovecot --version" reported) would be that
you are probably running a tarball installed version.

A quick check of the repositories, including rpmforge, indicates the
latest "official distribution" version is 1.0.7-2.el5.

To get the latest and greatest you'll have to either build your own RPM
or do a tarball install.


Good computing,
Rod
--
Post by Blake Carver
and
ps auxw | grep dovecot does show that's the one that's running
/usr/local/sbin/dovecot
Charles Marcus
2008-08-20 15:23:13 UTC
Permalink
Post by Roderick A. Anderson
To get the latest and greatest you'll have to either build your own
RPM or do a tarball install.
Or just use atrpms.net...

Why anyone would knowingly run ancient versions of critical apps is
beyond me.
--
Best regards,

Charles
Stewart Dean
2008-08-20 15:35:37 UTC
Permalink
Because it isn't busted?
Post by Charles Marcus
Why anyone would knowingly run ancient versions of critical apps is
beyond me.
--
====
Stewart Dean, Unix System Admin, Henderson Computer Resources
Center of Bard College, Annandale-on-Hudson, New York 12504
sdean at bard.edu voice: 845-758-7475, fax: 845-758-7035
Charles Marcus
2008-08-20 15:46:22 UTC
Permalink
Post by Stewart Dean
Because it isn't busted?
Just because you don't *think* its busted doesn't mean its not...

Of course, I'm not saying that running an up to date version completely
solves this question - *all* s/w has bugs, its just a matter of when
they are discovered - but I'd rather be running a version that has fixes
for *known* bugs/issues - not to mention the performance improvements,
new features, etc.

But of course, thats the nice thing about free software... we're all
free to do it our way...

:)
--
Best regards,

Charles
Kenneth Porter
2008-08-20 21:41:29 UTC
Permalink
--On Wednesday, August 20, 2008 11:23 AM -0400 Charles Marcus
Post by Charles Marcus
Why anyone would knowingly run ancient versions of critical apps is
beyond me.
Stability. It's not uncommon for apps to be interdependent. Upgrading one
can have unexpected consequences in another app.

For this reason, RHEL back-ports fixes for critical apps rather that
automatically upgrading to the latest version. For it to do so, it needs to
have patches for specific issues registered in Bugzilla.

For those of us willing to take the risk of wholesale upgrade to the
bleeding edge, we can grab an RPM from Red Hat's Rawhide distro. My
practice is usually to grab the source RPM and rebuild it to match the
libraries I have on my distro (CentOS 5).

In some cases, 3rd party distros like atrpms.net and RPMForge carry the
latest version pre-built for many distros. If I need a package that
RPMForge supports, I'll grab the binary from there.
mouss
2008-08-20 16:05:11 UTC
Permalink
Post by Blake Carver
Thanks Rod,
So I guess my big question here is, how do I upgrade this sucker?
I'd love to just use an RPM, but if this was originally installed via
source will I mess it up?
When I do rpm -qa | grep dovecot I get dovecot-1.0-1.2.rc15.el5
BUT
dovecot --version shows me a different #
Post by Roderick A. Anderson
Unless, like he said above it may have been installed via a tarball.
dovecot --version
You should and see if there is more than one installed and
So --version shows just one version, 1.0.3 (pretty damn old)
Post by Roderick A. Anderson
So try a 'which dovecot' to see if you have more than one installed. And if
there is more than one look in /etc/init.d (for SysV-type systems - YMMV)
for a dovecot file and see which one it is calling.
'which dovecot' just gives me /usr/local/sbin/dovecot
Taking a look at /etc/init.d/dovecot shows me it's staring Dovecot
using /usr/local/sbin/dovecot
and
ps auxw | grep dovecot does show that's the one that's running
/usr/local/sbin/dovecot
so you're somewhat lucky: the software was installed (probably from
source) in a well known place (/usr/local). you can remove this by
looking at all dovecot and postfix files under /usr/local/. you can do
the same for other software. yum and rpm don't install software in
/usr/local/. you'll have to remove startup scripts as well.

once you've removed all the "old" stuff, you can install new packages
(if you have a development env somewhere, you can build recent SRPMs
instead of using the old available ones).
Kenneth Porter
2008-08-20 02:02:45 UTC
Permalink
--On Tuesday, August 19, 2008 1:22 PM -0400 Blake Carver
Post by Blake Carver
They say that they're not sure if it was installed Via an RPM or a
source tarball. Dovecot is use MySQL.
This is a RHEL5 server. There are RPMs listed as installed (rpm -qa)
but I don't know how I can tell what was used to install the currently
used set up. (also asking on the Postifix list)
Is there something in a conf file or something that shows me how it
was installed?
RPM is a database of installed files and their checksums. The RPM commands
unpack files and update the database, or remove files and update the
database. The best you can do here is to query the database to see if the
files it knows about match those on the disk. For that, use "rpm -V -v
dovecot". That does a verbose verify and tells you what files it knows
about have been changed in some way.

I recommend periodically running "rpm -Va" and dumping the result to a
file. This will reflect the current state of the system. (You should expect
that configuration files will show up in this report as modified.) Then
create a cron job that performs the same command and diffs the result
against your snapshot. This will alert you of any unexpected changes.
Blake Carver
2008-08-20 11:35:39 UTC
Permalink
Thanks Kenneth
Post by Kenneth Porter
The best you can do here is to query the database to see if the
files it knows about match those on the disk. For that, use "rpm -V -v
dovecot". That does a verbose verify and tells you what files it knows about
have been changed in some way.
I guess I'm not quite sure how to interpret this to help me figure out
my problem, there are changes rpm reports, does this mean that an RPM
was installed but so was a source package?

rpm -V -v dovecot
........ c /etc/dovecot.conf
........ c /etc/pam.d/dovecot
........ c /etc/pki/dovecot/dovecot-openssl.cnf
S.5....T c /etc/rc.d/init.d/dovecot
........ /usr/lib/dovecot
........ /usr/lib/dovecot/imap
........ /usr/lib/dovecot/imap/lib01_acl_plugin.so
........ /usr/lib/dovecot/imap/lib01_convert_plugin.so
........ /usr/lib/dovecot/imap/lib01_quota_plugin.so
........ /usr/lib/dovecot/imap/lib01_zlib_plugin.a
........ /usr/lib/dovecot/imap/lib01_zlib_plugin.la
........ /usr/lib/dovecot/imap/lib01_zlib_plugin.so
........ /usr/lib/dovecot/imap/lib02_imap_quota_plugin.a
........ /usr/lib/dovecot/imap/lib02_imap_quota_plugin.la
........ /usr/lib/dovecot/imap/lib02_imap_quota_plugin.so
........ /usr/lib/dovecot/imap/lib02_trash_plugin.so
........ /usr/lib/dovecot/lda
........ /usr/lib/dovecot/lda/lib01_acl_plugin.so
........ /usr/lib/dovecot/lda/lib01_convert_plugin.so
........ /usr/lib/dovecot/lda/lib01_quota_plugin.so
........ /usr/lib/dovecot/lda/lib02_trash_plugin.so
........ /usr/lib/dovecot/lib01_acl_plugin.a
........ /usr/lib/dovecot/lib01_acl_plugin.la
........ /usr/lib/dovecot/lib01_acl_plugin.so
........ /usr/lib/dovecot/lib01_convert_plugin.a
........ /usr/lib/dovecot/lib01_convert_plugin.la
........ /usr/lib/dovecot/lib01_convert_plugin.so
........ /usr/lib/dovecot/lib01_quota_plugin.a
........ /usr/lib/dovecot/lib01_quota_plugin.la
........ /usr/lib/dovecot/lib01_quota_plugin.so
........ /usr/lib/dovecot/lib02_trash_plugin.a
........ /usr/lib/dovecot/lib02_trash_plugin.la
........ /usr/lib/dovecot/lib02_trash_plugin.so
........ /usr/lib/dovecot/pop3
........ /usr/lib/dovecot/pop3/lib01_convert_plugin.so
........ /usr/lib/dovecot/pop3/lib01_quota_plugin.so
........ /usr/libexec/dovecot
........ /usr/libexec/dovecot/checkpassword-reply
........ /usr/libexec/dovecot/deliver
prelink: /usr/libexec/dovecot/dict: at least one of file's
dependencies has changed since prelinking
S.?..... /usr/libexec/dovecot/dict
prelink: /usr/libexec/dovecot/dovecot-auth: at least one of file's
dependencies has changed since prelinking
S.?..... /usr/libexec/dovecot/dovecot-auth
........ /usr/libexec/dovecot/gdbhelper
........ /usr/libexec/dovecot/imap
prelink: /usr/libexec/dovecot/imap-login: at least one of file's
dependencies has changed since prelinking
S.?..... /usr/libexec/dovecot/imap-login
........ /usr/libexec/dovecot/pop3
prelink: /usr/libexec/dovecot/pop3-login: at least one of file's
dependencies has changed since prelinking
S.?..... /usr/libexec/dovecot/pop3-login
........ /usr/libexec/dovecot/rawlog
prelink: /usr/libexec/dovecot/ssl-build-param: at least one of file's
dependencies has changed since prelinking
S.?..... /usr/libexec/dovecot/ssl-build-param
........ /usr/sbin/dovecot
prelink: /usr/sbin/dovecotpw: at least one of file's dependencies has
changed since prelinking
S.?..... /usr/sbin/dovecotpw
........ /usr/share/doc/dovecot-1.0
........ d /usr/share/doc/dovecot-1.0/REDHAT-FAQ.txt
........ d /usr/share/doc/dovecot-1.0/USE-WIKI-INSTEAD
........ /usr/share/doc/dovecot-1.0/UW-to-Dovecot-Migration
........ d /usr/share/doc/dovecot-1.0/UW-to-Dovecot-Migration/maildir-migration.txt
........ d /usr/share/doc/dovecot-1.0/UW-to-Dovecot-Migration/migrate-folders
........ d /usr/share/doc/dovecot-1.0/UW-to-Dovecot-Migration/migrate-users
........ d /usr/share/doc/dovecot-1.0/UW-to-Dovecot-Migration/perfect_maildir.pl
........ d /usr/share/doc/dovecot-1.0/auth-protocol.txt
........ d /usr/share/doc/dovecot-1.0/auth.txt
........ d /usr/share/doc/dovecot-1.0/configuration.txt
........ d /usr/share/doc/dovecot-1.0/design.txt
........ /usr/share/doc/dovecot-1.0/examples
........ d /usr/share/doc/dovecot-1.0/examples/dovecot-ldap.conf
........ d /usr/share/doc/dovecot-1.0/examples/dovecot-sql.conf
........ d /usr/share/doc/dovecot-1.0/examples/mkcert.sh
........ d /usr/share/doc/dovecot-1.0/index.txt
........ d /usr/share/doc/dovecot-1.0/mail-storages.txt
........ d /usr/share/doc/dovecot-1.0/multiaccess.txt
........ d /usr/share/doc/dovecot-1.0/nfs.txt
........ d /usr/share/doc/dovecot-1.0/securecoding.txt
........ d /usr/share/doc/dovecot-1.0/variables.txt
........ /var/lib/dovecot
........ /var/run/dovecot
........ /var/run/dovecot/login
Kenneth Porter
2008-08-20 21:47:22 UTC
Permalink
--On Wednesday, August 20, 2008 7:35 AM -0400 Blake Carver
Post by Blake Carver
I guess I'm not quite sure how to interpret this to help me figure out
my problem, there are changes rpm reports, does this mean that an RPM
was installed but so was a source package?
rpm -V -v dovecot
........ c /etc/dovecot.conf
This is a config file, as denoted by the "c". The row of dots means the
file is pristine (hasn't been modified since it was installed).
Post by Blake Carver
S.5....T c /etc/rc.d/init.d/dovecot
This config file is different from the package. I don't recall what all the
flags mean but the "5" means an MD5 checksum mismatch. As a rule,
initscripts shouldn't be modified unless you're doing something tricky, so
this was likely replaced from a tarball install.
Post by Blake Carver
prelink: /usr/libexec/dovecot/dict: at least one of file's
dependencies has changed since prelinking
S.?..... /usr/libexec/dovecot/dict
prelink: /usr/libexec/dovecot/dovecot-auth: at least one of file's
dependencies has changed since prelinking
S.?..... /usr/libexec/dovecot/dovecot-auth
All of these prelink errors suggest that your binaries were overwritten
from a tarball installation. The easy fix is to erase ("rpm -e") the
package and re-install it, likely upgrading to a newer package at the same
time.
Post by Blake Carver
........ d /usr/share/doc/dovecot-1.0/REDHAT-FAQ.txt
"d" files are documentation, and if you're tight on disk space, you can
suppress installation of documentation when the package is installed.
Scott Silva
2008-08-21 16:42:43 UTC
Permalink
Post by Kenneth Porter
--On Wednesday, August 20, 2008 7:35 AM -0400 Blake Carver
Post by Blake Carver
I guess I'm not quite sure how to interpret this to help me figure out
my problem, there are changes rpm reports, does this mean that an RPM
was installed but so was a source package?
rpm -V -v dovecot
........ c /etc/dovecot.conf
This is a config file, as denoted by the "c". The row of dots means the
file is pristine (hasn't been modified since it was installed).
Post by Blake Carver
S.5....T c /etc/rc.d/init.d/dovecot
This config file is different from the package. I don't recall what all
the flags mean but the "5" means an MD5 checksum mismatch. As a rule,
initscripts shouldn't be modified unless you're doing something tricky,
so this was likely replaced from a tarball install.
Post by Blake Carver
prelink: /usr/libexec/dovecot/dict: at least one of file's
dependencies has changed since prelinking
S.?..... /usr/libexec/dovecot/dict
prelink: /usr/libexec/dovecot/dovecot-auth: at least one of file's
dependencies has changed since prelinking
S.?..... /usr/libexec/dovecot/dovecot-auth
All of these prelink errors suggest that your binaries were overwritten
from a tarball installation. The easy fix is to erase ("rpm -e") the
package and re-install it, likely upgrading to a newer package at the
same time.
But a rpm install will not overwrite the tarball install since tarball
installs usually go to /usr/local or under /opt while rpm installs will go
into /usr directly. I don't know if the tarball has a make uninstall command,
but the previous admin "should" have left the unpacked source around from the
install somewhere in either /root or in his home directory. That can give more
clues.
Post by Kenneth Porter
Post by Blake Carver
........ d /usr/share/doc/dovecot-1.0/REDHAT-FAQ.txt
"d" files are documentation, and if you're tight on disk space, you can
suppress installation of documentation when the package is installed.
--
MailScanner is like deodorant...
You hope everybody uses it, and
you notice quickly if they don't!!!!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://dovecot.org/pipermail/dovecot/attachments/20080821/1b5b5838/attachment.bin
mouss
2008-08-21 17:38:18 UTC
Permalink
Post by Scott Silva
Post by Kenneth Porter
All of these prelink errors suggest that your binaries were
overwritten from a tarball installation. The easy fix is to erase
("rpm -e") the package and re-install it, likely upgrading to a newer
package at the same time.
But a rpm install will not overwrite the tarball install since tarball
installs usually go to /usr/local or under /opt while rpm installs will
go into /usr directly.
sure, but
- if you intend to always build from sources, you don't really care
about packages. it's only once you get a problem that you start becoming
more careful.
- however you do it, init scripts generally go under /etc (at least
under Linux).
Post by Scott Silva
I don't know if the tarball has a make uninstall
This almost never exists. it is not easy to implement (because you don't
want to remove files installed otherwise) without implementing a package
manager. an install.log would be nice though...
Post by Scott Silva
command, but the previous admin "should" have left the unpacked source
around from the install somewhere in either /root or in his home
directory. That can give more clues.
well, he could "should", but "he" generally would never :-)

OP can try to find the distribution that was installed from source and
use it to determine which files it installs, or he could ignore it and
only remove the files that create problems with a new version. if he is
motivated enough, reinstalling the whole system may be worth the pain.
Post by Scott Silva
Post by Kenneth Porter
Post by Blake Carver
........ d /usr/share/doc/dovecot-1.0/REDHAT-FAQ.txt
"d" files are documentation, and if you're tight on disk space, you
can suppress installation of documentation when the package is installed.
or buy more disk ;-p

Continue reading on narkive:
Search results for '[Dovecot] How Can I Tell How Dovecot Was Installed?' (Questions and Answers)
4
replies
Turning Outlook into a POP3 Server?
started 2009-06-24 08:06:19 UTC
software
Loading...