On Wed, 2014-04-02 at 11:20 +0000, Emiliano Heyns wrote: > 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?
No, it's broken. You are right, one has to add --configure above. > 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)? "google-credentials" is a normal peer config in the @default context. It just never gets used for syncing, only for indirect lookup of credentials. So yes, you can then do username=id:google-credentials or databaseUser=id:google-credentials everywhere and only keep the actual password set and up-to-date in one place. > >This is guaranteed to use a network password in GNOME Keyring for > >server > >www.googleapis.com and login > >[email protected]. > For [email protected], right? Right. > >Also note that username/password access to Google services is no longer > >officially supported by Google. > Not even using app-specific passwords? Not even that. > >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? SyncEvolution doesn't deal with OAuth itself. It relies on these external components to do that. In other words, that question needs to be answered by the developers of each of these systems. I don't know either :-( > >> 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? Because nothing in the command above references any config, so all properties required for accessing the CalDAV server have to given on the command line. Once a config with the necessary settings exists, it is possible to use those instead (--print-databases @context source). > >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?) Right. > - a 'source' names a peer which is going to figure in a sync-pair later > (right?), No. A source provides access to a set of items in a single database. A peer has access to all sources in its context and can enable or disable them via the "sync" property, which is set per source and peer, in contrast to peer-independent properties (like "backend") which are only set once per source. > >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? The call ensures that username= password= printChanges=1 are set to those values (username and password empty!) in Exchange@Local. The "--template none" is only necessary if the config does not exist yet, because the command line tool has some sanity checks that prevent creating new configs unless they look reasonable. This is meant to catch typos where the config name got misspelled: $ syncevolution --configure foobar2 [ERROR] No configuration template for 'foobar2@default' available. [INFO] Use '--template none' and/or specify relevant properties on the command line to create a configuration without a template. Need values for: syncURL ... > >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? Most templates define the default set of sources ("addressbook", "calendar", "todo", "memo"). These sources get created only when using a template that has them or when naming them explicitly on the command line. > >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? "Exchange@Local" is a peer config. When you run "syncevolution Exchange@Local", it acts as a sync config where as "target-config@Exchange" is the target config. Together they become a sync pair if you want, although that's not a term used elsewhere. > 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? "local" is a keyword here that tells SyncEvolution to use a local sync. "http(s)" is for SyncML via HTTP, "bt-obex" for server-initiated SyncML over Bluetooth, > 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" Such a setup is possible because you are free to configure access to Google lists and local file storages and then pair them via the "uri" in the sync config. > >> # 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? "peer setup" here would be called "source setup" in SyncEvolution terminology. Can we agree that we stick to the terminology defined in the README.rst? If that section is unclear, then let's clarify that first before trying to deduct the terms from example command lines. > >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? Sometimes peers force you to use certain names. If you only use one peer, you can use the names hard-coded in that peer. If not, you need aliases. > >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? SyncML clients, like a phone. -- 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
