Re: FTS indexer-worker Panic

2019-12-15 Thread Joan Moreau 

Please kindly file an issue on github, together with an example of email
causing the panic 


On 2019-11-11 15:21, Yarema via dovecot wrote:


Set up fts_xapian over the weekend and re-indexed.
https://github.com/grosjo/fts-xapian

Tried to search my INBOX and got:


dovecot: indexer-worker: Panic: file charset-iconv.c: line 83

(charset_to_utf8_try): assertion failed: (srcleft <=
CHARSET_MAX_PENDING_BUF_SIZE)

What could I possibly have lurking in my INBOX to cause that ??

Re: dovecot full text search

2019-12-15 Thread Joan Moreau 
Hi 


The first run of indexing on a large existing mailbox is indeed slow,
and I would run "doveadm index -A -q \*" before putting the system in
production. 

Besides the Ram disk, what kind of solution would you suggest ? 


On 2019-12-10 19:28, Wojciech Puchar via dovecot wrote:


Where do write ops take place?


to the xapian index  subdirectory


Maybe mount that path to a RAM disk rather than looking for anorher solution.

not a solution for a problem but workaround

Am 10.12.2019 um 15:50 schrieb Wojciech Puchar via dovecot 
:

what FTP module should i use instead of squat that is probably no longer 
supported or no longer at all?

i want to upgrade my dovecot installation. it currently uses squat but i found 
it often crashes on FTS on large mailboxes.

i found "xapian" addon for dovecot but while it works excellent AFTER database 
is created, i found it need like 20 or so minutes to index less than 10GB of mails and 
while doing this - generate many tens of megabytes/s constant write traffic on it's 
database files.

Excellent way of killing SSD.

something must be broken.

my config is

plugin {
plugin = fts fts_xapian

fts = xapian
fts_xapian = partial=2 full=20 verbose=0

fts_autoindex = yes
fts_enforced = yes

#   fts_autoindex_exclude = \Junk
#   fts_autoindex_exclude2 = \Trash
}

any ideas?

Re: Bug: indexer-worker segfaults with fts_xapian 1.2.5

2019-12-15 Thread Joan Moreau 
It seems this comes from the old version of gcc/stdlib also. 


Please kindly file a "issue" on github
https://github.com/grosjo/fts-xapian/issues 


On 2019-12-15 21:35, Martynas Bendorius wrote:


