I think the only problem is to have called the flag --daemon. Something like --wait-for-auth-req would be clearer and wouldn’t encourage people to launch it in the background.
If I see option daemon I think it is meant for the process to run, started by the init or systemd process on Linux, or roughly the same as started in the background (& behind). Like for example
Yes, and it was the intention back then when we started with safe_auth CLI, we wanted to this be a daemon eventually but didn’t invest the effort on that thing, now the moment has arrived . Note this also will give us some additional cool features apart from what it’s being discussed here, e.g. any Authenticator UI/GUI could be connected to this daemon, so you could interact with it using the CLI, and 5mins later you can do it with SNAPP GUI, while still logged in with same account all the time (you could be allowing auth reqs from the CLI or from SNAPP).
All users of the shared vault please note that this vault was restarted today and so the vault_connection_info.config file has been updated in the GitHub releases for the vault.
See the latest vault release here for the new vault_connection_info.config file - if you intend to use the shared vault you should download this to the relevant location for your platform, as per the OP.
And now is it supposed to work? I mean new SAFE Browser v0.15.0 with current safe-cli, safe-authenticator-cli and safe_vault built from source. Because I still get the same symptoms.
This sounds like a different issue to me, I’m not able to see safe://test with CLI v.0.4.0 either, are you?
EDIT: I’m sorry @tfa, I’m actually able to fetch it with SAFE CLI v0.4.0 (I had the wrong config before), but so I’m with the browser v0.15.0, aren’t you? perhaps making the same mistake as me not having the correct vault config in place and/or having a local vault running?
I have a local vault and it is the one I want to use. My config file on the PC with safe browser is certainly correct because I get “Connected” and “Accepted” messages with its ip address in the vault logs.
Ah ok, well it also works for me with local vault, uploading a site with CLI v0.4.0 to local vault and loading it with browser v0.15.0 on local vault too. What issue are you experiencing?
Ok, that’s what I just tried, can you please make sure you are re-authorising your CLI before uploading the site to your local vault? if you authorised it before with a safe_auth running against another vault the CLI may be storing the data in a different vault than the one your browser is connecting to.
$ ./safe cat safe://test
Files of FilesContainer (version 0) at "safe://test":
+-------------------------+------+----------------------+----------------------+-------------------------------------------------------------------+
| Name | Size | Created | Modified | Link |
+-------------------------+------+----------------------+----------------------+-------------------------------------------------------------------+
| /img/safe_logo_blue.svg | 5851 | 2019-09-29T19:09:46Z | 2019-09-29T19:09:46Z | safe://hbwynon5ey35si9umca83jkuo6t6qkmkwcp6s9t3g964d9u8fyippaza6z |
+-------------------------+------+----------------------+----------------------+-------------------------------------------------------------------+
| /index.html | 355 | 2019-09-29T19:09:46Z | 2019-09-29T19:09:46Z | safe://hbhybynoh189jbfes6u1qcu9ojff9rwap9dehr9neop6xikr5atdewactk |
+-------------------------+------+----------------------+----------------------+-------------------------------------------------------------------+
Traces of connection from client in vault logs:
$ ./safe_vault --ip pp.pp.pp.pp -p 5483 -vvv > /var/log/safe_vault.log
INFO 2019-09-29T17:39:04Z [src/bin/safe_vault.rs:140] Checking for updates...
INFO 2019-09-29T17:39:05Z [src/bin/safe_vault.rs:169] Current version is 0.19.2
INFO 2019-09-29T17:39:05Z [src/bin/safe_vault.rs:170] No releases are available for updates
INFO 2019-09-29T17:39:05Z [src/bin/safe_vault.rs:119]
Running safe-vault v0.19.2
==========================
INFO 2019-09-29T17:39:05Z [src/client_handler.rs:102] QuicP2p started on pp.pp.pp.pp:5483
with certificate [...]
...
INFO 2019-09-30T19:42:17Z [src/client_handler.rs:153] 3f8f50..: Connected to new client on nn.nn.nn.nn:1024
INFO 2019-09-30T19:42:17Z [src/client_handler.rs:700] 3f8f50..: Accepted App(Bls(85a2ae..), owner: Bls(85a2ae..)) on nn.nn.nn.nn:1024.
INFO 2019-09-30T19:45:21Z [src/client_handler.rs:157] 3f8f50..: Networking error: Connection was actively cancelled
INFO 2019-09-30T19:45:21Z [src/client_handler.rs:159] 3f8f50..: Disconnected from App(Bls(85a2ae..), owner: Bls(85a2ae..)) on nn.nn.nn.nn:1024
(pp.pp.pp.pp is IP address of vault, nn.nn.nn.nn is IP address of client)
Config file content (partial):
$ head ~/.config/safe_vault/vault_connection_info.config
{
"peer_addr": "pp.pp.pp.pp:5483",
"peer_cert_der": [
...
Exactly, that’s the problem you are facing, you should build both safe_auth and safe_cli for real vault, the local vault is a real vault, and remember to re-authorise the safe CLI with the safe_auth connected to your local vault
But now I get the following error when I try to create an account with safe_auth (on the same machine as the vault):
$ ./safe_auth --test-coins
Secret:
Password:
[2019-10-01T03:29:19Z ERROR safe_auth] safe_auth error: Failed to create an account: AccountContainersCreation("NFS error: NfsError::CoreError -> Request has timed out - CoreError::RequestTimeout")
The corresponding vault log is:
INFO 2019-10-01T03:26:16Z [src/client_handler.rs:153] a8865d..: Connected to new client on pp.pp.pp.pp:443
INFO 2019-10-01T03:26:17Z [src/client_handler.rs:700] a8865d..: Accepted Client(Bls(970930..)) on pp.pp.pp.pp:443.
INFO 2019-10-01T03:26:17Z [src/client_handler.rs:157] a8865d..: Networking error: Connection was actively cancelled
INFO 2019-10-01T03:26:17Z [src/client_handler.rs:159] a8865d..: Disconnected from Client(Bls(970930..)) on pp.pp.pp.pp:443
INFO 2019-10-01T03:26:17Z [src/client_handler.rs:153] a8865d..: Connected to new client on pp.pp.pp.pp:443
INFO 2019-10-01T03:26:18Z [src/client_handler.rs:700] a8865d..: Accepted Client(Bls(970930..)) on pp.pp.pp.pp:443.
INFO 2019-10-01T03:26:18Z [src/client_handler.rs:157] a8865d..: Networking error: Connection was actively cancelled
INFO 2019-10-01T03:26:18Z [src/client_handler.rs:159] a8865d..: Disconnected from Client(Bls(970930..)) on pp.pp.pp.pp:443
INFO 2019-10-01T03:26:18Z [src/client_handler.rs:153] a8865d..: Connected to new client on pp.pp.pp.pp:443
INFO 2019-10-01T03:26:19Z [src/client_handler.rs:700] a8865d..: Accepted Client(Bls(970930..)) on pp.pp.pp.pp:443.
INFO 2019-10-01T03:29:19Z [src/client_handler.rs:157] a8865d..: Networking error: Connection was actively cancelled
INFO 2019-10-01T03:29:19Z [src/client_handler.rs:159] a8865d..: Disconnected from Client(Bls(970930..)) on pp.pp.pp.pp:443
Then I authorized port 443 both udp and tcp, but that didn’t change anything.