owntracks / docker-recorder

Docker image for OwnTracks Recorder
151 stars 68 forks source link

Does not work from scratch #55

Closed alexkutsan closed 9 months ago

alexkutsan commented 2 years ago

Many unclear steps, and many points that just do not work.

How to setup eclipse-mosquitto

Setup eclipse-mosquitto in docker with authentification is not obvious part and should be described. Shortly is something like

  1. Create ./mosquitto/{data,logs,config} dirs.
  2. Create mosquitto.conf without authentification
  3. Run container with mapped volumes,
  4. Jump in to the container and run mosquitto_passwd /mosquitto/config/passwd USER
  5. Shutdown docker, add allow_anonymous false and password_file /mosquitto/config/passwd to mosquitto.conf
  6. Run docker, check the connection with MQTT explorer or another way.

I had to collect this information from all over the internet, and still think that this is huge overhead just for running authenticated mqtt broker (I will definitely forget it in several month)

Broken and not clear docker-composes

Why https://github.com/owntracks/docker-recorder/blob/master/docker-compose.yml contain 2 recorders? one is built from a Docker file, and another is just a used image? And ports forwarded only to one of them

Misunderstanding in ports that are used for otrecorder and mqtt (or broken compose). 8083 initially used for otrecorder web interface, but then https://github.com/owntracks/docker-recorder/blob/master/docker-compose-ssl.yml start using it for mqtt tls . 8083 forwarded to mqtt https://github.com/owntracks/docker-recorder/blob/master/docker-compose-ssl.yml#L74 service, but at the same time recorder request nginx to forward connection to this port https://github.com/owntracks/docker-recorder/blob/master/docker-compose-ssl.yml#L41

otrecorder does not listening to external connections

I had to add ot-recorder ${OTR_TOPIC} --http-host 0.0.0.0 in entrypoint.sh, to start listening for external connections and only after that owntracks-frontend works.

No frontend

Easy way to check that everything works is owntracks-frontend, but this is not mentioned in this repo at all.

No arm messages

RPI is the most popular hardware for such things.

My working configuration is

version: '3'

services:
  owntracks-frontend:
    container_name: owntracks-frontend
    image: alexkutsan/owntracks_frontend_arm
    restart: unless-stopped
    expose:
      - "80"
    ports:
      - 8888:80
    environment:
      - SERVER_HOST=otrecorder
      - SERVER_PORT=8083
    depends_on:
      - otrecorder

  otrecorder:
    build: ./docker-recorder
    ports:
      - 8083:8083
    depends_on:
      - mosquitto
    volumes:
      # - ./owntrack/config:/config
      - ./owntrack/store:/store
    restart: unless-stopped
    environment:
      OTR_HOST: mosquitto
      OTR_USER: alex
      OTR_PASS: ******************
      OTR_STORAGEDIR: /store

  mosquitto:
    image: eclipse-mosquitto
    ports:
      - 1883:1883
      # - 8883:8883
    volumes:
      -  data:/mosquitto/data
      - ./mosquitto/logs:/mosquitto/logs
      - ./mosquitto/config:/mosquitto/config
    restart: unless-stopped

But even within this configuration, I have to remember how to init OTR_USER/OTR_PASS. And how to set up a mobile app.

pchampio commented 2 years ago

related issues: https://github.com/owntracks/recorder/issues/387#issuecomment-1135660241 https://github.com/owntracks/docker-recorder/issues/54

Simple workaround:

  otr-recorder:
    image: owntracks/recorder
    entrypoint: ot-recorder --http-host 0.0.0.0 owntracks/#
    [.....]
futuretim commented 2 years ago

Wow, thank-you @alexkutsan for posting this issue and immediately confirming my issues (frontend not accessible). I was to the point where I was pulling down the source, building my container locally from source and just about to start prodding at the code. After all of this I was about to open this issue and say "the documentation makes it seem like this will work and despite all my best efforts, it doesn't".

I'm always suspect that I'm doing something wrong (a relative high degree of complexity getting the various things to all cooperate, MQTT, reverse-proxy, etc, etc.) and in this case I wasn't. Well, I should have looked for this 2 hours ago when my first couple of attempts failed.

Knowing this is really helpful. I think first things first, the web needs to be put in its own web service (who serves HTTP from C these days :smile: ??). I'll do that now.

jpmens commented 2 years ago

who serves HTTP from C these days ??

Unsure if this is supposed to be funny. If it isn't, you might wish to glance at the source code of all of the world's largest HTTP servers.

jpmens commented 2 years ago

@alexkutsan we're somewhat touchy when people write "should be described".

I'm fully aware that the documentation and possibly lots of other things are lacking, and we don't do this on purpose. If you think you can contribute good documentation, I'll be the first to say "thank you".

futuretim commented 2 years ago

who serves HTTP from C these days ??

Unsure if this is supposed to be funny. If it isn't, you might wish to glance at the source code of all of the world's largest HTTP servers.

It was intended as a somewhat of a joke. I am well aware of any point you might be making with respect to all of the world's largest HTTP servers however I would say there's a large distinction between using an HTTP server written in C and serving static resources yourself with a custom built HTTP server.

Having said all of that I definitely don't want to devolve into anything and I certainly meant no disrespect. So I will issue my sincere apology and move on (not from the project per se but from the ill-conceived joke).

jpmens commented 2 years ago

Thanks for clarifying. :-)

jpmens commented 9 months ago

Understood, and we've now done this, however sans docker. We hope our quicksetup will very greatly assist people who don't spend their whole day in front of a command line. :-)

Feedback is appreciated at the quicksetup repo.