On Wed, 2014-04-02 at 08:49 +0000, Emiliano Heyns wrote:
> On 01/04/2014 18:05:50, "Patrick Ohly" <[email protected]> wrote:
>
> >On Tue, 2014-04-01 at 16:52 +0200, Emiliano Heyns wrote:
> >> The lastest version of the script now lists my google calendar (yay!)
> >> but I can't get it to list my other calendars on the same Google Cal
> >> account.
> >
> >You are right, the database discovery is broken for Google (and
> >possibly
> >other servers). I looked into it and have a fix.
> >
> >You can get around that for now by using database=
> >https://www.google.com/calendar/dav/[calendar-ID]/events?SyncEvolution=Google
> >with [calendar-ID] replaced by the string that Google shows in its web
> >interface when you click on "calendar settings" in the context menu of
> >the desired calendar.
> >
> Splendid, that works. BTW, I'm reply-all'ing to these messages, but
> should these go to the list instead?
Yes, it would have been good to CC the list. I thought it was on CC
already, but we must have lost it at some point during the discussion.
I'm adding it back.
> I can now access the GCal database, but if I don't pass the credentials
> on the command line, it fails or hangs. Can I store these in gconf too?
No, SyncEvolution doesn't use gconf for passwords. That activesyncd does
is kind of hacky.
In SyncEvolution, you need to use the command line to set the passwords
initially. There are ways to set the value without leaking it to other
processes:
password (no default, unshared)
password used for authorization with the peer; in addition to
specifying it directly as plain text,
it can also be read from the standard input or from an
environment variable of your choice:
plain text : password = <insert your password here>
ask : password = -
env variable: password = ${<name of environment variable>}
When using "-", the user needs to type it each time the password is
needed.
Under the hood, SyncEvolution stores passwords in GNOME Keyring or
KWallet. One could pre-populate that storage with a password and then
use "-", but the exact keys to find the password are not documented.
What might work better is to use password=id:<config name>, for example
password=id:google-credentials, and configure "google-credentials" with
syncevolution [email protected] \
password=foobar \
syncURL=https://www.googleapis.com google-credentials
This is guaranteed to use a network password in GNOME Keyring for server
www.googleapis.com and login
[email protected].
Also note that username/password access to Google services is no longer
officially supported by Google. Long-term they expect everyone to use
OAuth2. SyncEvolution can do that with the help of GNOME Online
Accounts, Ubuntu Online Accounts or gSSO. The downside is that in all
cases you need a UI at least during the initial login.
> This is how I'm setting it up:
>
> OPTIONS=
> OPTIONS="${OPTIONS} password=${GOOGLE[password]}"
> OPTIONS="${OPTIONS}
> syncURL=https://www.google.com/calendar/dav/%u/user/?SyncEvolution=Google";
> OPTIONS="${OPTIONS}
> database=https://www.google.com/calendar/dav/${GOOGLE[calendar]}/events?SyncEvolution=Google";
> syncevolution --configure --template none backend=caldav
> username=${GOOGLE[email]} $OPTIONS target-config@Google
> And this is how I'm printing the DB:
>
> OPTIONS=
> OPTIONS="${OPTIONS} password=${GOOGLE[password]}"
> OPTIONS="${OPTIONS}
> database=https://www.google.com/calendar/dav/${GOOGLE[calendar]}/events?SyncEvolution=Google";
> syncevolution --print-databases username=${GOOGLE[email]} backend=caldav
> $OPTIONS
> Setting up the actual sync (exchange-local so far -- on to google once I
> understand this) is still mystifying. This is what works (for Exchange
> <-> Local), but I have no idea why:
>
> # TODO: I thought "syncevolution --configure" set up a peer...
What --configure creates depends on what config name and source name(s)
(if any) are given.
> is the
> x@y automatically a sync config between peers?
Only if you configure it for that. The key property here is the syncURL.
It determines what the config syncs with.
> Does this set up all
> possible (cal-cal, contact-contact) pairings?
> syncevolution --configure --template none username= password=
> printChanges=1 Exchange@Local
No. If you don't use a template, no sources (and thus no such pairings)
will be configured.
Also note that the template is only relevant when creating a new config.
Once the config exists, such a --configure operation will merely update
the given properties.
> # TODO: Seems to be necessary but I don't know what it does.
> syncevolution --configure syncUrl=local://@Exchange peerIsClient=1
> Exchange@Local
It declares that Exchange@Local is meant to sync with the
target-config@Exchange, which is the config where access to Exchange
gets defined.
> # TODO -- what is the meaning of 'uri=contacts' here? The docs say "is
> added to the end of the server URL". Is this then the actual sync setup
> between contacts-exchange and contacts-local?
> syncevolution --configure sync=two-way uri=contacts Exchange@Local
> contacts
> syncevolution --configure sync=two-way uri=calendar Exchange@Local
> calendar
Sources have names on both sides of a sync. The names can be identical
(as in this example), in which case specifying the uri is optional. The
names can also be different, for example "my-personal-contacts" locally
and "default-addressbook" remotely, in which case uri must be used to
match the two.
> # TODO -- why are we setting up two-way sync here again? Isn't this
> part of the peer setup I did earlier?
> syncevolution --configure --template none username=${EXCHANGE[email]}
> password= printChanges=1 target-config@Exchange
This defines how to access Exchange. This is different from the
definition of the local storage.
> # TODO -- What is the meaning of the last contacts/calendar in these
> lines? Shouldn't this be part of the peer setup rather than the sync
> setup?
> syncevolution --configure sync=two-way uri=contacts
> target-config@Exchange contacts
> syncevolution --configure sync=two-way uri=calendar
> target-config@Exchange calendar
This *is* the peer (target-config@Exchange). uri in this context
specified a name alias, which means that (if the value was different,
which it isn't here) the same source can be addressed under different
names.
Using different names is not recommended, though, because it confuses
the Synthesis engine a bit. It's only needed for clients that use fixed
uris and a server setup where sources cannot be named as expected by
that one client (think of a server config which has to work for two
different clients).
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
