A couple of suggestions for improving documentation

[useradd-deploy]

OS / Environment

macOS and iOS devices running Algo on a DO Ubuntu 16.04.3 droplet.

Summary of the problem

No problems at all. Everything's working great. I'm adding an issue simply to say thanks to you and your team and offer a couple of suggestions.

First, I see that you're building a new version with a 1 minute deploy time to make Algo easier to install. That's great, I'm looking forward to it. After you roll it out, you might consider focusing on improving the user documentation. I've seen a half dozen installation guides that users have written up to explain how to install Algo. That indicates to me that your users perceive a need for improved documentation beyond your announcement and GitHub pages. Improving your documentation (maybe even starting a dedicated website) could go a long way to expanding and reaching the audience of users who'll benefit from using Algo. (The next time you apply for grants, perhaps consider including a request for money for documentation, communications and PR.)

Second, to that end, I just wrote up my experience installing Algo in a blog post on Medium: Brew Your Own VPN With Algo. I aimed it at people just like I am -- a computer-literate user who's used Terminal but who had never created a SSH key pair or deployed a server or even heard of Ubuntu. I did my best to lay out the instructions clearly so that someone like me could set up Algo on his or her own. I hope it helps in expanding Algo's reach to a broader audience. Feel free to share it if you wish.

[dguido]

Thanks for the feedback!

[dguido]

Note that the method you're using to deploy Algo adds many unnecessary steps. Rather than create a keypair, login to the droplet, and mess with it at length, I would strongly recommend simply creating an API token and then letting the Algo scripts handle all of the setup for you. It would be possible to chop your guide down by 75% using that method and entirely avoid the use of a remote terminal.

Further, many tasks that you're running on the droplet end up making it less secure or are simply unnecessary, like adding a root password, setting up a firewall, and installing Fail2Ban. Setting a root password enables password bruteforcing, Fail2Ban would be unnecessary if you stick with only certificate-based auth but it now may have the potential to lock you out of your own machine, and rather than a firewall you should simply not install or not start any software you don't want exposed to the internet.

These kinds of issues are why we set the default script to simply prompt for an API token and handle all the rest.

[useradd-deploy]

Thanks, I'm learning as I'm going and appreciate the feedback.

[watkinsmd]

Is there any benefit to still following the step to enable MFA on the droplet using Google Authenticator? I followed this step using the "Take 1" instructions and was able to get it working. I use MFA wherever I can.