Snap packaging

[mz2]

trafficstars

Adds strictly confined snap packaging of ollama-webui for x86-64 as an alternative to docker & k8s, presently published on the channel latest/beta (sudo snap install ollama-webui --beta).

This is proposed as a nice alternative to docker (no need to install and configure the nvidia docker runtime for example, systemd service is set up automatically, over-the-air updates, straightforward to access resources and data from user's host system within the limits of the application's confinement) and safer of course than bare installation onto host system.

Installable with:

sudo snap install ollama --channel beta # or ollama installed any other method, or on another host
sudo snap install ollama-webui --channel beta

As you might guess from above I also packaged up ollama as a snap (this snapped version of ollama-webui does not require it, demonstrating this mostly just to note the ease of installing both).

• strict confinement used with network, network-bind, home, removable-media, opengl interfaces in use, i.e. it can access and serve a port, access home directory and /media, and access the GPU (the opengl interface also grants access to CUDA etc).
• starts up a systemd service automatically for the service.
• if removable media access is needed (e.g. user prefers storing data under a disk mounted under /media), sudo snap connect ollama:removable-media achieves that (for security reasons, removable media access not granted without user action).

If this looks interesting, I'm happy to hand over the package on snapcraft.io to a maintainer, and can contribute CI integration to make it easy to keep the snap package up to date whenever you release.

If you want to build this locally, after installing snapcraft and either the multipass or LXD provider for it go to the root directory of the repository, and ...:

snapcraft

Configuration

Offers the following configuration keys and default values, configurable with sudo snap set ollama-webui key=value:

• data-dir: /var/snap/ollama-webui/common/data
• enable-signup: true
• host: 0.0.0.0
• ollama-api-base-url: http://localhost:11434/api
• openai-api-base-url: https://api.openai.com/v1
• openai-api-key: (blank)
• port: 8080
• secret-key (randomized)

[tjbck]

Amazing stuff, Thanks for the hard work! We're planning on changing our name as per Ollama team's request, so let's wait until we decide on our new name before we merge this!

[mz2]

Thanks! I'll keep improving it meanwhile: I am going to add the support for this package pulling the ollama snap as a dependency through the "content" interface, also to allow making it possible to download models via the frontend to ollama.

[mz2]

I updated this PR now with latest changes from main, including updating the name of the package, and published an initial revision to https://snapcraft.io/open-webui on the beta channel (sudo snap install open-webui --beta).

On doing so I hit a security check with the new transient dependency libctranslate2 (that dynamic library is built with an executable stack -- curious to learn if that will have been intentional or a mistake?)

In my own testing I have been able to use the regular chat functionality with text input just fine, but I hit an issue with the document upload / RAG functionality: on attempting to upload a document I experience a 500 status code from the server but am not clear how I would be able to debug this further short of starting to add debug log statements, track trace output in myself. Am I missing a debug facility I should just turn on?

[justinh-rahb]

I updated this PR now with latest changes from main, including updating the name of the package, and published an initial revision to https://snapcraft.io/open-webui on the beta channel (sudo snap install open-webui --beta).

On doing so I hit a security check with the new transient dependency libctranslate2 (that dynamic library is built with an executable stack -- curious to learn if that will have been intentional or a mistake?)

In my own testing I have been able to use the regular chat functionality with text input just fine, but I hit an issue with the document upload / RAG functionality: on attempting to upload a document I experience a 500 status code from the server but am not clear how I would be able to debug this further short of starting to add debug log statements, track trace output in myself. Am I missing a debug facility I should just turn on?

That libctranslate2 needs some more explanation, not sure that I understand. Which package depends on it? If there's something we can do about it, by all means let's get another issue/PR for that going.

As for debugging, I don't think you've missed anything. We really need some more debug log statements, and a DEBUG=true variable to activate it.

[mz2]

Thanks! I'll keep improving it meanwhile: I am going to add the support for this package pulling the ollama snap as a dependency through the "content" interface, also to allow making it possible to download models via the frontend to ollama.

I had second thoughts about this after stating this: it's not necessarily a good idea to add this dependency from open-webui => ollama snap via a content interfacce because a user may a) not care for ollama, or choose to get it from another source, not necessarily the snap (build from source, use a Dockerfile exposed to the host system etc).

[mz2]

That libctranslate2 needs some more explanation, not sure that I understand. Which package depends on it? If there's something we can do about it, by all means let's get another issue/PR for that going.

It's a dependency of one of the ML frameworks included in open-webui. I've understood that an executable call stack in a dynamic library is in most cases an accident (the reason that the snap store automatically validates against it is that it is a security hole), and appears to indeed be an accidental command line flag in that dependency library build since with cleaning up that exec stack bit out in the snapped open-webui, the app works without it set. I can try to dig into that some more at some point, I think it should be fine to keep the processing of that library in place.

As for debugging, I don't think you've missed anything. We really need some more debug log statements, and a DEBUG=true variable to activate it.

This seemed to have improved since I opened the PR :smile: I got the file upload (and RAG support for documents and websites, both of which I've successfully been using past weeks) feature fixed thanks to some added debug logging that made it clear that the data directory was not getting configured quite right inside the app's sandbox (I was my bad, got fixed by updating the hooks and launcher provided inside the snap).

[mz2]

I've updated the branch now against the current dev branch, which actually simplified things: the introduction of the configurable $HOST is the only change (beside what's under the snap directory). If you're happy with this contribution, I'd propose introducing in a follow-up branch a GitHub workflow based automation that would automatically build the snap and publish to the store (at that point it would be best to get the snap ownership to yourselves in the upstream project). I can come chat on Discord about all this if you like.

Also, a fresh update (revision 7) is working its way through the snap store processing that reflects the current HEAD of this branch. To accelerate snapd picking up the update when it's made available in the next < 30mins, you can do sudo snap refresh open-webui --channel beta (... or it will be delivered automatically during the next day).

[justinh-rahb]

Hi @mz2 I didn't mean to leave this unreviewed for so long. I'd like to chat with Tim first about adopting this under our umbrella, you're more than welcome to join us in Discord! https://discord.gg/5rJgQTnV4s