similar to: Dovecot not surviving OpenLDAP restart

Hi! Running Dovecot 2.2.36 and authenticating against an OpenLDAP 2.4.45 server. Now since some update of dovecot it will not be able to authenticate your logins after a restart of the LDAP service is restarted without a reboot of the dovecot server. Anything new here that I should be aware of? Best Regards Dag

Hi! Just udated my Fedora dovecot to version 2.2.36 and found that after the update dovecot will fail all LDAP logins after slapd has been restarted during the logrotate. Restarting dovecot fixes the problem. Is there a bug preventing dovecot to reopen the LDAP session when it fails? Best Dag

Am 08.05.19 um 15:32 schrieb Dag Nygren via dovecot: > Now since some update of dovecot it will not be able to authenticate > your logins after a restart of the LDAP service is restarted > without a reboot of the dovecot server. Hello, This sounds more like a configuration glitch. Could you show the ldap related dovecot configuration? Logs with failure message will also be helpful.

On onsdag 29 augusti 2018 kl. 17:39:18 EEST Stephen John Smoogen wrote: > On Wed, 29 Aug 2018 at 10:25, Dag Nygren <dag at newtech.fi> wrote: > > Anyone here with an experience in transitioning QEMU -> XEN ? > http://www.cse.psu.edu/~pdm12/cse544/slides/cse544-schiffman-vTPM.pdf goes > through some of the problems. Yes, I had a look at that earlier and it seems XEN has

Hi! Have been using Fedora as my dovecot server for some time and am struggling with systemd at every update. Fedora insists on setting ProtectSystem=full in both dovecot.service and postfix.service at every update of the packages. This makes my mailstore which is in /usr/local/var/mail Read-only. And this makes the incoming emails delivered through dovecot-lda disappear into /dev/null until I

On onsdag 29 augusti 2018 kl. 10:00:39 EEST Sandro Bonazzola wrote: > 2018-08-28 13:52 GMT+02:00 Dag Nygren <dag at newtech.fi>: > > > We have a desperate need for TPM support and: > > > > 1. Tried the "standard" distro install. linvirt supports > > TPM passthrough but kvm-qemu barfs: > > "unsupported configuration: The QEMU executable

hmm if message cannot be written to disk surely it remains on mda queue as not delviered and does not just disappear ? or am i reading this wrong ?! > Dag Nygren <mailto:dag at newtech.fi> > 16 August 2017 at 7:14 am > Thanks for all the advice on how to configure systemd > not to loose my emails after every update. Much appreciated. > > But there could be other reasons

Hi all! Just setting up a cluster using Centos 7 We have a desperate need for TPM support and: 1. Tried the "standard" distro install. linvirt supports TPM passthrough but kvm-qemu barfs: "unsupported configuration: The QEMU executable /usr/libexec/qemu-kvm does not support TPM backend type passthrough" 2. The activated the qemu-ev repo and updated qemu-kvm to version

On onsdag 29 augusti 2018 kl. 15:37:47 EEST Alvin Starr wrote: > You could try using Xen. > A quick search implies that Xen from 4.3 onward will virtualize TPM. > I am not sure if the libvirt drivers for xen will support the feature > but some work around may be possible. Nice attitude and helpfulness in this list! Just had a look and it doesn't seem to be that an intrusive

On torsdag 13 september 2018 kl. 12:58:03 EEST George Dunlap wrote: > Dag, > Just verified after a lengthy compilation of the kernel that the patch really works and now I can see a TPM on the virtual side! > Thanks for tracking this down. Any chance you could send a PR to > https://github.com/CentOS-virt7/xen-kernel? I will definitely join that mailing list. Have a feeling this is

Hi again! Succeeded in creating vtpmmgr-stubdom.gz from the source RPM with some shortcuts. ow the next problem seems to be that the libvirt we have will not support the XEN vtpm:s For example: virsh dumpxml <vm-machine> will not contain any info on the vtpm :-( Am I really the first one around with a need for TPM support in the VM:s ?? Best Dag

One of our backend pop/imap-server running dovecot v1.2.16 experienced some problems yesterday. It suddenly couldn't authenticate users anymore, flooding the logs with: pop3-login: Disconnected (auth failed, 1 attempts): user=<user1 at example.com>, method=PLAIN, rip=192.168.42.15, lip=192.168.42.28 The problem seemed to start with this log entry: Mar 29 18:57:21 popimap1 dovecot:

On 08/29/2018 12:08 PM, Stephen John Smoogen wrote: > > > On Wed, 29 Aug 2018 at 11:58, Dag Nygren <dag at newtech.fi > <mailto:dag at newtech.fi>> wrote: > > On onsdag 29 augusti 2018 kl. 17:39:18 EEST Stephen John Smoogen > wrote: > > On Wed, 29 Aug 2018 at 10:25, Dag Nygren <dag at newtech.fi > <mailto:dag at newtech.fi>>

I'm having trouble getting openldap through its initial setup. I created a /etc/openldap/slap.conf file with a default rootdn and rootpw, and they didn't seem to take effect. After much wailing and gnashing of teeth I found that if there is a config directory at /etc/openldap/slapd.d, it will ignore slapd.conf. I can't figure out how to translate slapd.conf into the (new?) standard

I currently have several fresh installs of XP that will connect to shares, but will not reconnect after a workstation reboot. These are workstations that are not joined to the domain. Only accessing shares from a local profile, but using the same user/pass to login as to connect to Samba. I get various errors at that point. Upon reboot, attempting to access the share generates: "An error

On onsdag 29 augusti 2018 kl. 15:37:47 EEST Alvin Starr wrote: > On 08/29/2018 07:38 AM, Dag Nygren wrote: > > > On onsdag 29 augusti 2018 kl. 10:00:39 EEST Sandro Bonazzola wrote: > >> 2018-08-28 13:52 GMT+02:00 Dag Nygren <dag at newtech.fi>: > >> > >>> We have a desperate need for TPM support and: > >>> > >>> 1. Tried the

Wiki seems to be out of date here. The wiki reference's [1] [2] a "setup/provision-backend" script, as well as a "setup/provision" script, yet current git only has a setup/provision executable. Some #samba and #openldap IRC advice was that provision-backend wasnt needed anymore, but based off the errors i'm seeing, there's definitely _something_ missing, I just

Greetings Experts! Sorry for my poor english, but I?m inside of a terrible nightmare!!! I?m using Samba+LDAP has about 2 months ago without problems, but in the last 4 hours, the system is absolutelly unstable. I couldn?t upgrade or patched anything. The problem simply has appeared. Principally system characteristics: - Sun Fire V880 running Solaris 9 - openldap-2.2.23 - nss_ldap-232 -

Am 25.11.18 um 14:27 schrieb Dag Nygren: > Just udated my Fedora dovecot to version 2.2.36 and > found that after the update dovecot will fail all > LDAP logins after slapd has been restarted during the logrotate. > > Restarting dovecot fixes the problem. must be something special on your local side. usually I restart my ldap server without any side effects. dovecot (the ldap

Hello List I have a strange problem here which i try to analyse, but i'm stuck. Maybe someone has a hint? What happened: A few weeks ago one of the LDAPS Servers which is not maintained by us has crashed. From that moment on, users could still login to check their emails, but they were not able to send any email through postfix (which uses smtpd_sasl_type = dovecot) What i do not