Core was generated by `dovecot/indexer-worker'.
Program terminated with signal 11, Segmentation fault.
#0  0x7f30f7ad056d in __exchange_and_add (__val=-1, 
__mem=0xfff8)
at 
/usr/src/debug/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/ext/atomicity.h:49
49  { return __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); }

(gdb) bt full
#0  0x7f30f7ad056d in __exchange_and_add (__val=-1, 
__mem=0xfff8)
at 
/usr/src/debug/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/ext/atomicity.h:49
No locals.
#1  __exchange_and_add_dispatch (__val=-1, __mem=0xfff8)
at 
/usr/src/debug/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/ext/atomicity.h:82
No locals.
#2  std::string::_Rep::_M_dispose (this=0xffe8, __a=...)
at 
/usr/src/debug/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/bits/basic_string.h:246
No locals.
#3  0x7f30f7b3407e in _M_dispose (__a=..., this=)
at 
/usr/src/debug/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/bits/basic_string.tcc:254
No locals.
#4  std::string::assign (this=this@entry=0x55c7b93e0168, __str="return-path")
at 
/usr/src/debug/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/bits/basic_string.tcc:250
__a = {<__gnu_cxx::new_allocator> = {}, }
#5  0x7f30fa8776ce in operator= (__str="return-path", this=0x55c7b93e0168) 
at /usr/include/c++/4.8.2/bits/basic_string.h:547
No locals.
#6  fts_backend_xapian_update_set_build_key (_ctx=0x55c7b93e0140, 
key=0x7ffc1ba2c380) at fts-backend-xapian.cpp:303
ctx = 0x55c7b93e0140
i = 
f2 = "return-path"
backend = 
field = 0x55c7b943fb5f "RETURN-PATH"
j = 11
#7  0x7f30fb0b8cda in fts_backend_update_set_build_key (ctx=0x55c7b93e0140, 
key=key@entry=0x7ffc1ba2c380) at fts-api.c:174
__func__ = "fts_backend_update_set_build_key"
#8  0x7f30fb0ba243 in fts_build_mail_header (block=0x7ffc1ba2c340, 
block=0x7ffc1ba2c340, ctx=0x7ffc1ba2c3b0) at fts-build-mail.c:173
hdr = 
key = {uid = 6006200, type = FTS_BACKEND_BUILD_KEY_HDR, part = 0x55c7b935eed0, hdr_name = 0x55c7b943fb5f "RETURN-PATH", body_content_type = 0x0, 
body_content_disposition = 0x0}

ret = 
#9  fts_build_mail_real (may_need_retry_r=0x7ffc1ba2c2f3, 
retriable_err_msg_r=0x7ffc1ba2c300, mail=0x55c7b93dcff8, 
update_ctx=0x55c7b93e0140) at fts-build-mail.c:568
block = {part = 0x55c7b935eed0, hdr = 0x55c7b93d7f18, data = 0x55c7b938b8a8 "", 
size = 0}
ret = 
input = 0x55c7b93d78c0
raw_block = {part = 0x55c7b935eed0, hdr = 0x55c7b93d80b0, data = 0x0, size = 0}
skip_body = false
ctx = {mail = 0x55c7b93dcff8, update_ctx = 0x55c7b93e0140, content_type = 0x0, content_disposition = 0x0, body_parser = 0x0, word_buf = 0x0, 
---Type  to continue, or q  to quit---

pending_input = 0x0, cur_user_lang = 0x0}
prev_part = 0x55c7b935eed0
parser = 0x55c7b93d7b38
decoder = 0x55c7b93d7f00
parts = 0x7ffc1ba2c414
body_part = false
body_added = false
binary_body = 
error = 0x5ba5b8 
#10 fts_build_mail (update_ctx=0x55c7b93e0140, mail=mail@entry=0x55c7b93dcff8) 
at fts-build-mail.c:617
_data_stack_cur_id = 6
attempts = 2
retriable_err_msg = 0x11e900729 
may_need_retry = false
#11 0x7f30fb0c1102 in fts_mail_index (_mail=0x55c7b93dcff8) at 
fts-storage.c:550
ft = 0x55c7b9396880
flist = 0x55c7b938b8a8
pmail = 0x55c7b93dcff8
#12 fts_mail_precache (_mail=0x55c7b93dcff8) at fts-storage.c:571
_data_stack_cur_id = 5
mail = 0x55c7b93dcff8
fmail = 
ft = 0x55c7b9396880
__func__ = "fts_mail_precache"
#13 0x7f30fc1b7d64 in mail_precache (mail=0x55c7b93dcff8) at mail.c:432
_data_stack_cur_id = 4
p = 0x55c7b93dcff8
#14 0x55c7b8b4c844 in index_mailbox_precache (conn=, 
box=0x55c7b938ef18) at master-connection.c:102
counter = 0
max = 21569
percentage_sent = 0
storage = 
status = {messages = 21569, recent = 0, unseen = 0, uidvalidity = 1462447525, uidnext = 6027769, first_unseen_seq = 0, first_recent_uid = 6027758, 
last_cached_seq = 0, highest_modseq = 0, highest_pvt_modseq = 0, keywords = 0x0, permanent_flags = 0, flags = 0, permanent_keywords = false, 
allow_new_keywords = false, nonpermanent_modseqs = false, no_modseq_tracking = false, have_guids = true, have_save_guids = true, have_only_guid128 = false}

uids = 
username = 0x55c7b9385988 "m...@domain.com"
first_uid = 6006200
---Type  to continue, or q  to quit---
percentage_str = "\003\000\000"
percentage = 
error = MAIL_ERROR_NONE
trans = 0x55c7b9390480
ctx = 0x55c7b93d15f0
last_uid = 6006200
ret = 0
box_vname = 0x55c7b938f280 "INBOX.lfd.SSH login alerts"
errstr = 
search_args = 0x0
mail = 0x55c7b93dcff8
metadata = {guid = '\000' , virtual_size = 0, physical_size = 0, first_save_date = 0, cache_f

Re: Local lmtp proxy on backend server

2019-12-15 Thread Aki Tuomi 


 
 
  
   
  
  
   
On 15/12/2019 23:09 Marc Roos <
m.r...@f1-outsourcing.eu> wrote:
   
   

   
   

   
   
I receive a local mail when I do a 'mail test' on a backend svr1 with
   
   
this[0] configuration. However when I just add only one configuration
   
   
change 'lmtp_proxy = yes' I am getting these errors[1]. I would expect
   
   
this email to still be delivered locally, should this be working or do I
   
   
misunderstand the lmtp proxy functionality?
   
   

   
   

   
   
[0]
   
   
passdb {
   
   
args =
   
   
auth_verbose = default
   
   
default_fields = proxy=y host=svr1
   
   
deny = no
   
   
driver = pam
   
   

   
   

   
   
[1]
   
   
Dec 15 23:28:48 svr1 dovecot: lmtp(9270): Debug: none: root=, index=,
   
   
indexpvt=, control=, inbox=, alt=
   
   
Dec 15 23:28:48 svr1 dovecot: lmtp(9270): Connect from local
   
   
Dec 15 23:28:48 svr1 dovecot: auth: Debug: master in:
   
   
PASS#0111#011test#011service=lmtp
   
   
Dec 15 23:28:48 svr1 dovecot: auth: Debug: pam(test): passdb doesn't
   
   
support credential lookups
   
   
Dec 15 23:28:48 svr1 dovecot: auth: Debug: passdb out:
   
   
FAIL#0111#011reason=Configured passdbs don't support credentials lookups
   
   
Dec 15 23:28:48 svr1 dovecot: lmtp(9270): Debug: user test: Auth PASS
   
   
lookup returned temporary failure: reason=Configured passdbs don't
   
   
support credentials lookups
   
   
Dec 15 23:28:48 svr1 dovecot: lmtp(9270): Debug: auth PASS input:
   
   
reason=Configured passdbs don't support credentials lookups
   
   

   
   

   
   
dovecot-pigeonhole-2.2.36-3.el7_7.1.x86_64
   
   
dovecot-2.2.36-3.el7_7.1.x86_64
   
  
  
   
  
  
   PAM does not support looking up users, so you cannot use it for LMTP proxying. Try adding
  
  
   
  
  
   passdb {
  
  
     driver = passwd
  
  
     skip = authenticated
  
  
   }
  
  
   
  
  
   after PAM block.
  
  
   ---
Aki Tuomi

Local lmtp proxy on backend server

2019-12-15 Thread Marc Roos 


I receive a local mail when I do a 'mail test' on a backend svr1 with 
this[0] configuration. However when I just add only one configuration 
change 'lmtp_proxy = yes' I am getting these errors[1]. I would expect 
this email to still be delivered locally, should this be working or do I 
misunderstand the lmtp proxy functionality?


[0]
passdb {
  args =
  auth_verbose = default
  default_fields = proxy=y host=svr1
  deny = no
  driver = pam


[1]
Dec 15 23:28:48 svr1 dovecot: lmtp(9270): Debug: none: root=, index=, 
indexpvt=, control=, inbox=, alt=
Dec 15 23:28:48 svr1 dovecot: lmtp(9270): Connect from local
Dec 15 23:28:48 svr1 dovecot: auth: Debug: master in: 
PASS#0111#011test#011service=lmtp
Dec 15 23:28:48 svr1 dovecot: auth: Debug: pam(test): passdb doesn't 
support credential lookups
Dec 15 23:28:48 svr1 dovecot: auth: Debug: passdb out: 
FAIL#0111#011reason=Configured passdbs don't support credentials lookups
Dec 15 23:28:48 svr1 dovecot: lmtp(9270): Debug: user test: Auth PASS 
lookup returned temporary failure: reason=Configured passdbs don't 
support credentials lookups
Dec 15 23:28:48 svr1 dovecot: lmtp(9270): Debug: auth PASS input: 
reason=Configured passdbs don't support credentials lookups


dovecot-pigeonhole-2.2.36-3.el7_7.1.x86_64
dovecot-2.2.36-3.el7_7.1.x86_64

Re: Cannot install 'libdcrypt_openssl.la' to a directory not ending in /usr/lib/dovecot

2019-12-15 Thread @lbutlr 
On 15 Dec 2019, at 15:19, Alexander Dalloz  wrote:
> Am 15.12.2019 um 21:08 schrieb Mart Pirita:
>> Well, but not for centos 5 and also these rpm are including a lot stuff
>> what I don't need. But I will check the src rpm -s from repo and diff
>> these specs with my current ones.
>> Mart
> 
> CentOS 5 is end of life since April 2017. Don't use it! There is no good 
> reason to build anything for it.

And Centos 6 will be EOL in less than a year, so you probably shouldn’t move to 
it either.


-- 
"Are you pondering what I'm pondering?"
"Um, I think so, Brain-2, but a show about two talking lab mice? Hoo!
It'll never get on the air.”

Re: Cannot install 'libdcrypt_openssl.la' to a directory not ending in /usr/lib/dovecot

2019-12-15 Thread Alexander Dalloz 

Am 15.12.2019 um 21:08 schrieb Mart Pirita:

Well, but not for centos 5 and also these rpm are including a lot stuff
what I don't need. But I will check the src rpm -s from repo and diff
these specs with my current ones.



Mart


CentOS 5 is end of life since April 2017. Don't use it! There is no good 
reason to build anything for it.


Alexander

Re: Dovecot v2.3.9.2 released

2019-12-15 Thread John Fawcett 
On 13/12/2019 15:16, aki.tu...@dovecot.fi wrote:
> We are pleased to release v2.3.9.2 of Dovecot. Please find it from
> locations below
>
> https://dovecot.org/releases/2.3/dovecot-2.3.9.2.tar.gz
> https://dovecot.org/releases/2.3/dovecot-2.3.9.2.tar.gz.sig
> Binary packages in https://repo.dovecot.org/
> Docker images in https://hub.docker.com/r/dovecot/dovecot
>
> ---
>
> - Mails with empty From/To headers can also cause crash in push notification 
> drivers.
>
> ---
>
> Aki Tuomi
> Open-Xchange oy

dovecot.org website still indicates latest version is Dovecot v2.3.9.1
(though the link next to the text points to v2.3.9.2).

John

Bug: icu linking issue in fts plugin

2019-12-15 Thread Martynas Bendorius 
FTS plugin seems not to be linking dynamic libraries correctly:
[root@server ~]# ldd /usr/lib/dovecot/lib20_fts_plugin.so
linux-vdso.so.1 =>  (0x7ffd2eb95000)
libicui18n.so.64 => not found
libicuuc.so.64 => not found
libicudata.so.64 => not found
libc.so.6 => /lib64/libc.so.6 (0x7f1cb5566000)
/lib64/ld-linux-x86-64.so.2 (0x7f1cb5b73000)

ICU is in custom directory /usr/local/icu, it's not set in ld.so.conf, so, the 
linker would need to get this added automatically (that's how it's handled in 
PHP, for example):
-Wl,-rpath=/usr/local/icu/lib

Thank you!

--
Best regards,
Martynas Bendorius

Bug: indexer-worker segfaults with fts_xapian 1.2.5

2019-12-15 Thread Martynas Bendorius 
Core was generated by `dovecot/indexer-worker'.
Program terminated with signal 11, Segmentation fault.
#0  0x7f30f7ad056d in __exchange_and_add (__val=-1, 
__mem=0xfff8)
at 
/usr/src/debug/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/ext/atomicity.h:49
49{ return __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); }

