Peershares / Peershares

Peershares Template
http://www.peershares.net
MIT License
35 stars 17 forks source link

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

Open brossi opened 10 years ago

brossi commented 10 years ago

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 commented 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.

brossi commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

That's definitely reasonable.

sigmike commented 10 years ago

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.