08:12 <stellar-slack> <armed10> So I've managed to set up a standalone server like we talked about yesterday. But the server still won't get to the SYNCED state unless we use --forcescp

08:17 <stellar-slack> <armed10> I'm trying to reset the history and database to see if it will change anything

08:18 <stellar-slack> <sacarlson> I think --forcescp is always required for standalone. I would have to verify by looking at my scripts that did that

08:20 <stellar-slack> <sacarlson> yup that's what my script did --forcescp then run

08:21 <stellar-slack> <sacarlson> however I haven't ran standalone in some time

08:22 <stellar-slack> <armed10> algright, so standalone is working now

08:22 <stellar-slack> <armed10> thank you

08:51 <stellar-slack> <armed10> What steps are needed to get 2 nodes working and in sync?

08:52 <stellar-slack> <armed10> it seems to be dropping and reconnecting the same peer over and over

08:53 <stellar-slack> <sacarlson> you will need @jed or the other -core guys to help you setup configs for that. and this is not there time window of operation

08:55 <stellar-slack> <sacarlson> but I think it's meant to run with 4 at minimum

08:56 <stellar-slack> <armed10> That would be strange since there's a docker that runs 3

08:57 <stellar-slack> <sacarlson> this might help UNSAFE_QUORUM=true

08:58 <stellar-slack> <sacarlson> yes seems the default THRESHOLD_PERCENT=51 so with 2 of 3 would still be ok

08:59 <stellar-slack> <sacarlson> so crank THRESHOLD_PERCENT=48 I would think would work with 1 or 2

09:00 <stellar-slack> <armed10> Thanks, I'll try that

09:18 <stellar-slack> <armed10> Have you experienced a node trying to fetch a history file that does not exist?

09:18 <stellar-slack> <sacarlson> yes but only on testnet and live

09:19 <stellar-slack> <sacarlson> I'm not even sure how to setup saving history. I only setup as a watching node

09:19 <stellar-slack> <armed10> it's trying to fetch a non-existing history file on a second node over a local network

09:21 <stellar-slack> <armed10> I think because it's trying to catch up

09:21 <stellar-slack> <sacarlson> it gets stuck forever if it can't get the history

09:22 <stellar-slack> <armed10> yeah I've noticed :)

09:23 <stellar-slack> <sacarlson> with jed's and or the other -core guys you will have a working 2 set and 3 set in a few minutes with correct configs

09:24 <stellar-slack> <sacarlson> once working it's all the same as if your running standalone

09:26 <stellar-slack> <mvaneijk> have you tried the docker-stellar-core configuration?

09:27 <stellar-slack> <mvaneijk> it's doing exactly the same as you are doing but than automatically in docker containers

09:34 <stellar-slack> <armed10> well we haven't had much succes with docker, but their configuration should be helpful

09:34 <stellar-slack> <armed10> thank

09:38 <stellar-slack> <armed10> could you maybe share the config file your docker uses/

09:51 <stellar-slack> <raymens> can you post your config files?

09:52 <stellar-slack> <mvaneijk> https://github.com/stellar/docker-stellar-core/blob/0f0a68dd9fd5743ba1f143ba9f71fb7d65c3b4df/examples/single.env for the docker example

09:52 <stellar-slack> <mvaneijk> you should create your own history store to make it work

10:01 <stellar-slack> <armed10> @raymens: are you asking me?

10:02 <stellar-slack> <armed10> it's probably just the history thing. The store of one node is not available to another

10:08 <stellar-slack> <mvaneijk> in docker the containers are connected and have disk level access

10:10 <stellar-slack> <mvaneijk> so they can see the history of other containers, hence the `cp history` parameter for `HISTORY_GET`

10:11 <stellar-slack> <mvaneijk> You should use something like the AWS file storage used by the stellar testnet

10:21 <stellar-slack> <raymens> @armed10 yup, are you running all of the nodes on 1 machine or multiple?

10:39 <stellar-slack> <armed10> no seperate machines

10:43 <stellar-slack> <armed10> I will create a remote history, it should fix the problem

10:43 <stellar-slack> <raymens> then you need to let them access each others history by using a shared store (AWS, FTP, Azure, etc.)

13:44 <stellar-slack> <armed10> Should all nodes write to the externally available history or just one?

13:44 <stellar-slack> <armed10> just got duplicate child work: put-snapshot-files

13:52 <stellar-slack> <raymens> they shouldn't write to the same history store

13:53 <stellar-slack> <raymens> not sure if that's related to that error

13:53 <stellar-slack> <raymens> they should be able to read from the other stores though

13:54 <stellar-slack> <raymens> check https://www.stellar.org/developers/stellar-core/learn/core-data-flow.pdf for (some) more technical information about this

14:04 <stellar-slack> <armed10> it's something about the database that gives the duplicate child work error

14:07 <stellar-slack> <mamamae> hey why not use this to diffuse stellar : https://uplink.outernet.is/?utm_source=Outernet+Updates&utm_campaign=b432cc8218-50_Discount_on_Lighthouse2_10_2016&utm_medium=email&utm_term=0_0d5b37bd52-b432cc8218-171543185&goal=0_0d5b37bd52-b432cc8218-171543185&mc_cid=b432cc8218&mc_eid=9892743968

14:23 <stellar-slack> <armed10> Apparently the error was caused by having 2 places to write history to

14:29 <stellar-slack> <armed10> I'm still not getting the different node types entirely, one note, who has 2 peers gives me 3 agrees and 2 fails on a ledger

14:33 <stellar-slack> <raymens> All 3 nodes are validators?

14:33 <stellar-slack> <armed10> well not entirely, 2 nodes have only eachother as preferred nodes and 1 had all three

14:34 <stellar-slack> <armed10> And how would you add a full validator to an existing network?

14:42 <stellar-slack> <armed10> so all nodes are validator but only one is full validator

14:48 <stellar-slack> <raymens> What's the difference between a validator and a full validator?

14:50 <stellar-slack> <eva> @raymens: here's a chart with the 4 different kinds of nodes: https://www.stellar.org/developers/stellar-core/learn/admin.html#level-of-participation-to-the-network

14:50 <stellar-slack> <raymens> thanks eva, so it's just the publishing that's different

14:50 <stellar-slack> <eva> yeah :)

14:51 <stellar-slack> <raymens> @armed10 so you can just add it by letting it catchup COMPLETE to the current network

14:53 <stellar-slack> <raymens> (that you invoke by calling `http://{node}/catchup?ledger=1&mode=complete`)

14:54 <stellar-slack> <armed10> so imagine this scenario: you have a running stellar network. it has 5 validators that know each other. now you want to add a 6th validator, but its validation is only useful if other validators consider him a validator

14:55 <stellar-slack> <armed10> in the quorem

14:55 <stellar-slack> <armed10> so you have to shut down each server, edit the config and reboot?

14:56 <stellar-slack> <raymens> you have to manually add him to the quorum set

14:56 <stellar-slack> <raymens> and so far as I know, yes

14:58 <stellar-slack> <armed10> That would be inconvenient on a larger scale

16:40 <stellar-slack> <mvaneijk> I guess there are a few issues about that topic in the stellar-core github repo