Syncing KeePass installation, config file and database across computers

Help
TimK
2013-11-24
2013-11-24
  • TimK

    TimK - 2013-11-24

    How do people sync their KeePass installation across multiple Windows computers? Ideally I'd like to be able to upgrade KeePass on only 1 computer and then have it pushed to the rest. I'd like to sync the configuration file and also the database across computers using something like SyncBackSE that can do 2-way sync. Trouble is that KeePass doesn't detect when it's config file is changed externally if it's running and when I close it it overwrites the config file. I'm coming from RoboForm where I was able to just sync its configuration across computers and a running RF would detect a change config file an reload it, never overwriting the newer changes. The KeePass database is a little bit tricky too compared to RoboForm where each entry was its own file so a lot easier to sync across computers as I would almost never edit the same entry on 2 computers.

    What strategies do you use to easily manage installations across computers and make sure you have no data loss?

    Note: I do not want my password database stored online, I want a local copy on each computer and device I use.

     
  • wellread1

    wellread1 - 2013-11-24

    I do not want my password database stored online, I want a local copy on each computer and device I use.

    Syncing to a central location is more common but if you are using an ad-hoc network topology then you won't need a central location.

    How do people sync their KeePass installation across multiple Windows computers?

    The preferred method for syncing a KeePass database is to use a trigger to implement a KeePass sync of a purely local database copy to a second local copy of the database that is then replicated via a central node (e.g. Dropbox) or a peer-to-peer network (e.g. Windows ad-hoc network). The recommended trigger implementation is described in the Trigger Examples using Dropbox for replication. However this trigger will also work for a ad-hoc or sneaker network configurations.

    In the above arrangement, the KeePass synchronization handles the entry by entry synchronization and the synchronized copies are distributed via the "replication" network of your choice.

    I'd like to sync the configuration file .... using something like SyncBackSE that can do 2-way sync

    The KeePass.config.xml file contains a fair bit of installation specific settings (e.g. paths) which make "synchronization" of the config file problematic. However, if you want to do the work, you could replicate the installation independent portions as follows:

    1. Make a copy of the keepass.config.xml and rename it keepass.config.enforced.xml
    2. Use a text editor to strip out the installation specific settings
    3. Place the keepass.config.enforced.xml in the keepass program directory of each KeePass installation.
    4. Use the replication (sync) software of your choice to propagate manual edits of this file to other KeePass installations (KeePass does not modify the keepass.config.enforced.xml file). A hard link might be useful if you need to sync just the config file but the replication software only syncs directories.

    The keepass.config.enforced.xml will control all settings that are specified in it. To make changes you will need to edit it directly. You may be able to use a third party sync program to replicate the keepass.config.enforced.xml to other computers. See the KeePass configuration help page for additional general information about KeePass config files.

     
    Last edit: wellread1 2013-11-24
  • TimK

    TimK - 2013-11-24

    Thank you very much for all the info.

    For the config sync I don't think I have any installation specific settings. They are all Windows machines using the portable version of KeePass which is located at the same path on all machines (exactly for this reason). Any other machine specific data in there for a portable KP?

    Could you please clarify how the database sync against another local copy helps? Scenario:
    - computer 1 makes some changes to some entries in the database. They get synced the the other local copy on computer 1
    - computer 2 makes other changes to entries in its database that then get synced to its local copy on computer 2
    Then when I try to sync the local copies from computer 1 and computer 2 I get a sync conflict because both copies seem to have been updated. I can't pick any of these files because it will result in data loss.

    And I think it would make sense to sync the two local copies both when the db is opened and also when it's saved so that i get the latest data when the db is opened and not have to wait for a save so that a sync occurs.

     
    Last edit: TimK 2013-11-24
  • wellread1

    wellread1 - 2013-11-24

    Could you please clarify how the database sync against another local copy helps?

    Take a look at the figure in the Trigger example. In most situations replication (the portion represented by the green double headed arrows) is fast compared to commits of user changes to a database (Saving or KeePass sync), so replication collisions are rare. However if a replication collision does occur, all user changes are preserved in the respective "KeePass Local DB" and will be incorporated into the local "KeePass Master DB" at the next KeePass sync. The rare "KeePass Master DB - conflicted copy" is ignored by KeePass and may be disregarded (deleted) without data loss.

    Any other machine specific data in there for a portable KP?

    Keepass.config.xml is the same for both versions of KeePass. However, in the absence of an active config file, portable KeePass will create an active Global keepass.config.xml (i.e. in the KeePass Application Directory), whereas the installed version of KeePass will create an active Local keepass.config.xml (i.e. in the User Application Data). In either version of KeePass, the setting <PreferUserConfiguration> determines whether KeePass uses a Local or Global config file. See the KeePass config help page for details.

    Both Global and Local config files can contain PATHS in some settings.

    For the config sync I don't think I have any installation specific settings.

    Then just replicate your keepass.config.xml.

     
    Last edit: wellread1 2013-11-24
    • TimK

      TimK - 2013-11-24

      Take a look at the figure in the Trigger example. In most situations replication (the portion represented by the green double headed arrows) is fast compared to commits of user changes to a database (Saving or KeePass sync), so replication collisions are rare. However if a replication collision does occur, all user changes are preserved in the respective "KeePass Local DB" and will be incorporated into the local "KeePass Master DB" at the next KeePass sync. The rare "KeePass Master DB - conflicted copy" is ignored by KeePass and may be disregarded (deleted) without data loss.

      Makes sense now. Trouble is that I'm going to use SyncBackSE in manual mode to do the sync. So chances of having "Master DB" conflicts are pretty high. I do not want to have anything in the cloud, so when on the road changes might occur to both Local and Master DB on a laptop. Then as I get home I might use my desktop to make some changes to its Local and Master DB. Then at some point I'll remember to sync the laptop and the desktop which will result in a conflict. But I see now why this will not result in data loss even if I just pick either of the Master DB files to be the synced file.

      My latest idea is to use a Master DB file on the desktop that every computer synchronizes its local copy to (including the desktop itself, it will have another local copy). Now if I have a trigger to sync with this network based file and the file is not available (because the laptop is not on the home LAN), what happens to the database save operation? Will it fail or will it simply report the trigger error but still save the Local DB?

       
  • wellread1

    wellread1 - 2013-11-24

    My latest idea is to use a Master DB file on the desktop that every computer synchronizes its local copy to (including the desktop itself, it will have another local copy).

    If you examine the figure again you should recognize that the proposal to collapse the "Master DB" into one shared database is topologically equivalent to the three "Master DB" configuration shown. Simply adjust the PATH to the target database in step 16 of the trigger example accordingly. However, the proposal to put a shared database, that is only used for KeePass synchronization, on the Desktop leaves it vulnerable to accidental deletion. Better to put that database in a shared folder that is not on the desktop.

    Now if I have a trigger to sync with this network based file and the file is not available (because the laptop is not on the home LAN), what happens to the database save operation? Will it fail or will it simply report the trigger error but still save the Local DB?

    The synchronization trigger does not affect whether the local database is saved or not. Step 7 uses a successful save of the local database to "trigger" the synchronization trigger. To gracefully prevent execution of the synchronization trigger when you are not attached to the network add "Remote Host is reachable (ping)" AND "File Exists" conditions as needed after Step 13. This will abort the sync to the shared "Master DB" if either the network or the shared database is unavailable.

     
    Last edit: wellread1 2013-11-24
  • TimK

    TimK - 2013-11-24

    Thank you very much, you are a wealth of information and great ideas!

    I'm not worried about the shared database being deleted from the desktop (and the same can happen with the database being on any share). The desktop is backed up continuously so I'd be able to recover it. Plus there are always the local copies on a bunch of computers and Android devices that I could recover from. If anything this database will be overly backed up :-)

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks