i8beef / HomeAutio.Mqtt.GoogleHome

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Question about running as a standalone application without Docker

glsf91 opened this issue · comments

I saw I can run this app also as a standalone application by using the precompiled releases. I know I can use docker but I don't have Docker running on the target system (and not planned to do this).

I want to use this on Ubuntu 18.04.5 LTS.
But for which OS are these precompiled releases ?
And will it be enough to install the .NET Core and ASP.NET Core runtimes or are is the .Net framework already included?
(and of course reverse proxy)

Default compile targets are Windows based, meaning it has an EXE in it... Im not actually sure if you can download that and run dotnet HomeAuto.Mqtt.GoogleHome.dll if it'll run or not... you can try it, just keep in mind that it (a) isn't the way I suggest running this and all my knowledge and support is built around you running it in Docker, and (b) even if you get it running you still have to setup a proxy, etc.

Thanks.
I managed to compile this on Linux and I can start the program. But I got a lot of warnings when compiling.
An example:
Quickstart/Grants/GrantsViewModel.cs(25,1): warning SA1516: Elements must be separated by blank line [/home/john/HomeAutio.Mqtt.GoogleHome/src/HomeAutio.Mqtt.GoogleHome/HomeAutio.Mqtt.GoogleHome.csproj]

Do you also have a lot of warning when compiling ?

If you leave this issue open for a while, I will add the commands I used, First try to get it up and running with google.

Yes, those are just the static analysis running against the IdentityServer4 templates. I choose to ignore them rather than attempt to fix those templates as they are managed by someone else, and I always want to be able to re-clone them for upgrades. All of the warnings for MY code are cleaned up, and unfortunately there isn't a good way that I've found to isolate those external templates so the static analysis doesn't run against them. They can be safely ignored.

I got everything up and running when using / (so not google/home) in the reverse proxy. I am using apache as a reverse proxy.
But I want to use /google/home instead of / .
So I changed

    ProxyPass /  http://localhost:5000/
    ProxyPassReverse /  http://localhost:5000/

to

    ProxyPass /google/home/  http://localhost:5000/
    ProxyPassReverse /google/home/  http://localhost:5000/

Of course I also added /google/home to the urls in Google and also changed:
"authority": "https:///google/home",

I unlinked in google home, throw away tokens.json and try to link again.
But in google home I'am redirected to https://Account/Login?ReturnUrl= instead of https://google/home/Account/Login?ReturnUrl=
And of course this is not working.

In the access log I see

[01/Nov/2020:18:31:49 +0100] "GET /google/home/connect/authorize?redirect_uri=
[01/Nov/2020:18:31:50 +0100] "GET /Account/Login?ReturnUrl=

Same happens if I try to go to https:///google/home/ on my desktop pc browser. I got also redirected to https:///Account/Login?ReturnUrl=%2F

Any idea what goes wrong?

Ensure that you are passing the X-Forward headers correctly: https://github.com/i8beef/HomeAutio.Mqtt.GoogleHome/wiki/Setup:-Proxy

I do not have an example for Apache for this, though if you get it, I actually wouldn't mind adding it to the docs as its not exactly an uncommon proxy choice.

Also, you will need to make sure the environment variable "ASPNETCORE_PATHBASE" is set. In Docker you'd do this when starting the container with -e ASPNETCORE_PATHBASE="/google/home"... As I think about how that might seem out of place in your case here, I wonder if the original direction I had for this might have been misguided, and this should have just been in the config file though. I was under the impression it had to be an environment variable because the rest of the .NET Core framework picked it up, but Im not finding evidence for that, and I think I could have just as easily sourced this from config... Might be something I'll change in the future.

I pass the headers correct. Checked with tcpdump.
Using ASPNETCORE_PATHBASE is not working in my case. Also see on google a lot of trouble and confusing with this. So indeed better when it is in the config.
For now I put it back to / instead of /google/home/. Now everything is working again, including state.

I have to say, the instructions are a little cryptic. Google stuff is changed, not always matching. Also Homegraph stuff is missing. There is a link but not talking about apikey (also not in your table). A took me a while to discover agentUserId can be anything you want (I hope). Maybe you can add this to the description.
Luckily I have done this before, but even then it was searching a lot.
Don't take this to hard :-)

But you have made great software. I will take a better look later on.

Compiling for my case was easy:
Install dotNet: https://docs.microsoft.com/en-us/dotnet/core/install/linux-ubuntu

I did this in my home directory:
git clone https://github.com/i8beef/HomeAutio.Mqtt.GoogleHome.git
Made also directory xx and then:
dotnet publish /home/john/HomeAutio.Mqtt.GoogleHome/src -c Release -r linux-x64 -f netcoreapp3.1 -o /home/john/xx/HomeAutio.Mqtt.GoogleHome
This is a self containing release. I moved it to another Linux server where you can run it without dotNet installed.
More information: https://docs.microsoft.com/en-us/dotnet/core/deploying/#publish-framework-dependent
If you don't want selfcontained:
dotnet publish /home/john/HomeAutio.Mqtt.GoogleHome/src -c Release -r linux-x64 -f netcoreapp3.1 -o /home/john/xx/HomeAutio.Mqtt.GoogleHome -self-contained false

Go to /home/john/xx/HomeAutio.Mqtt.GoogleHome and make the configuration as described.
You can start it (for now) with: ./HomeAutio.Mqtt.GoogleHome
Starting after system restart needs to be done of course.

ASPNETCORE_PATHBASE would need to be set as an ENVIRONMENT VARIABLE active for the user that is running the command, not sure if you caught that its NOT a command line parameter. I'll probably change this to a config value in the next release though, as it would also simplify the Docker commands and some confusion around that since its basically the only ENV based config this app needs so its out of place.

I am completely open to suggestions on documentation changes. Google is... not the best... at communication about changes, so I kind of rely on new setups like yours to point out new variations I need to correct for.

The sections about maintaining "test mode" for instance probably aren't needed anymore, as that was mostly a hack for Google's less than obvious setup instructions. There's a note there its "optional" now, but frankly I just maintained the docs as a "just in case" someone found it IS still necessary in some case.

Yes I used ASPNETCORE_PATHBASE as a environment variable, without success. I did:
export ASPNETCORE_PATHBASE="/google/home"

edit: now I see it is an environment variable in your program. Thought it was something dotNet thing.
Maybe an idea to log this setting. It will be easier to see if it is picked up.

Is it also possible to see the body of the requests which are received or sent?
I'm interested in the message which is sent for the state update to debug something. With Verbose I see the headers but not the body.

Hm weird that should work for the environment var. I don't usually run this from a Linux environment directly (only via Docker), so maybe there's a trick to it.

There isn't a DIRECT way besides debugging to see the response, and Google's log access is basically useless. If you log into the app you can export the SYNC response, but not individual QUERY / COMMAND responses. Could be a useful ask though for "debug logging" capabilities here... I'll consider it.

Note, the 1.3.x version tree now supports setting the ASPNETCORE_PATHBASE env variable via config setting instead, which eliminates that necessity. See #103

Thanks. I will try config setting later when I have more time. I'am now running on /