Hello all,
Is it possible to split out the mail piece of zarafa so that it uses an external dovecot server? Currently have all emails being sent via our qmail server, but need to wrap my head around using our current dovecot server. Have read that one could use fetchmail, unfortunately this is not a viable solution with close to 3,000 end users as well as the possible duplication of mail directories and email on two servers.
-Ron
Hello Ronald,
On Tue, 04 May 2010, Ronald J. Yacketta wrote:
Is it possible to split out the mail piece of zarafa so that it uses an external dovecot server? Currently have all emails being sent via our qmail server, but need to wrap my head around using our current dovecot server. Have read that one could use fetchmail, unfortunately this is not a viable solution with close to 3,000 end users as well as the possible duplication of mail directories and email on two servers.
right now, this is not possible.
Zarafa uses everywhere MAPI which isn't IMAP even the four letters are the same just in another order. With MAPI every regular e-mail gets splitted up into many socalled properties which are saved in the MySQL database; that's the very short form at least.
There are no plans by Zarafa to make Zarafa able reading IMAP stores rather just the MAPI stores on which they actually really depend on. But Zarafa doesn't strictly exclude the possibility of a IMAP storage for e-mails for the (far) future - if recently I got one of the Zarafa employees right.
But what I don't get in your scenario is, why you need Dovecot? I don't know QMail exactly, but you can make QMail delivering e-mails via .forward or LMTP to Zarafa. And Zarafa provides a socalled gateway for IMAP and POP3 for the users. Yes, of course this isn't that perfect like Dovecot or Cyrus IMAPd, because it's not a classical IMAP server and it doesn't support all the funky IMAP extensions some IMAPd servers do. But the gateway is really usable for most cases.
Hope that helps you? Note, IANAZE (I Am Not A Zarafa Employee).
Greetings, Robert
Robert Scheck wrote:
Hello Ronald,
On Tue, 04 May 2010, Ronald J. Yacketta wrote:
Is it possible to split out the mail piece of zarafa so that it uses an external dovecot server? Currently have all emails being sent via our qmail server, but need to wrap my head around using our current dovecot server. Have read that one could use fetchmail, unfortunately this is not a viable solution with close to 3,000 end users as well as the possible duplication of mail directories and email on two servers.
right now, this is not possible.
Zarafa uses everywhere MAPI which isn't IMAP even the four letters are the same just in another order. With MAPI every regular e-mail gets splitted up into many socalled properties which are saved in the MySQL database; that's the very short form at least.
There are no plans by Zarafa to make Zarafa able reading IMAP stores rather just the MAPI stores on which they actually really depend on. But Zarafa doesn't strictly exclude the possibility of a IMAP storage for e-mails for the (far) future - if recently I got one of the Zarafa employees right.
But what I don't get in your scenario is, why you need Dovecot? I don't know QMail exactly, but you can make QMail delivering e-mails via .forward or LMTP to Zarafa. And Zarafa provides a socalled gateway for IMAP and POP3 for the users. Yes, of course this isn't that perfect like Dovecot or Cyrus IMAPd, because it's not a classical IMAP server and it doesn't support all the funky IMAP extensions some IMAPd servers do. But the gateway is really usable for most cases.
Hope that helps you? Note, IANAZE (I Am Not A Zarafa Employee).
Greetings, Robert
Robert,
Thanks for the reply!
Dovecot is used for pop3 & imap, integration with avelsieve and squirrelmail. We are just not keen on hosting another mail server which (with my limited zarafa knowledge) would appear to store duplicate e-mails and possibly mail directories.
The main reason for asking is that during our initial (today) testing events created with iCal or Sunbird are not showing up on attendees calendars but emails are showing up. It seems (to me) that we would need to use zarafa's email features in-order to send / accept meeting invitations? Using other calendar type applications (bedework) events created and submitted via ics/caldav show on both the creators and attendees calendar for which they can be accepted, declined or what have you.
Regards,
Ron
zarafa mailing list zarafa@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/zarafa
Hello Ronald,
On Tue, 04 May 2010, Ronald J. Yacketta wrote:
The main reason for asking is that during our initial (today) testing events created with iCal or Sunbird are not showing up on attendees calendars but emails are showing up. It seems (to me) that we would need to use zarafa's email features in-order to send / accept meeting invitations? Using other calendar type applications (bedework) events created and submitted via ics/caldav show on both the creators and attendees calendar for which they can be accepted, declined or what have you.
some people might slap me for the comparison, but the Zarafa Webaccess is something like Thunderbird with Lightning. But instead of using IMAP and CalDav it's MAPI-based. And instead of a client application, it's webbased.
If you create an appointment using Lightning or Sunbird, they will create an e-mail which gets send to the invited person(s). If the person(s) accept the invitation, the appointment data will be written into their calendars. It behaves equivalent at Zarafa Webaccess: And thus without Zarafa Spooler, no e-mail appointment invitation will be sent and without Zarafa DAgent, no appointment invitation will show up in the inbox which could get accepted by somebody. So yes, you need the e-mail features if you would like to use the Zarafa Webaccess as calendaring software. Or you need a worse hack to only get appointment e-mails pushed into Zarafa (e.g. by using .procmailrc rules to detect appointment invitations or using a special e-mail address).
An alternative could be to just use the iCal/CalDav server component Zarafa provides and skip the Zarafa Webaccess completely. But then you need a client software handling iCal/CalDav and sending/receiving e-mails. And it is not webbased, Zarafa would just provide an iCal/CalDav server. I'm not absolutely sure whether it really makes sense to use Zarafa for only iCal/ CalDav, because there are other iCal/CalDav server implementations around.
If I explained something wrong above, somebody might correct me, please.
Greetings, Robert
Hello Ronald,
On Tue, 04 May 2010, Ronald J. Yacketta wrote:
The main reason for asking is that during our initial (today) testing events created with iCal or Sunbird are not showing up on attendees calendars but emails are showing up. It seems (to me) that we would need to use zarafa's email features in-order to send / accept meeting invitations? Using other calendar type applications (bedework) events created and submitted via ics/caldav show on both the creators and attendees calendar for which they can be accepted, declined or what have you.
some people might slap me for the comparison, but the Zarafa Webaccess is something like Thunderbird with Lightning. But instead of using IMAP and CalDav it's MAPI-based. And instead of a client application, it's webbased.
If you create an appointment using Lightning or Sunbird, they will create an e-mail which gets send to the invited person(s). If the person(s) accept the invitation, the appointment data will be written into their calendars.
This has not been the case for us, we have created numerous events via external clients and those being invited never see the meeting or get an invitation.
For example, I created an event, invited Joe and Fred for which neither received a meeting request or seen the meeting in there calendar.
It behaves equivalent at Zarafa Webaccess: And thus without Zarafa Spooler, no e-mail appointment invitation will be sent and without Zarafa DAgent, no appointment invitation will show up in the inbox which could get accepted by somebody. So yes, you need the e-mail features if you would like to use the Zarafa Webaccess as calendaring software. Or you need a worse hack to only get appointment e-mails pushed into Zarafa (e.g. by using .procmailrc rules to detect appointment invitations or using a special e-mail address).
We are not keen on using the webaccess portion, it is nice but faculty / staff have grown accustom to using ics / caldav aware clients (iCal, SunBird etc..)
An alternative could be to just use the iCal/CalDav server component Zarafa provides and skip the Zarafa Webaccess completely. But then you need a client software handling iCal/CalDav and sending/receiving e-mails. And it is not webbased, Zarafa would just provide an iCal/CalDav server. I'm not absolutely sure whether it really makes sense to use Zarafa for only iCal/ CalDav, because there are other iCal/CalDav server implementations around.
As mentioned earlier this is exactly (Zarafa would just provide an iCal/CalDav server) what we are looking for, but have been unable to get working.
Regards,
Ron
If I explained something wrong above, somebody might correct me, please.
Greetings, Robert _______________________________________________ zarafa mailing list zarafa@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/zarafa
Evening Ronald,
On Tue, 04 May 2010, Ronald J Yacketta wrote:
As mentioned earlier this is exactly (Zarafa would just provide an iCal/CalDav server) what we are looking for, but have been unable to get working.
what you're describing sounds like a bug to me. I'll try to reproduce that tomorrow. Because Zarafa is able to just provide the iCal/CalDav daemon. Is there anything special you've done? Anything interesting in serverside logs?
Greetings, Robert
Evening Ronald,
On Tue, 04 May 2010, Ronald J Yacketta wrote:
As mentioned earlier this is exactly (Zarafa would just provide an iCal/CalDav server) what we are looking for, but have been unable to get working.
what you're describing sounds like a bug to me. I'll try to reproduce that tomorrow. Because Zarafa is able to just provide the iCal/CalDav daemon. Is there anything special you've done? Anything interesting in serverside logs?
Greetings, Robert _______________________________________________ zarafa mailing list zarafa@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/zarafa
All config files are stock with exception to ldap.cfg and server.cfg which was modified to use pam (using ldap for users) for authentication and ldap as the plugin.
Have log level set to 6 for server, ical and ldap so the chatter is pretty high. Have seen a couple exceptions today after a client (SunBird / Lightining) caldav error (will post in the morning).
The server is a vanilla Fedora 13 with yum zarafa* installed.
Robert,
Received this stack trace after a client using SunBird received MODIFICATION FAILED. The same stack trace occurred using T-Bird with the lightning (MODIFICATION FAILED) plug in
Did not catch any errors etc in the ical.log
Wed 05 May 2010 11:34:10 AM EDT: Caught SIGSEGV (6), traceback: Wed 05 May 2010 11:34:10 AM EDT: 0x0000000047342b /usr/bin/zarafa-server(_Z7sigsegvi+0x4b) [0x47342b] Wed 05 May 2010 11:34:10 AM EDT: 0x007f2516660960 /lib64/libpthread.so.0(+0xf960) [0x7f2516660960] Wed 05 May 2010 11:34:10 AM EDT: 0x007f25162fd955 /lib64/libc.so.6(gsignal+0x35) [0x7f25162fd955] Wed 05 May 2010 11:34:10 AM EDT: 0x007f25162ff135 /lib64/libc.so.6(abort+0x175) [0x7f25162ff135] Wed 05 May 2010 11:34:10 AM EDT: 0x007f251633b6bb /lib64/libc.so.6(+0x716bb) [0x7f251633b6bb] Wed 05 May 2010 11:34:10 AM EDT: 0x007f2516341076 /lib64/libc.so.6(+0x77076) [0x7f2516341076] Wed 05 May 2010 11:34:10 AM EDT: 0x000000005688a3 /usr/bin/zarafa-server(soap_dealloc+0xc3) [0x5688a3] Wed 05 May 2010 11:34:10 AM EDT: 0x00000000570798 /usr/bin/zarafa-server(soap_end+0x18) [0x570798] Wed 05 May 2010 11:34:10 AM EDT: 0x00000000477ec3 /usr/bin/zarafa-server(_Z16gsoap_fserveloopP4soap+0x13) [0x477ec3] Wed 05 May 2010 11:34:10 AM EDT: 0x00000000612f99 /usr/bin/zarafa-server(_Z10soap_serveP4soap+0xb9) [0x612f99] Wed 05 May 2010 11:34:10 AM EDT: 0x0000000047957b /usr/bin/zarafa-server(_ZN22ECSoapServerConnection15process_requestEPv+0xbb) [0x47957b] Wed 05 May 2010 11:34:10 AM EDT: 0x007f2516658951 /lib64/libpthread.so.0(+0x7951) [0x7f2516658951] Wed 05 May 2010 11:34:10 AM EDT: 0x007f25163aed3d /lib64/libc.so.6(clone+0x6d) [0x7f25163aed3d] Wed 05 May 2010 11:34:10 AM EDT: When reporting this traceback, please include Linux distribution name, system architecture and Zarafa version. Wed 05 May 2010 11:34:10 AM EDT: Caught SIGSEGV (11), traceback: Wed 05 May 2010 11:34:10 AM EDT: 0x0000000047342b /usr/bin/zarafa-server(_Z7sigsegvi+0x4b) [0x47342b] Wed 05 May 2010 11:34:10 AM EDT: 0x007f2516660960 /lib64/libpthread.so.0(+0xf960) [0x7f2516660960] Wed 05 May 2010 11:34:10 AM EDT: 0x007f25163a7893 /lib64/libc.so.6(__select+0x33) [0x7f25163a7893] Wed 05 May 2010 11:34:10 AM EDT: 0x000000004781ea /usr/bin/zarafa-server(_ZN22ECSoapServerConnection6SelectEv+0x12a) [0x4781ea] Wed 05 May 2010 11:34:10 AM EDT: 0x000000004771f5 /usr/bin/zarafa-server(_Z14running_serverPcS_+0x1f95) [0x4771f5] Wed 05 May 2010 11:34:10 AM EDT: 0x00000000477c6c /usr/bin/zarafa-server(main+0x5ec) [0x477c6c] Wed 05 May 2010 11:34:10 AM EDT: 0x007f25162e8d2d /lib64/libc.so.6(__libc_start_main+0xfd) [0x7f25162e8d2d] Wed 05 May 2010 11:34:10 AM EDT: 0x00000000473059 /usr/bin/zarafa-server() [0x473059] Wed 05 May 2010 11:34:10 AM EDT: When reporting this traceback, please include Linux distribution name, system architecture and Zarafa version.
Robert,
Looks like zarafa under F13 is a bit biggie :(
I just installed zarafa on a F11 server and was able to create a meeting via caldav and it showed up for the attendee on there calendar (via caldav)
-Ron
Ronald J. Yacketta wrote:
Robert,
Looks like zarafa under F13 is a bit biggie :(
I just installed zarafa on a F11 server and was able to create a meeting via caldav and it showed up for the attendee on there calendar (via caldav)
-Ron _______________________________________________ zarafa mailing list zarafa@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/zarafa
I spoke to soon, had my iCal mis-configured. Events are _NOT_ showing up for attendees in there calendar when meetings are created.
Vanilla F11 with the following zarafa RPM's installed:
zarafa-common-6.30.12-1.fc11.i586 zarafa-client-6.30.12-1.fc11.i586 zarafa-server-6.30.12-1.fc11.i586 zarafa-caldav-6.30.12-1.fc11.i586 zarafa-ical-6.30.12-1.fc11.i586 zarafa-utils-6.30.12-1.fc11.i586
ical.cfg is stock while server.cfg has been modified to use pam for authentication and ldap as the plugin. ldap.openldap.cfg copied to ldap.cfg and modified to work with out Fedora 389
Hello Ronald,
On Thu, 06 May 2010, Ronald J. Yacketta wrote:
Received this stack trace after a client using SunBird received MODIFICATION FAILED. The same stack trace occurred using T-Bird with the lightning (MODIFICATION FAILED) plug in
I've opened https://bugzilla.redhat.com/show_bug.cgi?id=590442 as this looks like a bug. Let's try to get there all information Zarafa requires in order to solve this issue. May you please add a note in the bug report whether the segmentation fault happens without LDAP for you as well? I'm somehow not able to reproduce the issue...
Greetings, Robert
zarafa@lists.fedoraproject.org
-
Robert Scheck -
Ronald J. Yacketta