Le jeu. 28 f?vr. 2019 ? 11:18, Francis <francisd at gmail.com> a ?crit :> Le mar. 26 f?vr. 2019 ? 22:58, David Myers <david.myers.24j74 at gmail.com> > a ?crit : > >> Hello Francis, >> >> I wonder if this is due to how a cluster is configured to function >> internally. >> >> Tell us more about the cluster, is it one of those ?fancy pants? high >> availability, auto backup heart beat things, or is it more a traditional >> multi server (master slave style) setup. >> >> Either way you may need to disconnect the servers from one another and >> delete the offending files / directories either via dove or or via the os >> (although reading your original email it sounds like you are already >> attempting this). >> >> If you have a fancy cluster this may actually be more difficult than it >> sounds and have interesting (unwanted) side effects, also the underlying >> database (if you are storing emails that way) may have a method to remove >> data >> >> I assume you are keeping back up copies of all those emails somewhere, >> just in case you need them in the future. >> >> See this wiki article to better understand what I mean by the ?fancy >> pants? clusters : >> https://en.m.wikipedia.org/wiki/High-availability_cluster >> They sound very cool, but I suspect are overkill for a mail server, >> unless your database is already inside one then it would make sense I >> guess. >> >> > Hello, > > I just use the cluster/replication functionality integrated into dovecot, > nothing more. There is no database involved. I use LDAP for the > authentication. The mails are stored locally on each server and replicated > with the replication feature of dovecot. > > I followed this wiki article: https://wiki.dovecot.org/Replication > >Hello, So nobody use the replication feature? or nobody never ever remove a mailbox? or maybe my question is so dumb and I should RTFM something? :) Do you need more information to help me to debug that issue? Thanks. -- Francis -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20190304/54859ca7/attachment.html>
> Am 04.03.2019 um 16:35 schrieb Francis via dovecot <dovecot at dovecot.org>: > > Le jeu. 28 f?vr. 2019 ? 11:18, Francis <francisd at gmail.com <mailto:francisd at gmail.com>> a ?crit : > Le mar. 26 f?vr. 2019 ? 22:58, David Myers <david.myers.24j74 at gmail.com <mailto:david.myers.24j74 at gmail.com>> a ?crit : > Hello Francis, > > I wonder if this is due to how a cluster is configured to function internally. > > Tell us more about the cluster, is it one of those ?fancy pants? high availability, auto backup heart beat things, or is it more a traditional multi server (master slave style) setup. > > Either way you may need to disconnect the servers from one another and delete the offending files / directories either via dove or or via the os (although reading your original email it sounds like you are already attempting this). > > If you have a fancy cluster this may actually be more difficult than it sounds and have interesting (unwanted) side effects, also the underlying database (if you are storing emails that way) may have a method to remove data > > I assume you are keeping back up copies of all those emails somewhere, just in case you need them in the future. > > See this wiki article to better understand what I mean by the ?fancy pants? clusters : > https://en.m.wikipedia.org/wiki/High-availability_cluster <https://en.m.wikipedia.org/wiki/High-availability_cluster>They sound very cool, but I suspect are overkill for a mail server, unless your database is already inside one then it would make sense I guess. > > > Hello, > > I just use the cluster/replication functionality integrated into dovecot, nothing more. There is no database involved. I use LDAP for the authentication. The mails are stored locally on each server and replicated with the replication feature of dovecot. > > I followed this wiki article: https://wiki.dovecot.org/Replication <https://wiki.dovecot.org/Replication> > > > Hello, > > So nobody use the replication feature? or nobody never ever remove a mailbox? or maybe my question is so dumb and I should RTFM something? :) > > Do you need more information to help me to debug that issue? > > Thanks.Hallo Francis, have you tried removing the account from your ldap? If dovecot has no information about a particular user, it won't replicate. Then you would have to delete the mailbox (on both cluster nodes) from the filesystem (rm -rf /path/to/mailbox) During testing you could move the mailbox somewhere else instead of deleting it, just in case something does not work as expected. Deleting files on another server could be automated with ssh (ssh keys). Best regards, Gerald -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20190304/0a14db2f/attachment-0001.html>
Le lun. 4 mars 2019 ? 12:48, Gerald Galster via dovecot <dovecot at dovecot.org> a ?crit :> > Hallo Francis, > > have you tried removing the account from your ldap? If dovecot has no > information about a particular user, it won't replicate. > > Then you would have to delete the mailbox (on both cluster nodes) from the > filesystem (rm -rf /path/to/mailbox) > During testing you could move the mailbox somewhere else instead of > deleting it, just in case something does not work as expected. > > Deleting files on another server could be automated with ssh (ssh keys). > >Hello, I'm also using single instance storage for attachments. Because of that, I think I can't just remove the mdbox storage with rm because I'll be stuck with attachments from removed mailboxes. Am I wrong? This is why I first use doveadm flags/expunge to mark as removed all messages then I use doveadm purge to remove them from storage. I can't use theses commands on deleted/disabled user, I get an error saying the user cannot be found, so I can't remove them from LDAP first. -- Francis -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20190304/166eaf2f/attachment.html>