(gdb) bt full
#0  0x7f30f7ad056d in __exchange_and_add (__val=-1, 
__mem=0xfff8)
at 
/usr/src/debug/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/ext/atomicity.h:49
No locals.
#1  __exchange_and_add_dispatch (__val=-1, __mem=0xfff8)
at 
/usr/src/debug/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/ext/atomicity.h:82
No locals.
#2  std::string::_Rep::_M_dispose (this=0xffe8, __a=...)
at 
/usr/src/debug/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/bits/basic_string.h:246
No locals.
#3  0x7f30f7b3407e in _M_dispose (__a=..., this=)
at 
/usr/src/debug/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/bits/basic_string.tcc:254
No locals.
#4  std::string::assign (this=this@entry=0x55c7b93e0168, __str="return-path")
at 
/usr/src/debug/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/bits/basic_string.tcc:250
__a = {<__gnu_cxx::new_allocator> = {}, }
#5  0x7f30fa8776ce in operator= (__str="return-path", this=0x55c7b93e0168) 
at /usr/include/c++/4.8.2/bits/basic_string.h:547
No locals.
#6  fts_backend_xapian_update_set_build_key (_ctx=0x55c7b93e0140, 
key=0x7ffc1ba2c380) at fts-backend-xapian.cpp:303
ctx = 0x55c7b93e0140
i = 
f2 = "return-path"
backend = 
field = 0x55c7b943fb5f "RETURN-PATH"
j = 11
#7  0x7f30fb0b8cda in fts_backend_update_set_build_key (ctx=0x55c7b93e0140, 
key=key@entry=0x7ffc1ba2c380) at fts-api.c:174
__func__ = "fts_backend_update_set_build_key"
#8  0x7f30fb0ba243 in fts_build_mail_header (block=0x7ffc1ba2c340, 
block=0x7ffc1ba2c340, ctx=0x7ffc1ba2c3b0) at fts-build-mail.c:173
hdr = 
key = {uid = 6006200, type = FTS_BACKEND_BUILD_KEY_HDR, part = 
0x55c7b935eed0, hdr_name = 0x55c7b943fb5f "RETURN-PATH", body_content_type = 
0x0, 
  body_content_disposition = 0x0}
