On 02/04/2014 11:44:41, "Patrick Ohly" <[email protected]> wrote:
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.
But if I set it using password=, it's supposed to be stored, right? But
then why should the print-databases call require me to repeat the
password on the command line (the call hangs if I don't).
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 doesn't use the --configure option, that is correct? So this simply
attaches a couple of properties (username, password, syncURL) under a
name (google-credentials) for reuse later. Would that mean I could
likewise do username=id:google-credentials elsewhere and it would fetch
the username from the google-credentials bucket (for lack of a better
term)?
This is guaranteed to use a network password in GNOME Keyring for
server
www.googleapis.com and login
[email protected].
For [email protected], right? Sorry to be so pedantic about this,
but I'm still in the process of documenting what means what.
Also note that username/password access to Google services is no longer
officially supported by Google.
Not even using app-specific passwords?
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.
Hmm. Is there a way to retrieve a token on a gui-enabled machine and
feed that to syncevolution? I could set up a remote x server and forward
to it, but if the full setup could be scripted, that would have my
preference (easier to test the process, which should make the HOWTO more
robust).
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
<safelink(3771f585-ea5d-4a2d-a61d-bcfcba12a9a1):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
So if the setup part was supposed to store the password and database
into 'bucket' (I know the terminology says "source" but the word source
is used in a way that seems ambigous to me -- with 'bucket' I mean
nothing else than a named bundle of key-value pairs)
'target-config@Google', why must I repeat them here?
What --configure creates depends on what config name and source name(s)
(if any) are given.
Just so I am getting this clear:
- A 'config' names a bundle of key-value pairs (right?)
- a 'source' names a peer which is going to figure in a sync-pair later
(right?), or it could be a sync-pair of sources. Is a peer-source always
of a certain type (so exchange-calendar) or can a peer-source be simply
a service-aggregate (such as exchange, which might host multiple
exhange-contacts and exchange-calendars)
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.
So without the syncURL assignment, what does the line "syncevolution
--configure --template none username= password= printChanges=1
Exchange@Local" do? Does it add the key-value pair "printChanges=1" to
sync-pair "Exchange@Local"? Is the --template call here inert (iow
should it be removed)? Why the empty username/password keypairs?
No. If you don't use a template, no sources (and thus no such pairings)
will be configured.
So the use of --template triggers that a source is (re) configured (in
the sense that key-value pairs are added to it)? Or a source-pair,
depending on whether the source is a peer or a sync-pair of peers?
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.
OK, and I can refer to these by name.
# 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.
OK, so in this phrasing, "Exchange@Local" is an entity (a source? a
config?) that syncs with something, it is *not* a sync-pair itself? Or
is this a declaration of the sync-pair "Exchange@Local"? In
syncUrl=local://@Exchange, is the "local" part a literal (as in,
not-remote) or is it a reference to the file-based entity (source?
config?) named "local" I set up earlier? If the former, is it impossible
to set up multiple remote-local pairs, such as:
* "Google Contacts list X" syncs with local file store "lX"
* "Google Contacts list Y" syncs with local file store "lY"
# 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.
OK, so a source is intrinsically tied to a sync? That conflicts with my
understanding of "source" as I outlined above.
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.
OK, so in such a case the line would read
syncevolution --configure sync=two-way uri=my-personal-contacts
Exchange@Local default-addressbook
which references two entities (configs? sources?) named
"my-personal-contacts" which is tied in some way to a exchange entity
(config? source?) and "default-addressbook" tied to a local entity
(source? config?) set up earlier.
# 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.
So this defines how, in general, to access this specific exchange
server, regardless of whether I'm accessing a contacts list or a
calendar, or even which contacts list or calendar. It has nothing to do
with setting up a sync pair.
# 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).
I'm trying to group "server setup", "peer setup" (where "peer" in my
usage is a particular folder on a particular server of a particular type
-- exchange contacts folder name "Contacts", for example) and "sync
setup" (which syncs peers) into separate sections in my script/HOWTO. In
those terms, this would go into "peer" setup, correct?
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.
OK, so 'calendar' is supposed to be meaningful to me, not to SE. Why
would I want to address the same source (and I am at this point
thoroughly confused on what "source" means) under different names?
Using different names is not recommended, though, because it confuses
the Synthesis engine a bit.
Not to mention me! :)
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).
And clients here are "programs" then -- contexts of use?
I'm trying to get a good conceptual handle on the terms in use; I've
gone through
https://syncevolution.org/documentation/syncevolution-usage, but it's
still slow-going as I get up to speed.
Emile
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
