No one will answer, so I will provide my own answer for posterity.
The -s flag does not accept a file, but a string. So a correct for loop would be the following :
for user in $userlist ; do state=$(cat "/Users/_dovecot/.bin/syncStates/syncstate$user" ) doveadm sync -u $user -s $state tcp:xxx.xxx.xxx.xxx > "/Users/_dovecot/.bin/syncStates/syncstate$user" done
Hope it helps someone.
Message: 3 Date: Fri, 25 Mar 2016 19:26:11 -0400 From: Simon Pierre Desrosiers simonpie@cs.mcgill.ca To: dovecot@dovecot.org Subject: State for dsync not working. Message-ID: CAF2F45A-3F6A-4540-8C32-6551C6F27F7C@cs.mcgill.ca Content-Type: text/plain; charset=us-ascii
Hello,
Since replication does not seem to work on Mac OSX, I will run doveadm sync by hand every few minutes.
In order to improve efficiency, I would like to use state. I have tried a few ways, but I always get the following error doveadm(user): Error: Saved sync state is invalid, falling back to full sync: Invalid base64 data KBtMOd0181bQ/wAAoQsxE90181YBAAAAAQAAAAAAAAAAAAAAAAAAABtI+mg=
Here is the code I use to sync : for user in $userlist ; do doveadm sync -u $user -s "/Users/_dovecot/.bin/syncStates/syncstate$user" tcp:xxx.xxx.xxx.xxx > "/Users/_dovecot/.bin/syncStates/syncstate$user" done
Any idea on how I can correct the encoding error ?
Thank you
Message: 4 Date: Sat, 26 Mar 2016 13:30:03 +1000 From: Noel Butler noel.butler@ausics.net To: dovecot@dovecot.org Subject: Re: NetApp NFS vs. ZFS and NFS for Maildir Message-ID: 79e7f44d74014b5c83d370d74e02205b@ausics.net Content-Type: text/plain; charset=US-ASCII; format=flowed
It seems its troll time again on this list, ohh maybe its Harry in disguise... So I will play along, for today anyway :)
On 19/03/2016 18:11, Stephan von Krawczynski wrote:
On Sat, 19 Mar 2016 17:37:04 +1000 Noel Butler noel.butler@ausics.net wrote:
On 14/03/2016 18:49, Stephan von Krawczynski wrote:
and you've never seen these cause problems with FS? then you must be a newbie, in over 25 years I've seen it happen several times - yes even after an apparent controlled shutdown.
Maybe you're doing something wrong then. because in my last 21 years working exactly in this business I've not seen a single deadly fs-crash because of a power-outage. Not one. And we had of course several, all backed by UPS.
Consider yourself lucky, Most network admins whove been around large busy ISP DC's have seen this in their lifetime, to not have seen one is rare, go buy yourself a lotto ticket :)
If your servers get drowned with water during a fire your fs is probably the least of your worries. You don't really plan to re-enable servers with water- or fire-damage, do you? That's probably why there shouldn't be a fireman pouring water in the first place.
This shows you dont understand structural engineering, the fire does not have to be on your floor, it can be far away as two or so levels above, with the high pressure water used - equating to a shitload of water, there are ducts, shafts, other risers and so on that with a shit-tone of water can easily penetrate fireblocks of floors below - dont take my work, go ask a fireman, or maybe watch the nightly news sometime (building fire - many levels water affected blah blah blah)... so keeping those boxes on via UPS's is asking for lots of charcoaled boards and fried drives. IOW, total stupidity.
Should those machines be depowered as required by our building codes, well, might take a few days of drying out but at least they will power back up without error - yes, done it in risk assessments.
Obviously you must work for people that have not the slightest idea about using hardware in a correct way and don't know when the time has come to throw
it away. Man, there is no way to let a drowned box survive. It is not back to
Wow, how long did you allege to have been in network/sys admin? 20 years? Really? I think you made a typo and and it should have read 20 minutes, ya know I have refrained from posting no here for a long time (apart from fact I rarely read the list), and I was not going to feed the trolls, but sometimes the smart mouthed know nothing, need to bitch slap upside the head so thats why I am devoting about 60 seconds to you.
Of course there is, networks dont throw away many hundreds of servers valued $7K to $10K, nor $100K+ storage systems, or $40K routers, LB's or switches, just because they got drenched - with power isolated.
normal when it is dry. If you don't get that I am pretty happy to be no customer. This can only be an idea born in the sick mind of a controller who
You will never be a customer _or_employee_ of mine, trust me on that one!
didn't want to pay insurance in the first place. We are talking about serious
Got nothing to with insurance, it might take 2 days to dry out and get back up and running, it will take an awful lot longer to get offsite backups and restore every last one of them.
I hope your employer reads this list, because he/she should be seeing alarm bells from your comments.
corrosion effects here let alone that you have a hard time even knowning when
yep, you sure did fail basic engineering
your boxes are really dry. Your fireman on the other hand seem to be stuck in the 80ths. Today there are solar panels almost everywhere _which you cannot turn off_.
Wow, you really are clutching the fantasy straws arnt you, perhaps your country lacks modernisation, I can go to the side of my house and isolate the panels with a flick of a switch, strangely enough and I guess in your eyes horrifyingly called "solar isolator" that stops the panels providing power to my electrical circuits, yes, there might be power from panels to it, but thats not going to affect my power circuits or equipment
-- If you have the urge to reply to all rather than reply to list, you best first read http://members.ausics.net/qwerty/
Message: 5 Date: Sat, 26 Mar 2016 13:34:34 +1000 From: Noel Butler noel.butler@ausics.net To: dovecot@dovecot.org Subject: Re: Email hosting provider Message-ID: 2b1abc9c94e3f1322753d7547cb991e4@ausics.net Content-Type: text/plain; charset=UTF-8; format=flowed
On 21/03/2016 17:06, Andre Rodier wrote:
Hello,
Sorry if I am off topic a little.
I am looking for an email host provider that supports dovecot, sieve and manage sieve. Ideally with the roundcube webmail and managesieve plugin
Better if it is in Europe or switzerland. I don't mind paying a little.
Thanks, Andr?.
Hi Andre,
see www.webhostingtalk.com
There are a number of reliable and reasonable priced hosts in Germany (best place if you value your privacy) and Netherlands.
-- If you have the urge to reply to all rather than reply to list, you best first read http://members.ausics.net/qwerty/
Message: 6 Date: Sat, 26 Mar 2016 10:52:33 +0530 From: Joy pj.netfilter@gmail.com To: Joseph Tam jtam.home@gmail.com Cc: Dovecot Mailing List dovecot@dovecot.org Subject: Re: IMAP Idle Message-ID: CALM64LbXF_Nw+7STyxHMnjLNujEcTsc5mEXMA8DXaZuNX4pvpA@mail.gmail.com Content-Type: text/plain; charset=UTF-8
I am ok if connection is closed automatically after 30 min if client is not responding but connection is not being closed even after 2 days.
On Sat, Mar 26, 2016 at 2:52 AM, Joseph Tam jtam.home@gmail.com wrote:
Joy pj.netfilter@gmail.com wrote:
We have implement imap idle in web mail built by us to havepush mail feature. IMAP idle working perfectly with browser notification and we are happy with it but having one issue with users who close the browser directly and never logout in that case there are number of idle connection which are not in use and users are unable to login once IP wise connection limit is reached.
Dovecot is not closing connection which are not in use, is there any setting available which can help me to resolve this issue.
I had much the same situation where a user signed up with a roaming wireless carrier that assigned a new IP to the client whenever it got passed from one access point to another. Good fun when this person took a bus ride through the city, leaving orphaned connections in its wake.
The IDLE disconnection timeout is hardwired in the Dovecot code
http://wiki.dovecot.org/TimeoutsIt's set to the RFC minimum of 30min. You'll have to recompile Dovecot to lower this to a non-RFC compliant value. I'm not sure how this this will affect clients, but 30min seems to be overly generous.
Joseph Tam jtam.home@gmail.com
Message: 7 Date: Sat, 26 Mar 2016 08:04:33 +0100 From: Stephan von Krawczynski skraw@ithnet.com To: dovecot@dovecot.org Subject: Re: Email hosting provider Message-ID: 20160326080433.07fcf216.skraw@ithnet.com Content-Type: text/plain; charset=ISO-8859-1
On Sat, 26 Mar 2016 13:34:34 +1000 Noel Butler noel.butler@ausics.net wrote:
On 21/03/2016 17:06, Andre Rodier wrote:
Hello,
Sorry if I am off topic a little.
I am looking for an email host provider that supports dovecot, sieve and manage sieve. Ideally with the roundcube webmail and managesieve plugin
Better if it is in Europe or switzerland. I don't mind paying a little.
Thanks, Andr?.
Hi Andre,
see www.webhostingtalk.com
There are a number of reliable and reasonable priced hosts in Germany (best place if you value your privacy) and Netherlands.
You mean "best place if you have no idea of the german laws and whats really going on" ...
-- Regards, Stephan
Message: 8 Date: Sat, 26 Mar 2016 10:48:47 +0000 From: michael crane mick.crane@gmail.com To: dovecot@dovecot.org Subject: mailbox prefix Message-ID: CACJbxCQ5by9eXKtAMfJ7aa1C2hCkmph=LbyUqn2yv6w=0hVseQ@mail.gmail.com Content-Type: text/plain; charset=UTF-8
dovecot version 2.2.13
hello, I try to make a new server just for me after having old one working for ages with Dovecot, Fetchmail, Squirrelmail, Procmail making new one with above plus Postfix using Maildir structure. I am having a bit of trouble understanding exactly what the namespace and prefix are. Is the "private/" prefix an internal thing with Dovecot ? Or is it supposed to be a real directory ? I'm not quite sure how to properly address the INBOX in Procmail, Squirrelmail, Postfix config.
for example am I supposed to say inbox is ".private/.INBOX"
cheers
zemlik
Subject: Digest Footer
dovecot mailing list dovecot@dovecot.org http://dovecot.org/cgi-bin/mailman/listinfo/dovecot
End of dovecot Digest, Vol 155, Issue 45