ret = 
#9  fts_build_mail_real (may_need_retry_r=0x7ffc1ba2c2f3, 
retriable_err_msg_r=0x7ffc1ba2c300, mail=0x55c7b93dcff8, 
update_ctx=0x55c7b93e0140) at fts-build-mail.c:568
block = {part = 0x55c7b935eed0, hdr = 0x55c7b93d7f18, data = 
0x55c7b938b8a8 "", size = 0}
ret = 
input = 0x55c7b93d78c0
raw_block = {part = 0x55c7b935eed0, hdr = 0x55c7b93d80b0, data = 0x0, 
size = 0}
skip_body = false
ctx = {mail = 0x55c7b93dcff8, update_ctx = 0x55c7b93e0140, content_type 
= 0x0, content_disposition = 0x0, body_parser = 0x0, word_buf = 0x0, 
---Type  to continue, or q  to quit---
  pending_input = 0x0, cur_user_lang = 0x0}
prev_part = 0x55c7b935eed0
parser = 0x55c7b93d7b38
decoder = 0x55c7b93d7f00
parts = 0x7ffc1ba2c414
body_part = false
body_added = false
binary_body = 
error = 0x5ba5b8 
#10 fts_build_mail (update_ctx=0x55c7b93e0140, mail=mail@entry=0x55c7b93dcff8) 
at fts-build-mail.c:617
_data_stack_cur_id = 6
attempts = 2
retriable_err_msg = 0x11e900729 
may_need_retry = false
#11 0x7f30fb0c1102 in fts_mail_index (_mail=0x55c7b93dcff8) at 
fts-storage.c:550
ft = 0x55c7b9396880
flist = 0x55c7b938b8a8
pmail = 0x55c7b93dcff8
#12 fts_mail_precache (_mail=0x55c7b93dcff8) at fts-storage.c:571
_data_stack_cur_id = 5
mail = 0x55c7b93dcff8
fmail = 
ft = 0x55c7b9396880
__func__ = "fts_mail_precache"
#13 0x7f30fc1b7d64 in mail_precache (mail=0x55c7b93dcff8) at mail.c:432
_data_stack_cur_id = 4
p = 0x55c7b93dcff8
#14 0x55c7b8b4c844 in index_mailbox_precache (conn=, 
box=0x55c7b938ef18) at master-connection.c:102
counter = 0
max = 21569
percentage_sent = 0
storage = 
status = {messages = 21569, recent = 0, unseen = 0, uidvalidity = 
1462447525, uidnext = 6027769, first_unseen_seq = 0, first_recent_uid = 
6027758, 
  last_cached_seq = 0, highest_modseq = 0, highest_pvt_modseq = 0, 
keywords = 0x0, permanent_flags = 0, flags = 0, permanent_keywords = false, 
  allow_new_keywords = false, nonpermanent_modseqs = false, 
no_modseq_tracking = false, have_guids = true, have_save_guids = true, 
have_only_guid128 = false}
uids = 
username = 0x55c7b9385988 "m...@domain.com"
first_uid = 6006200
---Type  to continue, or q  to quit---
percentage_str = "\003\000\000"
percentage = 
error = MAIL_ERROR_NO

