Hi Nilesh,
Okay... I don't mean to do a 180 on you but I've made some changes. I think I could still provide a configuration file with reasonable defaults. But 90% of users would have to edit it. I would rather avoid playing 20 questions with the user in order to configure the package. It would add a layer of complexity and wouldn't be able to capture all the use cases. I was trying to preserve an easy path from installation to use. But, I don't think this has to be accomplished by the package along. Rather, I would like to provide all the building blocks and let others build what they wish. If someone wants to create tools or write additional documentation with a set of default configurations for lighthouses / host nodes, this package can provide all the components. To that end, I: * templated the systemd service so it can be used with any number of configuration files. This will allow the service to manage multiple networks. In order to do this, I had to write a launcher which would take the template parameter and find the corresponding yaml (or yml) file in /etc/nebula. The launcher is installed into /usr/lib/nebula/bin so it doesn't show up in the user's path. * created /etc/nebula in dirs (since it is empty after installation) * created a nebula.yml(5) man page to describe how to configure nebula and enable a unit * removed the default configuration files I'm going to move the documentation I was printing out in postinst upstream when the package enters unstable. They can instruct users to copy over the example configuration, edit the appropriate fields, and setup the keys. Since this is not reference documentation, it doesn't seem appropriate to put it in a man page. Thanks for your encouragement, patience, and review. :D Best, - Alex
