Describe the bug Error getting initial buttons is displayed when opening the web ui. TypeError: NetworkError when attempting to fetch resource.

To Reproduce Build with docker-compose

version: "2.1"
services:
  airsonic:
    image: jamesread/olivetin
    container_name: olivetin
    restart: unless-stopped
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=America/
    volumes:
      - /olivetin:/config
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.olivetin.rule=Host(`olivetin.example.com`)"
      - "traefik.http.routers.olivetin.entrypoints=websecure"
      - "traefik.http.routers.olivetin.tls=true"
      # Uncomment to fetch Let's Encrypt certificates.
      # Make sure you set up DNS records and they point to your IP.
      - "traefik.http.routers.olivetin.tls.certresolver=letsencrypt"

networks:
  default:
    external:
      name: traefik_default

Expected behavior Page should launch with 1 button as per the config.yaml

Screenshots

Trying to run the current OliveTin_2021-11-19_linux_armv7.deb on an older Pi Zero W with Debian Stretch doesn't work and just returns an "Illegal instruction" message. The last releases which worked where the older armv6 packages.

So I went ahead and built from source which does produce a working binary. What I do miss is a make target or something to turn this into a .deb package, though?

Also, manually copying the new OliveTin binary over an old installation lets me start the server, but then returns a "TypeError: json.actions is undefined" on the web UI. This runs with an existing config.yaml, but I don't see any breaking changes there which would explain that message.

Describe the bug When trying to install docker inside olivetin it is not possible due to lack of superuser permissions.

To Reproduce

1. Install olivetin using dockerfile
2. Perform additional steps for docker. (Tweaked the dockerfile instead)
3. run docker exec -it olivetin dnf install -y docker Error: This command has to be run with superuser privileges (under the root user on most systems). or
4. run docker exec -it olivetin sudo dnf install -y docker [sudo] password for olivetin:

Expected behavior Should install docker

Additional context

dockerfile
---
version: "2.1"
services:
  olivetin:
    container_name: olivetin
    image: jamesread/olivetin 

    volumes:
      - /srv/dev-disk-by-uuid-d2287285-5827-439a-bc32-7c8ad314eacf/Config/OliveTin:/config:ro
      - /var/run/docker.sock:/var/run/docker.sock
    ports:
      - "1337:1337"
    restart: unless-stopped

Running inside Portainer 2.6.1 on Openmediavault 5.6.7-1

$ uname -a
Linux rockpi 5.10.35-rockchip64 #21.05.1 SMP PREEMPT Fri May 7 13:53:11 UTC 2021 aarch64 GNU/Linux

Suggestion: If you don't want to run the container as root, what about adding something like olivetin ALL=(ALL) /usr/bin/dnf in /etc/sudoers?

Is your feature request related to a problem? Please describe. For non tech. people to provide as few buttons as possible.

Describe the solution you'd like It would be nice to disable the "Actions" and "Logs" buttons on the top of the page to make it as clean as possible. In config.yaml something like navigation: disable.

Additional context I equipped my parents in law with a raspberry running kodi. Every now and then kodi hangs and the only option for them on their own is to power cycle the pi. The more elegant solution would be to just restart the service, for which I haven't found an elegant solution for non technical people until I stumbled upon OliveTin. This will be a website-link on their phones open the site with only one button "Restart Kodi".

Hi, your project looks really promising and would be very useful for lots of people running SBCs as servers. However at the moment there is no docker image for these platforms. If you could create one that would be awesome!

It would be nice to trigger a task with a arguments, such a light brightness, custom timeouts, or similar.

Describe the solution you'd like Available to be set on a per action basis, the ability to specify a couple of arguments.

There are considerable security implications of doing this though - you're basically giving free SSH access to a server if the arguments are abused.

Additional context Originally requested by Luca Heitmann here; https://youtu.be/Ej6NM9rmZtk

Current status

• [x] Get the UI to send these values back to the server when starting the action
• [x] Find/Replace variable names (ie, actually use them) on exec
• [x] Fix behavior for undefined variables, unused variables, etc
• [x] A type system for variables, with several safe/unsafe helpers (ie string_identifier, string_raw_unsafe)
• [x] Code audit for style, cyclo, fmt, etc.
• [ ] Test the hell out of it

Feedback

Feedback is most welcome, even if it's just a :+1: on this comment to indicate you're interested in the feature.

As per the documentation on how to set up multiple instances, I'd like to suggest the addition of a feature that could make the process even simpler: a flag (tentatively called config, but the name is irrelevant) that allows to specify the location of the config.yaml when this is not in the default directory.

For example, in order to create a second OliveTin instance, all I'd have to do would be to place a second config.yaml in /home/myuser/OliveTin2, and then call the executable located in /usr/local/bin/OliveTin with this service file:

[Unit]
Description=OliveTin2

[Service]
ExecStart=/usr/local/bin/OliveTin --config /home/myuser/OliveTin2/config.yaml
Restart=always