Re: Cannot install 'libdcrypt_openssl.la' to a directory not ending in /usr/lib/dovecot

2019-12-15 Thread Mart Pirita 


Well, but not for centos 5 and also these rpm are including a lot stuff
what I don't need. But I will check the src rpm -s from repo and diff
these specs with my current ones.



Mart

Aki Tuomi wrote:
> We provide rpm packages for centos 6&7 at https://repo.dovecot.org if you 
> want 
> to try them?
> 
> Aki
>> On 15/12/2019 13:01 Mart Pirita < m...@e-positive.ee 
>> > wrote:
>>
>>
>> Hi,
>>
>> For some reason I've never been able to build x64 dovecot rpm package,
>> no matter how I try, I'm still getting lib64 errors, first tried few
>> years on centos 5, ok I know this is old distro, then few years tried
>> with centos 6 (and wrote here also - CentOS x64 compilation fails),
>> supported distro, no luck, now installed centos 7 and still no luck, so
>> seems it's not about centos or rpm version.
>>
>> So I'm using option "rpmbuild -ba --target=i686 dovecot2.3.spec" to
>> build it, and it works but I'd still like to build x64 version. Why
>> libtool tries to install libdcrypt_openssl.la only instead
>> /usr/lib/dovecot into /usr/lib64/dovecot? . But as I can compile fine
>> postfix etc other openssl used app rpm -s, then is this some dovecot bug
>> or what am I missing?
>>
>> Error:
>> /usr/bin/mkdir -p
>> '/root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/lib/dovecot'
>> /bin/sh ../../libtool --mode=install /usr/bin/install -c
>> libssl_iostream_openssl.la
>> '/root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/lib/dovecot'
>> libtool: install: /usr/bin/install -c .libs/libssl_iostream_openssl.so
>> /root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/lib/dovecot/libssl_iostream_openssl.so
>>  
>>
>> libtool: install: /usr/bin/install -c .libs/libssl_iostream_openssl.lai
>> /root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/lib/dovecot/libssl_iostream_openssl.la
>>  
>>
>> libtool: install: /usr/bin/install -c .libs/libssl_iostream_openssl.a
>> /root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/lib/dovecot/libssl_iostream_openssl.a
>>  
>>
>> libtool: install: chmod 644
>> /root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/lib/dovecot/libssl_iostream_openssl.a
>>  
>>
>> libtool: install: ranlib
>> /root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/lib/dovecot/libssl_iostream_openssl.a
>>  
>>
>> libtool: warning: remember to run 'libtool --finish /usr/lib/dovecot'
>> /usr/bin/mkdir -p
>> '/root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/include/dovecot'
>> /usr/bin/install -c -m 644 iostream-openssl.h iostream-ssl.h
>> iostream-ssl-private.h iostream-ssl-test.h
>> '/root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/include/dovecot'
>> make[3]: Leaving directory
>> `/root/rpmbuild/BUILD/dovecot-2.3.9.2/src/lib-ssl-iostream'
>> make[2]: Leaving directory
>> `/root/rpmbuild/BUILD/dovecot-2.3.9.2/src/lib-ssl-iostream'
>> Making install in lib-dcrypt
>> make[2]: Entering directory
>> `/root/rpmbuild/BUILD/dovecot-2.3.9.2/src/lib-dcrypt'
>> make[3]: Entering directory
>> `/root/rpmbuild/BUILD/dovecot-2.3.9.2/src/lib-dcrypt'
>> /usr/bin/mkdir -p
>> '/root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/lib64/dovecot'
>> /bin/sh ../../libtool --mode=install /usr/bin/install -c
>> libdcrypt_openssl.la
>> '/root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/lib64/dovecot'
>> libtool: error: error: cannot install 'libdcrypt_openssl.la' to a
>> directory not ending in /usr/lib/dovecot
>> make[3]: *** [install-pkglibLTLIBRARIES] Error 1
>> make[3]: Leaving directory
>> `/root/rpmbuild/BUILD/dovecot-2.3.9.2/src/lib-dcrypt'
>> make[2]: *** [install-am] Error 2
>> make[2]: Leaving directory
>> `/root/rpmbuild/BUILD/dovecot-2.3.9.2/src/lib-dcrypt'
>> make[1]: *** [install-recursive] Error 1
>> make[1]: Leaving directory `/root/rpmbuild/BUILD/dovecot-2.3.9.2/src'
>> make: *** [install-recursive] Error 1
>> error: Bad exit status from /var/tmp/rpm-tmp.EVWbif (%install)
>>
>>
>> Options:
>> ./configure \
>> --prefix=/usr \
>> --with-ssl=openssl \
>> --with-ssldir=/etc/ssl \
>> --sysconfdir=/etc \
>> --without-vpopmail \
>> --with-pam \
>> --without-bsdauth \
>> --without-sql \
>> --without-nss \
>> --without-ldap \
>> --without-pgsql \
>> --without-mysql \
>> --without-sqlite \
>> --with-rundir=/var/run/dovecot \
>> --without-sia \
>> --without-cassandra \
>> --without-lucene \
>> --without-solr \
>> --without-textcat \
>> --without-libcap \
>> --without-stemmer \
>> --disable-rpath \
>> --disable-dependency-tracking \
>> --disable-silent-rules \
>> --without-gssapi \
>> --without-cdb
>>
>> -- 
>> Mart
> 
> ---
> Aki Tuomi
>

Re: Solr commit and optimize: which user?

2019-12-15 Thread John Fawcett 
On 15/12/2019 17:13, John Gateley wrote:
> Hi,
>
> I have Solr FTR working with dovecot, and need to do the commit and
> optimize recommended here:
> https://wiki.dovecot.org/Plugins/FTS/Solr
>
> Should this run as root, or as each mail user. The documentation above
> implies, but doesn't state,
> that it is root. The docs here are similar:
> http://grimore.org/networking/dovecot/full_text_search
>
> But the docs here say it has to be done for each user:
> http://www.unixsamurai.com/dovecot-full-text-search-jetty-solr/
>
> I don't know Solr well enough to answer. Which is correct?
>
> Thanks
>
> John
>
John

the optimize and commit commands don't specify any mail user in them:

# Optimize should be run somewhat rarely, e.g. once a day
curl https://:/solr/dovecot/update?optimize=true
# Commit should be run pretty often, e.g. every minute
curl https://:/solr/dovecot/update?commit=true

It doesn't actually matter which cron user you run them under so long as that 
user can execute the commands successfully. The idea (if you need them) is to 
run them globally under a single user. 
If you schedule them under more than one cron user it is just running the same 
commands more times, not doing anything specific per user.

John

0 1 * * * curl http://127.0.0.1:8080/solr/update?optimize=true 2 * * * *
curl http://127.0.0.1:8080/solr/update?commit=true

Copyright © UnixSamurai.com Read more at:
http://www.unixsamurai.com/dovecot-full-text-search-jetty-solr/
curl http://127.0.0.1:8080/solr/update?optimize=true 2 * * * * curl
http://127.0.0.1:8080/solr/update?commit=true

Copyright © UnixSamurai.com Read more at:
http://www.unixsamurai.com/dovecot-full-text-search-jetty-solr/
curl http://127.0.0.1:8080/solr/update?optimize=true 2 * * * * curl
http://127.0.0.1:8080/solr/update?commit=true

Copyright © UnixSamurai.com Read more at:
http://www.unixsamurai.com/dovecot-full-text-search-jetty-solr/

Solr commit and optimize: which user?

2019-12-15 Thread John Gateley 

Hi,

I have Solr FTR working with dovecot, and need to do the commit and 
optimize recommended here:

https://wiki.dovecot.org/Plugins/FTS/Solr

Should this run as root, or as each mail user. The documentation above 
implies, but doesn't state,

that it is root. The docs here are similar:
http://grimore.org/networking/dovecot/full_text_search

But the docs here say it has to be done for each user:
http://www.unixsamurai.com/dovecot-full-text-search-jetty-solr/

I don't know Solr well enough to answer. Which is correct?

Thanks

John

Re: Cannot install 'libdcrypt_openssl.la' to a directory not ending in /usr/lib/dovecot

2019-12-15 Thread Aki Tuomi 


 
 
  
   We provide rpm packages for centos 6&7 at https://repo.dovecot.org if you want to try them?
  
  
   
  
  
   Aki
  
  
   
On 15/12/2019 13:01 Mart Pirita <
m...@e-positive.ee> wrote:
   
   

   
   

   
   
Hi,
   
   

   
   
For some reason I've never been able to build x64 dovecot rpm package,
   
   
no matter how I try, I'm still getting lib64 errors, first tried few
   
   
years on centos 5, ok I know this is old distro, then few years tried
   
   
with centos 6 (and wrote here also - CentOS x64 compilation fails),
   
   
supported distro, no luck, now installed centos 7 and still no luck, so
   
   
seems it's not about centos or rpm version.
   
   

   
   
So I'm using option "rpmbuild -ba --target=i686 dovecot2.3.spec" to
   
   
build it, and it works but I'd still like to build x64 version. Why
   
   
libtool tries to install libdcrypt_openssl.la only instead
   
   
/usr/lib/dovecot into /usr/lib64/dovecot? . But as I can compile fine
   
   
postfix etc other openssl used app rpm -s, then is this some dovecot bug
   
   
or what am I missing?
   
   

   
   
Error:
   
   
/usr/bin/mkdir -p
   
   
'/root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/lib/dovecot'
   
   
/bin/sh ../../libtool --mode=install /usr/bin/install -c
   
   
libssl_iostream_openssl.la
   
   
'/root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/lib/dovecot'
   
   
libtool: install: /usr/bin/install -c .libs/libssl_iostream_openssl.so
   
   
/root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/lib/dovecot/libssl_iostream_openssl.so
   
   
libtool: install: /usr/bin/install -c .libs/libssl_iostream_openssl.lai
   
   
/root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/lib/dovecot/libssl_iostream_openssl.la
   
   
libtool: install: /usr/bin/install -c .libs/libssl_iostream_openssl.a
   
   
/root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/lib/dovecot/libssl_iostream_openssl.a
   
   
libtool: install: chmod 644
   
   
/root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/lib/dovecot/libssl_iostream_openssl.a
   
   
libtool: install: ranlib
   
   
/root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/lib/dovecot/libssl_iostream_openssl.a
   
   
libtool: warning: remember to run 'libtool --finish /usr/lib/dovecot'
   
   
/usr/bin/mkdir -p
   
   
'/root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/include/dovecot'
   
   
/usr/bin/install -c -m 644 iostream-openssl.h iostream-ssl.h
   
   
iostream-ssl-private.h iostream-ssl-test.h
   
   
'/root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/include/dovecot'
   
   
make[3]: Leaving directory
   
   
`/root/rpmbuild/BUILD/dovecot-2.3.9.2/src/lib-ssl-iostream'
   
   
make[2]: Leaving directory
   
   
`/root/rpmbuild/BUILD/dovecot-2.3.9.2/src/lib-ssl-iostream'
   
   
Making install in lib-dcrypt
   
   
make[2]: Entering directory
   
   
`/root/rpmbuild/BUILD/dovecot-2.3.9.2/src/lib-dcrypt'
   
   
make[3]: Entering directory
   
   
`/root/rpmbuild/BUILD/dovecot-2.3.9.2/src/lib-dcrypt'
   
   
/usr/bin/mkdir -p
   
   
'/root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/lib64/dovecot'
   
   
/bin/sh ../../libtool --mode=install /usr/bin/install -c
   
   
libdcrypt_openssl.la
   
   
'/root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/lib64/dovecot'
   
   
libtool: error: error: cannot install 'libdcrypt_openssl.la' to a
   
   
directory not ending in /usr/lib/dovecot
   
   
make[3]: *** [install-pkglibLTLIBRARIES] Error 1
   
   
make[3]: Leaving directory
   
   
`/root/rpmbuild/BUILD/dovecot-2.3.9.2/src/lib-dcrypt'
   
   
make[2]: *** [install-am] Error 2
   
   
make[2]: Leaving directory
   
   
`/root/rpmbuild/BUILD/dovecot-2.3.9.2/src/lib-dcrypt'
   
   
make[1]: *** [install-recursive] Error 1
   
   
make[1]: Leaving directory `/root/rpmbuild/BUILD/dovecot-2.3.9.2/src'
   
   
make: *** [install-recursive] Error 1
   
   
error: Bad exit status from /var/tmp/rpm-tmp.EVWbif (%install)
   
   

   
   

   
   
