View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003884 | GNUnet | gnunet-setup | public | 2015-07-08 21:30 | 2015-07-09 17:26 |
| Reporter | lynX | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | acknowledged | Resolution | open | ||
| Product Version | Git master | ||||
| Summary | 0003884: gnunet-setup should help you use it right | ||||
| Description | https://gnunet.org/how-start-and-stop-gnunet-peer says: "If you want to configure your peer later, you need to stop it before invoking the gnunet-setup tool to customize further and to test your configuration (gnunet-setup has build-in test functions)." Currently my user expectation would be that gnunet-setup affects the running gnunet node in real-time since it doesn't say otherwise. Would therefore be useful if gnunet-setup was able to figure out that a gnunet instance is already running and warn the user it will not be doing a useful job. Or maybe it merely needs "Save" or "Save & Restart" buttons? (I chose "major" because these kind of UX problems deter users…) | ||||
| Tags | No tags attached. | ||||
|
|
Ideally, gnunet-setup should probably interact with a running gnunet-service-arm, ask it to stop the peer and re-start when it is done. I could even imagine gnunet-setup sending the 'new' config to gnunet-service-arm via IPC so that gnunet-setup can run as the "normal" user and gnunet-service-arm would then write the updated system-wide config to file (assuming the user has the right permissions for that...). So yes, we can do way better here. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-07-08 21:30 | lynX | New Issue | |
| 2015-07-09 17:25 | Christian Grothoff | Note Added: 0009407 | |
| 2015-07-09 17:26 | Christian Grothoff | Severity | major => feature |
| 2015-07-09 17:26 | Christian Grothoff | Status | new => acknowledged |
