Re: Cyrus IMAP 'CAPABILITIES' and 'AUTH=PLAIN'
> > I would guess you are missing libsasl2 modules for authentication, which > your OS probably has packaged in a separate package. You can use > pluginviewer/saslpluginviewer to view existing plugins. Awesome - was looking in entirely the wrong location (assumed it was a Cyrus thing) and never even contemplated it might be a SASL thing; especially as users could authenticate against it, even without the CAPABILITY being shown. Accounts now syncing, so hopefully we can get this system out of service by tomorrow… Thanks again… marty 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 IMAP 'CAPABILITIES' and 'AUTH=PLAIN'
Forgive me asking this question, we’ve just had a server disk that’s starting to die in a remote location, and I’m frantically trying to clone some IMAP users onto another server - along with a number of other things. Despite imapd.conf having 'allowplaintext: yes’ (it’s an internal server) when logging in, ‘AUTH=LOGIN’ isn’t advertised, yet it works if I manually try to login. ‘imapsync’ is complaining as it can’t see the LOGIN capability. I’m about to start looking at the code, but if anyone can let me know if a setting needs changed, that would be great - clearly, I’ve got a number of things to try to get off this server ASAP, so any advice would be greatly appreciated. Server version is 3.0.4: [root@imapserver /opt/local/etc/cyrus]# nc localhost 143 * OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE] imapserver Cyrus IMAP 3.0.4 server ready 0 CAPABILITY * CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE ACL RIGHTS=kxten QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY CATENATE CONDSTORE ESEARCH SEARCH=FUZZY SORT SORT=MODSEQ SORT=DISPLAY SORT=UID THREAD=ORDEREDSUBJECT THREAD=REFERENCES THREAD=REFS ANNOTATEMORE ANNOTATE-EXPERIMENT-1 METADATA LIST-EXTENDED LIST-STATUS LIST-MYRIGHTS LIST-METADATA WITHIN QRESYNC SCAN XLIST XMOVE MOVE SPECIAL-USE CREATE-SPECIAL-USE DIGEST=SHA1 X-REPLICATION URLAUTH URLAUTH=BINARY COMPRESS=DEFLATE X-QUOTA=STORAGE X-QUOTA=MESSAGE X-QUOTA=X-ANNOTATION-STORAGE X-QUOTA=X-NUM-FOLDERS IDLE Many regards Marty 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: Solaris (11) support
Jean-Crishtophe, we use Cyrus on Solaris, but at the moment, haven’t used Murder - so can’t offer advice etc on that one directly. We’ve got a couple of big projects under way at the moment for some customers - once we’ve got those sorted, I can try to get a test setup going and see what happens - but it would be in a couple of weeks time at the earliest… marty - Marty Lee e: ma...@maui-systems.co.uk Technical Directorv: +44 131 564 1980 Maui Systems Ltd w: http://www.maui-systems.co.uk Scotland, UK > On 18 Jun 2018, at 11:03, Jean-Christophe Delaye > wrote: > > On 06/18/2018 05:25 AM, ellie timoney wrote: >> Hi Jean-Christophe, > > Thanks Ellie for your inputs. >> >> On Fri, Jun 15, 2018, at 5:49 PM, Jean-Christophe Delaye wrote: >>> So this is why the first part of my >>> question was to known if there are many running murder systems running >>> on Solaris (11) and why I can't find specifics notes about >>> compiling/installing Cyrus imapd on this operating system. >> >> The main contributors to Cyrus development are not running Solaris, either >> personally or organisationally, so Solaris support doesn't get a lot of >> direct attention. >> >> There are a few people out there running Cyrus on Solaris (not sure if >> they're using murder or not). They usually pop up on the list with >> Solaris-compatibility issues/patches not long after new releases where we've >> accidentally broken something on Solaris, which we greatly appreciate! :) > > Yes, I tried the running unit tests (Version 2.1-3) on my setup and > found the following issue on the backend: > > Suite: backend > Test: badhost ...passed > Test: badservice ...passed > Test: sasl_plain ...Server failed to find requested SASL mechanism > "PLAIN" FAILED >1. ./cunit/backend.testc:198 - CU_ASSERT_PTR_NOT_NULL_FATAL(be) > Test: sasl_digestmd5 ...passed > Test: multiline_caps ...Server failed to find requested SASL mechanism > "PLAIN" FAILED >1. ./cunit/backend.testc:314 - CU_ASSERT_PTR_NOT_NULL_FATAL(be) > Test: oneline_caps ...Server failed to find requested SASL mechanism > "PLAIN" FAILED >1. ./cunit/backend.testc:314 - CU_ASSERT_PTR_NOT_NULL_FATAL(be) > Test: starttls ...Server failed to find requested SASL mechanism > "PLAIN" FAILED >1. ./cunit/backend.testc:408 - CU_ASSERT_PTR_NOT_NULL_FATAL(be) > > But,it's not easy for me to go further; I'll continue investigating > > > Run Summary:Type TotalRan Passed Failed Inactive > suites 39 39n/a 00 > tests432432427 50 > asserts 829800 829800 829795 5 n/a > > > Cheers > >> >> I have no access to Solaris, and so additional insight to offer. But I'd be >> very happy to accept/merge patches to code/documentation for you if you get >> things working properly. >> >> Cheers, >> >> 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 >> > > > 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: Upgrading Cyrus from 2.3.16, going to 2.5.11 or 3.0.2 ?
Eric, I know 3.0 compiles on Solaris 10 & 11; I think the only bit that didn’t work was the http section to provide caldav/carddav, as the implementation seems to depend on linux’isms. I got it compiled without the calendar and address book functionality (although that was a couple of months ago and I haven’t done any more with it as yet). marty > On 28 Jun 2017, at 13:39, Eric Luyten wrote: > > Hi, > > > Our environment is Solaris 10 / Intel. > > Are there good reasons to stay away from 3.0 ? > > > We have a pretty impressive user count and mail spool volume > > but not a lot of complexity (no murder nor replication, no domains, > > and few, if any, access control extravaganza). > > > Thank you in advance for your feedback, > > Eric Luyten, Computing Centre VUB/ULB. > > > > 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: cyrus 2.4.17 TLS woes
> On 15 Jan 2015, at 12:34, Patrick Goetz wrote: > > Does anyone have a secure, functional cipher list entry they'd like to > share? I’m using the following on 2.4.17-caldav-b10 tls_cipher_list:TLSv1+HIGH:!aNull:@STRENGTH Functional yes; I won’t make any promises about secure, as I’m sure someone more enlightened would correct me! cheers - Marty Lee e: ma...@maui-systems.co.uk Technical Directorv: +44 845 869 2661 Maui Systems Ltd f: +44 871 433 8922 Scotland, UK w: http://www.maui-systems.co.uk signature.asc Description: Message signed with OpenPGP using GPGMail 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-imapd-2.4.17-caldav-beta9 released
Ken, the workaround in beta 9 for MacOSX Mavericks works fine - I can now delete items from calendars :-) Thanks for getting this in - saves me applying the patch myself.. cheers marty On 17 Dec 2013, at 14:18, Ken Murchison wrote: > We are pleased to announce the ninth beta release of Cyrus IMAP with > integrated calendaring and contacts. This is a bugfix release with the > following changes: > > - Fixed bug in parsing of Accept header (now accepts */* and /*) > - Fixed telemetry logging bug (old garbage appearing in log) > - Added a workaround for the DELETE bug in MacOS X 10.9.0 Calendar > client > > The complete list of changes can be found in doc/changes.html in the > distribution. > > > This code is based on the stable Cyrus 2.4.17 release with support for > HTTP-based services (CalDAV, CardDAV, RSS, and Timezone) added. All of > the standard Cyrus IMAP daemons and utilities should be considered > production quality in this release, but the HTTP support is in beta status. > > You can download via HTTP or FTP: > > http://cyrusimap.org/releases/cyrus-imapd-2.4.17-caldav-beta9.tar.gz > ftp://ftp.cyrusimap.org/cyrus-imapd/cyrus-imapd-2.4.17-caldav-beta9.tar.gz > > Installation documentation will be found in doc/install-http.html in the > distribution. > > Upgrade documentation will be found in doc/install-upgrade.html in the > distribution. > > Thanks for your continued support, and we look forward to any and all > feedback. > > -- > Kenneth Murchison > Principal Systems Software Engineer > Carnegie Mellon University > > > 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 - Marty Lee e: ma...@maui-systems.co.uk Technical Directorv: +44 845 869 2661 Maui Systems Ltd f: +44 871 433 8922 Scotland, UK w: http://www.maui-systems.co.uk signature.asc Description: Message signed with OpenPGP using GPGMail 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 IMAP / CalDAV
Thanks for all the hard work to get the actual answer Ken; I’ll apply the patch
to my
local server for me to test (only 2 of us using the calendar stuff at the
moment) and
wait with baited breath for an apple update :-)
If you get wind of apple fixing things, let me know - if I spot it at this end,
I’ll send
something out too.
Cheers
marty
On 16 Dec 2013, at 19:09, Ken Murchison wrote:
> I confirmed that the DELETE problem is indeed a bug in the Apple client, and
> that Apple is aware of it. I'm somewhat reluctant to to include a fix in
> Cyrus for a bug in a client that will hopefully get fixed sooner rather than
> later. The patch below will work around the problem by making the faulty
> conditional DELETE a non-conditional one. But, by doing so we may delete a
> resource that has been changed by another user/client/session. Given that we
> really don't support shared calendars at the moment, this probably isn't a
> big deal but I don't really want to create potentially bigger problems moving
> forward.
>
> The real fix is Apple correcting their client to use an If-Match header
> rather than If-Schedule-Tag-Match header if the resource doesn't have a
> Schedule-Tag and/or isn't a scheduling object.
>
>
> On 12/14/2013 01:02 PM, Ken Murchison wrote:
>> I just committed a fix to git for the 406 response to GET. I will make
>> a beta9 release with this fix, and hopefully with a fix for the DELETE
>> issue by early next week.
>>
>> I have an email into one of the CalDAV experts that I know at Apple to
>> see what CalendarServer does with the empty If-Schedule-Tag-Match
>> header. I think its a bug in the Apple client, but I will have to come
>> up with a sane workaround for it. In the meantime, this uncommitted
>> patch should fix your problem with DELETE:
>>
>>
>> diff --git a/imap/http_caldav.c b/imap/http_caldav.c
>> index c00223f..641feb8 100644
>> --- a/imap/http_caldav.c
>> +++ b/imap/http_caldav.c
>> @@ -695,6 +695,7 @@ static int caldav_check_precond(struct transaction_t
>> *txn, const void *data,
>>
>> /* Per RFC 6638, check Schedule-Tag */
>> if ((hdr = spool_getheader(txn->req_hdrs, "If-Schedule-Tag-Match"))) {
>> +if (!*hdr[0]) return precond; /* XXX Hack for bug in Apple client */
>> if (etagcmp(hdr[0], stag)) return HTTP_PRECOND_FAILED;
>> }
>>
>>
>>
>>
>> On 12/14/2013 09:39 AM, Marty Lee wrote:
>>> No worries.. I'm about to get back onto another train so will back out b8..
>>> Only me using it in earnest, so if you need anything else tested before
>>> pushing out, just send me a link.
>>>
>>> Marty Lee
>>> v: 07827 950 918
>>>
>>>> On 14 Dec 2013, at 14:26, Ken Murchison wrote:
>>>>
>>>> Hi Marty,
>>>>
>>>> Thanks for the info. The 406 is in response to the GET, caused by a bug I
>>>> introduced when I added support for jCal and xCal data. I can't believe
>>>> that this didn't present itself in my testing. I will need to fix this
>>>> immediately. You probably want to downgrade to beta7 in the meantime.
>>>>
>>>> I *think* the problem with DELETE is that iCal is sending an empty
>>>> If-Schedule-Tag-Match header. I will need to test this here and possibly
>>>> talk to the Apple guys to find out why they are sending an empty header,
>>>> and what they expect the behavior to be.
>>>>
>>>>
>>>>> On 12/14/2013 03:09 AM, Marty Lee wrote:
>>>>> Ken,
>>>>>
>>>>> I haven’t but have just taken the opportunity to update to Beta 8 and
>>>>> also to refresh Sqlite, which
>>>>> seems to be the source of the error message…
>>>>>
>>>>> Using cyrus beta 7, the iCal client would delete the event, but when it
>>>>> updated with the server, the
>>>>> event would magically just re-appear. With b8, this has changed; now I
>>>>> get a dialog box:
>>>>>
>>>>> --
>>>>> The request for “Marty” in account “Maui” failed.
>>>>>
>>>>> The server responded with
>>>>> “406” to operation CalDAVDeleteEntityQueueableOperation.
>>>>> -
>>>>>
>>>>> Telemetry log:
>>>>>
>>>>> <1387007669>>>> /dav/calendars/user/marty/Default/0C48ECD9-44A7-4F1F-9C87-9A2EF647C574.ics
>
Re: Cyrus IMAP / CalDAV
Ken, I haven’t but have just taken the opportunity to update to Beta 8 and also to refresh Sqlite, which seems to be the source of the error message… Using cyrus beta 7, the iCal client would delete the event, but when it updated with the server, the event would magically just re-appear. With b8, this has changed; now I get a dialog box: -- The request for “Marty” in account “Maui” failed. The server responded with “406” to operation CalDAVDeleteEntityQueueableOperation. - Telemetry log: <13870076691387007670>HTTP/1.1 406 Not Acceptable Date: Sat, 14 Dec 2013 07:54:30 GMT Strict-Transport-Security: max-age=600 Vary: Accept-Encoding Server: Cyrus/v2.4.17-caldav-beta8 Cyrus-SASL/2.1.23 OpenSSL/0.9.8 zlib/1.2.3 libxml2/2.6.29 SQLite/3.8.2 libical/0.48 Content-Length: 0 I’ll keep looking; I can create and edit events, just not delete them… marty On 12 Dec 2013, at 17:30, Ken Murchison wrote: > Hi Marty, > > Did you find anything related to this? I don't have Mavericks yet, but maybe > a telemetry log of the client trying to delete an entry would point me in the > right direction. > > Worst case, I will be with the Apple client developers in early February and > can test then. > > > > On 10/24/2013 07:22 AM, Marty Lee wrote: >> Good afternoon (local time for me!) >> >> Updated my Mac to Mavericks this morning and am now getting the following >> error from >> the CalDAV part of Cyrus when I try to delete an entry. >> >> dav_exec() step: cannot start a transaction within a transaction >> >> Creation & modification works fine, but iCal on the mac now can’t delete >> items. I can work >> around this by using a web interface to my calendars, but I just thought I’d >> mention it here >> that Apple have changed something in iCal with the new version of OS-X. >> >> If I get a chance this weekend, I’ll have a look at the source code and see >> if I can do >> anything to help. >> >> cheers >> >> marty >> >> >> >> >> - >> Marty Lee e: >> ma...@maui-systems.co.uk >> >> Technical Directorv: +44 845 869 2661 >> Maui Systems Ltd f: +44 871 433 8922 >> Scotland, UK w: >> http://www.maui-systems.co.uk >> >> >> >> >> >> >> 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 > > > -- > Kenneth Murchison > Principal Systems Software Engineer > Carnegie Mellon University > - Marty Lee e: ma...@maui-systems.co.uk Technical Directorv: +44 845 869 2661 Maui Systems Ltd f: +44 871 433 8922 Scotland, UK w: http://www.maui-systems.co.uk signature.asc Description: Message signed with OpenPGP using GPGMail 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 IMAP / CalDAV
Good afternoon (local time for me!) Updated my Mac to Mavericks this morning and am now getting the following error from the CalDAV part of Cyrus when I try to delete an entry. dav_exec() step: cannot start a transaction within a transaction Creation & modification works fine, but iCal on the mac now can’t delete items. I can work around this by using a web interface to my calendars, but I just thought I’d mention it here that Apple have changed something in iCal with the new version of OS-X. If I get a chance this weekend, I’ll have a look at the source code and see if I can do anything to help. cheers marty ----- Marty Lee e: ma...@maui-systems.co.uk Technical Directorv: +44 845 869 2661 Maui Systems Ltd f: +44 871 433 8922 Scotland, UK w: http://www.maui-systems.co.uk signature.asc Description: Message signed with OpenPGP using GPGMail 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+CalDAV
Hi, I've been playing with the latest Cyrus beta which includes the CalDAV & CardDAV additions - from a personal perspective, almost all seems ok. Server is a Solaris 10 (x86) box; clients are mainly Mac OSX (Mountain Lion) and some PCs (Thunderbird/Lightning). One question that Ken or someone may already know and one issue that I need to track down further. The question first: I've got two users that have permission to read each others Default calendar (lr9) - but I'm guessing that the list of calendars returned to the Mac calendar app only includes calendars for the actual user, not shared ones, as the shared calendars can't be seen… does this sound right, or should I be able to see the shared calendars (or need to do something to make it work)? I've also seem similar with the CardDAV interface - I use a DAV client to pull down all my contacts and put them into a local LDAP server for address book lookups for a number of other apps. This works if I use my username+password, but not if I use a different account with permissions to read my Default address book (lr). The issue I've seen revolves around adding pictures to vCards - some existing cards have pictures (copied from existing Mac address book), but changing pictures or adding new cards with photos seems to cause problems - I suspect it's 'segfaulting' the server process, but I'm not 100% certain of that yet, so I won't log a bug just yet… Anyone else tried any of these scenario's and able to say whether they've had success or not - maybe I'm just too bleeding edge and dive into the code myself (which I'll do anyway, I just don't want to spend time doing something someone has already worked out!). Cheers Marty 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