Options:
   
   
./configure \
   
   
--prefix=/usr \
   
   
--with-ssl=openssl \
   
   
--with-ssldir=/etc/ssl \
   
   
--sysconfdir=/etc \
   
   
--without-vpopmail \
   
   
--with-pam \
   
   
--without-bsdauth \
   
   
--without-sql \
   
   
--without-nss \
   
   
--without-ldap \
   
   
--without-pgsql \
   
   
--without-mysql \
   
   
--without-sqlite \
   
   
--with-rundir=/var/run/dovecot \
   
   
--without-sia \
   
   
--without-cassandra \
   
   
--without-lucene \
   
   
--without-solr \
   
   
--without-textcat \
   
   
--without-libcap \
   
   
--without-stemmer \
   
   
--disabl

Cannot install 'libdcrypt_openssl.la' to a directory not ending in /usr/lib/dovecot

2019-12-15 Thread Mart Pirita 
Hi,

For some reason I've never been able to build x64 dovecot rpm package,
no matter how I try, I'm still getting lib64 errors, first tried few
years on centos 5, ok I know this is old distro, then few years tried
with centos 6 (and wrote here also - CentOS x64 compilation fails),
supported distro, no luck, now installed centos 7 and still no luck, so
seems it's not about centos or rpm version.

So I'm using option "rpmbuild -ba --target=i686 dovecot2.3.spec" to
build it, and it works but I'd still like to build x64 version. Why
libtool tries to install libdcrypt_openssl.la only instead
/usr/lib/dovecot into /usr/lib64/dovecot? . But as I can compile fine
postfix etc other openssl used app rpm -s, then is this some dovecot bug
or what am I missing?