[Install]
WantedBy=multi-user.target

This differs from the method in the documentation in that it doesn't need to use a different copy of the executable for each instance, as it can use one executable for all instances; including the one installed in the default location by the .deb/.rpm installer.

It'd also allow to give the config.yaml any name, which would make possible to have multiple configuration files in the same directory (for example, I could have /home/myuser/OliveTin_configs with files called config2.yaml, config3.yaml, etc.).

And even though it's possible to do something similar simply by specifying a WorkingDirectory in the service file, this is a more cross-OS method. For example, if I was using Windows, I could make a shortcut that called the executable this way:

C:\Program Files\OliveTin\OliveTin.exe --config C:\Users\MyUser\OliveTin2\config.yaml

Or it could be used for distros that don't use systemd, or if for some reason I can't or don't want to use a service file; for example, if I'm running it on a machine where I don't have root permissions (the latter could be paired with a webUIDirectory option in the config.yaml that similarly allows to choose a different location for the web files, but that's independent from this suggestion).

Is your feature request related to a problem? Please describe.

Apple devices rely on a separate metadata description for "touch icons".

https://lynk.icu/F79pi

Originally requested by ScrumpyJack on discord.

Is your feature request related to a problem? Please describe. Don't include version name in releases. Tag based release identifiers make it easy to curl latest package in a script

Describe the solution you'd like Rather than release named OliveTin_2022-04-07_linux_amd64.deb, it should be OliveTin_linux_amd64.deb

Additional context Follow a standard naming convention for release names since tags serve as release number. For practical representation, refer to Adguard Home's release page

Cool app. Excited to see where it goes.

My request is to document the API so other users can easily integrate with 3rd party apps, For example, I'm using it in combination with HTTP Request Shortcuts so I can place OliveTin actions right on my homescreen.

Current API seems simple enough. Actions can be triggered by POSTing to http://<HOST>/api/StartAction with the following request

{"actionName":"Start transmission-daemon","arguments":[]}

Interaction with the bash script All is good with 'fire and forget' actions with no parameter. There are other very interesting scenarios which require some form of interaction. Can we use OliveTin in those cases?

My OliveTin is OliveTin_2021-07-19_linux_amd64.deb, running in ubuntu 20.04 My script is of the type 'sudo bashcommand', how do I send the user's password? The action complete without errors but the log show nothing. Can I find docs for this type of script?

More generally, how do I allow a script to accept user input and continue processing? I have scripts which require input from user in the middle of processing: can I interact with the script in some way?

Thank you for your help

Bumps json5 from 1.0.1 to 1.0.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

https://github.com/OliveTin/OliveTin/blob/244404afbc2fcd854476997370cde923ee54e207/internal/config/config.go#L93

The "update check" is enabled by default. This misleadingly named surveillance feature will phone home to the developers of the software at http://update-check.olivetin.app:

https://github.com/OliveTin/OliveTin/blob/49cb2e5c0a5e64abe45b87f2470ef2605e5b2596/internal/updatecheck/updateCheck.go#L109

It's not just checking for updates. It sends to the server personally identifying information (PII), something called an "installation ID", which persists between launches:

https://github.com/OliveTin/OliveTin/blob/49cb2e5c0a5e64abe45b87f2470ef2605e5b2596/internal/updatecheck/updateCheck.go#L32

This network-based surveillance is not disclosed to the user and happens without first obtaining consent from the user. The user's PII is transmitted automatically.

Is your feature request related to a problem? Please describe. OliveTin doesn't always include the executables I'd like to run.

Describe the solution you'd like I'd really like the ability to automatically run scripts when OliveTin is started, sort of like how the LinuxServer containers have implemented. This would allow me to install executables within the container each time it's rebuilt.

I used this with another Docker image I used up until recently - I needed some additional stuff installed, so I wrote a small script to install the extras each time the container was rebuilt.

Describe alternatives you've considered For now, I can do this manually, or script it myself when building the container.

Additional context #89 made me think of this - instead of having to include docker compose in the image, it'd be really great if I could just install it myself, automatically, each time the container is built. This would keep the image small and free of additional security issues, depending on what users might want to have installed.

Thanks!

I really appreciate that docker is pre-installed in the images. It would be even better, if the docker compose plugin was installed as well.

This would allow simple compose based services to be restarted etc.. i.e. shell: docker compose up -d

Based on the official docker docs this works:

mkdir -p /usr/local/lib/docker/cli-plugins
curl -SL https://github.com/docker/compose/releases/latest/download/docker-compose-linux-x86_64 \
 -o /usr/local/lib/docker/cli-plugins/docker-compose
chmod +x /usr/local/lib/docker/cli-plugins/docker-compose

This could be added to the RUN "install"command in the Dockerfiles.

This issue will track it.

• [ ] Check Arch
• [ ] Check the download script
• [ ] Check docs pages
• [ ] Check name of folder in tar.gz and zip
• [ ] Check release notes template