Hi
I'm about to upgrade to 2.1.7 in my test environment, but "doveconf -n -c dovecot.1.conf > dovecot.2.conf" is producing a blank file, so I am unsure how to proceed. I know a lot has changed between them, so I don't really want to have to start from scratch unless I have to.
I have tried both as my user and with sudo.
Simon
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 5 Mar 2013, Simon Brereton wrote:
I'm about to upgrade to 2.1.7 in my test environment, but "doveconf -n -c dovecot.1.conf > dovecot.2.conf" is producing a blank file, so I am unsure how to proceed. I know a lot has changed between them, so I
honestly, especially because "a lot has changed between them" I would start from scratch.
don't really want to have to start from scratch unless I have to.
check what you have changed in v1.2 config, then check if that particular setting has changed or the functionality has changed, and finally change the default in v2.1
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBUTX/PV3r2wJMiz2NAQI2AAf+Iq80FmUHsZp1qvD7R8q14V2NCwK4Tktp 3LN+yjMaeaZ+FJEDGsZD99eEDhfqNSU1BCbQl/RfXjMngr8ptBLowqCb7ooSK3X4 jjK9bf8eHaKbjpEMMlHACFWkxl8nCgT0IHqQk//L+sic8UhgbuyXyv5oo4nyTc7A 4WQBWnB7nfx9zmfARDCJpEhM2sEPzU74BU9OQ94hyKCczIEMHj5Ri/rnqfuustvZ pBHOyOb6a4XJ51LffviVucgpoLvO1fYJK2L3ztbybS9RnySZTtIwFr56dtfTWNed VByo0ICJW0djinnkBKjOb0s29OydjHbrsTfFcZOEeCOgKj9mShyzqA== =F9YZ -----END PGP SIGNATURE-----
On 5 Mar 2013 15:19, "Steffen Kaiser" skdovecot@smail.inf.fh-brs.de wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 5 Mar 2013, Simon Brereton wrote:
I'm about to upgrade to 2.1.7 in my test environment, but "doveconf -n -c dovecot.1.conf > dovecot.2.conf" is producing a blank file, so I am unsure how to proceed. I know a lot has changed between them, so I
honestly, especially because "a lot has changed between them" I would start from scratch.
don't really want to have to start from scratch unless I have to.
check what you have changed in v1.2 config, then check if that particular
setting has changed or the functionality has changed, and finally change the default in v2.1
I'd prefer to have a semi-decent config to work from without having to research 100 new variable names and values. The migration tool exists for a reason.
Simon
On 3/5/2013 6:30 AM, Simon Brereton wrote:
I'd prefer to have a semi-decent config to work from without having to research 100 new variable names and values. The migration tool exists for a reason.
I just went through the same thing - converting from 1.2.10 to 2.1.15. Trust me, you are better off starting from scratch. Use the default template then modify it for your customizations. I thought the same thing as you, but in the end, trying to convert the old config file turned out to be much more work.
Dem
On 5 March 2013 16:28, Professa Dementia professa@dementianati.com wrote:
On 3/5/2013 6:30 AM, Simon Brereton wrote:
I'd prefer to have a semi-decent config to work from without having to research 100 new variable names and values. The migration tool exists for a reason.
I just went through the same thing - converting from 1.2.10 to 2.1.15. Trust me, you are better off starting from scratch. Use the default template then modify it for your customizations. I thought the same thing as you, but in the end, trying to convert the old config file turned out to be much more work.
What's the recommended approach then? Pack it all into dovecot.conf as it was before, or use the split config files under conf.d/ - is this even a choice?
Simon
On 3/5/2013 7:34 AM, Simon Brereton wrote:
What's the recommended approach then? Pack it all into dovecot.conf as it was before, or use the split config files under conf.d/ - is this even a choice?
Split configs are nicer and easier to work with and I am all for nicer and easier.
Dem
On Tue, 2013-03-05 at 08:28 -0800, Professa Dementia wrote:
On 3/5/2013 7:34 AM, Simon Brereton wrote:
What's the recommended approach then? Pack it all into dovecot.conf as it was before, or use the split config files under conf.d/ - is this even a choice?
Split configs are nicer and easier to work with and I am all for nicer and easier.
Dem
WTF? Everything in one file is much nicer and easier, and you don't have to guess what option is in what file
Noel Butler wrote:
On Tue, 2013-03-05 at 08:28 -0800, Professa Dementia wrote:
On 3/5/2013 7:34 AM, Simon Brereton wrote:
What's the recommended approach then? Pack it all into dovecot.conf as it was before, or use the split config files under conf.d/ - is this even a choice?
Split configs are nicer and easier to work with and I am all for nicer and easier.
WTF? Everything in one file is much nicer and easier, and you don't have to guess what option is in what file
We're using a single file too, since this can be easily managed by a configuration management system and avoids unexpected changes.
Split files might get accidentally updated or added on package updates and change the behaviour of your whole mail system.
Regards Daniel
On 3/5/2013 3:06 PM, Daniel Parthey wrote:
We're using a single file too, since this can be easily managed by a configuration management system and avoids unexpected changes.
Split files might get accidentally updated or added on package updates and change the behaviour of your whole mail system.
This is a valid point, however, the same type of argument can be made for a single file. Updates, changes or bugs can corrupt your entire configuration all at once.
With split files, you can set permissions so specific utilities or scripts can only access certain parts. There is better granularity that can be assigned to permissions.
I am basing most of this on my experience of RedHat vs. the SuSE configuration for Apache. The split files of SuSE were always easier to manage and had less problems. And when there was a problem, I knew exactly where to go to look, and that file generally fit on one editor screen so I could see all the applicable directives all at once, instead of wading through a huge file, scrolling up and down, accidentally changing the wrong stanza, etc.
Dem
On Tue, 2013-03-05 at 15:33 -0800, Professa Dementia wrote:
I am basing most of this on my experience of RedHat vs. the SuSE configuration for Apache. The split files of SuSE were always easier to
httpd, which utilises identical directives is nothing like Dovecot with split config files containing different directives, no comparison.
manage and had less problems. And when there was a problem, I knew exactly where to go to look, and that file generally fit on one editor screen so I could see all the applicable directives all at once, instead of wading through a huge file, scrolling up and down, accidentally changing the wrong stanza, etc.
You got serious problems if your dovecot.conf ends up like a large httpd config with thousands of vhosts... my conf file is massive, so massive its like , wow, 4.7k in size, I should really split that into a bunch of tiny idy bidy files :)
On Wed, 2013-03-06 at 00:06 +0100, Daniel Parthey wrote:
WTF? Everything in one file is much nicer and easier, and you don't have to guess what option is in what file
We're using a single file too, since this can be easily managed by a configuration management system and avoids unexpected changes.
Exactly, and even if management tools were not in play, it would still be easier for a novice to check out a directive setting.
On 6 March 2013 02:57, Noel Butler noel.butler@ausics.net wrote:
On Wed, 2013-03-06 at 00:06 +0100, Daniel Parthey wrote:
WTF? Everything in one file is much nicer and easier, and you don't have to guess what option is in what file
We're using a single file too, since this can be easily managed by a configuration management system and avoids unexpected changes.
Exactly, and even if management tools were not in play, it would still be easier for a novice to check out a directive setting.
:%s/novice/idiots like Simon/g
;)
Simon
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 6 Mar 2013, Daniel Parthey wrote:
Noel Butler wrote:
On Tue, 2013-03-05 at 08:28 -0800, Professa Dementia wrote:
On 3/5/2013 7:34 AM, Simon Brereton wrote:
What's the recommended approach then? Pack it all into dovecot.conf as it was before, or use the split config files under conf.d/ - is this even a choice?
Split configs are nicer and easier to work with and I am all for nicer and easier.
WTF? Everything in one file is much nicer and easier, and you don't have to guess what option is in what file
We're using a single file too, since this can be easily managed by a configuration management system and avoids unexpected changes.
A single file with just one place a configuration setting might exist is easier for novices or installations without (half-)automatic processing, I agree with Noel.
But I wonder why this is true for a configuration management system? Esp. then I would consider to put local options into yet another file is easier to manage and more robust.
Split files might get accidentally updated or added on package updates and change the behaviour of your whole mail system.
In Dovecot I can override any setting of the default files with conf.d/99-my-XYZ.conf, so the package management of the distribution keeps its hands off my files and my conf management system doesn't interfere with the packager and/or original author. I would expect a monolitic file to break easier, when an automatic script changes something therein.
I do not have good experience with all-in-one config files and automatic processing. At least comments got screwed up.
I want to enable ACLs, so I add conf.d/99-my-acl.conf
protocol imap { mail_plugins = $mail_plugins imap_acl } plugin { acl = vfile } plugin { acl_shared_dict = proxy::acl } dict { acl = pgsql:[...]/dovecot-dict-sql.conf.ext }
This file is part of my conf management system, but I leave 10-mail.conf and 20-imap.conf alone. If I change my ACL setting, I (well, the script or management system) need to fiddle in one small file with dramatic less places to get something wrong.
One GoodThing(tm) with Dovecot is that you can have both: one monolitic flat file (no !include in primary .conf) and split files. That's however opens the probability for flame wars about what's better. ;-)
Kind regards,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBUTbhal3r2wJMiz2NAQL1Ugf/bDDgLKG5yZ1heAT/l0wIi1/VcFJNsAvH IDQ9rjrbr2p22oFMvhWnVW4+97kwwO/yVg1am2mutFW8sjolIrkgbMYpVIh71QvC +rh+NRIk3WEuzZ8tlmE2g8r+5Hmy4G7qsckR4DkK/ciqgPWiYXdjLgrz5MS9+z37 kzn++riNc5XaDAve5poaayvAnuu36+NNMaxDfh0S1yACxfh0XXZR/xiXe3PC1qQo +pb5Dy69R+aEqvYSDWcpuUyjAF/eEcyDnS2/ZPSY9ZVFCxPw3RkH5iSN/msuy5P7 YIij4AUXXqLLQVL99mHliG3fpwq5z/ngXRSjsDn5u23PXz5JQy/ojw== =2EA7 -----END PGP SIGNATURE-----
Am 2013-03-05 23:27, schrieb Noel Butler:
On Tue, 2013-03-05 at 08:28 -0800, Professa Dementia wrote:
On 3/5/2013 7:34 AM, Simon Brereton wrote:
What's the recommended approach then? Pack it all into dovecot.conf as it was before, or use the split config files under conf.d/ - is this even a choice?
Split configs are nicer and easier to work with and I am all for nicer and easier.
WTF? Everything in one file is much nicer and easier, and you don't have to guess what option is in what file
Using dovecot from .deb package in ubuntu, I am missing a way, to undo configs done in the conf.d in my local.conf file. Provided that, conf.d contains some reasonable defaults for everybody, and that the changes to accomodate local needs are few.
-- Peter
On Wed, 06 Mar 2013 08:27:51 +1000 Noel Butler noel.butler@ausics.net wrote:
On Tue, 2013-03-05 at 08:28 -0800, Professa Dementia wrote:
On 3/5/2013 7:34 AM, Simon Brereton wrote:
What's the recommended approach then? Pack it all into dovecot.conf as it was before, or use the split config files under conf.d/ - is this even a choice?
Split configs are nicer and easier to work with and I am all for nicer and easier.
Dem
WTF? Everything in one file is much nicer and easier, and you don't have to guess what option is in what file
Here's a question for both of you:
- Is there any reason someone could not, after the fact, cut parts of the main file and put that cut into conf.d?
- Is there any reason someone could not, after the fact, cut parts out of the conf.d files and paste them into the main files, perhaps adding a comment as to where they were originally?
If both of those are possible, although we could still argue which should be the default (and I strongly believe in one file), at least each of us can have our own way with a half hour of work.
Thanks,
SteveT
Steve Litt * http://www.troubleshooters.com/ Troubleshooting Training * Human Performance
Am 06.03.2013 22:42, schrieb Steve Litt:
On Wed, 06 Mar 2013 08:27:51 +1000 Noel Butler noel.butler@ausics.net wrote:
On Tue, 2013-03-05 at 08:28 -0800, Professa Dementia wrote:
On 3/5/2013 7:34 AM, Simon Brereton wrote:
What's the recommended approach then? Pack it all into dovecot.conf as it was before, or use the split config files under conf.d/ - is this even a choice?
Split configs are nicer and easier to work with and I am all for nicer and easier.
Dem
WTF? Everything in one file is much nicer and easier, and you don't have to guess what option is in what file
Here's a question for both of you:
- Is there any reason someone could not, after the fact, cut parts of the main file and put that cut into conf.d?
- Is there any reason someone could not, after the fact, cut parts out of the conf.d files and paste them into the main files, perhaps adding a comment as to where they were originally?
If both of those are possible, although we could still argue which should be the default (and I strongly believe in one file), at least each of us can have our own way with a half hour of work.
conf.d files are easier if the config is really large and for make it possible to add and remove pieces by software managment tools
a monolithic config file is way better as long it is not too big at all because depending on your screen you can view most of the config at once and backup/restore is also much easier in many cases
On Tue, 05 Mar 2013 08:28:06 -0800 Professa Dementia professa@dementianati.com wrote:
On 3/5/2013 7:34 AM, Simon Brereton wrote:
What's the recommended approach then? Pack it all into dovecot.conf as it was before, or use the split config files under conf.d/ - is this even a choice?
Split configs are nicer and easier to work with and I am all for nicer and easier.
Dem
I couldn't disagree more. With everything in one file, you use your editor's search facility instead of needing to use grep on everything. You see everything by scanning up and down instead of changing windows or buffers. Copy and paste is harder between files than within one. When changing or experimenting, you need to make backup copies of more files. With one file, you always know which file to put something in, and you run less risk of duplicates.
I see the attraction of a separate file for a separate and distinct facility added by the site administrator, but otherwise, I'm a big fan of the one file config.
SteveT
Steve Litt * http://www.troubleshooters.com/ Troubleshooting Training * Human Performance
Simon Brereton skrev den 2013-03-05 15:30:
honestly, especially because "a lot has changed between them" I would start from scratch.
as same as saying if new iso file is out anyone need to delete there old servers ?
I'd prefer to have a semi-decent config to work from without having to research 100 new variable names and values. The migration tool exists for a reason.
dovecot -n is simple enough, but what about layouts ?, and will dovecot 2.x understand maildirs same way as it was under dovecot 1.x, nothing changed ?
wiki.dovecot.org still exists so it should be safe to stay on 1.x :)
Am 05.03.2013 22:24, schrieb Benny Pedersen:
Simon Brereton skrev den 2013-03-05 15:30:
honestly, especially because "a lot has changed between them" I would start from scratch.
as same as saying if new iso file is out anyone need to delete there old servers ?
and you think convert a configration file to a new syntax is the same as reinstall the whole OS?
I'd prefer to have a semi-decent config to work from without having to research 100 new variable names and values. The migration tool exists for a reason.
dovecot -n is simple enough, but what about layouts ?, and will dovecot 2.x understand maildirs same way as it was under dovecot 1.x, nothing changed ?
wiki.dovecot.org still exists so it should be safe to stay on 1.x :)
well you can also use CentOS5................... you can also use PHP 5.2............... but does it make sense over the long?
problems are not solved by sit them out
Reindl Harald skrev den 2013-03-05 22:50:
Am 05.03.2013 22:24, schrieb Benny Pedersen:
Simon Brereton skrev den 2013-03-05 15:30:
honestly, especially because "a lot has changed between them" I would start from scratch.
as same as saying if new iso file is out anyone need to delete there old servers ?
and you think convert a configration file to a new syntax is the same as reinstall the whole OS?
does it matter what i think ?, or what problem others have ?
I'd prefer to have a semi-decent config to work from without having to research 100 new variable names and values. The migration tool exists for a reason.
dovecot -n is simple enough, but what about layouts ?, and will dovecot 2.x understand maildirs same way as it was under dovecot 1.x, nothing changed ?
wiki.dovecot.org still exists so it should be safe to stay on 1.x :)
well you can also use CentOS5...................
no go, i will not use any precompiled problems
you can also use PHP 5.2...............
and i can compile with gcc 2.95 still ?
but does it make sense over the long?
you ask to much :)
problems are not solved by sit them out
thats why i use opensource, maybe i get it wrong, but this is my life
----- Original Message -----
From: Reindl Harald h.reindl@thelounge.net To: dovecot@dovecot.org Cc: Sent: Tuesday, 5 March 2013, 23:50 Subject: Re: [Dovecot] Upgrading 1.2 to 2.x
Simon Brereton skrev den 2013-03-05 15:30:
honestly, especially because "a lot has changed between
Am 05.03.2013 22:24, schrieb Benny Pedersen: them"
I would start from scratch.
as same as saying if new iso file is out anyone need to delete there old servers ?
and you think convert a configration file to a new syntax is the same as reinstall the whole OS?
I'd prefer to have a semi-decent config to work from without having to research 100 new variable names and values. The migration tool exists for a reason.
dovecot -n is simple enough, but what about layouts ?, and will dovecot 2.x understand maildirs same way as it was under dovecot 1.x, nothing changed ?
wiki.dovecot.org still exists so it should be safe to stay on 1.x :)
well you can also use CentOS5................... you can also use PHP 5.2............... but does it make sense over the long?
problems are not solved by sit them out
Don't know if you are interested in this, but I always document installations and procedures. Extensively . . .
HTH,
s.
"I merely function as a channel that filters music through the chaos of noise"
- Vangelis
On Tue, 2013-03-05 at 11:33 +0100, Simon Brereton wrote:
Hi
I'm about to upgrade to 2.1.7 in my test environment, but "doveconf -n -c dovecot.1.conf > dovecot.2.conf" is producing a blank file, so I am unsure how to proceed. I know a lot has changed between them, so I don't really want to have to start from scratch unless I have to.
I have tried both as my user and with sudo.
Simon
Sounds like symptom of an error or something in 1.conf, I found converting that if it strikes something it does not like it bails there and then, but it gave me about 80% conversion, only requiring tweaking to finalise it, however it did not convert quota stuff to new format so start that from scratch.
When you run convert it usually spits out what it is, or is not doing, that must give you some clue.
and should matter what UID you are on, so long as you have read access to 1.conf and write access to 2.conf
On 5 March 2013 23:25, Noel Butler noel.butler@ausics.net wrote:
On Tue, 2013-03-05 at 11:33 +0100, Simon Brereton wrote:
Hi
I'm about to upgrade to 2.1.7 in my test environment, but "doveconf -n -c dovecot.1.conf > dovecot.2.conf" is producing a blank file, so I am unsure how to proceed. I know a lot has changed between them, so I don't really want to have to start from scratch unless I have to.
I have tried both as my user and with sudo.
Simon
Sounds like symptom of an error or something in 1.conf, I found converting that if it strikes something it does not like it bails there and then, but it gave me about 80% conversion, only requiring tweaking to finalise it, however it did not convert quota stuff to new format so start that from scratch.
When you run convert it usually spits out what it is, or is not doing, that must give you some clue.
and should matter what UID you are on, so long as you have read access to 1.conf and write access to 2.conf
So many replies - I feel like a celebrity! :)
Noel - this is what I get when I run the command. As you can see dovecot.2.conf is empty afterwards.
sbuongiorno@local:~$ doveconf -n -c dovecot.1.conf > dovecot.2.conf
doveconf: Warning: NOTE: You can get a new clean config file with:
doveconf -n > dovecot-new.conf
doveconf: Warning: Obsolete setting in dovecot.1.conf:4: 'imaps'
protocol is no longer necessary, remove it
doveconf: Warning: Obsolete setting in dovecot.1.conf:4: 'pop3s'
protocol is no longer necessary, remove it
doveconf: Warning: Obsolete setting in dovecot.1.conf:5: ssl_ca_file
has been replaced by ssl_ca = What if I comment that line out? What happens is I get a bit further. I ended up having to comment out
the following lines: #login_executable(imap)= /usr/lib/dovecot/imap-login
#login_executable(pop3)= /usr/lib/dovecot/pop3-login
#mail_executable(imap)= /usr/lib/dovecot/imap
#mail_executable(pop3)= /usr/lib/dovecot/pop3
#mail_plugins(imap)= quota imap_quota
#mail_plugins(pop3)= quota
#mail_plugin_dir(imap)= /usr/lib/dovecot/modules/imap
#mail_plugin_dir(pop3)= /usr/lib/dovecot/modules/pop3
#imap_client_workarounds(imap)= outlook-idle delay-newmail
#imap_client_workarounds(pop3)=
#pop3_save_uidl(imap)= no
#pop3_save_uidl(pop3)= yes
#pop3_uidl_format(default)= %08Xu%08Xv
#pop3_uidl_format(imap)= %08Xu%08Xv
#pop3_uidl_format(pop3)= %v.%u
#pop3_client_workarounds(default)=
#pop3_client_workarounds(imap)=
#pop3_client_workarounds(pop3)= outlook-no-nuls oe-ns-eoh Some of those look pretty crucial, and some I know I've definitely changed. However, once I commented them all, I am able to generate a
dovecot.2.conf - thanks for the hint! Simon
Simon,
- Simon Brereton simon.buongiorno@gmail.com:
I'm about to upgrade to 2.1.7 in my test environment, but "doveconf -n -c dovecot.1.conf > dovecot.2.conf" is producing a blank file, so I am unsure how to proceed. I know a lot has changed between them, so I don't really want to have to start from scratch unless I have to.
unless you have spent hours tweaking your config, setting up Dovecot 2.x should be fairly easy. If your old config isn't too complex I wouldn't waste time discussing this problem, but move on to create it from scratch in 2.x.
p@rick
-- [*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
participants (11)
-
Benny Pedersen
-
Daniel Parthey
-
Hungerburg
-
Noel Butler
-
Patrick Ben Koetter
-
Professa Dementia
-
Reindl Harald
-
Simon Brereton
-
Spyros Tsiolis
-
Steffen Kaiser
-
Steve Litt