Error:
 /usr/bin/mkdir -p
'/root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/lib/dovecot'
 /bin/sh ../../libtool   --mode=install /usr/bin/install -c
libssl_iostream_openssl.la
'/root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/lib/dovecot'
libtool: install: /usr/bin/install -c .libs/libssl_iostream_openssl.so
/root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/lib/dovecot/libssl_iostream_openssl.so
libtool: install: /usr/bin/install -c .libs/libssl_iostream_openssl.lai
/root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/lib/dovecot/libssl_iostream_openssl.la
libtool: install: /usr/bin/install -c .libs/libssl_iostream_openssl.a
/root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/lib/dovecot/libssl_iostream_openssl.a
libtool: install: chmod 644
/root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/lib/dovecot/libssl_iostream_openssl.a
libtool: install: ranlib
/root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/lib/dovecot/libssl_iostream_openssl.a
libtool: warning: remember to run 'libtool --finish /usr/lib/dovecot'
 /usr/bin/mkdir -p
'/root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/include/dovecot'
 /usr/bin/install -c -m 644 iostream-openssl.h iostream-ssl.h
iostream-ssl-private.h iostream-ssl-test.h
'/root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/include/dovecot'
make[3]: Leaving directory
`/root/rpmbuild/BUILD/dovecot-2.3.9.2/src/lib-ssl-iostream'
make[2]: Leaving directory
`/root/rpmbuild/BUILD/dovecot-2.3.9.2/src/lib-ssl-iostream'
Making install in lib-dcrypt
make[2]: Entering directory
`/root/rpmbuild/BUILD/dovecot-2.3.9.2/src/lib-dcrypt'
make[3]: Entering directory
`/root/rpmbuild/BUILD/dovecot-2.3.9.2/src/lib-dcrypt'
 /usr/bin/mkdir -p
