KeePass on Multiple Computers via Cloud

Help
steelej
2012-11-08
2012-11-19
  • steelej
    steelej
    2012-11-08

    I have been using a cloud service for 10 months to synchronise the KeePass V2 database to three computers

    I only use a password for my database. Windows login would not work and a keyfile would have to be copied to each machine and if that file was also replicated through the cloud the security it provides could be weaker. I am unable to use USB storage on one of the computers.

    I have two copies of the database file on each computer - let us call these Local.kdbx and Cloud.kbdx.

    The Local.kbdx is just that - it is the one I open on each computer using KeePass.

    The Master.kbdx is the Master copy that is replicated using cloud services.I have reservations about using Dropbox as the security has been compromised in the past. I have used both SpiderOak and am now using TeamDrive. Both of these encrypt the data on the cloud servers so it is double encrypted and makes me fell more comfortable.

    One each computer I have the following two Triggers.

    Synchronise Local with Master when Local database is opened
    Synchronise Local with Master when Local Database is saved or closed

    I open the Local version on each machine when I use KeePass. The first trigger fires and causes the Master/Cloud copy and the local copy to update each other with any unrecorded changes.

    If the Master copy has been changed then it replicates to all machines sharing the database in the cloud.

    The same thing happens on the file saving trigger so that any changes made to the local database are replicated to other computers when the local database is manually saved or closed.

    This is slightly more complex than just storing the database in the cloud copy but it enables any conflicts between multiple updates to be better managed and, once set, up is transparent to the user.

    In detail the triggers are shown below (note that strictly the conditions are not necessary but I feel more comfortable with the two tests being present as I use more than one database on one of the computers)

    Trigger 1

    Name = Sync to master on Open

    Event = Opened Database file -> Full path to Local copy of database

    Conditions = file exists -> Full path to Local copy of database
                 file exists -> Full path to Master copy of database i.e. the one in the cloud

    Actions = Change Trigger to Off (to avoid looping)
              Synchronise Active database with -> Master copy (in the cloud)

    Note that there is no need to re-enable this trigger

    Trigger 2

    Name = Sync to Master on Save or close

    Event = Saving database file -> Local database

    Conditions = file exists -> Full path to Local copy of database
                 file exists -> Full path to Master copy of database i.e. the one in the cloud

    Actions = Change Trigger to Off (to avoid looping)
              Synchronise Active database with -> Master copy (in the cloud)
              Change Trigger state to ON (to allow further changes to be replicated)

    ==================================================================
    This works well between all three computers.

    To start the process off:

    Create the first database on one computer. It does not need to contain and password entries yet (but could)

    Manually copy the database to the cloud replication location and rename it to match the triggers

    Create the triggers and restart KeePass (the triggers did not work correctly until I did this - I actually rebooted to be sure)

    Make a trivial change (to the note area for example) and save it an ensure that the file does replicate to the cloud.

    Go to another computer and make sure that it has received the replicated master database

    copy this to your chosen local location and rename it to four local file

    Create the triggers as before

    Make a trivial change and ensure that it replicates to the cloud (look at the file versions or times)

    Verify that the change is replicated to the first machine - note that forcing a Save will trigger synchronisation)

    Repeat on as many machines as you like.

    I have only been using TeamDrive for a week but it seems to be easier to set up than SpiderOak and replication is faster. I will try it for a few more days but expect to switch over to it completely.It also copes better with Proxies which helps when I use my work computer on the corporate network.I don't have to reconfigure the settings.

    If you create separate TeamDrive accounts for each of the computers and have one (think of this as the master) "invite" the others to join the space you can then see which machine made the most recent change. All previous versions are retained so there is an automatic backup taking place. This was the advice given to me on the TeamDrive forum

    I hope this helps somebody.

     
  • Paul
    Paul
    2012-11-08

    We have a similar set of instructions in the Help, but without the first trigger. The trigger on opening is a nice touch.

    cheers, Paul

     
  • steelej
    steelej
    2012-11-08

    I used the Saving event rather than the Saved event. My logic was that any changes on the master copy would get replicated to the local file as well as vice versa.

    What are the pros and cons of my method compared with the help file (sorry I did not find the help  example first)?

     
  • Paul
    Paul
    2012-11-09

    The sync is a 2 way process so saved is probably best. It waits until the save has succeeded before syncing - in case there are problems with the save.

    cheers, Paul

     
  • steelej
    steelej
    2012-11-09

    With synchronising a local copy to a version on the cloud can you tell me what happens if you do as you say i.e. sync on SAVED in the following case.

    I make a change to my local copy and suspend my computer without saving the file.

    I go to work and use my work computer. This syncs the cloud copy to that machine and then I open the local copy, make a change to a completely different record and then shut down Keypass. This will sync the cloud copy to the work local copy which will now update to the cloud.

    when I get home and un-suspend my machine the cloud copy will replicate to my home computer but there are now two different changes.

    If I save the local copy using the saved trigger I believe it will only synchronised the local changes to the cloud but not replicate the work changes back to the local copy as the save has completed. My thinking was that is I synchronised before saving then the local copy would also have the work changes.

    I suppose however it will synchronise when the local file is next opened so it is perhaps the end result will ultimately be the same.

     
  • Paul
    Paul
    2012-11-10

    Synch is a 2 way process and keeps all changes in history, with the most recent as the main entry. See the Help
    http://keepass.info/help/v2/sync.html

    cheers, Paul

     
  • steelej
    steelej
    2012-11-10

    I do understand what sync does in principle. I am however trying to understand exactly what happens with sync on Saved compared to sync on Saving when both files have been changes independently. It has become an ingrained  habit to attempt to understand detailed system behaviour under all failure conditions. I have been designing computer systems involving data exchanges since the 1960s.

    Assume both the local copy and cloud copy have separate records changed so there are no conflicts.

    When using the Saved trigger then the cloud copy will have the local changes merged but the local copy will not have the cloud changes merged back in. This merge to the local copy however will happen when the local file is  next opened and the Open trigger fires.

    When using the Saving trigger then the cloud copy will have the local changes as before and the difference will be that the local copy has the cloud changes merged as well.

    Is this a correct description?

    Choosing which trigger to use is not straight forward. The Saving trigger might appear to be best as local changes are written to the cloud version but the integrity of the database in each case depends on what might happen under fault conditions. (I have not attempted to look at the code.)

    If something prevents the file being the saved then it would seem to be better to do the merge before the local file is saved (saving trigger) in case the local copy save should fail. With cloud storage the cloud services will keep previous versions so that should be the safest location to keep the definitive copy as it is easy to revert to an earlier version.

    Using the saved trigger ensures the local copy has been saved before the merge but does not save the changes to the cloud if the local save fails and such changes might then be lost.

    I made such an assessment before choosing the Saving trigger rather than the Saved trigger - are there any scenarios that I have not taken into account?

     
  • Paul
    Paul
    2012-11-10

    Sync is the same  whether you do it before or after a save. Both files are opened, changed if required and saved if changed.
    My suggestion to save before sync was to prevent a failed sync attempt if there is a problem saving the local copy. This gives you time to recover your changes before anything else happens.

    cheers, Paul

     
  • develop1
    develop1
    2012-11-10

    Steelj - a Keepass sync is a two way record level sync.  New items in either file are pushed to the other, updates/deletes to either file is pushed to the other. Records are identified via the  UUID which a record level unique identifier.

     
  • steelej
    steelej
    2012-11-10

    Please note I fully understand the synchronisation occurs at the record level. the area I don't yet fully understand is what happens at the file level during/following synchronisation when KeyPass is being closed and the file save/saving triggers operate.

    If I follow the suggestion and use Saved trigger but the cloud copy has also changed can you tell me what happens in the following circumstances.

    The now local file contains some updated record that needs to be replicated to the cloud copy and the cloud copy also contains some changed records that have not yet been applied to the local copy.

    The local copy is saved e.g; during an application close

    The trigger synchronises the local changes to the cloud copy, and as it is a two way sync the local in-memory copy will be changed again so that it now differs from the locally saved copy.

    Does the local copy then get written to to disk a second time to apply these changes or are these changes dropped?

    My triggers would re-sync when the file is next opened so it may not be an issue in practice.

     
  • Paul
    Paul
    2012-11-10

    The sync is file level, not in-memory. When you perform a sync each file is opened, changed and saved.

    cheers, Paul

     
  • steelej
    steelej
    2012-11-10

    Thanks Paul - that is the bit I was missing. What you are saying about the Saved trigger now makes complete sense to me. I will change over to using the Saved trigger.

    Incidentally I have found TeamDrive to behave very well as my cloud storage and will now be using this instead of SpiderOak.