Added Travis CI, more checks to scripts and output more system information.

[tdulcet]

• Added Travis CI (continuous integration). See the log here.
  • Need to enable at travis-ci.org before merging this pull request.
  • See my starting a test suite (#777) #1039 (comment) for more info.
  • Ready to run the starting a test suite (#777) #1039 test suite, once it is merged. Just uncomment the three lines.
• Added more checks to scripts.
  • Check that the user is on Linux before, checking that they are on Ubuntu 14.04/18.04.
  • Check internet connectivity, before preforming network checks, etc..
  • Output warning if hostname is not a valid FQDN.
  • Added temporary message to direct Ubuntu 18.04 users to the corresponding branch.
• Outputs more system information (for user verification and debugging).
• Outputs error messages to stderr.
• Randomly generates a password for NONINTERACTIVE users that is more secure than 12345678.
• Copy edited Readme and script documentation.
• Fixed numerous bugs found by ShellCheck.

[JoshData]

Hi. Thanks. There's a lot here.

In fact.... There's too much for me to review. Just as a practical matter, it'll take many months before I could finish going through all of the changes here.

I also strongly prefer to not mix logically unrelated changes in the same commit because it makes it very hard to review and in the future to use the history to pinpoint when things changed and for what reason. For instance, removing commas because of a personal preference about punctuation shouldn't be mixed with new features like setting up TravisCI. Each of your bullets in your summary above should be a separate commit (more or less).

Is there any chance you would submit a new pull request that makes the changes for just one of the logical things you were trying to do here?

[tdulcet]

@JoshData Thanks for looking at this.

Which one of the logical changes would you like me to make a pull request for? Or would you like me to make a new pull request for roughly each bullet? I considered doing that originally, but many of the bullets modify the same few files and I did not want to create a bunch of merge conflicts for you.

[zatricky]

Research "Oxford Comma". As is, this change is likely to be rejected. ;)

[zatricky]

There are many standards in use by many projects - but the main thing in common is the goal of making the changes easy to understand:

• Pull requests should address a single topic
• Commits should balance being as small and individually reviewable as possible against being overly burdensome on the persons committing or reviewing the code. Personally I err towards having better documentation for when someone is bugfixing and reviewing old changes.

@JoshData might prefer to do things differently of course, in particular with regard to the number of pull requests. His reply above implies perhaps he'd be okay with a single pull request - just not all in a single commit. The following is how I would likely structure my pull requests:

.travis.yml new file -> own commit -> travis-related pull request
Code of Conduct grammar -> own commit -> grammar-related PR
Contributing.md grammar -> own commit -> together with grammar-related PR
README.md grammar -> own commit -> together with grammar-related PR
README.md added URI/wiki links -> own commit -> own PR
daily_tasks.sh -> shared commit for linting -> linting-related PR
Security.md grammar -> own commit -> together with grammar-related PR
bootstrap.sh changes -> at least 3 commits -> "improved deploy"-related PR
dkim.sh linting -> shared commit for linting -> linting-related PR
dns.sh linting -> shared commit for linting -> linting-related PR
firstuser.sh spelling -> own commit -> together with grammar-related PR
firstuser.sh randomising PW -> own commit -> own PR
firstuser.sh linting -> shared commit for linting -> linting-related PR
functions.sh mktemp vs tempfile and removing the file -> own commit -> shared PR for functions.sh
functions.sh changes PACKAGES array -> own commit -> shared

And so forth

This might seem like a little more work for Josh to get through - but it's far easier. It gives your commits and pull requests focus. It also gives an opportunity for others to help spot and fix issues beforehand, which means there is less burden on Josh.

For your own peace of mind, it also means you can get some changes applied without depending on first resolving differences of opinion on unrelated changes, meaning the conversations don't lose focus.

[tdulcet]

@zatricky Thanks for your review and feedback.

@JoshData and @zatricky I divided this into three new pull requests: #1455, #1456, #1457.

I skipped all the spelling/grammar fixes in the markdown files, because I did not exhaustively fix all the mistakes, only the ones I noticed while making other changes and I did not feel there was enough to justify a separate pull request. Someone else is welcome to fix these errors.

[JoshData]

Thanks. Closing this one then.