'/root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/lib64/dovecot'
 /bin/sh ../../libtool   --mode=install /usr/bin/install -c
libdcrypt_openssl.la
'/root/rpmbuild/BUILDROOT/dovecot-2.3.9.2-mp.x86_64/usr/lib64/dovecot'
libtool:   error: error: cannot install 'libdcrypt_openssl.la' to a
directory not ending in /usr/lib/dovecot
make[3]: *** [install-pkglibLTLIBRARIES] Error 1
make[3]: Leaving directory
`/root/rpmbuild/BUILD/dovecot-2.3.9.2/src/lib-dcrypt'
make[2]: *** [install-am] Error 2
make[2]: Leaving directory
`/root/rpmbuild/BUILD/dovecot-2.3.9.2/src/lib-dcrypt'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/root/rpmbuild/BUILD/dovecot-2.3.9.2/src'
make: *** [install-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.EVWbif (%install)


Options:
./configure \
--prefix=/usr \
--with-ssl=openssl \
--with-ssldir=/etc/ssl \
--sysconfdir=/etc \
--without-vpopmail \
--with-pam \
--without-bsdauth \
--without-sql \
--without-nss \
--without-ldap \
--without-pgsql \
--without-mysql \
--without-sqlite \
--with-rundir=/var/run/dovecot \
--without-sia \
--without-cassandra \
--without-lucene \
--without-solr \
--without-textcat \
--without-libcap  \
--without-stemmer \
--disable-rpath \
--disable-dependency-tracking \
--disable-silent-rules \
--without-gssapi \
--without-cdb

-- 
Mart

Re: Parsing variables in config files

2019-12-15 Thread Eudald Valcàrcel Lacasa 
You're right.
My apologies.

El dom., 15 dic. 2019 a las 7:54, Christian Kivalo ()
escribió:

>
>
> On December 15, 2019 2:50:03 AM GMT+01:00, "Eudald Valcàrcel Lacasa" <
> eudald.valcar...@gmail.com> wrote:
> >Hello,
> >I'm trying to set up a mailbox for a bunch of domains.
> >To do so I'm running some docker containers (I know I can use
> >multidomain
> >set up and I'm doing so, but I need to have some domains on different
> >containers for specific reasons).
> >
> >In order to keep it all clean, I want to use different PostgreSQL
> >databases
> >for each container, and I'm running the container with an environment
> >file
> >containing database parameters, such as:
> >DB_USER
> >DB_HOST
> >DB_NAME
> >I've been trying to pass these parameters to dovecot's configuration,
> >but
> >they don't get parsed and I end up with messages like: dovecot: auth:
> >Error: pgsql(%{env:DB_HOST}): Connect failed to database %{env:DB_NAME}
> >
> >I've tried to pass variables alone, using import_environment = DB_HOST
> >DB_NAME DB_USER, but I'm stuck at the same errors.
> >
> >Is there anything I could do to fix this?
> There was this exact question a short time ago.
> See the list archive from December 4, there is your answer.
> Basically, the pgsql library will use specific env variables when they
> exist and aren't set through dovecot configuration.
> >Thank you!
> >Eudald
>
> --
> Christian Kivalo
>