My version output is below, under the heading "My actual question".
Background to my woes:
I installed a new virtual machine with CentOS 6.9 (I'll refer to it as xxserverxx) and included the postfix server. I configured a virtual network, did a decent job of hardening firewalls for both physical host and virtual guests. I was able to get mail / mailx to send and receive mail on the command line using postfix using Maildir delivery. Sent and received email to/from self as well as from an external email address hosted elsewhere.
But not being satisfied enough with mailx mail client...
wanting an IMAP client on the same 192 virtual private subnet, I used yum to install dovecot package from CentOS repositories on the virtual mail guest server.
Configured mail client (Evolution installled via graphical interface on a CentOS 6.9 workstation on the same subnet), and configured dovecot, used mbox delivery, struggled with documentation to understand how server mail directories/files are actually used, fixed a problem or two, but did not have IMAP send and receive working.
Then, wanting to be on the latest stable version of dovecot anyway, I downloaded dovecot 2.3.0 from dovecot.org and attempted to follow the instructions on building from source, but in the end all I could really find was the simple sequence of steps, make configure, make and make install, so that's what I did.
Continued struggling with configuration (needing to be somewhat certain that defaults would not create a completely wide open mail server that would be hacked in 10 minutes, since this is on a real physical host with a public ip. I actually got an email to get appended to the users mbox file. Evolution Email client at one point actually logged into dovecot/IMAP and retrieved 3 received emails. The problem is that Email client is now failing on permissions in creating index files. I've gotten to the point of going to extreme measures to "fix" that file creation problem, but to no avail.
Now unfortunately I've found an underlying problem to everything, going back to the beginning where I upgraded dovecot.
My actual question:
I don't want troubleshooting help, but help with documentation.
It appears that make install has not replaced the old 2.0.9 binaries with new 2.3.0 binaries, even though it faithfully created everying under the /usr directories, e.g., /usr/bin, etc., and make install did not set some variable or otherwise configure for the new version to run instead of the old. Well, maybe.
Very scary (to me) in my maillog file, starting up and shutting down doevcot...
Jan 6 16:15:59 xxserverxx dovecot: master: Dovecot v2.0.9 starting up (core dumps disabled)
Jan 6 16:16:05 xxserverxx dovecot: master: Warning: Killed with signal 15 (by pid=5983 uid=0 code=kill)
Jan 6 16:16:16 xxserverxx dovecot: master: Dovecot v2.0.9 starting up (core dumps disabled)
Jan 6 16:21:02 xxserverxx dovecot: master: Warning: Killed with signal 15 (by pid=6056 uid=0 code=kill)
Jan 6 16:23:39 xxserverxx dovecot: master: Dovecot v2.0.9 starting up (core dumps disabled)
Precisely how should this 2.3.0, built from source, be properly installed and configured to actually run the new version ?
Here is what I currently get from --version and -n, just running in my root directory:
[root@xxserverxx ~]# dovecot --version
[root@xxserverxx ~]# dovecot -n
# 2.3.0 (c8b89eb): /usr/local/etc/dovecot/dovecot.conf
doveconf: Fatal: open(/usr/local/etc/dovecot/dovecot.conf) failed: No such file or directory (copy example configs from /usr/local/share/doc/dovecot/example-config/)
Here is root's path:
[root@xxserverxx ~]# env|grep -i path
Perhaps, of course, the new versions are running. Of course, it appears that the dovecot executable can't find config files. So why would my maillog say that the old version is running ? Perhaps it's the new executable running with some leftover config from the old version ?
Obviously I have not a clue as to the following, and these are my questions:
a) what determines from which directories are each and every dovecot executable runs (i.e., normal plus any oddball) ?
b) under what userid is each one run ?
c) what determines from which directories are each and every dovecot config file is read ?
d) when I install a new version of dovecot, how do I control which versions of config and executables are used at runtime ?
Is there a place in the documentation where all this is contained in one place in a nice organized table ?
My mitigating workaround:
I can of course start over, creating a brand new mail server VM, WITHOUT installing dovecot 2.0.6, and then JUST download the 2.3.0 and build and install it. At least then I will only have 1 version of dovecot present on the virtual machine to deal with.
But the obvious question then remains:
After my NEXT dovecot upgrade, I'm back in the quagmire, needing to know a) b) and c) above.
I am confident that dovecot is not lacking in this department, I just can't find what I'm looking for in the documentation.
Thanks in advance,
On 2018.01.08. 21:23, John Tulp wrote:
> My version output is below, under the heading "My actual question".
IMHO, it's distributions(package maintainers) area of responsibility to
create proper package install/upgrade scripts.
In reply to this post by John Tulp
On 09/01/18 08:23, John Tulp wrote:
> I installed a new virtual machine with CentOS 6.9
Just so you know Red Hat classifies RHEL6 (and by extension CentOS 6) as
being in Phase 3 support, which means that only the most critical
security vulnerabilities get updates now. I would not recommend
starting a new server with CentOS 6, but rather you should be using
CentOS 7 instead.
> Then, wanting to be on the latest stable version of dovecot anyway, I
> downloaded dovecot 2.3.0 from dovecot.org and attempted to follow the
> instructions on building from source,
And this was your next problem. You should very rarely, if ever build
and install from source onto a package-managed distribution, and only if
you really understand what you're doing and why. There are packages
available for dovecot 2.3.0 from dovecot.org now that you can replace
the stock dovecot packages with, or you can also use the packages
available from ghettoforge.org. Either one of those sources is vastly
preferable to installing from source.
> I actually got an email to get appended to the users mbox file.
I'm not sure how since above you said you were using Maildir delivery.
> It appears that make install has not replaced the old 2.0.9 binaries
> with new 2.3.0 binaries, even though it faithfully created everying
> under the /usr directories, e.g., /usr/bin, etc., and make install did
> not set some variable or otherwise configure for the new version to run
> instead of the old. Well, maybe.
And if you did manage to successfully replace replace the CentOS stock
dovecot binaries you would be in for a heap of trouble. Among other
reasons the moment you run "yum update" and it finds and updates the
dovecot packages CentOS will replace all those files that you just built
with the older dovecot 2.0 files that it distributes again.
> Precisely how should this 2.3.0, built from source, be properly
> installed and configured to actually run the new version ?
It shouldn't, see above.
On 09/01/18 11:46, John Tulp wrote:
> Should I send a response to your message via an email to
> [hidden email] ?
> Or just reply to you directly like this ?
You should always reply to the mailing list unless told otherwise.
> For CentOS version, I need to support 32-bit x86 a while longer.
> Could you possibly save me some time and provide a
> link on the dovecot.org site ?
> I really did not want to install from
> source, I was very surprised that I did not find a link to download a
> completely built backage on dovecot.org.
The official dovecot repo is fairly new, but also GhettoForge has been
providing dovecot packages for CentOS 6 and 7 for quite some time now.
> Regarding yum update, yes, I would assume that I would not run yum
> update after that build/install.
That's a bad idea. You need to run updates on a regular basis to fix
new vulnerabilities that are discovered such as the very recent meltdown
and spectre vulnerabilities (look these up, they're serious).
> I'm really perplexed as to why yum update would not just take me to
> 2.3.0 ??? I guess the RedHat folks just include "certain" releases of
> packages in the repositories ?
In reply to this post by John Tulp
Find responses between the lines.
On 08.01.2018 21:23, John Tulp wrote:
https://repo.dovecot.org has prebuilt packages if you want to give them a try.
You should really have removed the old installation.
That's just SIGTERM which is the normal way dovecot stops itself.
You have forgotten to provide correct parameters for configure, e.g. this is what is used by rpm building for centos6
./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info 'INSTALL_DATA=install -c -p -m644' --docdir=/usr/share/doc/dovecot-ce --disable-static --disable-rpath --with-nss --with-shadow --with-pam --with-gssapi=plugin --with-ldap=plugin --with-sql=plugin --with-lua=plugin $'\302\240' --with-pgsql --with-mysql --with-sqlite --with-zlib --with-libcap --with-libwrap --with-ssl=openssl --with-ssldir=/etc/pki/dovecot-ce --with-solr --with-docs
|Free forum by Nabble||Edit this page|