search

sahib / brig

File synchronization on top of ipfs with git like interface & web based UI
https://brig.readthedocs.io
GNU Affero General Public License v3.0
567 stars 33 forks source link

better error messaging for brig daemon launch #57

Closed evgmik closed 3 years ago

evgmik commented 3 years ago

Currently, if something go wrong brig daemon launch fails without error message to stdout. The default is to send all logs to syslog but if we fail the user should know why. A typical case scenario, user does not have keyphrase loaded for the password manager (pass in my case), then brig daemon cannot start up, but user see no hints for it:

$ ./brig daemon launch                                                                                          (0 sec)
23.12.2020/12:43:11 ⚐ cmd/util.go:592: ipfs: -- IPFS repository is supposed to be at /home/evmik/.ipfs
23.12.2020/12:43:11 ⚐ cmd/util.go:592: ipfs: -- The API address of the repo is: /ip4/127.0.0.1/tcp/5001
23.12.2020/12:43:11 ⚐ cmd/util.go:592: ipfs: -- IPFS Daemon seems to be running. Let's go!
23.12.2020/12:43:11 ⚐ cmd/util.go:592: ipfs: -- Will set some default settings for IPFS.
23.12.2020/12:43:11 ⚐ cmd/util.go:592: ipfs: -- These are required for brig to work smoothly.
23.12.2020/12:43:11 ⚐ cmd/util.go:592: ipfs: -- The IPFS version is »0.7.0«.
23.12.2020/12:43:11 ⚐ cmd/util.go:592: ipfs: -- Setting config: IPFS_PATH='/home/evmik/.ipfs' ipfs config --json Experimental.Libp2pStreamMounting true
23.12.2020/12:43:11 ⚐ cmd/repo_handlers.go:430: all further logs will be piped to the syslog daemon.
$

We are back to command line and everything seems to be good (excerpt error code 4). But actually password read out fails and daemon is not running.

Cause of the issue: the log is tuned to send to syslog and does not switch back on exit. We probably should report grave mistakes to stdout as well.

Related question

Why do we send password helper function to server/server.go if it is used only once? Would it be better to send password itself?

sahib commented 3 years ago

We can just send it to both syslog and stdout (if stdout is conneced to a tty) at that point.

Why do we send password helper function to server/server.go if it is used only once? Would it be better to send password itself?

Historic reasons: I had plans to store the repository encrypted permanently and only hold all relevant files in memory (bit like an encFS). I stopped implementing that, so it could be cleaned up and made a part of the CLI instead of the server.

sahib commented 3 years ago

I did a small quick fix here: 9f2e5a94c163eb67e5acc74540a11ceeaaed8f9b

Can be improved in the following ways:

evgmik commented 3 years ago

Could you elaborate on logrus issues? It seem to work for us, except that it seems to be able only one colorscheme. So once we switched to syslog, it strips colors.

Other than this it works, and we probably do not need extra speed in logging which is promised by other newer loggers.

sahib commented 3 years ago

Correct, it's not a real issue. It's just that I don't like the logrus API very much and found it often awkward to use. So really low priority, just want to change it when I get the chance (shouldn't be hard, can be automated mostly). Highest prio of the bunch has this point:

Clean up password handling and move to client (it's a UI/UX thing, that's where it belongs anyways).

sahib commented 3 years ago

Closing, since original issue had been addressed. The rest is refactoring.