Open markusressel opened 4 years ago
markusressel
commented
4 years ago For context:
I am trying to run almond-server inside of a rancher managed kubernetes cluster. I have exposed on port 3000 both TCP and UDP using a HostPort mapping.
I ran almond-server:latest-portable to test things out and it did work, however since it is not the "normal" version and the home assistant integration seems to be missing I would like to try almond-server:latest instead.
gcampax
commented
4 years ago Both latest and latest-portable should have the same level of Home Assistant integration. Note though that you need to configure Almond from Home Assistant, not the other way around, otherwise Almond will try to connect to a Home Assistant on the local network and fail.
Follow the instructions at https://www.home-assistant.io/integrations/almond/ to set up.
The difference between latest and latest-portable is PulseAudio support. If you're in a Kubernetes cluster, I am assuming this is a cloud installation, so sound won't be available - or are you using PulseAudio network support?
If you actually want to provide sound in the docker, you can either use podman with --userns=keep-id as in the readme, or you can configure PulseAudio in system mode and grant access to the PulseAudio socket to the Almond container.
If your PulseAudio has TCP enabled, setting PULSE and PULSE_COOKIE environment variables might be an alternative to fiddling with permissions on the local socket (especially if you're running in an environment with SELinux, which will also complain loudly).
markusressel
commented
4 years ago Well I want home assistant to handle the audio/texting communication with almond, so I think I don't need audio support on Almond itself, right? If that is the case I would just use latest-portable.
No this is not a cloud setup. I am using Rancher on a private server running in my home network. The machine has internet access, but services running on it are not directly exposed to the internet. My Home Assistant instance runs on another machine in my home network and is accessible through a NGINX reverse proxy. But almond can communicate with Home Assistant using a local connection, so it only needs internet access for the machine learning magic, right?
I followed the instructions you mentioned, but I simply don't know where to get the client_id and token from. On the webinterface of almond (of my local instance running via Rancher/Kubernetes/Docker) I don't see anything to create such a token. I can set a password, but I can not create client tokens. What am I missing?
EDIT: I also tried to tell almond:
configure home assistantbut it responded with:
Okay, I'm going to configure a new Home Assistant.
I'm sorry, but Home Assistant is not supported on this version of Almond.So, whats the problem?
gcampax
commented
4 years ago Use the instructions for the local installation of Almond, not the web one. You should add a snippet like this in your configuration.yaml:
almond:
type: local
host: http://127.0.0.1:3000Replace the IP with whatever IP Home Assistant can use to talk to Almond. Also, make sure that Home Assistant knows an IP address of itself good enough to pass through to Almond. In practice, this probably means either one needs docker host networking. I'm not familiar with Rancher to be honest. I know hass.io (which is the easiest way to setup local Almond) also has a full docker based setup where Almond is behind nginx, and they have quite a rig to get all the port forwards in place. This is their startup script where they pass the correct HA information to Almond: https://github.com/home-assistant/hassio-addons/blob/master/almond/data/run.sh - and then Home Assistant itself recognizes when running in hassio and uses hassio configuration to talk to Almond.
As for the command you gave, that's Almond trying to do OAuth to talk to Home Assistant. OAuth is disabled in almond-server, because the local server doesn't have a stable URI to redirect to. (We might fix that in the near future with a cloud-based proxy). HA doesn't require a registered OAuth URI, and therefore could work, but OAuth is just disabled across the board in almond-server for now.
markusressel
commented
4 years ago Also, make sure that Home Assistant knows an IP address of itself good enough to pass through to Almond.
In my current setup Home Assistant is running on a FreeBSD Jail with an independent network stack. It acts like a VM with a static IP enforced through DHCP settings on my router. Is there a config option in Home Assistant that needs to be set? I have set the http.base_url property to the domain that is reachable via the NGINX proxy, but that should not be necessary for local communication.
I tried to set the almond container to use host networking now. I can access the almond web interface (just like before) with the IP of the host system now, but Home Assistant complains that it is not setting up almond because it cant connect when specifying this exact IP. The config I set is:
almond:
type: local
host: http://192.168.2.20:3000When I access this URL in my browser I get the web interface. I skipped through the script you linked, but I don't see anything fancy except the token authentication which I assume is unnecessary when using a local instance? They do setup a device using the http://x.x.x.x:3000/api/devices/create almond api endpoint with some HASSIO_TOKEN, but I would think that the home assistant integration would do that automatically once a local configuration has been set up (like I did).
Any chance @balloob or @frenck or whoever is involved in the Home Assistant integration side has some insights into this? The documentation for all of this is really sparse right now, would be very cool to get some help so I can open some PRs to improve the situation.
Btw do you mean HA as a synonym for Home Assistant or HA the layer-4 proxy :question: :smile:
gcampax
commented
4 years ago Basically, there are two sides of the configuration.
On one side, Home Assistant must be able to talk to Almond. For this you need:
THINGENGINE_HOST_BASED_AUTHENTICATION=insecure in your environment; this disables all authentication, because normal host-based auth (localhost only) wouldn't work in your routed world. Make sure to put some auth in your nginx proxy if you do this!On the other side, Almond must be able to talk to Home Assistant. For this you need:
base_url, so all good?If not, the run.sh script I linked is an alternative way to call /devices/create in AlmondDoes this make sense?
EDIT: yeah sorry HA is Home Assistant. I forgot about the other HA.
markusressel
commented
4 years ago It does, I have no clue why it is not working though.
Executing curl from inside the jail that is hosting Home Assistant is working:
curl -vL http://192.168.2.20:3000
* Trying 192.168.2.20:3000...
* TCP_NODELAY set
* Connected to 192.168.2.20 (192.168.2.20) port 3000 (#0)
> GET / HTTP/1.1
> Host: 192.168.2.20:3000
> User-Agent: curl/7.65.3
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< X-Powered-By: Express
< Content-Type: text/html; charset=utf-8
< Content-Length: 3503
< ETag: W/"daf-Ro8WSfQy2kkY0CW29Ln41s13w6s"
< Set-Cookie: connect.sid=s%3Azwl3_TuvI1MRkaAbxdylFMGTacUmnzsI.8A4U7DfUr27flcMsgcNrwnrJn0r7D594CzBhIJeZw3E; Path=/; HttpOnly
< Date: Tue, 03 Dec 2019 04:14:47 GMT
< Connection: keep-alive
<
<!DOCTYPE html><html><head><meta charset="utf-8"><meta http-equiv="X-UA-Compatible" content="IE=edge"><meta name="viewport" content="width=device-width, initial-scale=1"><title>Almond - The Open Virtual Assistant</title><link rel="stylesheet" href="https://use.fontawesome.com/releases/v5.2.0/css/all.css"><link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Source+Sans+Pro:200,200i,300,300i,400,400i,600,600i,700,700i,900,900i"><link rel="stylesheet" href="/stylesheets/bootstrap.min.css"><link rel="stylesheet" href="/stylesheets/style.css"><script src="https://code.jquery.com/jquery-3.4.1.min.js" integrity="sha256-CSXorXvZcTkaix6Yvo6HppcZGetbYMGWSFlBw8HfCJo=" crossorigin="anonymous"></script><script src="https://stackpath.bootstrapcdn.com/bootstrap/3.4.1/js/bootstrap.min.js" integrity="sha384-aJ21OjlMXNL5UyIl/XNwTMqvzeRMZH2w8c5cRVpzpU8Y5bApTppSuUkhZXN0VxHd" crossorigin="anonymous"></script><script src="/javascripts/validator.min.js"></script><script src="/javascripts/jstz.min.js"></script><script src="/javascripts/shared.js"></script></head><body data-developer-key="" data-thingpedia-url="https://thingpedia.stanford.edu/thingpedia" data-csrf-token="4RRoFmSh-HEjWt7V0xaOwi5DOdjEE1USrJeg"><nav class="navbar-inverse navbar navbar-fixed-top" role="banner"><div class="navbar-header"><button class="navbar-toggle collapsed" data-toggle="collapse" data-target="#page-nav"><span class="sr-only">Toggle navigation</span><span class="icon-bar"></span><span class="icon-bar"></span><span class="icon-bar"></span></button><a class="navbar-brand scroller hidden-xs hidden-sm" href="/">Almond</a><span class="navbar-brand scroller hidden-md hidden-lg" aria-hidden="true">Almond</span></div><div class="navbar-collapse collapse" role="navigation" id="page-nav"><ul class="nav navbar-nav"><li class="hidden-md hidden-lg"><a class="scroller" href="/">Home</a></li><li><a class="scroller" href="/apps">My Rules</a></li><li><a class="scroller" href="/devices">My Skills</a></li><li><a class="scroller" href="/conversation">Conversation</a></li></ul><ul class="nav navbar-nav navbar-right"><li><a class="scroller" href="/config">Configuration</a></li><li><a class="navbar-login scroller" id="navbar-login-button" href="/user/logout">Log out</a></li></ul></div></nav><div class="container" id="page-body"><div class="row"><div class="col-sm-12"><div class="jumbotron text-center"><h1>It works!</h1><p>This is your personal Almond instance, running on KFC (127.0.0.1) at port 3000.</p><p>If you see this message, your server is correctly configured.</p><p><a class="btn btn-primary" href="/conversation">Start a conversation</a> <a class="btn btn-default" href="/apps">Check your enabled rules</a></p><!--if !cloud.isConfiguredp You did not configure cloud access yet. You should do that 
a(href=Config.BASE_URL + '/config') now
| .
--><!--if server.initialSetupp.text-danger
| The server is in initial setup mode and thus open to
* Connection #0 to host 192.168.2.20 left intact
| all external access. Pair your phone soon!--></div></div></div></div><footer class="page-footer hidden-xs hidden-sm"><div class="container"><div class="row"><div class="col-xs-12"><p><small>Almond is part of a research project of the <a href='https://mobisocial.stanford.edu'>Mobisocial Computing Laboratory</a> at Stanford University.</small></p><p><small>Almond is free software, distributed under the <a href='https://www.gnu.org/licenses/gpl-3.0-standalone.html'>GPLv3 license</a>. </small></p></div></div></div></footer></body></html>It even states the IP address in there.
I set the THINGENGINE_HOST_BASED_AUTHENTICATION env variable and cleaned the existing configuration to make sure, it did not change the problem.
I tried to change base_url in the Home Assistant config to the local IP (http://192.168.x.x:8123), which did break my telegram integration, but also didn't fix almond. I still get the "could not connect" message in Home Assistant logs.
I did not try to execute the run.sh script manually yet, I will have to get some sleep before I do that :sleeping_bed:
Thx for your help so far :+1:
grewhit25
commented
4 years ago Subscribing to this issue because I have the exact same problem as reported here regarding a locally hosted almond-server.
This message appears in the almond-server logs when home-assistant tries to connect.
GET /api/apps/list 403 3.793 ms - 30
grewhit25
commented
4 years ago Hi @markusressel , @gcampax
Here is a temporary workaround I am using until an official solution becomes available for connecting to almond-server on a remote host.
I have two hosts in my setup both are Raspberry Pi4s, but hardware shouldn't be an issue.
Host 1 - Home-Assistant running under docker. Host 2 - Almond-Server running under podman behind nginx proxy – docker not installed here.
Host 1 – config
configuration.yaml
almond:
type: local
host: http://<remote.server.ip>:3001Note: port 3001
Host 2 – config
Ubuntu 19.10 Eoan Ermine Official RPi 64bit image
almond-server 1.7.2
fuse-overlayfs
podman-composer version 0.1.6dev
podman version 1.6.2
pulseaudio
nginx (alpine) 1.17.6
/etc/hosts
<myserver.duckdns.org> <server.ip>
Note: nginx.conf is the same as utilised in the hassio configuration found here pretty much unmodified, except for the allow section which needs to match your network. Check nginx logs.
gcampax
commented
4 years ago Thanks @grewhit25 for sharing your nginx config! Not sure by the way what you mean by official solution. The preferred way to integrate Almond and Home Assistant is through Hass.io. Other than that, Almond is just a plain old webapp, and it's up to the user to configure it in their preferred way. If you like, I will be happy to include your nginx config in our documentation as a recommended way to do so. Note though, I am not sure about the authentication in this setting. As I understand from this config, auth in Almond is completely bypassed (using the default setting for host-based auth), and you rely on host-based auth to nginx. There are, I think, two challenges with this config: one, you cannot expose that nginx to the internet, in any form, or they will be able to access Almond. Two, you cannot run a browser anywhere on the same network, or webpages will also be able to access Almond. Hass.io ticks both boxes in this respect, as external access is behind Home Assistant authentication, and there is no browser running in the docker network. I just wanted to let you know of this caveat, in case your config is different.
grewhit25
commented
4 years ago Hi @gcampax thank you for your reply.
First off thanks for pointing out the pitfalls and challenges that this workaround brings, anyone considering this solution would need to proceed with caution.
I am interested in exploring almond’s capabilities locally, but have no plans to migrate to hass.io in the near future, so I guess my reference to an official solution was actually referring to an Almond integration into a non hass.io environment where Home-Assistant and Almond-Server could be on different hosts.
OAuth2 would be an option as mentioned in the documentation – but I believe that is currently disabled in the local server.
I would be happy for you to include the nginx.conf in your documentation as option with a clear warning of the security risks.
Great project btw.
markusressel
commented
4 years ago @grewhit25 Thx for providing a workaround, I could not get it to work on my system though. The error in home assistant is still the same:
Aborting import of Almond because we're unable to connectI am running version 0.103.4.
When browsing the NGINX site I can see and access almond like expected (this was also possible without the additional reverse proxy though). When I curl the NGINX proxy from the home assistant host I get a "good" response. Home Assistant still will not set up the almond component because of the error mentioned above.
I looked at the source code of Home Assistant and started debugging the lines that were causing the issue. After some digging I found this class in the pyalmond library:
class AlmondLocalAuth(AbstractAlmondAuth):
"""Base class for talking to a local Almond API."""
async def async_get_auth_headers(self) -> dict:
"""Get the request auth headers."""
return {"origin": "http://127.0.0.1:3000"}which is responsible for setting request headers made by the almond integration. This header seems to be the culprit on my setup. I checked this by temporarily removing this header from the library and (when debugging) it started to work. I was able to talk to almond via the Home Assistant conversations GUI. At this point the Home Assistant config was pointing directly to the almond host, no nginx reverse proxy involved like mentioned from @gcampax. Actually when I tried to use this setup I ran into Forbidden Cross Origin Request errors when trying to access http://192.168.2.20:3001/api/apps/list, which is the URL that home assistant tries to access on almond component setup.
So, whats the deal with this "origin": "http://127.0.0.1:3000" header? Why is it set and why does it work without it? Is it a really bad idea to omit this header? Does "local" necessitate the same host and therefore 127.0.0.1 is used as the hardcoded origin? Can/Should this be modified to allow different origin hosts?
grewhit25
commented
4 years ago @markusressel Sorry to hear that the workaround isn't working for you.
You just need to ensure that 'almond' and 'nginx' is attached to the host network.
Indeed you followed the same route I did to 'pyalmond' and you will also notice that the local almond server is rigidly fixed to the localhost at the moment.
So the purpose of the reverse-proxy in the workaround is to setup the header requirements including setting Origin "http://127.0.0.1:3000"
Here is a sample of my docker-compose:
Note that Home-Assistant is configured with port 3001 for local almond and that nginx takes care of the rest by listening for port 3001 on the remote server.
configuration.yaml
almond:
type: local
host: http://<remote.server.ip>:3001Hope this helps.
markusressel
commented
4 years ago @markusressel Sorry to hear that the workaround isn't working for you. You just need to ensure that 'almond' and 'nginx' is attached to the host network.
Well, not if there is no need for an NGINX at all, which would be my preferred solution.
Indeed you followed the same route I did to 'pyalmond' and you will also notice that the local almond server is rigidly fixed to the localhost at the moment. So the purpose of the reverse-proxy in the workaround is to setup the header requirements including setting Origin "http://127.0.0.1:3000"
Thx for the clarification. However, I would like to know (Probably from @gcampax) if this "localhost fixation" is really necessary. I understand the security implications of running almond on a local network without any authentication - thats on me to figure out a solution - but why is it fixed to a localhost origin if a different one works just fine? Is this supposed to help with the same security concerns or are there other aspects I am missing here?
Note that Home-Assistant is configured with port 3001 for local almond and that nginx takes care of the rest by listening for port 3001 on the remote server.
Thx again, I did check that but in the end it didn't work because of the "Cross Origin Requests" erros I mentioned above. Thats why I tried to get rid of the reverse proxy alltogether since it shouldn't be necessary for a "simple web app" running in a local environment anyway - at least thats what I expected - and it does, if it weren't for that hardcoded Origin header :smile:.
AlexKalopsia
commented
4 years ago I am having the same issue as the OP. My current setup is
My docker create code:
docker run -d \
--net=host \
--name=almond \
--restart=always \
-v /volume1/docker/almond/:/var/lib/almond-server \
-p 3000:3000 \
stanfordoval/almond-server:latest-portableI can't reach myip:3000, and the log is the same as the one in the open post.
Any idea what I can do?
brezlord
commented
4 years ago This issue is still a problem. You can not access the api on any other address but 127.0.0.1. Is this ever going to get fixed?
gcampax
commented
4 years ago Thanks for the reminder. This is not something we're actively working on at the moment, as the preferred integration methods (through the Home Assistant addon, or directly on the local network from the browser) are still working, and workarounds exist (basically replicating the home assistant configuration). At the same time, if you would like to contribute a fix, we would love it. I imagine a possible design for a solution involves directly generating API access tokens. This could happen perhaps on the user configuration page, similar to how almond-server's big brother almond-cloud operates. I don't imagine we'll integrate a full oauth2 stack, but that's another option.
markusressel
commented
4 years ago Generating API tokens surely would be great. However, I still do not understand the benefits of the current localhost lockdown. I consider my home network's security to be high enough to allow services to communicate over it. Otherwise I would have a big problem with my whole Home Assistant and device integration setup anyway.
A simple configuration option inside of the Home Assistant almond configuration to override the Origin required by pyalmond would fix the problem for users setting up almond locally and still keep a sane and safe default for the standard use case.
Again, if I am missing something crucial here that would compromise security to a large degree, I would really appreciate it to hear your thoughts on this.
gcampax
commented
4 years ago The Origin check is for your browser. Anything running on your local network without authentication and without Origin checks is vulnerable to you visiting a malicious page, and that page connecting to it. The browser will block some of it through Access-Control-Allow-Origin (CORS), but notably it will not block Web Sockets and it will not block POST requests (only the reply) - that's enough to do damage with the Almond API. Network level protection don't matter for this kind of attack, because the browser is in your network already. So any Origin override must be deployed very carefully, and with the appropriate check moved at a different level of the stack (such as nginx, as I suggested earlier).
Note that most things running on the local network do have some form of authentication, usually login/cookies or some access token. Home Assistant uses OAuth, for example.
grewhit25
commented
4 years ago Not sure if this is of use to you, but since the original post I have migrated my setup from Docker to Kubernetes. In this setup I had to implement the nginx solution as discussed previously.
The differenced here is that nginx runs as a sidecar in the almond-server deployment. You could give that method a try see if it helps, if you are interested in my setup and need more info pls let me know. Note though that I am not running docker, I use podman to generate any custom image like almond-server for example.
markusressel
commented
4 years ago @grewhit25 Thx, I did already know that it needs to be a sidecar for it to be available on localhost. You made me try again and after I found the new location of the nginx.conf you mentioned earlier, and applied it, it started to work. Home Assistant is able to connect to almond, that is running on a different host, inside a pod with two docker containers (almond and nginx).
However, when I try to use anything Home Assistant related I just get the message:
Me: turn off amplifier
Almond: Sorry, I did not understand that. You might need to enable a new skill before I understand that command.In the My Skills section a Home Assistant Gateway is present, showing the correct IP. For a test I removed this skill and restarted Home Assistant, which brought it right back (as expected). There is no error log in Home Assistant related to the query. I do not know how to check for log messages in Almond, but I guess there isn't one either. I tried to remove the conversation: section from my Home Assistant main configuration.yaml, but it did not help. I assumed that Almond would be able to import device from Home Assistant automatically, any suggestions?
gcampax
commented
4 years ago Almond logs on standard output and standard errors, so you'll find the Almond logs in the docker logs.
If your My Skill section contains Home Assistant but no other IoT skill, it means that either: (a) Almond cannot connect to Home Assistant to sync the list of devices (b) The Home Assistant entities you have are not supported. They must have a "device_class" field in Home Assistant, which is used to map to a skill in Thingpedia (in your case, speaker). Some of the less maintained HA integrations do not have that field.
Also, that message you see might occur when the natural language was not understood correctly, and it mapped to the wrong device. I don't think we have seen the work "amplifier" before (we trained around "speaker" mainly). I added that training sample though, so we're good now.
markusressel
commented
4 years ago Well, the "amplifier" is actually just a simple switch in Home Assistant, not a speaker. I will probably run into similar issues with other devices in my home that do not really fit into a class definition by name, but I'll figure that out later.
@gcampax Thx, the logs seemed to indicate that Almond is trying to contact Home Assistant on port 80, which is incorrect:
Added device io.home-assistant/http://192.168.2.12
Home Assistant: connection attempt 1/10
POST /api/devices/create 200 8338.038 ms - 208
Error on Home Assistant websocket: Error: connect ECONNREFUSED 192.168.2.12:80I convinced Almond to use a different port using the base_url config option in Home Assistant:
http:
server_host: 0.0.0.0
server_port: 8123
base_url: http://192.168.2.12:8123This did work, Almond was able to import entities from Home Assistant and - although with pretty confusing accuracy - was able to control Home Assistant entities from the Almond Webinterface Chat. It is not a permanent solution to set a local base_url though, since this interferes with other integrations like f.ex. the telegram one, that expects an externally reachable base_url. I guess I can just change it back once it has synced the entity data.
grewhit25
commented
4 years ago @markusressel Great to see you have got it working. I am not experiencing those websocket errors you refer to. The connection should automatically be upgrade if using the nginx config as is.
Note though that in Home-Assistant 0.110, base_url has been depreciated in favour of external_url and internal_url in .yaml configuration.
grewhit25
commented
4 years ago I'll take that back. Thought I'd do a refresh on almond and I am now seeing websocket related errors shortly after the device creation phase.
Error on Home Assistant websocket: Error [ERR_TLS_CERT_ALTNAME_INVALID]: Hostname/IP does not match certificate's altnames: IP: 192.168.yy.yy is not in the cert's list:Which now the error is referencing Home-Assistant host IP as appose to the FQDN. This also shows up on the HA skill which also refer to HA's host IP and not the FQDN as previous.
Skills which previously worked; like simply "turn off living room lamp" are met with "Sorry, I did not understand that"
I think the problem relates to the latest changes in Home-Assistant 0.110
grewhit25
commented
4 years ago I fixed the websocket issue by:
There must be a better way.
PiperMp3
commented
3 years ago Not sure if this is of use to you, but since the original post I have migrated my setup from Docker to Kubernetes. In this setup I had to implement the nginx solution as discussed previously.
The differenced here is that nginx runs as a sidecar in the almond-server deployment. You could give that method a try see if it helps, if you are interested in my setup and need more info pls let me know. Note though that I am not running docker, I use podman to generate any custom image like almond-server for example.
You still have a copy of the kube yaml? Running into this issue now on Kube
grewhit25
commented
3 years ago @PiperMp3 Sure thing. Here is my sample deployment that configures nginx as sidecar for local Almond Server.
Points to note: The deployment depends on the inclided configmap for nginx configuration For the service I used a NodePort (32000), which doubles as Home-Assistant almond port and user browser access. The allow statements in the nginx configmap server block may need updating to your requirements.
Hope this helps.
PiperMp3
commented
3 years ago Hi @grewhit25 ,
Just wanted to come back to you once I had a chance to test this and I can confirm this works fab in Kubernetes. I can tell you I only had to make very minor, insignificant changes to make this work in my usecase.
HA is connecting and using Almond just fine with this setup. Thank you kind sir!
gcampax
commented
3 years ago Great to hear that there is a configuration that works. Shall we close this issue then? @grewhit25 would you like to have your configuration hosted in the repo as documentation, in case people are looking for them in the future?
markusressel
commented
3 years ago It was over 6 months ago and I am not trying to be mean or anything, but it is really strange to me how it took dozens of comments in this thread about the hardcoded localhost header without a possible solution, and then some "random" guy creates a one-liner PR (#4), it gets merged immediately and the problem is gone... Don't get me wrong, I am glad that it is in and working, but we could have saved us a lot of time there :sweat_smile: Keep up the good work :+1: :heart:
grewhit25
commented
3 years ago @PiperMp3 You are welcome! Could you share your changes pls so that they can either be incorporated into the script or added to the documentation.
@gcampax I’d be happy for this sample to go into the documentation as a basic Kubernetes example. We probably need a review to catch any necessary changes making the deployment more generic in the process.
PiperMp3
commented
3 years ago Hi @grewhit25 ,
So in the nginx-sidecar-conf.yaml the ONLY change I made was I added an allow all; to the allowed list. This works in MY use-case, because its a LAN Microk8s cluster, sitting behind HAproxy with UFW protecting 3 Clusternodes.
I can therefore relatively safely do this, I do not recommend anyone does this without firewall protection.
In the almond-server-deployment-yaml, I removed ;
securityContext: allowPrivilegeEscalation: true capabilities: {} readOnlyRootFilesystem: false runAsGroup: 1001 runAsUser: 1001 seLinuxOptions: {}
- name: run-user-1001 mountPath: /run/pulse
And `- hostPath:
path: /run/user/1001/pulse
type: Directory
name: run-user-1001`^ As for why? Unsure, it refused to run and kept erroring with these in the deployment, could be a Microk8s thing.
Could be that Microk8s is running on Ubuntu, who knows. This worked in MY use case, and for others it may be better to keep these.
I then also adjusted;
- hostPath: path: /home/user/.config/almond-server type: Directory
to a path that actually exists on my hosts.
I didn't change namespace anywhere, as I deployed the config with kubectl apply -f config.yaml -n (namespacehere)
I use glusterFS to replicate a shared folder between the 3 Microk8s nodes, meaning all nodes have access to the same "hostpath" folders and files regardless of which node needs the data making Microk8s Highly Available.
So I changed this hostPath to a location within this shared glusterfs volume which then replicates to the rest of the nodes.
The home-system here is in this case HA.
grewhit25
commented
3 years ago @PiperMp3, thanks for your detailed reply. I forgot to mention that in my scenario; Pulseaudio runs in user mode hence the privilege escalation for that user and may explain the errors you were experiencing.
@gcampax, would you like to move forward with documenting this Kubernetes examples? I’m happy to contribute further.
gcampax
commented
3 years ago @gcampax, would you like to move forward with documenting this Kubernetes examples? I’m happy to contribute further.
Yeah I'd love. Would you like to make a PR adding the configuration files and editing the readme to document them? You can also add the documentation to our wiki if you prefer. We host installation instructions for Almond at https://wiki.almond.stanford.edu/user-guide/almond-server
gcampax
commented
3 years ago Additionally, would anyone in this issue have time to test this configuration with the master version of almond-server? We're preparing a new release soon, and it would be quite nice to ensure the configuration stays working!
As you all test, it would also be very helpful to try some commands in the Conversation view and check that they work. If you like, give us command-by-command feedback by clicking the up/down votes. You can click "save conversation log" if you find something doesn't work, and send it to us for analysis. Thanks!
grewhit25
commented
3 years ago Ok, I’ll look into raising a PR.
grewhit25
commented
3 years ago PR #167 created.
mathmaniac43
commented
3 years ago Hello,
I am struggling to get Almond to work myself. I am using docker-compose with Traefik as a reverse proxy, and am using self-signed certificates. I am able to access the server via HTTPS in the web browser as desired, but I am having an issue where the websocket connections for the conversation are empty. The webpage states Lost connection to the server (which I have found on several threads in both this repo and Home Assistant Core). The docker container's logs do not indicate a problem, and I do not know how to find more information about what is preventing the websocket from doing its thing.
version: "3.1"
networks:
frontend:
ipam:
config:
- subnet: "172.21.0.0/16"
backend:
ipam:
config:
- subnet: "172.22.0.0/16"
services:
traefik:
image: "traefik:v2.4.8"
container_name: "traefik"
networks:
- frontend
- backend
restart: "always"
command:
# Docker setup
- "--providers.docker=true"
- "--providers.docker.exposedbydefault=false"
- "--providers.file.directory=/configuration/"
- "--providers.file.watch=true"
# Entrypoints
- "--entrypoints.protocol-http.address=:80"
- "--entrypoints.protocol-https.address=:443"
# Global HTTP -> HTTPS Redirect
- "--entrypoints.protocol-http.http.redirections.entrypoint.to=protocol-https"
- "--entrypoints.protocol-http.http.redirections.entrypoint.scheme=https"
# Enable dashboard
- "--api.dashboard=true"
ports:
- "80:80" # http
- "443:443" # https
volumes:
- "/var/run/docker.sock:/var/run/docker.sock:ro"
- "/docker/certificates:/certificates:ro"
- "./dyn-traefik.toml:/configuration/dyn-traefik.toml:ro"
labels:
# Dashboard
- "traefik.enable=true"
- "traefik.http.routers.traefik.rule=Host(`traefik`, `traefik.justice.league`)"
- "traefik.http.routers.traefik.entrypoints=protocol-https"
- "traefik.http.routers.traefik.tls=true"
- "traefik.http.routers.traefik.service=api@internal"
almond:
image: "stanfordoval/almond-server:v2.0.1-portable"
container_name: "almond"
networks:
- backend
restart: "always"
environment:
THINGENGINE_BASE_URL: "https://almond.justice.league"
THINGENGINE_HAS_REVERSE_PROXY: "true"
THINGENGINE_HOST_BASED_AUTHENTICATION: "insecure"
expose:
- "3000" # expose http port via Traefik
volumes:
# These CA files allow the web server to work... was unable to "install"
# them by running commands, but this seems like it will do.
# https://github.com/gliderlabs/docker-alpine/issues/52#issuecomment-560946618
- "/docker/certificates/cert-auth.justice.league.public.crt:/etc/ssl/certs/ca-certificates.crt:ro"
- "/docker/certificates/cert-auth.justice.league.public.crt:/etc/ssl/cert.pem:ro"
- "/docker/almond-server:/var/lib/almond-server:rw"
labels:
- "traefik.enable=true"
- "traefik.http.routers.almond.rule=Host(`almond`, `almond.justice.league`)"
- "traefik.http.routers.almond.entrypoints=protocol-https"
- "traefik.http.routers.almond.tls=true"
- "traefik.http.services.almond.loadbalancer.server.port=3000"
# creating middleware for headers
- "traefik.http.middlewares.fix-headers.headers.accesscontrolallowmethods=POST,GET,PUT,OPTIONS,DELETE"
- "traefik.http.middlewares.fix-headers.headers.accesscontrolalloworigin=https://almond.justice.league"
- "traefik.http.middlewares.fix-headers.headers.accesscontrolallowheaders=x-requested-with,Content-Type,Authorization"
#- "traefik.http.middlewares.fix-headers.headers.customrequestheaders.host=127.0.0.1:3000"
#- "traefik.http.middlewares.fix-headers.headers.customrequestheaders.origin=http://127.0.0.1:3000"
# attach middleware to the headers router
- "traefik.http.routers.almond.middlewares=fix-headers"
# @todo I think I need to force it to look like it comes from 127.0.0.1? https://github.com/stanford-oval/almond-server/issues/37
Any advice or guidance would be much appreciated.
Hey there, great stuff!
I want to run almond and integrate it with Home Assistant. Afaik this does not require voice support on the almond server side. However when running the server without the
/run/pulsevolume mount I get the following output:How can I run the docker image without the need for the pulseaudio volume? Do I need to use
almond-server:latest-portablealthough I use linux?