mcguirepr89 / BirdNET-Pi

A realtime acoustic bird classification system for the Raspberry Pi 4B, 3B+, and 0W2 built on the TFLite version of BirdNET.
Other
1.29k stars 138 forks source link

BirdNET-Pi behind a reverse proxy? #91

Closed Svardsten53 closed 2 years ago

Svardsten53 commented 2 years ago

Is it possible to disable or bypass the .local function? I guess this is the cause of the problem I have. I have several other web servers in my network and therefore use reverse proxy in my Synology NAS to direct calls from the Internet correctly, because in the router you can only control calls on one port to a specific server. This function requires that you enter an IP address and port number on the local network, a regular URL is not accepted. I have tried to enter both IP address and regular URL in the BirdNET-Pi configuration, but nothing works. So what I want is for the web server to respond to the local IP address instead of birdnetpi.local. I hope there is a solution to this.

mcguirepr89 commented 2 years ago

So what I want is for the web server to respond to the local IP address instead of birdnetpi.local. I hope there is a solution to this.

Hello, @Svardsten53 and thank you so much for you interest in BirdNET-Pi and for your great question. I actually was just helping another user with a similar scenario to allow for several BirdNET-Pis on the same local network. Please take a look through that conversation if you'd like to see how that worked out, though that is just for reference and not me pointing you elsewhere :)

Is it possible to disable or bypass the .local function? I guess this is the cause of the problem

BirdNET-Pi's announce themselves on the network via an avahi-alias for "birdnetpi.local" that allow mDNS allowed networks to find it easily. It can easily be disabled by issuing sudo systemctl disable --now avahi-alias@birdnetpi.local.service. With that said, however, that's not really going to be causing any issues and can safely be left alone.

The "problem" is actually a great security feature of Caddy's wherein caddy only listens and responds to its site-blocks and ignores requests to the underlying host's open ports when the requests don't match the site block. This means we just need to tell Caddy that is should listen for requests to the host's local IP. The birdnet.conf file is the place to set this, and you were SO close to having this resolved yourself.

I have tried to enter both IP address and regular URL in the BirdNET-Pi configuration, but nothing works.

It seems you came quite close to the solution and had precisely the right idea on how to achieve what you need, with one crucial step missing: updating BirdNET-Pi after altering the birdnet.conf file. After you edit the custom URL section of birdnet.conf to resemble my example below:

BIRDNETPI_URL=http://192.168.1.41
EXTRACTIONLOG_URL=
BIRDNETLOG_URL=

then issue update_birdnet.sh in the command line to reconfigure BirdNET-Pi to respond to the local IP address instead of birdnetpi.local.

Be sure to clear your web browser's cache so that it does not load old, broken links.

Please let me know how this works for you and if you have further questions or would like any further assistance as I am more than happy to help!

My best regards, Patrick

Svardsten53 commented 2 years ago

Patrick, thanks for your quick reply. I'm much closer the solution now I hope. I have managed to reach the BirdNET-Pi web server on the local network by typing the IP address 192.168.0.106 in the browser.

I have still problem when typing the URL which is defined in the reversed proxy to port 80 on the Pi, the only thing I get is a white page. The strange thing is if i point the proxy to port 8000 I can see the Icecast2 status page. I have not modified anything in the .local settings. Update is done after every change.

Settings in config file:

BIRDNETPI_URL=http://192.168.0.106
EXTRACTIONLOG_URL=
BIRDNETLOG_URL=

The caddy file looks like this:

http://localhost http://birdnetpi.local http://192.168.0.106 {
  root * /home/pi/BirdSongs/Extracted
  file_server browse
  basicauth /Processed* {
    birdnet xxx
  }
  basicauth /scripts* {
    birdnet xxx
  }
  basicauth /stream {
    birdnet xxx
  }
  basicauth /phpsysinfo* {
    birdnet xxx
  }
  reverse_proxy /stream localhost:8000
  php_fastcgi unix//run/php/php7.3-fpm.sock
}

The caddy log from the last update:

