I have searched several topics, cli documentation, and a few other pieces. I apologize in advance if I missed this… but I’m running into a little bit of a wall while automating syncthing.
I have the installation fully automated now with Ansible. The script works great to download, install, perform all the systemd pieces… and to change the line in file of the /home/user/.config/syncthing/config.xml for the 127.0.0.1 to 0.0.0.0 address change.
Now, I am trying to automate the GUI user/password. It looks like those pieces are in the config.xml as well with the password hashed. I can use Ansible vault to “securely” store and place the password, but I have not figured out yet how to do this via the command line. I could replace the contents in the config.xml, but the password wouldn’t go through the process to be hashed.
Is there any way to do this AND add devices (plus setting up folders - etc) as would be done with the GUI?
OS = Linux Centos 7.
I’m also looking into the dockerized version to see if something might be more easily done there for instances. I’m pretty sure I’ll run into the same (or some of the same) issues though.
I have - yes. I also just re-checked it and several of the 100 results. Many other search parameters were used. I searched through the online documentation as well under usage → * Command Line Operation
I am not finding anything specific to setting the GUI password, adding clients, or other pieces via the command line or if that’s possible. I did find a topic that talked about replacing the config.xml contents.
Are there any specifics to cli documentation or help with this above pieces?
The docs aren’t up-to-date, you need to really check syncthing cli help on the command line. Concretely syncthing cli config gui is relevant. Or alternatively you could use the rest api: Config Endpoints — Syncthing v1 documentation
AH! Understood… brain was on the forums / documentation. Checking that out now… and good call. Thank you for relaying the documentation online is stale.
OK… after trying a few things, I can get user and password to set… but I’m having all sorts of issues with the ip address command and applying with Ansible. Below:
- name: set syncthing gui ip address
become: true
become_user: user
command: syncthing cli config gui raw-address set 0.0.0.0:8384
Does it have to “connect” to change the address? This has been a bear to try to complete. I also tried using the ansible line in file, but had trouble with regexp or search_string to find and replace 127.0.0.1:8384 with the following:
<address>0.0.0.0:8384</address>
I’d love it if I could just get the command to work. FYI - setting the user and password (and pretty much any other setting) for the GUI fails as well with the Same error unless I am able to change the address. Commands directly from the command line on the instance that needs the settings chaanged work no matter what.
Update:
I scaled back the playbook to only do the installation (which all works). I then performed the IP address change and https change via cli directly on the instance (both work)… but once I set the user and password via cli, I cannot login to the web gui anymore. Not sure what’s up with that. If I look at the .config/syncthing/config.xml… the user looks like it’s set properly. The password is hashed so I cannot see it. IT might be because of some of the characters used on the command line.
I also don’t follow where you stand right now: First it looks like there’s a connection issue using the syncthing cli (which uses the REST api, so yes it needs to connect), then at the end what you write implies to me that everything worked but you can’t access the GUI afterwards.
OK - Let me remove the confusion and cut this back to the stuff that does not work.
TLDR is = I get the connection error automating syncthing cli commands through ansible.
The commands I’m trying to use:
syncthing cli config gui raw-address set 0.0.0.0:8384
syncthing cli config gui user set user
syncthing cli config gui password set pass
syncthing cli config gui raw-use-tls set true
I get the same error across all of the above commands:
IF I can get the IP address changed from 127.0.0.1 to 0.0.0.0, everything works with ansible. But the commands to change the ip address and all other cli commands (listed above) fail if the ip is not changed. So… if I run the installation part of the playbook and comment out all syncthing cli commands, then change the ip manually on the instance with the syncthing cli, AND THEN re-run the rest of the playbook running the syncthing cli commands for user, password, and raw-use-tls… they will work. This shouldn’t be happening with a loop back address. Something here appears to not be functioning properly, OR… there is another setting that needs to be done to get by this error.
Manually (done by me) using the syncthing cli with the above commands on the instance WORKS to set the settings.
You’d need to run the commands on the remote machine, with syncthing running. It’s not obvious to me that that is the case. Also, perhaps ansible does some sort of network isolation, or something runs in docker etc, but this is beyond me, and is down to your config.
It is 100% running. The initial installation that works runs the entire install to the point where the standard config is installed at /home/user/.config/syncthing/config.xml (and other subsequent files under that folder). Systemd process up and running, Ports listening, service is running - 100% verified, triple checked - etc.
If this didn’t complete… the .config/syncthing/* won’t have the proper files there. Also the /home/user/Sync folder won’t create… and that’s created.
You should only be modifying the config (unless its done via the apis), while its not running. The fact that it starts working after you manually changed the listen address, implies there is some network isolation happening. Perhaps due to containers? Also, I am still assuming that you are running the cli commands on the remote side.
I am not running a container for this version - direct install. I am trying to run the commands from the remote system. If not through the syncthing cli, how would I configure via apis?
If I configured when the services were down… I Would have to install, start all services so the proper files were created, shut down the systemd service, make the changes via syncthing cli, and then start the systemd services back up? Is that what you are stating? I can give that a try, but with the given errors, I don’t think that will solve the problem. I’m willing to try and give that a shot.
I guess I’m confused? I am trying to run the cli commands now - whether from the remote system using ansible, or if I am manually applying the cli command locally on an instance.
The problem I am having is applying these via ansible (remotely):
syncthing cli config gui raw-address set 0.0.0.0:8384
syncthing cli config gui user set user
syncthing cli config gui password set pass
syncthing cli config gui raw-use-tls set true
This is the same error for all 4 cli commands. The ONLY way I can (currently) get around this is, to comment out the 4 commands in ansible BUT still run the main installation. Then go to the local instance and manually run this command:
syncthing cli config gui raw-address set 0.0.0.0:8384
which is successful running the command (locally).
I can THEN run the remaining 3 commands from ansible successfully. They no longer get the error once the address is changed to 0.0.0.0 from 127.0.0.1. But I Cannot change it via the cli commands remotely (from Ansible) for whatever reason. That’s the main issue right now - that connection refused message is killing me from changing the address… which is killing the rest of cli commands I am trying to run as well (all remotely from ansible).
Holy crap that worked - 10 seconds pause was it… probably could be 5 but that’s the ticket. It’s especially weird because the service is started and then I change the following sysctl parameter:
- name: set sysctl net.core.rmem_max to 2500000
sysctl:
name: net.core.rmem_max
value: 2500000
state: present
A little bit of time passes. But obviously, it’s not enough.
Just to mention a different approach: You could place a very minimal config.xml file in the proper location before starting the service for the first time. It would just contain the GUI listen address configuration entry. Everything else will be populated with default values on first start, but the preconfigured GUI address should be kept.
