General question from a newbie about minor upgrading of Dovecot

J

jazzraven

Hi.
I have a production server with Postfix+Dovecot bundle.
I need to add Sieve features, so I`ve found that I`ve got to install either
dovecot-pigeonhole-0.5.4_1
or
dovecot-pigeonhole04-0.4.24_2

Let`s see I try to install the latter:
Code: 
# pkg install dovecot-pigeonhole04-0.4.24_2
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 2 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        dovecot-pigeonhole04: 0.4.24_2
        dovecot22: 2.2.36_4

At the moment I have dovecot2-2.2.31_1 installed from binaries and happily running for my users.
I have read pkg help upgrade and
https://dovecot.org/doc/NEWS
and couldn`t find any signs of problem for upgrading.

So the questions are:
1. Can I without any anxiety install dovecot-pigeonhole04-0.4.24_2 that as far as I know removes my existing dovecot2-2.2.31_1, installs dovecot22: 2.2.36_4 and after it will start without a problem? What should I do IF there are problems with starting/running new dovecot (it`s a production server)?
2. Is there any manual/good_article with general advices like how to maintain packages on live BSD systems? Maybe people clone those live systems before upgrading and try to do it safely on the clones, (for such minor upgradings like mine it could be probably too complicated and not worth of time spent but who knows)...
I have my mail server running on Vsphere but I might lose some data between snapshots. It`s a very general misunderstanding, because, for example I must update pkgs with vulnerabilities but how could I know I won`t break anything...

Thanks in advance!
 
jazzraven said:
as far as I know removes my existing dovecot2-2.2.31_1, installs dovecot22: 2.2.36_4 and after it will start without a problem?
Click to expand...
Yes, that's the idea. But keep in mind that Dovecot 2.2 is deprecated and will be removed at the end of this month, same with Pigeonhole 0.4. So you're probably better off taking the opportunity now and upgrade to Dovecot 2.3 first. Then you can have a another look at adding features/functionality. Or else you're going to spend some time getting it to work on 2.2 and will have to do it again for 2.3 next month.

mail/dovecot22
Code: 
DEPRECATED: End of Life upstream, use mail/dovecot instead
EXPIRATION DATE: 2019-01-31
 
Thanks for an answer.
But there is another obstacle: here I see this:
Code: 
Configuration Options

===> The following configuration options are available for dovecot-2.3.4_5:
    ...
====> Database support
    ...
    MYSQL=off: MySQL database support
So I need to add this functionality... oh, I`ve just found my own notes of this server installation, I actually installed it from ports exactly because this MySQL option needed...
But it`s not a good idea to mess with packages and ports in BSD anyway... So what options do I have?
 
If you have jail then you can create new mail jail and rebuild everything to be sure it's working then switch over to new mail jail. It's good opportunity to get rid of excess or outdated files to free up the space on the drive. I did that last month and my new mail jail is 4GB less now.
 
I`ve clonned my server and wanna play with it now.
I`m going to try poudriere as a tool in such situations. Would compile package from ports with options needed and then install the package quickly and easily (I hope).
 
jazzraven said:
I`ve clonned my server and wanna play with it now.
I`m going to try poudriere as a tool in such situations. Would compile package from ports with options needed and then install the package quickly and easily (I hope).
Click to expand...

When building packages using ports-mgmt/poudriere, be sure that your servers only use your own packages. FreeBSD packages usually will have more dependencies or libraries because some default options are included. You can set your /usr/local/etc/poudriere.d/make.conf to exclude unnecessary options. I don't need X11, CUPS, GUI or LPR options since I'm not running X Window on my servers. Here's my snippets from my make.conf.

Code: 
# Global options
OPTIONS_UNSET += CUPS LPR X11 GUI

# Dovecot
mail_dovecot_SET = MYSQL SOLR

# Postfix
mail_postfix_SET = MYSQL SASL
 
It all seems so frustrating... Sysadmins try to install new features for their users, new servers and so on... While I`m trying to figure out how to deal with outdated versions of software and dependecies (I need a new feature but what if I break the live system that has been working for many months, let`s just don`t touch it while working)...
I would pay money for real hardcore teaching course "how to maintain/update/... your live systems". This question has been killing me since I started working in this area... But it seems there is no such courses...
 
jazzraven said:
While I`m trying to figure out how to deal with outdated versions of software and dependecies (I need a new feature but what if I break the live system that has been working for many months, let`s just don`t touch it while working)...
Click to expand...
Most of us test on a test system before applying changes to a production system. That's really all there is to it. It helps identifying and solving potential problems. You don't want to identify and solve things when the production system is down and your boss is breathing down your neck. Be prepared and your downtime will be minimized.

jazzraven said:
I would pay money for real hardcore teaching course "how to maintain/update/... your live systems".
Click to expand...
Two magic words, test and backup. Test your changes as good as you can on a test system, make a good backup of the original production configuration, apply changes to production system. If things don't work out restore the original configuration. And as your systems become more important you tend to have everything double. So you don't have just one mailserver, you have two. Then you can easily upgrade one, make it active. If things don't work out revert to the backup system. If things do work out upgrade the backup systems too.
 
SirDice said:
Most of us test on a test system before applying changes to a production system.
Click to expand...

You can test an update on a test system but that's only for the upgrade. Once upgraded, you'll have to verify that it works by diverting either all or a small portion of live traffic to it. That's often a big problem.

I'm very new to system administration and FreeBSD specifically. I just finished Absolute FreeBSD and I'm now reading FreeBSD mastery: ZFS and Advanced ZFS. This filesystem is AMAZING! With the ability to create snapshots and clones (and jails - but that is unrelated to ZFS) testing your setup and rolling back in case of issues really becomes a lot easier. At least, that is what I imagine since at the moment, I'm only studying the theory and will test soon in a home lab. But since I'm not a sysadmin, I can't test in production :P
 
You learn by doing something. You also learn by failing and then getting it right the next time around. Above all else, take some backups. Either run some backup software/script, or at the very least make a copy of the configuration files for whatever software you are running. These are most likely to be found in /usr/local/etc or ~/.config.

My method which has worked well for me for many years is to update my packages every 24 hours (ish). You may think that is excessive, but the number of updates is then manageable. Zero or one per day maybe. When something updates, if I've never edited the config then fine. If I have edited the config then I do a diff of the old config against the new config to see what's changed that I might need to merge. Also sometimes I read the changelog to see if there's any new features I might be interested in. Doing this probably takes 5 minutes of my time every day.

If you only update once every 6 months then you may be faced with updates to virtually everything, and trying to do the above with that will quickly make you feel very unmotivated about it.

I build my own packages using ports-mgmt/poudriere and make sure that I only have the bare amount of extra dependencies. If a port only uses a couple then I'll leave it alone, but if it drags in 20 or 30 extra things I'll tweak the port options to try and bring that down. That keeps the number of daily updates as low as possible and is much easier to maintain.

And in the worst case scenario that something breaks, simply restore the backup of the previous config that you already took. It's quite possible to revert to previous versions of packages as well if needed.

If you have ZFS, then taking a ZFS snapshot before running pkg upgrade would also allow you to immediately rollback to the point where you took the snapshot. Very handy!

Going back to mail/dovecot which is what this topic was about. That has many different config files. With that what I do is before running pkg upgrade I copy /usr/local/etc/dovecot/example-config to /tmp. I then upgrade the package, and then inside that directory I will run something like for file in *.conf; do echo $file; diff $file /tmp/example-config/$file; done. This will show me which files have changed between the old and new versions. I will then take those diffs and apply them to my own config files using patch blah.conf < diff1.
 
Thanks for all your kind answers, guys!
Talking about backups - I have my FreeBSD servers on VMs as well as all of my enterprise boxes with additional backup system installed and jobs scheduled.
But another thing that I`m concerned about is the mailboxes of my users. I cannot loose anything during downtimes/rollbacks.
Having this said, the plan for me is:
1. Getting a backup servers for everything
2. Reading/lurking/working_through a lot of books/tutorials to fill the gaps.
3. Trying to break smth down successfully ))
 