dec 05 19:52:55 birdnetpi systemd[1]: Reloading Caddy.
dec 05 19:52:55 birdnetpi caddy[6717]: {"level":"info","ts":1638730375.1315625,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":""}
dec 05 19:52:55 birdnetpi caddy[6717]: {"level":"warn","ts":1638730375.1362822,"msg":"input is not formatted with 'caddy fmt'","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":2}
dec 05 19:52:55 birdnetpi caddy[630]: {"level":"info","ts":1638730375.1513507,"logger":"admin.api","msg":"received request","method":"POST","host":"localhost:2019","uri":"/load","remote_addr":"127.0.0.1:41944","headers":{"Accept-Encoding":["gzip"],"Content-Length":["2136"],"Content-Type":["application/json"],"Origin":["localhost:2019"],"User-Agent":["Go-http-client/1.1"]}}
dec 05 19:52:55 birdnetpi caddy[630]: {"level":"info","ts":1638730375.1541495,"logger":"admin","msg":"admin endpoint started","address":"tcp/localhost:2019","enforce_origin":false,"origins":["localhost:2019","[::1]:2019","127.0.0.1:2019"]}
dec 05 19:52:55 birdnetpi caddy[630]: {"level":"info","ts":1638730375.154579,"logger":"http","msg":"server is listening only on the HTTP port, so no automatic HTTPS will be applied to this server","server_name":"srv0","http_port":80}
dec 05 19:52:55 birdnetpi caddy[630]: {"level":"info","ts":1638730375.15463,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0x4000224b60"}
dec 05 19:53:05 birdnetpi caddy[630]: {"level":"info","ts":1638730385.152588,"logger":"tls.cache.maintenance","msg":"stopped background certificate maintenance","cache":"0x400019e620"}
dec 05 19:53:05 birdnetpi caddy[630]: {"level":"info","ts":1638730385.1531591,"msg":"autosaved config (load with --resume flag)","file":"/var/lib/caddy/.config/caddy/autosave.json"}
dec 05 19:53:05 birdnetpi caddy[630]: {"level":"error","ts":1638730385.1545076,"logger":"admin","msg":"stopping current admin endpoint","error":"shutting down admin server: context deadline exceeded"}
dec 05 19:53:05 birdnetpi caddy[630]: {"level":"info","ts":1638730385.1545749,"logger":"admin.api","msg":"load complete"}
dec 05 19:53:05 birdnetpi systemd[1]: Reloaded Caddy.
mcguirepr89 commented 2 years ago

Hello again!

I have still problem when typing the URL which is defined in the reversed proxy to port 80 on the Pi, the only thing I get is a white page.

This bit seems to point to the remaining issue, which is again tied to the aforementioned Caddy listening rules wherein it will only respond to requests that match its site-block definitions. This means that you'll need to add whatever URL is defined in your reverse proxy to the Caddyfile's main site-block. Also, you will want to change your CADDY_PWD since it was posted here (though it was hashed, it was not encrypted -- I did however, remove the original comment with the password).

  1. You can change the password easily by changing it in birdnet.conf and running another update, either through the command update_birdnet.sh or through the web-interface's "System Links" --> "Tools" --> "Update BirdNET-Pi".

  2. After the update, you will want to manually edit /etc/caddy/Caddyfile to look something like this::

    http://localhost http://birdnetpi.local http://192.168.0.106 http://WHATEVERISDEFINEDINYOURREVERSE.proxy {
    root * /home/pi/BirdSongs/Extracted
    file_server browse
    basicauth /Processed* {
    birdnet xxx
    }
    basicauth /scripts* {
     birdnet xxx
    }
    basicauth /stream {
     birdnet xxx
    }
    basicauth /phpsysinfo* {
    birdnet xxx
    }
    reverse_proxy /stream localhost:8000
    php_fastcgi unix//run/php/php7.3-fpm.sock
    }
  3. Then you would reload caddy and try again. The command below will reload caddy and then will "follow" the caddy log :

    sudo systemctl reload caddy && journalctl -fu caddy

    (Ctrl+c to quit)

I suspect that will work, but without knowing more specifics (that you should not post here) about how you're trying to route the traffic, and more specifically, what the request headers contain, I can only say that is my best guess as to what will work. Unfortunately, the caddy logs you've provided only show a successful caddy reload, which is a good thing and indicates that there are no issues on Caddy's end, but doesn't contain any requests/responses.

If you'd like more help, please consider emailing me privately so as not to share sensitive networking information here.

My fingers are crossed for you and I hope it works 👍