Hello Timo,
What was the reason to remove ssl_parameters_file setting? Is it possible to restore it? We really need it, and I can see no reason to remove this useful setting.
-- Sergey Redin
On Sat, 2006-02-25 at 17:31 +0800, Sergey Redin wrote:
Hello Timo,
What was the reason to remove ssl_parameters_file setting? Is it possible to restore it? We really need it, and I can see no reason to remove this useful setting.
Why do you need it? You know that it wasn't really even working before I removed it?
On Sat, 25 Feb 2006 12:59:39 +0200 Timo Sirainen tss@iki.fi wrote:
On Sat, 2006-02-25 at 17:31 +0800, Sergey Redin wrote:
Hello Timo,
What was the reason to remove ssl_parameters_file setting? Is it possible to restore it? We really need it, and I can see no reason to remove this useful setting.
Why do you need it? You know that it wasn't really even working before I removed it?
No, I did not know that, in fact I never needed it before.
Here is our problem. We run multiple virtual servers with some hosting software, including dovecot. Now it generates ssl-parameters.dat every time it starts, and this means that every time one of our servers reboots, all the VDS's inside it run ssl-build-param, and this takes really long before the server is able to do anything else. We changed ssl_parameters_file to 0 and now dovecot generates this file only when it is not present, but the problem is that all the files in /var/run are removed after reboot. So we need to put the files somewhere else, for example into /usr/local/etc. We can do it manually, in fact I already created a quick patch that makes dovecot use "/usr/local/etc/dovecot-ssl-parameters.dat", but we try to make as little patches as possible.
It is very easy to add this setting back to dovecot (even if it did not work before), and it will be usefull, at least for us.
-- Sergey Redin
On Sat, 2006-02-25 at 19:13 +0800, Sergey Redin wrote:
Here is our problem. We run multiple virtual servers with some hosting software, including dovecot. Now it generates ssl-parameters.dat every time it starts, and this means that every time one of our servers reboots, all the VDS's inside it run ssl-build-param, and this takes really long before the server is able to do anything else. We changed ssl_parameters_file to 0 and now dovecot generates this file only when it is not present, but the problem is that all the files in /var/run are removed after reboot. So we need to put the files somewhere else, for example into /usr/local/etc. We can do it manually, in fact I already created a quick patch that makes dovecot use "/usr/local/etc/dovecot-ssl-parameters.dat", but we try to make as little patches as possible.
It is very easy to add this setting back to dovecot (even if it did not work before), and it will be usefull, at least for us.
OK, I had also thought about this problem before. But it's not that simple actually.. If you put it somewhere else than login_dir, login processes won't see the file unless you have login_chroot=no, which is a bad idea.
Maybe it should be written in two places, and when starting up it could be copied to login_dir from the more permanent directory. I'm just not sure what would be a correct location for the more permanent directory. etc maybe, but that also seems a bit bad place.
On Sat, 25 Feb 2006 13:25:06 +0200 Timo Sirainen tss@iki.fi wrote:
OK, I had also thought about this problem before. But it's not that simple actually.. If you put it somewhere else than login_dir, login processes won't see the file unless you have login_chroot=no, which is a bad idea.
Maybe it should be written in two places, and when starting up it could be copied to login_dir from the more permanent directory. I'm just not sure what would be a correct location for the more permanent directory. etc maybe, but that also seems a bit bad place.
I guess you may just make some new parameter ssl_parameters_master_file, which is empty string by default, and copy it into ssl_parameters_master_file to ssl_parameters_file ONLY if ssl_parameters_master_file setting is not empty. Then the people who need it may use this setting with any directory they want, and you do not have to make any decision about directory :)
If ssl_parameters_master_file is set but the file is not present, dovecot will call ssl-build-param to create it and then copy it into the login directory. If it is not set, dovecot will generate the file in login directory.
Do you like this suggestion? This would be the best for us.
-- Sergey Redin
On Sat, 2006-02-25 at 19:41 +0800, Sergey Redin wrote:
I guess you may just make some new parameter ssl_parameters_master_file, which is empty string by default, and copy it into ssl_parameters_master_file to ssl_parameters_file ONLY if ssl_parameters_master_file setting is not empty. Then the people who need it may use this setting with any directory they want, and you do not have to make any decision about directory :)
But I think everyone would want that, so it's better to have it done by default. And if it's done by default, I don't think there's much point in being able to specify its directory. Dovecot has already a bit too many settings. :)
On Sat, 25 Feb 2006 13:49:10 +0200 Timo Sirainen tss@iki.fi wrote:
On Sat, 2006-02-25 at 19:41 +0800, Sergey Redin wrote:
I guess you may just make some new parameter ssl_parameters_master_file, which is empty string by default, and copy it into ssl_parameters_master_file to ssl_parameters_file ONLY if ssl_parameters_master_file setting is not empty. Then the people who need it may use this setting with any directory they want, and you do not have to make any decision about directory :)
But I think everyone would want that, so it's better to have it done by default. And if it's done by default, I don't think there's much point in being able to specify its directory. Dovecot has already a bit too many settings. :)
So, you will have some master copy of the file outside the login directory in the next version, right?
I guess you will have to use a new directory then, something like /var/lib/dovecot, only for this single file :) It should not be in /usr or /etc I guess.
-- Sergey Redin
So can you please confirm that this problem will be fixed in the next version, does not matter with a new parameter or without it?
I can create a patch myself and send it here if you do not consider it important.
-- Sergey Redin
participants (2)
-
Sergey Redin
-
Timo Sirainen