In case someone stumbles on the same issue.
Years ago i've deployed mail server that uses postfix+dovecot2.3.x+horde+mysql.
Postfix, dovecot and horde are set to use TLS.

Yesterday after upgrading FreeBSD from 11.X-RELEASE to 12.0-RELEASE dovecot auth started to core dump.
Dovecot and Postfix were build with TLS support with OpenSSL from ports. After I removed OpenSSL port and rebuild Dovecot and Postfix from base OpenSSL, everything started to work. Why is that I don't know :(

All I can say that now it is working fine. Unfortunate I don't remember the reason why it was initially deployed with OpenSSL from ports.
 
Did you rebuild all packages after the upgrade to 12? If not then that's probably why. I see you say you rebuilt them to use the base openssl, but you didn't say if you did that already or not after the upgrade. For what it's worth I'm running 12.0 with openssl from ports, postfix, and dovecot.
 
yes, i've rebuild all packages after the upgrade. I've removed dovecot several times and installed it and rebuild it and it didn't help :(
 
Only thing I can think of then is it could be because you are not doing it in a "clean room environment". Something like pkg-mgmt/poudriere will create a jail and build ports as if they are installed on a brand new system. If you are just building ports on the host system then it's possible something is being linked which should not be and it's causing issues. Running something like ldd `which dovecot` might shine some light on what's happening, where "dovecot" is whatever binary is breaking.
 
You must log in or register to reply here.
Back
Top