Hi,
I am not on this list so please CC me.
Using dovecot-1.2.x it seems we can not configure the location of ssl- parameters.dat.tmp, it is hard coded to be in PKG_STATEDIR:
./src/master/master-settings.c:
#define SSL_PARAMETERS_PERM_PATH PKG_STATEDIR"/"SSL_PARAMETERS_FILENAME
This can lead to problems when you're running multiple instances on one machine. Apart from that, it would be very useful if wasn't hard- coded like that.
Maybe it could be in base_dir or have a configuration option of its own?
--
Leo Baltus, internetbeheerder /
NPO ICT Internet Services /NPO/
Sumatralaan 45, 1217 GP Hilversum, Filmcentrum, west \ /\/
beheer@omroep.nl, 035-6773555 \/
On Mon, 2009-07-13 at 15:54 +0200, Leo Baltus wrote:
Hi,
I am not on this list so please CC me.
Using dovecot-1.2.x it seems we can not configure the location of ssl- parameters.dat.tmp, it is hard coded to be in PKG_STATEDIR:
./src/master/master-settings.c:
#define SSL_PARAMETERS_PERM_PATH PKG_STATEDIR"/"SSL_PARAMETERS_FILENAME
Right.
This can lead to problems when you're running multiple instances on one machine.
No, it doesn't really matter if one instance overwrites a file that was just generated by another one. The file just needs to be updated every once in a while.
Maybe it could be in base_dir or have a configuration option of its own?
It's copied to base_dir, but it's not primarily stored there because base_dir is typically under /var/run/, which gets deleted at boot time.
Hi Timo,
Op 13/07/2009 om 12:19:43 -0400, schreef Timo Sirainen:
On Mon, 2009-07-13 at 15:54 +0200, Leo Baltus wrote:
I am not on this list so please CC me.
Using dovecot-1.2.x it seems we can not configure the location of ssl- parameters.dat.tmp, it is hard coded to be in PKG_STATEDIR:
./src/master/master-settings.c:
#define SSL_PARAMETERS_PERM_PATH PKG_STATEDIR"/"SSL_PARAMETERS_FILENAME
Right.
This can lead to problems when you're running multiple instances on one machine.
No, it doesn't really matter if one instance overwrites a file that was just generated by another one. The file just needs to be updated every once in a while.
Maybe it could be in base_dir or have a configuration option of its own?
It's copied to base_dir, but it's not primarily stored there because base_dir is typically under /var/run/, which gets deleted at boot time.
Well base_dir is configurable, in our case it is not /var/run and we do no use compile-time pahnames, therefore we would like SSL_PARAMETERS_PERM_PATH configurable or just to use base_dir.
Maybe there a reason not to use base_dir which I am overlooking?
--
Leo Baltus, internetbeheerder /
NPO ICT Internet Services /NPO/
Sumatralaan 45, 1217 GP Hilversum, Peperbus (12.103) \ /\/
beheer@omroep.nl, 035-6773555 \/
On Mon, 2009-07-13 at 21:56 +0200, Leo Baltus wrote:
Maybe it could be in base_dir or have a configuration option of its own?
It's copied to base_dir, but it's not primarily stored there because base_dir is typically under /var/run/, which gets deleted at boot time.
Well base_dir is configurable, in our case it is not /var/run and we do no use compile-time pahnames, therefore we would like SSL_PARAMETERS_PERM_PATH configurable or just to use base_dir.
Why can't you use compile time paths?
Maybe there a reason not to use base_dir which I am overlooking?
base_dir in most installations is wiped out when rebooting, and the ssl-parameters file shouldn't be deleted then.
Op 13/07/2009 om 16:22:58 -0400, schreef Timo Sirainen:
On Mon, 2009-07-13 at 21:56 +0200, Leo Baltus wrote:
Maybe it could be in base_dir or have a configuration option of its own?
It's copied to base_dir, but it's not primarily stored there because base_dir is typically under /var/run/, which gets deleted at boot time.
Well base_dir is configurable, in our case it is not /var/run and we do no use compile-time pahnames, therefore we would like SSL_PARAMETERS_PERM_PATH configurable or just to use base_dir.
Why can't you use compile time paths?
We typically use multiple instances, and we do not want to use any unique rescources from the OS. So each instance has its own storage & tmp space as well as its own IP address and user- and group-name.
Maybe there a reason not to use base_dir which I am overlooking?
base_dir in most installations is wiped out when rebooting, and the ssl-parameters file shouldn't be deleted then.
Ah, ok. Then we need a place for more persistent data storage, something like data_dir?
--
Leo Baltus, internetbeheerder /
NPO ICT Internet Services /NPO/
Sumatralaan 45, 1217 GP Hilversum, Peperbus (12.103) \ /\/
beheer@omroep.nl, 035-6773555 \/
On Jul 14, 2009, at 2:29 AM, Leo Baltus wrote:
Maybe there a reason not to use base_dir which I am overlooking?
base_dir in most installations is wiped out when rebooting, and the ssl-parameters file shouldn't be deleted then.
Ah, ok. Then we need a place for more persistent data storage,
something like data_dir?
Maybe if more people keep complaining about this. I don't like adding
settings that are going to be used only by a single person.
Op 14/07/2009 om 02:32:37 -0400, schreef Timo Sirainen:
On Jul 14, 2009, at 2:29 AM, Leo Baltus wrote:
Maybe there a reason not to use base_dir which I am overlooking?
base_dir in most installations is wiped out when rebooting, and the ssl-parameters file shouldn't be deleted then.
Ah, ok. Then we need a place for more persistent data storage,
something like data_dir?Maybe if more people keep complaining about this. I don't like adding
settings that are going to be used only by a single person.
We could make a patch which introduces data_dir getting its default value from PKG_STATEDIR.
Would that be acceptable?
--
Leo Baltus, internetbeheerder /
NPO ICT Internet Services /NPO/
Sumatralaan 45, 1217 GP Hilversum, Peperbus (12.103) \ /\/
beheer@omroep.nl, 035-6773555 \/
On Jul 14, 2009, at 2:51 AM, Leo Baltus wrote:
Maybe if more people keep complaining about this. I don't like adding settings that are going to be used only by a single person.
We could make a patch which introduces data_dir getting its default
value from PKG_STATEDIR.Would that be acceptable?
It's not about writing the code. It's about having extra bloat (no
matter how small it is) for the benefit of 1-2 installations in the
world. I'm not currently convinced it's going to be useful for more
installations than that.
In future the statedir might have other files that are actually going
to be per-instance. In that situation a setting would be useful for
more people, but currently I can't even think of what such files could
be so perhaps that's never going to happen.
participants (2)
-
Leo Baltus
-
Timo Sirainen