Open brossi opened 10 years ago
I don't think the daemon should do anything interactive. A daemon is meant to be run without any user interface. It may be better to just generate a random username and password and write them to the config file if it doesn't exist.
I agree that the daemon is intended to be run without any user interface, once it has been configured the first time.
I'd be happy if the daemon, when it could not find what it was looking for, was allowed to create the required peershares.conf file with the most basic set of parameters required to start. This follows the existing pattern for creating a .peershares directory (and it's associated content) if it does not yet exist.
# Parameters passed to the Peershares daemon (peersharesd)
server=1
listen=1
port={{peershares default port}}
rpcuser={{randomly generated}}
rpcpassword={{randomly generated}}
rpcport={{peershares default rpcport}}
# To learn more about the configuration options available to use in this file,
# please visit https://peershares.net/developers/daemon.html
That way, the file is ready when the daemon starts up, and the user won't have to manually intervene unless they want to make changes.
I'm not sure about server=1
. If you use only the GUI then having RPC enabled may be a security risk. I think that's the reason why it's disabled by default. Also note that if you run the daemon, server
is automatically set to 1.
I think the same applies to listen=1
. Being open by default may be a security risk, whereas most people will be fine with only outgoing connections.
I think the ports should not be set either because it changes the default behavior. If you don't define the ports, the default is different whether you're on mainnet or on testnet. If you define it, you'll always use the same ports. I think it adds a risk of sending commands to the wrong server.
I agree on random user and password. It'd be a nice not to have to choose them. But I'm not so sure if it's the only thing we do. Maybe we should only do it when the daemon is started instead of displaying the error message you mentioned.
That's definitely reasonable.
server=1
wasn't needed, because you've likely already run ./peershares -daemon
. In that case, we have no reason to include it in an auto-generated .conf file.listen=1
parameter.I didn't realize (though it makes perfect sense, now) that server=1 wasn't needed, because you've likely already run ./peershares -daemon. In that case, we have no reason to include it in an auto-generated .conf file.
You don't even need -daemon
to enable the server. Running peersharesd
automatically enables the server: https://github.com/Peershares/Peershares/blob/master/src/init.cpp#L288-L291
For the port/rpcport, if the daemon already uses the hard-coded values included in the Peershares distribution they are using
Yes it uses the ports defined here: https://github.com/Peershares/Peershares/blob/master/src/protocol.h#L18
Is peersharesd started up in the background when the GUI is launched, or is it only invoked manually from the CLI?
peersharesd
is not started by the GUI. The peersharesd
code is included inside the peershares-qt
executable. They share the same source code. The only difference is the GUI code is not included in peersharesd
(and QT_GUI
is not defined).
In both programs the RPC server runs inside a thread.
It would improve the experience if, when the Peershares daemon is launched, it would not just detect if the peershares.conf file exists in the data directory, but would then allow the user to create a customizable one.
Currently, the process works like this:
peersharesd -daemon
is started from the command line, it will check to make sure that a valid peershares.conf file is in the correct data directory.Initially, the scope of this enhancement could be very simple:
FuzzyBear had created a bash script (or modified an existing one, I'm not sure where it originally came from) that creates a .conf file. Perhaps this would be a starting point for integration: