Move infrastructure cookbooks to docs (#2331)

* Move apache configuration to docs

* Add redirect

* Move certificate cookbooks to docs

* Add redirect

* Move tor configuration to docs

* Fix extension

* Update headings and add redirect

* Move file to docs

* Add redirect and remove whitespaces

* Add new sections
This commit is contained in:
Fabian Affolter 2017-03-25 19:19:33 +01:00 committed by GitHub
parent 82c9798f10
commit 8f1095fda0
6 changed files with 43 additions and 25 deletions

View file

@ -0,0 +1,103 @@
---
layout: page
title: "Apache Proxy"
description: "Configure Apache to work with Home Assistant as a subdomain"
date: 2016-06-20 13:05
sidebar: true
comments: false
sharing: true
footer: true
redirect_from: /cookbook/apache_configuration/
---
This example demonstrates how you can configure Apache to act as a proxy for Home Assistant.
This is useful if you want to have:
* a subdomain redirecting to your home assistant instance
* several subdomain for several instance
* HTTPS redirection
#### {% linkable_title Subdomain %}
So you already have a working Apache server available at example.org. Your Home Assistant is correctly working on this web server and available at http://localhost:8123
Enable [`mod_proxy_wstunnel`](https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.htm) by running if you encounter issues while serving Home Assistant through your proxy:
```bash
$ sudo a2enmod proxy_wstunnel
```
To be able to access to your Home Assistant instance by using https://home.example.org, add to following file to `/etc/httpd/conf/extra/` as `hass.conf`
```text
<VirtualHost *:443>
ProxyPreserveHost On
ProxyRequests Off
ServerName home.example.org
ProxyPass /api/websocket ws://localhost:8123/api/websocket
ProxyPassReverse /api/websocket ws://localhost:8123/api/websocket
ProxyPass / http://localhost:8123/
ProxyPassReverse / http://localhost:8123/
</VirtualHost>
```
and make sure that this file is read by Apache's main configuration file `/etc/httpd/conf/httpd.conf`
```text
...
Include conf/extra/hass.conf
...
```
If you don't want HTTPS, you can change `<VirtualHost *:443>` to `<VirtualHost *:80>` or better consider redirecting all HTTP to HTTPS.
#### {% linkable_title Multiple Instance %}
You already have Home Assistant running on http://localhost:8123 and available at home.example.org as describe before. The configuration file for this Home Assistant is available in `/home/alice/.homeassistant/configuration.yaml`
You want another instance available at https://countryside.example.org
You can either :
* Create a new user, `bob`, to hold the configuration file in `/home/bob/.homeassistant/configuration.yaml` and run home assistant as this new user
* Create another configuration directory in `/home/alice/.homeassistan2/configuration.yaml` and run home assistant using `hass --config /home/alice/.homeassistant2/`
In both solution, change port number used by modifying `configuration.yaml`
```yaml
http:
server_port: 8124
...
```
Start Home Assistant: Now, you have another instance running on http://localhost:8124
To access this instance by using https://countryside.example.org add to `/etc/httpd/conf/extra/hass.conf`
```text
<VirtualHost *:443>
ProxyPreserveHost On
ProxyRequests Off
ServerName countryside.example.org
ProxyPass /api/websocket ws://localhost:8123/api/websocket
ProxyPassReverse /api/websocket ws://localhost:8123/api/websocket
ProxyPass / http://localhost:8124/
ProxyPassReverse / http://localhost:8124/
</VirtualHost>
```
#### {% linkable_title HTTP to HTTPS redirection %}
Add to your `/etc/httpd/conf/extra/hass.conf`
```text
<VirtualHost *:80>
ServerName example.org
ServerSignature Off
RewriteEngine on
RewriteCond %{HTTPS} !=on
RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [NE,R,L]
</VirtualHost>
```

View file

@ -0,0 +1,214 @@
---
layout: page
title: "Configuration Backup to GitHub"
description: "Instructions how backup your Home Assistant configuration to GitHub"
date: 2017-01-05 18:00
sidebar: true
comments: false
sharing: true
footer: true
redirect_from: /cookbook/githubbackup/
---
Backing up and regularly syncing your Home Assistant configuration to [GitHub](http://GitHub.com) has several benefits:
- A remote copy of your Home Assistant YAML files in case you need to recover
- A documented history of your changes for troubleshooting purposes
- It will help the Home Assistant community learn from your configuration examples
<p class='note'>
This is not a comprehensive tutorial on using GitHub, more information can be found in the [GitHub Help](https://help.github.com/) pages. This guide assumes the user has an intermediate experience level and is comfortable with such concepts as: navigating the Home Assistant directory structure, logging in as the Home Assistant user, and working with the command line.
</p>
<p class='note'>
This will not create a full backup of your Home Assistant files or your OS. In addition to backing up to Github, you should consider having regular backups of all your Home Assistant configuration files and images of your SD card if applicable.
</p>
### {% linkable_title Important Best Practices %}
Some best practices to consider before putting your configuration on GitHub:
- Extensive use of [secrets.yaml](https://home-assistant.io/topics/secrets/) to hide sensitive information like usernames, passwords, device information, and location
- Exclusion of some files, including `secrets.yaml` and device-specific information using a [`.gitignore`](https://git-scm.com/docs/gitignore) file
- Regularly commiting your configuration to GitHub to make sure that your backup is up to date
- Use a README.md to document your configuration and include screenshots of your Home Assistant GUI
### {% linkable_title Step 1: Installing and Initializing Git %}
In order to put your configuration on GitHub, you must install the git package on your Home Assistant server (instructions below will work on Raspberry Pi, Ubunutu, or any Debian-based system):
```bash
$ sudo apt-get update
$ sudo apt-get install git
```
### {% linkable_title Step 2: Creating %} `.gitignore`
<p class='note warning'>
Before creating and pushing your Home Assistant configuration to GitHub, please make sure to follow the `secrets.yaml` best practice mentioned above and scrub your configuration for any passwords or sensitive information.
</p>
Creating a `.gitignore` file in your repository will tell git which files NOT to push to the GitHub server. This should be used to prevent publishing sensitive files to the public. It should contain a list of filenames and pattern matches. This list should include at least your `secrets.yaml` file, device configuration files, and the Home Assistant database/directory structure. The `.gitignore` file should be placed in your Home Assistant directory.
Here is a sane example, but yours should be based on the files in your structure:
`.gitignore`
```bash
*.pid
*.xml
*.csr
*.crt
*.key
www
OZW_Log.txt
home-assistant.log
home-assistant_v2.db
*.db-journal
lib
deps
tts
secrets.yaml
known_devices.yaml
*.conf
plex.conf
phue.conf
harmony_media_room.conf
pyozw.sqlite
.*
!/.gitignore
```
More information on the layout of the file can be found in the [.gitignore manual](https://git-scm.com/docs/gitignore).
### {% linkable_title Step 3: Preparing your Home Assistant directory for GitHub %}
In your Home Assistant directory, type the following commands as the Home Assistant user, replacing the email address and name with your information:
```bash
$ git init
$ git config user.email "you@example.com"
$ git config user.name "Your Name"
$ git add .
$ git commit
```
After the `git commit` command, you will be asked to enter a message for the commit. This will add a comment beside each file on GitHub describing the purpose for the commit. In this case, you can enter something like "Initial commit of my Home Assistant configuration."
### {% linkable_title Step 4: Creating Repository on GitHub %}
- Connect to [GitHub](https://github.com) and login to your account (or create an account if you don't already have one).
- Click "[New Repository](https://github.com/new)" and give your repository a name/description (`Home-AssistantConfig` is used in the example below). You do NOT need to change any other options.
- Click "Create Repository"
### {% linkable_title Step 5: Your initial commit to GitHub %}
Once you are sure you are using `secrets.yaml` and `.gitignore` correctly, it is time to push your configuration to the GitHub Repository that you just created.
In your Home Assistant directory, type the following commands as the Home Assistant user, replacing "username" in the URL with your GitHub username:
```bash
$ git remote add origin https://github.com/username/Home-AssistantConfig
$ git push -u origin master
```
You will be asked to enter your GitHub username and password (or ssh key passphrase if you use [GitHub with ssh](https://help.github.com/categories/ssh/)).
Congratulations, you now have a copy of your current Home Assistant Configuration on GitHub!
### {% linkable_title Step 6: Keeping your repository up to date %}
You should update your repository on a regular basis; ideally after you make a major configuration change (new device, new component, etc.). The below script will update your repository with any changed configuration files and allow you to add a comment with the commit for tracking purposes:
<p class='note'>
You may need to adjust the paths in the script depending on your Home Assistant configuration.
</p>
`gitupdate.sh`
```bash
#!/bin/bash
cd /home/homeassistant/.homeassistant
source /srv/homeassistant/homeassistant_venv/bin/activate
hass --script check_config
git add .
git status
echo -n "Enter the Description for the Change: " [Minor Update]
read CHANGE_MSG
git commit -m "${CHANGE_MSG}"
git push origin master
exit
```
Every time you run this script, you will be prompted for a comment to describe the change(s) that you are commiting. This comment will be displayed beside each changed file on GitHub and will be stored after each commit. You will also be asked to enter your GitHub username and password (or ssh key passphrase if you use [GitHub with ssh](https://help.github.com/categories/ssh/)).
### {% linkable_title Step 7: Configuration file testing %}
[Travis CI](https://travis-ci.org) is a continuous integration testing system that runs every time the code in your repository is updated and allows you to validate that your code works on a fresh install.
- [Authorise Travis CI](https://travis-ci.org/auth) to have access to your github repos.
- Create the build script that travis will run to test your repo.
- Create a dummy secrets.yaml for Travis.
Example .travis.yml
```yaml
language: python
python:
- "3.4"
before_install:
- mv travis_secrets.yaml secrets.yaml
install:
- pip3 install homeassistant
script:
- hass -c . --script check_config
```
Since the secrets.yaml should _not_ be stored in your repo for security reasons, you won't be able to access it at build time. Creating a dummy secrets.yaml is as simple as creating a new file that mimics your existing secrets.yaml with the required keys, but not their value.
```yaml
#travis_secrets.yaml
http_api: 000000000000000000000000
home_latitude: 00.00000
home_longitude: 00.0000
home_elevation: 0
```
### {% linkable_title Extra commands %}
You can enter these commands to get a list of the files in your local git repository and a status of files that have changed but not commited yet:
```bash
$ git ls-files
$ git status
```
Examples:
```bash
homeassistant@raspberrypi:~/.homeassistant $ git ls-files
.gitignore
README.md
automation.yaml
configuration.yaml
customize.yaml
device_tracker.yaml
group.yaml
script.yaml
homeassistant@raspberrypi:~/.homeassistant $ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: .gitignore
modified: automation.yaml
modified: customize.yaml
modified: group.yaml
no changes added to commit (use "git add" and/or "git commit -a")
```

View file

@ -0,0 +1,72 @@
---
layout: page
title: "Certificate for SSL/TLS via domain ownership"
description: "Configure a certificate to use with Home Assistant"
date: 2017-02-17 08:00
sidebar: true
comments: false
sharing: true
footer: true
redirect_from: /cookbook/tls_domain_certificate/
---
If your Home Assistant instance is only accessible from your local network you can still protect the communication between your browsers and the frontend with SSL/TLS. You can use [Self-sign certificate](/cookbook/tls_self_signed_certificate/) but your browser will present a warning and some https-only features might not work.
### {% linkable_title Prerequirement for this guide %}
* Your Home Assistant instance is not exposed to the internet. If it is - use [this guide]({{site_root}}/blog/2015/12/13/setup-encryption-using-lets-encrypt/)
* You control a public domain name. The domain doesn't have to point to a site. A domain controlled by a *trusted* friend will do. (A friend you trust not to MITM you)
* Your home router supports custom DNS entries.
### {% linkable_title Run certbot %}
```bash
$ mkdir certbot
$ cd certbot
$ wget https://dl.eff.org/certbot-auto
$ chmod a+x certbot-auto
$ sudo ./certbot-auto --manual certonly --preferred-challenges dns -d "mydomain.com" --email your@email.address
```
* Agree to Terms of Service
* Choose whether to share your email with Electronic Frontier Foundation.
* Agree to your IP being logged
You will get the following text:
```text
Please deploy a DNS TXT record under the name
_acme-challenge.mydomain.com with the following value:
deadbeefdeadbeefdeadbeefdeadbeefdeadbeef
Once this is deployed,
-------------------------------------------------------------------------------
Press Enter to Continue
```
* Deploy the value to TXT field using your domain registar.
* Go to a site that queries domain record. For example [this one](https://mxtoolbox.com/TXTLookup.aspx) and look if it sees your brand new TXT field (Don't forget to enter the full domain: `_acme-challenge.mydomain.com`)
* Press Enter at certbot prompt.
### {% linkable_title Make mydomain.com point to your Home Assistant instance %}
If your router uses DNSMasq (for example DDWRT) add the following line to DNSMasq options:
```text
address=/mydomain.com/<hass ip>
```
### {% linkable_title Edit your Home Assistant configuration to use your certificates %}
The [`http`](/components/http/) section must contain the full path to the needed files.
```yaml
http:
api_password: YOUR_SECRET_PASSWORD
base_url: https://mydomain.com:8123
ssl_certificate: /etc/letsencrypt/live/mydomain.com/fullchain.pem
ssl_key: /etc/letsencrypt/live/mydomain.com/privkey.pem
```
Make sure the files are accessible by the user that runs Home Assistant, eg. `homeassistant` for a HASSbian setup.

View file

@ -0,0 +1,34 @@
---
layout: page
title: "Self-signed certificate for SSL/TLS"
description: "Configure a self-signed certificate to use with Home Assistant"
date: 2016-10-06 08:00
sidebar: true
comments: false
sharing: true
footer: true
redirect_from: /cookbook/tls_self_signed_certificate/
---
If your Home Assistant instance is only accessible from your local network you can still protect the communication between your browsers and the frontend with SSL/TLS. [Let's encrypt]({{site_root}}/blog/2015/12/13/setup-encryption-using-lets-encrypt/) will only work if you have a DNS entry and remote access is allowed. The solution is to use a self-signed certificate. As you most likely don't have a certification authority (CA) your browser will conplain about the security. If you have a CA then this will not be an issue.
To create locally a certificate you need the [OpenSSL](https://www.openssl.org/) command-line tool.
Change to your Home Assistant [configuration directory](/getting-started/configuration/) like `~/.homeassistant`. This will make it easier to backup your certificate and the key. Run the command shown below.
```bash
$ openssl req -new -x509 -sha256 -newkey rsa:4096 -nodes -keyout privkey.pem -days 730 -out fullchain.pem
```
For details about the parameters, please check the OpenSSL documentation. Provide the requested information during the generation process. At the end you will have two files called `privkey.pem` and `fullchain.pem`. The key and the certificate.
Update the `http:` entry in your `configuration.yaml` file and let it point to your created files.
```yaml
http:
api_password: YOUR_SECRET_PASSWORD
ssl_certificate: /home/fab/.homeassistant/fullchain.pem
ssl_key: /home/fab/.homeassistant/privkey.pem
```
A tutorial "[Working with SSL Certificates, Private Keys and CSRs](https://www.digitalocean.com/community/tutorials/openssl-essentials-working-with-ssl-certificates-private-keys-and-csrs)" could give you some insight about special cases.

View file

@ -0,0 +1,110 @@
---
layout: page
title: "Tor Onion Service Configuration"
description: "Configure Tor to work with Home Assistant to provide secure remote access without opening your firewall"
date: 2016-07-06 13:05
sidebar: true
comments: false
sharing: true
footer: true
redirect_from: /cookbook/tor_configuration/
---
This is an example about how you can configure Tor to provide secure remote access to your Home Assistant instance as an Onion site, through [Tor's Hidden Service](https://www.torproject.org/docs/hidden-services.html.en) feature. With this enabled, you do not need to open your firewall ports or setup HTTPS to enable secure remote access.
This is useful if you want to have:
* Access your Home Assistant instance remotely without opening a firewall port or setting up a VPN
* Don't want to or know how to get an SSL/TLS certificate and HTTPS configuration setup
* Want to block attackers from even being able to access/scan your port and server at all
* Want to block anyone from knowing your home IP address and seeing your traffic to your Home Assistant
## {% linkable_title Background and Contact %}
This configuration is part of an effort to apply strong cryptography technologies (like Onion Routing and End-to-End Encryption) to technology we increasingly depend on in our day to day lives. Just like when WhatsApp enabled end-to-end encryption messaging for everyone, every home automation and IoT platform should do the same, because A) the technology is all there, freely licensed and open-source and B) up to this point, all the commercial manufacturers have been doing a horrific job with security.
You can learn more about how Tor can be used to secure home automation and IoT platforms through this short set of slides on the [Internet of Onion Things](https://github.com/n8fr8/talks/blob/master/onion_things/Internet%20of%20Onion%20Things.pdf)
## {% linkable_title Hidden Services and Onion Sites %}
Tor allows clients and relays to offer hidden services. That is, you can offer a web server, SSH server, etc., without revealing your IP address to its users. In fact, because you don't use any public address, you can run a hidden service from behind your firewall. Learn more about Hidden Services on the [Tor Project website](https://www.torproject.org/docs/tor-hidden-service.html.en).
Onion sites are websites that run on a Tor Hidden Service node. "dot onion" sites are an [IETF recognized special use domain name](https://datatracker.ietf.org/doc/rfc7686/).
## {% linkable_title Setting up Tor on your Home Assistant %}
First, install Tor. On a Debian-based system, you can install the package easily:
```bash
$ sudo apt-get install tor
```
You can find more instructions for downloading and installing Tor on other platforms on the [Tor Project Download Page](https://www.torproject.org/download/download.html).
Next, modify Tor's main configuration file `/etc/tor/torrc` to include the following lines:
```bash
############### This section is just for location-hidden services ###
## Once you have configured a hidden service, you can look at the
## contents of the file ".../hidden_service/hostname" for the address
## to tell people.
...
HiddenServiceDir /var/lib/tor/homeassistant/
HiddenServicePort 80 127.0.0.1:8123
HiddenServiceAuthorizeClient stealth haremote1
...
```
The "stealth" entry above ensures traffic to and from your Home Assistant instance over Tor, is hidden even from other nodes on the Tor network. The `haremote1` value is a generic client name entry that you can modify as you please.
Then, restart Tor:
```bash
$ sudo /etc/init.d/tor restart
```
Then read the new generated authentication cookie from the Tor-generated hostname file:
```bash
$ sudo more /var/lib/tor/homeassistant/hostname
```
The output of that command should look something like this, but with your own unique "dot onion" domain and authentication cookie:
```bash
abcdef1234567890.onion ABCDEF1122334455667789 # client: haremote1
```
You are now done with the Home Assistant Tor server configuration. Make sure your Home Assistant instance is running, and now you can move to client configuration.
## {% linkable_title Tor Client Access Setup %}
Using this setup, you can access your Home Assistant instance over Tor from your laptop or mobile device, using Tor Browser and other software.
Add the authentication cookie to your `torrc` client configuration on your laptop or mobile device. Using the sample values from above, it would look like this:
```bash
HidServAuth abcdef1234567890.onion ABCDEF1122334455667789
```
For Tor Browser on Windows, Mac or Linux, you can find the torrc file here: `<tor browser install directory>/Browser/TorBrowser/Data/Tor/torrc-defaults`
Once you have added the entry, restart the browser, and then browse to the "dot onion" site address to connect to your Home Assistant instance.
For [Orbot: Tor on Android](https://guardianproject.info/apps/orbot), add it in **Orbot** -> **Menu** -> **Settings** to the "Torrc Custom Config" entry. Restart Orbot, and then use the [Orfox browser app](https://guardianproject.info/apps/orfox/), and browse to the "dot onion" site name to access your Home Assistant instance. You can also use Orbot's VPN mode, to enable Tor access from any application on your device, such as Tasker or Owntracks.
On iOS, we have not fully tested this yet, but you should be able to add custom torrc entries on [Onion Browser](https://mike.tig.as/onionbrowser/), Red Onion or TOBY browsers, all available in the iTunes App Store.
## {% linkable_title Some More Advanced Ideas %}
With this configuration, only you can access your Home Assistant instance Onion site through Tor, and no one else. You can share the authentication cookie with multiple devices and users, or you can generate a unique one for each - up to you! If you have multiple, say for an industrial, business or corporate configuration, this would provide an easy way to revoke access to a specific user or device.
If you always access your Home Assistant instance via Tor, you can easily run this on an isolated "IoT" network segment at your install site, keeping your internal home network traffic separate from any potentially compromised devices (like cheap "smart" lightbulbs with backdoors!).
You could also use Tor as a means to connect your Home Assistant instance to a remote device, sensor or other service that you do not want to or connect provide a direct, open IP connection to. Again, Tor provides authenticated and confidential routing (aka "privacy and encryption") by default, without having to setup TLS/SSL or VPN. It is just important to secure IoT nodes within your network, as it is to secure remote access!
As mentioned, with Orbot on Android, you can enable a "full device" VPN mode, that allows any app you have to tunnel through Tor, even if it is not Tor or proxy aware. This means you should be able to enter your "dot onion" Onion site address into any app you want to access to your Home Assistant instance, and it should work.
This configuration was provided by @n8fr8 ([github](https://github.com/n8fr8), [twitter](https://twitter.com/n8fr8)) of the [Guardian Project](https://guardianproject.info) and [Tor Project](https://torproject.org). You can send questions, feedback and ideas to [support@guardianproject.info](mailto:support@guardianproject.info).