Allow the Peershares daemon to create a customizable peershares.conf file, if one is not already included

[brossi]

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:

1. When the 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.
2. If peershares.conf is found in the expected data directory, the daemon will launch and then attempt to connect to the Peershares offering it is programmed for.
3. However, if peershares.conf is not located where it expects it to be, an error message is presented and the daemon launch is aborted.

To use the "-daemon" option, you must set a rpcpassword in the configuration file:
/home/ubuntu/detected_path_to_peershares_offering/.peershares/peershares.conf
"rpcuser=bitcoinrpc"
"rpcpassword=arandompassword"
(you do not need to remember this password)
If the file does not exist, create it with owner-readable-only file permissions.

Initially, the scope of this enhancement could be very simple:

1. When the peershares.conf file is not located, instead of displaying the error message and help text, enter an interactive console mode where the user is prompted to enter the minimum values that are required for launching the daemon. (Definition of those questions will be added to this enhancement ticket)
2. After the interactive console questions are answered, let the user know where to find the new file and that updates can be made to it directly.
3. Build the peershares.conf file and save it to the data directory.
4. Automatically re-launch the daemon with the previous command

---

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:

#!/bin/bash

#################################################################################
### Run this code on two servers to create all the directories and conf files ###
#################################################################################

#################################################################
### Pass in CoinName, rpcPort and IP of server to connect to ####
### NOTE: NOT the IP of the server u are on but the other one ###
#################################################################

coinName=$1
rpcport=$2
IP=$3

echo "$coinName"
echo "$rpcport"
echo "$IP"

cd /root/Coins/
git clone http://github.com/Peershares/$coinName.git

##################################################################
#### Make the coinName.conf file in the ~/.coinName directory ####
##################################################################

mkdir ~/.$coinName

echo -e 'username=u\nrpcpassword=x\nrpcport='"$rpcport"'\nserver=1\nlisten=1' >> ~/.$coinName/$coinName.conf

cd /root/Coins/$coinName/src
./"$coinName"d --daemon -connect="$IP"

[sigmike]

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.

[brossi]

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.

[sigmike]

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.

[brossi]

That's definitely reasonable.

• 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.
• I agree with your assessment of the listen=1 parameter.
• For the port/rpcport, if the daemon already uses the hard-coded values included in the Peershares distribution they are using, then I agree that adding these is a duplication and are not needed.
• It was my intent that we'd only generate the peershares.conf file if it wasn't included when the daemon was (manually?) started. I agree that there's no reason to include it otherwise. Here's a related question: Is peersharesd started up in the background when the GUI is launched, or is it only invoked manually from the CLI?

[sigmike]

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.