From rjbs at fastmailteam.com  Mon Aug  3 07:43:19 2020
From: rjbs at fastmailteam.com (Ricardo Signes)
Date: Mon, 03 Aug 2020 07:43:19 -0400
Subject: meeting minutes, 2020-08-03
Message-ID: <0751d877-c439-43cd-a7ad-eb3b7ea928e6@dogfood.fastmail.com>

Minutes from this week's Cyrus dev call.  If we keep ending early, I can keep sending them immediately following the meeting! :)

 * Ken:
   * Where to store quotas for UUID mailboxes?
     * quota should stay with user during rename, so either needs to be by uuid or be transactional with rename; start at the leaf, walk up mailboxes to find quota; look at domain if none found
     * can put the quota file right in the folder (for non-domain quotaroots)
     * can we get rid of quotalegacy?
   * testing of uuid mailboxes on FM VM began, now Ken will be building new Fm
   * Updating JMAP Sieve spec and hope to get it posted as JMAP WG doc this week
   * ?and some refactoring of DAV delete code, which has gotten a bit out of hand
 * Bron:
   * sync replication: Bron has put a star next to it.  TWO STARS!
   * Going to change reconnection and ping logic for the indexer such that it handles transient errors more easily.
     * right now squatter is pinging the indexer every time, can fail hard if no good
     * bron will change to ?just try it and if it fails, retry? ? fewer pings, better recovery from transient error
   * rjbs asks whether Melbourne shift at Fm learned more about the high CPU use of Tika?
     * bron: we can always restart it once an hour once we have retry in place
     * rsto: we can use JMX to investigate what it?s doing, tune the VM if that?s the issue
     * current theory: it?s some bogus message
   * big reindex of Fm users continues apace
 * ellie
   * a bunch of new 3.2 issues have arisen since last meeting; new tests, framework work
   * next week?s away time moved to October
 * rsto
   * IETF last week, of course
   * doing some misc. bug fixing
   * working on sec?y mode and inbox role for jmap calendars
   * scheduling default calendar is now protected and movable (thanks Ken!)
   * implementing inbox role on calendars introduces same problem we have in mailboxes: ordering now matters
   * sec?y mode: should be a matter of just setting some cyrus setting properly
   * rjbs: aren?t we already in secretary mode in Fastmail?
     * yes, because the Perl middleware is setting this by default
     * see https://fastmail.blog/2017/11/04/shared-calendar-improvements/
   * rjbs will learn more about calendar-address-set?s behavior here - https://tools.ietf.org/html/draft-pot-caldav-sharing-01#section-5.1
 * IETF notes, if any:
   * bron has to finish polishing minutes from CodiMD from his 3 chaired sessions
   * mnot proposed an HTTP API WG, which seems interesting and useful
   * no new work from JMAP and EXTRA?
     * maybe we add S/MIME validator sometime?
     * we?ll probably do the quota work
     * we?ll probably implement all of IMAP4rev2 at some point

-- 
Ricardo Signes (rjbs)
CTO, Fastmail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20200803/d27a456c/attachment.html>

From rjbs at fastmailteam.com  Mon Aug 17 08:06:36 2020
From: rjbs at fastmailteam.com (Ricardo Signes)
Date: Mon, 17 Aug 2020 08:06:36 -0400
Subject: standardizing logging
Message-ID: <6923ff33-6723-420d-b152-0d31ac2055c5@dogfood.fastmail.com>

On our weekly call this morning, we were talking about moving toward standardizing the format of Cyrus logs.  My interest here is in making it easy for a program to read and classify logs.  That's not as simple as it could be, right now, because often a log line is sprintf-'d with parameters.  Even worse, sometimes those parameters have spaces in them.

I think we all agree on something like this:
 * produce a macro that does the logging in a standard format
 * the format leads with a "category", which is a fixed string
 * extra data to be included show up like auditlog does it:  foo=<x> bar=<y>
 * by using a macro, we can get the location (file, function) from which the log line is being emitted

Next steps:
 * agree on the specifics of the above and that it's the way to log in new code
 * start converting old code (prioritized by value of reading lines from each part of the code)

Further thoughts before we get on to specifics?

-- 
Ricardo Signes (rjbs)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20200817/eb4c3631/attachment.html>

From rjbs at fastmailteam.com  Mon Aug 17 09:21:11 2020
From: rjbs at fastmailteam.com (Ricardo Signes)
Date: Mon, 17 Aug 2020 09:21:11 -0400
Subject: meeting minutes, 2020-08-17
Message-ID: <74b22a96-0617-4f4a-8314-0a4f3bc48fa0@dogfood.fastmail.com>

Fun fact about working at Fastmail: so many meetings are held in the US evening / AU morning that most agendas get two dates on them.  The Cyrus call, though, is held in the US morning / AU night, so we only have one date to mention.

Anyway, the Cyrus development call happened this morning, and here are some notes from it:

2020-08-17:

 * log format normalization
   * figure out what we care about
   * create a syslog wrapper which generates the format we want!
   * logline(level, function_name, category, subcategory, message)
   * auditlog: type foo=<var> bar=<var> ?
   * create a macro to get things auto-added (fn name, line no)
   * agree what we want to do for new code
   * change it
   * tell everyone
   * [rjbs: I already sent an email asking for more info!]
 * deleting ACL when we delete folder: should we?
   * when user is recreated from pending delete in Fm, ACLs not recreated, including (anyone p) which allows plus addr delivery
   * ACL should be copied to the DELETED. folder
   * Doesn?t matter if we leave it on the tombstone as well, but we should always be bringing it back from the folder we undelete, not using the copy on the tombstone, because that folder is GONE.
 * lmtp fuzzy matching with plus addressing will cause delivery to parent (if ACL allows) if child doesn?t exist
   * is this a recent change? to be investigated
 * discuss upgrading mailboxes.db for UUID mailboxes - specifically multiple mailboxes with same UID
   * [discussion to be noted by Ken]
 * robert
   * bunch of work on making sure Email/changes exists on destroy of containing mailbox
     * involves change of semantics of deleted modseq counter
     * we now bump the email deleted modseq when we soft delete a mailbox
     * with this change: after doing Mailbox/set.delete, Email/changes will get cannotCalculateChanges
   * running AFL against MIME parser: so far, no results
     * will be looking into using AFL dictionaries to refine attack
     * DigitalOcean maybe not the best place to be running this; will look for other resource
   * looked into key-too-long errors that turned up recently; potential fix has been send upstream
   * next up: JSCalendar object updates; then updating role on Mailbox/set
   * rjbs to follow up internally about testing new JMAP Calendar branch on future
 * murch
   * sieve has been updated to match mailbox and snooze drafts
   * fixed weird bug in uppercasing in Sieve
 * bron
   * ?synchronous replication is awesome!?
   * I?ve patched synclog; there was a thing called a synclog checklog, which picked up the log and ran it right there
   * that?s sync replication? but kind of bogus
   * now we create it in memory
   * next step is to create a backend connection with a 30s timeout and change the synclog reader to read from a buffer; if our buffer is nonempty, we hand that to synclog
   * when we get back an OK, we know it has been committed to the ?blessed? replica
   * would like to get this under some real testing to figure out impact on performance and resource consumption
   * after that will be sync caching to improve performance of checking state of replica
     * append is 4 round trips; this will bring down to 3
     * drop another one by knowing about existing copies of msg
     * drop another one by embedding file (email) as part of the apply if file small enough; otherwise separate reserve upload
   * ?user has moved? bug: we tried to efficiently combine requests, but didn?t deduplicate mailbox names, which led to aborts ? once for every mailbox in a rename [rjbs: surely I got this a little wrong]
 * rjbs
   * we?ve changed how we aggregate errors
   * a question about how we get ?deadlock avoided? in delivery from Sieve: rjbs to research
 * rsto
   * needs to update Cyrus docs for new query behavior
 * murch
   * dealing with conflict between include-in-fm PRs and usermeta-bis work

-- 
Ricardo Signes (rjbs)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20200817/d3f6e02d/attachment-0001.html>

From rjbs at fastmailteam.com  Mon Aug 17 09:40:21 2020
From: rjbs at fastmailteam.com (Ricardo Signes)
Date: Mon, 17 Aug 2020 09:40:21 -0400
Subject: meeting minutes, 2020-08-17
In-Reply-To: <74b22a96-0617-4f4a-8314-0a4f3bc48fa0@dogfood.fastmail.com>
References: <74b22a96-0617-4f4a-8314-0a4f3bc48fa0@dogfood.fastmail.com>
Message-ID: <76af9362-827c-4db4-bc00-a5291ed8d87d@dogfood.fastmail.com>

On Mon, Aug 17, 2020, at 09:21, Ricardo Signes wrote:
>  * discuss upgrading mailboxes.db for UUID mailboxes - specifically multiple mailboxes with same UID
>    * [discussion to be noted by Ken]

   * the current code to update existing mailboxes.db to the new form (N, I, A records) processs records in order by name and creates I (uniqueid) records accordingly
   * however, this means that if multiple mailbox nbames correspond to the same uniqueid (e.g. in the case of a rename - current name plus tombstone), the I record will point to the last name record alphabetically
   * so, if I rename mailbox zzz to aaa, the I record will end up point to the zzz tombstone
   * the solution will be to to create a hash of uniqueid ? name(s) and create/update N and I records in the proper modseq/timestamp order

-- 
rjbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20200817/50e073a0/attachment.html>

From ellie at fastmail.com  Thu Aug 20 23:54:04 2020
From: ellie at fastmail.com (ellie timoney)
Date: Fri, 21 Aug 2020 13:54:04 +1000
Subject: standardizing logging
In-Reply-To: <6923ff33-6723-420d-b152-0d31ac2055c5@dogfood.fastmail.com>
References: <6923ff33-6723-420d-b152-0d31ac2055c5@dogfood.fastmail.com>
Message-ID: <639fbac0-0fe4-4580-a849-8eb0a000fe37@www.fastmail.com>

Prototype with some usage examples here:  https://github.com/cyrusimap/cyrus-imapd/pull/3149

On Mon, 17 Aug 2020, at 10:06 PM, Ricardo Signes wrote:
> On our weekly call this morning, we were talking about moving toward standardizing the format of Cyrus logs.  My interest here is in making it easy for a program to read and classify logs.  That's not as simple as it could be, right now, because often a log line is sprintf-'d with parameters.  Even worse, sometimes those parameters have spaces in them.
> 
> I think we all agree on something like this:
>  * produce a macro that does the logging in a standard format
>  * the format leads with a "category", which is a fixed string
>  * extra data to be included show up like auditlog does it:  foo=<x> bar=<y>
>  * by using a macro, we can get the location (file, function) from which the log line is being emitted
> 
> Next steps:
>  * agree on the specifics of the above and that it's the way to log in new code
>  * start converting old code (prioritized by value of reading lines from each part of the code)
> 
> Further thoughts before we get on to specifics?
> 
> -- 
> Ricardo Signes (rjbs)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20200821/aada537f/attachment.html>