Re: Cyrus Murder Environment Upgrade
Wolfgang, If you don't mind, I'd like to know if when you upgraded backend servers from 2.4 version to 2.5 version you have an increase, in metadata size.Here we had 30% around of increase Thanks one more time Greetings -- Miguel Moreira DTE/SRE/GRE - Gerência de Redes +55(31)3339-1401 PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação sigilosa e legalmente protegida. O uso impróprio será tratado conforme as normas da empresa e a legislação em vigor. Caso não seja o destinatário, favor notificar o remetente, ficando proibidas a utilização, divulgação, cópia e distribuição. Em Terça, Junho 09, 2020 10:39 -03, Wolfgang Breyha escreveu:Hi! On 09/06/2020 14:56, Miguel Mucio Santos Moreira wrote: > Dear Wolfgang, > > Firstly thanks for your answer, secondly I have one more doubt, during this > time where the new Mupdate Master is receiving mailboxes information from > backend servers, is necessary stopping comunications between frontend > servers and mupdate master or none action is necessary besides that one > you've mentioned before? > We're concerned if frontend servers will connect to Mupdate Master and > receive from it an information which there's no mailboxes anymore until the > backend push entirely mailboxes information and this situation to cause any > trouble. I recommend the follow steps: *) check that your currently running setup has no conflicts in mailboxes.db by running "ctl_mboxlist -mw". It is possible that you see output if somebody changes his mailboxes while you run the command, but it should not appear again if you run the command a second time. If everything is fine... *) shut down all running cyrus frontends first, then backends and mupdate last *) backup your mailboxes.db on mupdate server *) replace/update mupdate and start it with empty/removed mailboxes.db. *) backup your mailboxes.db on the backends *) do the ctl_mboxlist -m by hand on the backends (only one at the same time) you can check if everything went ok with "-mw" at any time afterwards. *) start cyrus on backends In our setup the frontends have mupdate running as well. I can't currently remember if this is mandatory. If this is true in your setup then: *) remove or rename the mailboxes.db database on the frontends and start them. They will fetch the database immediately from the mupdate server. This is visible in syslog as well and takes about 30 seconds in our setup (~250MB mailboxes.db). otherwise *) start the frontends At this point everything should be up and running again. Watching syslog output all the time usually helps. IIRC we updated the mupdate server to 2.5 first. Then we had a mix of 2.4 and 2.5 backends for some time. The 2.5 backends had some capabilities suppressed. Frontends had 2.4 until all backends had 2.5. Last but not least we upgraded to 2.5 on the frontends. If you need more info/details feel free to ask. Greetings, Wolfgang -- Wolfgang Breyha | https://www.blafasel.at/ Vienna University Computer Center | Austria Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Cyrus Murder Environment Upgrade
Wolfgang, I'm sure your help and experience with Cyrus Murder upgrading will save a lot of time and reduce the possibility of an eventual problem during the upgrade. Thankful -- Miguel Moreira DTE/SRE/GRE - Gerência de Redes +55(31)3339-1401 PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação sigilosa e legalmente protegida. O uso impróprio será tratado conforme as normas da empresa e a legislação em vigor. Caso não seja o destinatário, favor notificar o remetente, ficando proibidas a utilização, divulgação, cópia e distribuição. Em Terça, Junho 09, 2020 10:39 -03, Wolfgang Breyha escreveu:Hi! On 09/06/2020 14:56, Miguel Mucio Santos Moreira wrote: > Dear Wolfgang, > > Firstly thanks for your answer, secondly I have one more doubt, during this > time where the new Mupdate Master is receiving mailboxes information from > backend servers, is necessary stopping comunications between frontend > servers and mupdate master or none action is necessary besides that one > you've mentioned before? > We're concerned if frontend servers will connect to Mupdate Master and > receive from it an information which there's no mailboxes anymore until the > backend push entirely mailboxes information and this situation to cause any > trouble. I recommend the follow steps: *) check that your currently running setup has no conflicts in mailboxes.db by running "ctl_mboxlist -mw". It is possible that you see output if somebody changes his mailboxes while you run the command, but it should not appear again if you run the command a second time. If everything is fine... *) shut down all running cyrus frontends first, then backends and mupdate last *) backup your mailboxes.db on mupdate server *) replace/update mupdate and start it with empty/removed mailboxes.db. *) backup your mailboxes.db on the backends *) do the ctl_mboxlist -m by hand on the backends (only one at the same time) you can check if everything went ok with "-mw" at any time afterwards. *) start cyrus on backends In our setup the frontends have mupdate running as well. I can't currently remember if this is mandatory. If this is true in your setup then: *) remove or rename the mailboxes.db database on the frontends and start them. They will fetch the database immediately from the mupdate server. This is visible in syslog as well and takes about 30 seconds in our setup (~250MB mailboxes.db). otherwise *) start the frontends At this point everything should be up and running again. Watching syslog output all the time usually helps. IIRC we updated the mupdate server to 2.5 first. Then we had a mix of 2.4 and 2.5 backends for some time. The 2.5 backends had some capabilities suppressed. Frontends had 2.4 until all backends had 2.5. Last but not least we upgraded to 2.5 on the frontends. If you need more info/details feel free to ask. Greetings, Wolfgang -- Wolfgang Breyha | https://www.blafasel.at/ Vienna University Computer Center | Austria Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Cyrus Murder Environment Upgrade
Dear Wolfgang, Firstly thanks for your answer, secondly I have one more doubt, during this time where the new Mupdate Master is receiving mailboxes information from backend servers, is necessary stopping comunications between frontend servers and mupdate master or none action is necessary besides that one you've mentioned before? We're concerned if frontend servers will connect to Mupdate Master and receive from it an information which there's no mailboxes anymore until the backend push entirely mailboxes information and this situation to cause any trouble. One more time, thanks Cheers! -- Miguel Moreira DTE/SRE/GRE - Gerência de Redes +55(31)3339-1401 PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação sigilosa e legalmente protegida. O uso impróprio será tratado conforme as normas da empresa e a legislação em vigor. Caso não seja o destinatário, favor notificar o remetente, ficando proibidas a utilização, divulgação, cópia e distribuição. Em Terça, Junho 09, 2020 05:31 -03, Wolfgang Breyha escreveu:On 08/06/2020 17:37, Miguel Mucio Santos Moreira wrote: > Now we're in doubt about how is the best solution to replace the mupdate > master server for a new one. > Nowadays we have around 16K mailboxes. IIRC we simply replaced the mupdate server and did a "ctl_mboxlist -m" on all backends to fill it. Shouldn't take that long since we did it with 130k on 8 backends in under 20 minutes (or even shorter). Greetings, Wolfgang -- Wolfgang Breyha | https://www.blafasel.at/ Vienna University Computer Center | Austria Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Cyrus Murder Environment Upgrade
Hello guys! We have a cyrus murder environment with cyrus 2.4 version, according to cyrus documentation we should upgrade backend servers, mupdate master and for last frontend servers. Following this recommendantions we've installed new backend servers, with 2.5 version, joined them to the cluster and migrated mailboxes from old servers to new servers throught xfer. Now we're in doubt about how is the best solution to replace the mupdate master server for a new one. Nowadays we have around 16K mailboxes. Any hint? Thanks in advance Cheers! -- Miguel Moreira DTE/SRE/GRE - Gerência de Redes +55(31)3339-1401 PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação sigilosa e legalmente protegida. O uso impróprio será tratado conforme as normas da empresa e a legislação em vigor. Caso não seja o destinatário, favor notificar o remetente, ficando proibidas a utilização, divulgação, cópia e distribuição. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Increasing metadata data
Dear, We're upgrading our cyrus version from 2.4.16-5 on Debian 7 to 2.5.10-3 on Debian 9. Our environment is composed for backend, mupdate master and frontend servers in a Murder topology. Following the cyrus imap documentation we're creating new backend servers with that new version informed above. Even with some punctual issues, we're migrating mailboxes successfully to new backend server. However we diagnostic this new backend has a huge increasing in it's metadata data in comparison with the old ones. We are in doubt if it is a expected behaviour or not, and if not what could be the problem related to. Thanks in advance. Respectfully -- Miguel Moreira DTE/SRE/GRE - Gerência de Redes +55(31)3339-1401 PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação sigilosa e legalmente protegida. O uso impróprio será tratado conforme as normas da empresa e a legislação em vigor. Caso não seja o destinatário, favor notificar o remetente, ficando proibidas a utilização, divulgação, cópia e distribuição. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: kick_mupdate refused
Hello Michael, We don't use TLS in our Mudpate Master. Thanks for your help. -- Miguel Moreira DTE/SRE/GRE - Gerência de Redes +55(31)3339-1401 PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação sigilosa e legalmente protegida. O uso impróprio será tratado conforme as normas da empresa e a legislação em vigor. Caso não seja o destinatário, favor notificar o remetente, ficando proibidas a utilização, divulgação, cópia e distribuição. Em Quinta, Setembro 26, 2019 04:31 -03, Michael Menge escreveu:Hi, Quoting Miguel Mucio Santos Moreira : > Hello everybody > > I've had a weird log information on my frontends servers regards to > mupdate connection from frontend to mupdate master. > Mupdate Master would be refusing connections from frontend servers. > > srvimapfprd01 cyrus/imaps[29677]: kick_mupdate: can't connect to > target: Connection refused > > These messages don't appear all day long and I don't notice any > problem with the murder cluster > > All my cluster has cyrus 2.4.16-4 version. > > Any hints about it? > Does your mupdate master use TLS? https://github.com/cyrusimap/cyrus-imapd/issues/2774 The problem was obvious in Cyrus 3.0 but I hat those connection problems also with 2.4 and I now think it was non-thread-safe usage of openssl M.Menge Tel.: (49) 7071/29-70316 Universität Tübingen Fax.: (49) 7071/29-5912 Zentrum für Datenverarbeitung mail: michael.me...@zdv.uni-tuebingen.de Wächterstraße 76 72074 Tübingen Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
kick_mupdate refused
Hello everybody I've had a weird log information on my frontends servers regards to mupdate connection from frontend to mupdate master. Mupdate Master would be refusing connections from frontend servers. srvimapfprd01 cyrus/imaps[29677]: kick_mupdate: can't connect to target: Connection refused These messages don't appear all day long and I don't notice any problem with the murder cluster All my cluster has cyrus 2.4.16-4 version. Any hints about it? Thanks in advance -- Miguel Moreira DTE/SRE/GRE - Gerência de Redes +55(31)3339-1401 PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação sigilosa e legalmente protegida. O uso impróprio será tratado conforme as normas da empresa e a legislação em vigor. Caso não seja o destinatário, favor notificar o remetente, ficando proibidas a utilização, divulgação, cópia e distribuição. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Mailboxes with slow access
Hi Ellie, Thanks for answers, I'm gonna check how much memory the imap process is using like you suggest. Any other update about this issue I'll post here. Regards -- Miguel Moreira Gerente DPR/SRE/GSR - Gerência de Serviços de Rede +55(31)3339-1401 PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação sigilosa e legalmente protegida. O uso impróprio será tratado conforme as normas da empresa e a legislação em vigor. Caso não seja o destinatário, favor notificar o remetente, ficando proibidas a utilização, divulgação, cópia e distribuição. Em Domingo, Janeiro 20, 2019 23:33 -02, ellie timoney escreveu: Hi Miguel, On Sat, Jan 19, 2019, at 8:20 AM, Miguel Mucio Santos Moreira wrote:Hi folks! I've had a problem with some huge mailboxes, with a lot of folders and subfolders. Problably thousand of folders.The access on these mailboxes is too slow, if you change from INBOX to another folder called CYRUS, even if CYRUS folder has just 4 messages for example the access is slow. This sounds like you don't have enough RAM to hold the metadata for these mailboxes in memory, and so the system is swapping while accessing them. You could find the imapd process that is servicing this connection and look at its virtual memory size, and compare that to the amount of physical RAM in your system, to see whether this is the case. Or, if you post up the size of these mailboxes' cyrus.header, cyrus.index, cyrus.annotations, cyrus.cache (...) files and the size of their [user].conversations file (if you have conversations enabled), then maybe someone will be able to suggest a RAM size that would support this. You mention being in a murder environment -- I'm not sure if you will need to increase the RAM on just the backend for these mailboxes, or the frontends as well. Maybe someone running a large murder can chime in with how they provision their servers? Sorry I don't have specific numbers for you, but hopefully this points you in the right direction! I was trying to find out anything on internet about this issue and I read that a parameter maxword on imapd.conf could be the solution.Nowadays in our cyrus-imap murder all backend servers and frontend servers have the maxword parameter set to default value which is 128kb.Based on that information, I'd like to know if I increase this parameter to a high value like 1Mb for instance it could fix the issue about slow access and which considerations about memory, disk and cpu resources I must take care if I set up this value in my environment.Another question is, this value must be setting in all backends and frontends servers? imapd.conf(5) says: maxword: 131072 Maximum size of a single word for the parser. Default 128k This setting won't have any effect on performance at all. It's just an upper limit for the IMAP parser -- if some IMAP client tries to send a single word that is longer than this, the imapd process serving their connection will exit immediately with a "word too long" error rather than trying to keep parsing. Normal traffic won't hit this limit, it's just protecting itself from (possibly malicious) garbage. The default should be never need changing really. Hope this helps, ellie Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Mailboxes with slow access
Hi folks! I've had a problem with some huge mailboxes, with a lot of folders and subfolders. Problably thousand of folders. The access on these mailboxes is too slow, if you change from INBOX to another folder called CYRUS, even if CYRUS folder has just 4 messages for example the access is slow. I was trying to find out anything on internet about this issue and I read that a parameter maxword on imapd.conf could be the solution. Nowadays in our cyrus-imap murder all backend servers and frontend servers have the maxword parameter set to default value which is 128kb. Based on that information, I'd like to know if I increase this parameter to a high value like 1Mb for instance it could fix the issue about slow access and which considerations about memory, disk and cpu resources I must take care if I set up this value in my environment. Another question is, this value must be setting in all backends and frontends servers? Thanks in advance Regards -- Miguel Moreira Gerente DPR/SRE/GSR - Gerência de Serviços de Rede +55(31)3339-1401 PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação sigilosa e legalmente protegida. O uso impróprio será tratado conforme as normas da empresa e a legislação em vigor. Caso não seja o destinatário, favor notificar o remetente, ficando proibidas a utilização, divulgação, cópia e distribuição. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: mbox operations performance issue
Dears, We've identified a problem in one of our DNS Servers, so we decided to remove it in Mupdate Master Server resolv.conf and fix it later. Thanks Best regards -- Miguel Moreira Gerente DPR/SRE/GSR - Gerência de Serviços de Rede +55(31)3339-1401 PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação sigilosa e legalmente protegida. O uso impróprio será tratado conforme as normas da empresa e a legislação em vigor. Caso não seja o destinatário, favor notificar o remetente, ficando proibidas a utilização, divulgação, cópia e distribuição. Em 20/01/2017 12:31:02, Miguel Mucio Santos Moreira via Info-cyrus escreveu: > Is the mupdate server still running? > > Yes it's running > > Do you see connections from the backends to the mupdate on port 3905? > Yes, there are connections from backend to mupdate master. > > Can you create new mailboxes? I can > > Did you try restarting cyrus on mupdate server? > > I've already done that with no success > > I've noticed this message in mupdate master log Thread timed out waiting for > listener_lock > > Thnx > > -- > Miguel Moreira > Gerente > DPR/SRE/GSR - Gerência de Serviços de Rede > +55(31)3339-1401 > PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais> > > Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação sigilosa e legalmente protegida. O uso impróprio será tratado conforme as normas da empresa e a legislação em vigor. Caso não seja o destinatário, favor notificar o remetente, ficando proibidas a utilização, divulgação, cópia e distribuição. > > > > Em 20/01/2017 12:19:26, Michael Menge via Info-cyrus escreveu: > > Hi, Quoting Miguel Mucio Santos Moreira via Info-cyrus > > : > Dears, > > > I've had a problem for some days with mailboxes operations like sam, dam etc. > Those operations are too slow, I have some mailboxes with many > subfolders when I applied a sam command to allow other user access > it, the command spends too much time (e.g 20hours). > There's nothing weird in logs or etc. > We have murder environment with cyrus-.4.16-4 on Debian 7. > mailbox operations need to be acknowledged by/committed on the MUPDATE server. Is the mupdate server still running? Do you see connections from the backends to the mupdate on port 3905? Can you create new mailboxes? Did you try restarting cyrus on mupdate server M.MengeTel.: (49) 7071/29-70316 Universität Tübingen Fax.: (49) 7071/29-5912 Zentrum für Datenverarbeitung mail: michael.me...@zdv.uni-tuebingen.de Wächterstraße 76 72074 Tübingen Cyrus Home Page: > > http://www.cyrusimap.org/> > List Archives/Info: > > http://lists.andrew.cmu.edu/pipermail/info-cyrus/> > To Unsubscribe: > > https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus> > > > @lists.andrew.cmu.edu> > Cyrus Home Page: > http://www.cyrusimap.org/> List Archives/Info: > http://lists.andrew.cmu.edu/pipermail/info-cyrus/> To Unsubscribe: > https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: mbox operations performance issue
Is the mupdate server still running? Yes it's running Do you see connections from the backends to the mupdate on port 3905? Yes, there are connections from backend to mupdate master. Can you create new mailboxes? I can Did you try restarting cyrus on mupdate server? I've already done that with no success I've noticed this message in mupdate master log Thread timed out waiting for listener_lock Thnx -- Miguel Moreira Gerente DPR/SRE/GSR - Gerência de Serviços de Rede +55(31)3339-1401 PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação sigilosa e legalmente protegida. O uso impróprio será tratado conforme as normas da empresa e a legislação em vigor. Caso não seja o destinatário, favor notificar o remetente, ficando proibidas a utilização, divulgação, cópia e distribuição. Em 20/01/2017 12:19:26, Michael Menge via Info-cyrus escreveu: > Hi, Quoting Miguel Mucio Santos Moreira via Info-cyrus > : > Dears, > > > I've had a problem for some days with mailboxes operations like sam, dam etc. > Those operations are too slow, I have some mailboxes with many > subfolders when I applied a sam command to allow other user access > it, the command spends too much time (e.g 20hours). > There's nothing weird in logs or etc. > We have murder environment with cyrus-.4.16-4 on Debian 7. > mailbox operations need to be acknowledged by/committed on the MUPDATE server. Is the mupdate server still running? Do you see connections from the backends to the mupdate on port 3905? Can you create new mailboxes? Did you try restarting cyrus on mupdate server M.MengeTel.: (49) 7071/29-70316 Universität Tübingen Fax.: (49) 7071/29-5912 Zentrum für Datenverarbeitung mail: michael.me...@zdv.uni-tuebingen.de Wächterstraße 76 72074 Tübingen Cyrus Home Page: > http://www.cyrusimap.org/> List Archives/Info: > http://lists.andrew.cmu.edu/pipermail/info-cyrus/> To Unsubscribe: > https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus> > @lists.andrew.cmu.edu> Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
mbox operations performance issue
Dears, I've had a problem for some days with mailboxes operations like sam, dam etc. Those operations are too slow, I have some mailboxes with many subfolders when I applied a sam command to allow other user access it, the command spends too much time (e.g 20hours). There's nothing weird in logs or etc. We have murder environment with cyrus-.4.16-4 on Debian 7. Thanks in advance -- Miguel Moreira Gerente DPR/SRE/GSR - Gerência de Serviços de Rede +55(31)3339-1401 PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação sigilosa e legalmente protegida. O uso impróprio será tratado conforme as normas da empresa e a legislação em vigor. Caso não seja o destinatário, favor notificar o remetente, ficando proibidas a utilização, divulgação, cópia e distribuição. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Seen problem after xfer command
Hi everybody, SERPRO (It's an IT services corporation of Brazilian Federal Government) has discovered what was going on about my xfer problem, they had the same situation in their environment. We've suppressed the Server Information turning the serverinfo parameter off and this was causing the problem. We thought better to suppress it because of security reasons, turning it on (default value), cyrus put a lot of environment information into email header. Actually the serverinformation parameter only causes problem if it turned off in backend servers (Murder Environment). During the mailbox transfer the source server does a downgrade of index to version 6 and the destination server does an upgrade from version 6 to 12: Jan 25 16:35:48 srcserver cyrus/imap[4608]: user.X.Templates downgrading index to version 6 for XFER Jan 25 16:35:55 dstserver cyrus/imap[325]: Index upgrade: user.x.Templates (6 -> 12) When the serverinfo parameter is turned on, the above information doesn't appear in log file. I'd like to thank Gustavo from SERPRO for sharing the information, so if someone else has the same problem put the serverinfo parameter on and have the problem solved. We'd prefer to suppress this information but mailbox transfer is more important than security reasons for now. See you -- Miguel Mucio Santos Moreira Analista - LPIC 1 Linux Professional Institute Certified GRE - Gerência de Redes (31)3339-1401 PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e legalmente protegida. Se você não for destinatário dela, desde já fica notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. Caso você tenha recebido por engano, pedimos que responda essa mensagem informando o acontecido. Em 16/07/2015 16:21:49, Miguel Mucio Santos Moreira escreveu: > Hi everybody, > > I've had a weird trouble in my cyrus murder environment. > After I move a mailbox between the backend servers, for each non empty folder > which has all email as read, it put the most recent email as unread. > It seems a seen problem but I wasn't able to find out the reason. > Have anyone already had this problem? Is it a known bug? > My backend environment is: > Debian 7.0 > Cyrus Version: 2.4.16-4 > > I've checked the changes on this link > > https://cyrusimap.org/docs/cyrus-imapd/2.4.18/changes.php> looking for this > problem. > > Thanks in advance > > Sincerely > > -- > Miguel Mucio Santos Moreira > Analista - LPIC 1 Linux Professional Institute Certified > GRE - Gerência de Redes > (31)3339-1401 > PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais> > > Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e legalmente protegida. Se você não for destinatário dela, desde já fica notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. Caso você tenha recebido por engano, pedimos que responda essa mensagem informando o acontecido. > > Cyrus Home Page: > http://www.cyrusimap.org/> List Archives/Info: > http://lists.andrew.cmu.edu/pipermail/info-cyrus/> To Unsubscribe: > https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: imapd.conf configuration - Received Mail Header
Dear Walter, I think some part of your configuration there's a socket option, problably if you change this socket to listen for real ip server instead of loopback and also change cyrus to connect in this real ip server the information mail.local would be replaced for what you want. See you -- Miguel Mucio Santos Moreira Analista - LPIC 1 Linux Professional Institute Certified GRE - Gerência de Redes (31)3339-1401 PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e legalmente protegida. Se você não for destinatário dela, desde já fica notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. Caso você tenha recebido por engano, pedimos que responda essa mensagem informando o acontecido. Em 08/12/2015 16:23:33, Walter H. via Info-cyrus escreveu: > Hello, does anybody know if it is possible to prevent Cyrus adding a Received-Line in the mail header at my Cyrus this looks like Received: from mail.local ([unix socket]) by storage.mail (Cyrus v2.3.16-Fedora-RPM-2.3.16-13.el6_6) with LMTPA; Tue, 08 Dec 2015 18:35:12 +0100 instead of mail.local there is adds my real server name; from where does this come? can I also just change it here, without renaming anything? like "storage.mail", which come from /etc/imapd.conf "servername: storage.mail" I'd like either instead of mail.local a user defined value or no Received-line at all; is this possible, if yes, how? Thanks, Walter > Cyrus Home Page: > http://www.cyrusimap.org/> List Archives/Info: > http://lists.andrew.cmu.edu/pipermail/info-cyrus/> To Unsubscribe: > https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Seen problem after transfering a mailbox
Hello everybody, I have a weird trouble in my cyrus murder environment. After I move a mailbox between backend servers, for each non empty folder which has all email as read, it put the most recent email as unread. It seems a seen problem but I wasn't able to find out the reason that it happens after a transfer of a mailbox. Could anyone help me? My backend/frontend environment is: Debian 7.0 Cyrus Version: 2.4.16-4 Cheers -- Miguel Mucio Santos Moreira Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: cyradm: perl: symbol lookup error?
Patrick, About question 3, is possible to use a php script or even a python script to manage users. Would be possible but I don't know if would be to you,install a new machine with a standard operational system just to manager these users. -- Miguel Mucio Santos Moreira Analista - LPIC 1 Linux Professional Institute Certified GRE - Gerência de Redes (31)3339-1401 PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e legalmente protegida. Se você não for destinatário dela, desde já fica notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. Caso você tenha recebido por engano, pedimos que responda essa mensagem informando o acontecido. Em 16/09/2015 13:33:42, Patrick Goetz escreveu: > So, I've been happily avoiding upgrading cyrus imap because everything has been working and I'm generally in the "if it ain't broke, don't fix it" category. Cyrus version: 2.4.17 Perl version: 5.22.0 However, this morning I tried to create a new user using cyradm and got a perl error message: pgoetz@www:~$ cyradm --user administrator localhost perl: symbol lookup error: /usr/lib/perl5/site_perl/auto/Cyrus/IMAP/IMAP.so: undefined symbol: Perl_xs_apiversion_bootcheck I'm running Arch linux, which aggressively updates software packages. Apparently some Perl upgrade broke cyradm? 3 questions: 1. Does this mean I need to bite the bullet and upgrade my cyrus installs? 2. Is upgrading to 2.5.6 painless? Should I just wait for 3.0? 3. Is there a workaround for cyradm not working for adding users? I've only ever used cyradm and have no idea how to add users otherwise. Cyrus Home Page: > http://www.cyrusimap.org/> List Archives/Info: > http://lists.andrew.cmu.edu/pipermail/info-cyrus/> To Unsubscribe: > https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus> Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Seen problem after xfer command
Hi everybody, I've had a weird trouble in my cyrus murder environment. After I move a mailbox between the backend servers, for each non empty folder which has all email as read, it put the most recent email as unread. It seems a seen problem but I wasn't able to find out the reason. Have anyone already had this problem? Is it a known bug? My backend environment is: Debian 7.0 Cyrus Version: 2.4.16-4 I've checked the changes on this link https://cyrusimap.org/docs/cyrus-imapd/2.4.18/changes.php looking for this problem. Thanks in advance Sincerely -- Miguel Mucio Santos Moreira Analista - LPIC 1 Linux Professional Institute Certified GRE - Gerência de Redes (31)3339-1401 PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e legalmente protegida. Se você não for destinatário dela, desde já fica notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. Caso você tenha recebido por engano, pedimos que responda essa mensagem informando o acontecido. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
