I sometimes use Syncthing to share large files with friends. Most of my friends are technical so it is easy to talk them through downloading and setting up Syncthing, adding each other’s folder IDs and so on.
However, what about non technical friends? Explaining everything as I go takes much more effort, including explaining why “nothing is happening” when folders are waiting to see each other.
It would be great if there was a way we could easily customise a Syncthing package so that it is already configured to sync one of my folders and my server has both approved their client ID and their install has approved my client ID.
Maybe this can be easily achieved with a config.xml generator, which is accessed via the syncthing web interface (so that it can extract their generated client ID and pre-approve it)?
Before I look into the Syncthing internals mysself, I wonder if anyone here can contribute some ideas on the best approach.
Actions: Using a folder or folders as context, generate and send a single archive (e.g. ZIP) to a friend
Instructions: extract it and double click on one file (e.g. syncthing.exe)
Result: Syncthing immediately begins syncing the pre-configured folder or folders
I reply to explain my interest in such a kind of thing.
I’m having a little bit the same idea, but I expect to do it using syncthing portable (Both win/lin) on a usb stick : I send a key allready pre loaded of most of the files, then the sync process keeps it updated with only instruction “insert and one click”.
The trouble is that I need to create every single usb stick to get a single unique ID for each.
A bundle maker could be a step closer to this solution.
Don’t get me wrong, this isn’t a complete and easy solution but you can get part of the way there with a config XML bundled in the zip archive.
The questions though are:
Where does Synching look for the shares?
Are they pre-configured relative to the binary and in root of the zip archive?
If so you are actually just wanting to copy the Synching binary to a folder and run it specifying the home directory relatively i.e. .
Then you can configure it and add any shares you would like. Add the new instance as a trusted device set you instance as an introducer if you want.
But my view is just to duplicate usb keys ready to run as portable app. The only thing I need is, after having duplicated/written the key (with dd), to set a new unique ID and name on the key to be recognized as a unique device, no matter where it runs. I’ve dropped quickly an eye on the config and I haven’t seen/located the ID that seems to be created by default on the computer itself, in hidden files if I remember well.
A “one-time first run” setting this up on the key would solve the problem, but there is maybe another way.
Runnig the key, cross using linux and win, allready needs two different config files to locate both / & \ path of the folder on the key.
I 've had an eye on the -generate option, but I didn’t understood it could generate the ID in a usable way for my needs.
Syncthing will generate the key if it’s missing on first run, and insert it into the config. It sounds like you just need to prep a usb key with a config that contains your device ID and folder ID, and then be prepared to accept incoming requests.
I 've made 2 usb stick 32 bits only and I’ve ran them without trouble on linux 32, 64 and win 64. I just put the lin and win versions together on the key, and call them with their appropriate .bat / .sh to set the separate .config path.
Edit : The data dir is on the key too.
Of course. Just ship a config.xml with all needed devices & folders IDs inside as well as Folders labels and membership, but do not supply the keys. Worth a try, no? hopefully the config.xml file won’t be overridden on first start when keys will be generated.
Ooops, Jakob just said the same above ! Give him your confidence.
The problem with this is that you need to manually accept the incoming share requests. If you are receiving many of them and they are randomly generated, how do you know which one actually belongs to someone you gave the USB key to? If you follow my suggestion, you know because you generated them yourself. The only disadvantage is that you know the private key of the person you gave the USB key to, but you can explain this. And of course they can trust you - they are plugging in a USB key you provided them after all.