It’s iirc OpenSuse. They also use the RPM format, so no worries 
1 Like
So finally at least on my fedora test machine, it installed successfully.
For now I provide the image here:
https://hub.docker.com/r/sheogorath/test-repo/
To test it you can setup a machine with the docker repository and then use the same commands as in the readme, just replace https://sisheogorath.github.io/bitwarden-rpm-deb-mirror/ with the container URL.
Of course this is just a PoC and I wouldn’t use this key any further. So if you want to make it part of the bitwarden world, please generate an own key to sign the things.
Also we should consider to:
- Use the version number in the repo .rpm and .deb file
- Provide the last two or three versions, so if something is not working people can still downgrade
Actually yes… That or AppImage and Flatpacks will be enough for running anywhere. Without having to keep legacy repositories around.
1 Like
In this case you just replace .rpm and .deb with snap, flatpak and appimages… This doesn’t make anything easier, just different.
And with things like flatpak you run into problems like missing ibus support on electron apps, …
They are nice ideas and they will evolve but they are not bullet proven yet and still have a lot of papercut issues. Can’t say too much about snap, but I guess you run into similar problems.
And all in all, it doesn’t matter too much, as in case of bitwarden it’s just a directory which is thrown into /opt and (in most cases) just works. You run more or less in as many issues with this method as you run with snap, flatpak, …
So all in all, what do we win?
PS: Don’t get me wrong, snap, flatpak and appimages are a nice idea and will become more popular in future, but for now we already have .deb and .rpm packages, so why not use them?
Not securely confined, need to do the same thing multiple times…
Need to add external repositories which are a mess in terms of updates and of security (they can change any package in your system, without you noticing it).
Having just one type (can be snap, can be flatpak or anything else), will just run in all the machines.
It’s just up to the machines to support multiple formats, but they do that already.
1 Like
Well, you can do various things to prevent this, but to be honest, it’s just another discussion about legacy and future package formats. We find them recently in all kind of desktop app repos where people ask for a repository or .deb or .rpm packages.
At the end of the day the important thing is what people use and what people want to use. It’s a bit like a tabs vs. spaces debate. Every side has arguments, sometimes good arguments, but at the end of the day it comes down to the personal taste.
So let’s stay on topic, where the request are repositories for the linux packages. If you prefer snap, appimage or flatpak, no problem, there is enough space for feature requests
1 Like
Plus one for linux packages.
It would be great if we weren’t forced to use microsoft on such a great project, specially on self-hosted installs.
Indeed. Wrong section. Sorry.
But I also agree it would be easier to have linux packages for Desktop app.
I’m going to post again in the proper section. Which is it? app:core?
1 Like
@kspearrin Any news on this?
This has been around quite a while and only waits for your setup of the containers I setup the repo for above.
Thanks. I still haven’t gotten around to this yet unfortunately. I haven’t wrote it off, just need to find the time.
Mhm as my test turned out it looks like you can’t host your apt and yum/dnf/zypper repository on GitHub. I haven’t figured out all details, but they actively prevent using github pages as well as the raw cdn for this.
Did you figure out anymore about the reasons for this? Can I use an Azure storage bucket instead? I don’t really want to host a server just for this.
1 Like
As long as the directory structure for the webend stays the same, yes.
Not really, haven’t looked into this specific problem.
It basically says that it can’t send the specified content $key\r to the command from line 4 because it’s no longer existing. Means your rpm --addsign $rpmfile does something odd. (Maybe wrong path, maybe something else, needs some more detailed debugging, maybe by running the command by hand).
For Ubuntu and other Debian-based Linux distributions we can use PPA service, that will auto-update packages for all versions, here is description https://help.launchpad.net/Packaging/SourceBuilds/GettingStarted
2 Likes
I for one am very much interested in implementing Bit Warden as self-hosted. Namely, on Ubuntu.
However, relying on a script that downloads other scripts online just to install/update/remove software, is not a good, nor desirable practice. This means that my package manager is unaware of it being installed, is unable to update or remove it, or anything like that. Package managers are the industry standard for software management within the Linux ecosystem. Whether it is Deb/RPM packaging (Debian/Ubuntu, CentOS/RedHat/Fedora), this aspect extends to both.
I for one would like the org behind Bitwarden to run their own package repositories for both deb and rpm packaging. And not just for the server components, but also for the desktop components too.
This would mean that the software provably comes from a trusted source, as these repositories can be setup very securely. Furthermore, this would drastically reduce the effort to implement Bitwarden, as well as update it in-place. Be it server or desktop components.
Can we please see the org behind Bitwarden implement these repos and make them standard operating methods for self-hosted installations, and be included in the documentation? It’s really the best way to get this aspect done, and will make the tool more appealing to IT/admins globally.
1 Like
Any updates on any of this? (Respects if @kspearrin is still busy)
Besides just wondering if anything new has happened, I thought I’d just throw in my two cents on why I’m not fond of things like Snaps and AppImages
Snaps are fairly well known for just being slow, in both their normal function and startup times.
With AppImages, those function speed-wise just fine, but I can’t ever get those to work right if I want to pin those to my taskbar(they never let you(unless you were to extract it, but then that breaks things like auto-updates).
Flatpaks suffer more-or-less the same issues as Snaps.
I honestly just like bare-metal packages though 
Flatpaks suffer more-or-less the same issues as Snaps.
Maybe, but flatpaks performance wise are comparable to native deb packages and are supported by wide range of distros, unlike snaps that are pushed only by ubuntu and are horribly slow.
From convenience point of view flatpaks is the way to go. Also, I totally don’t understand the existence of appimage package if you have deb or rpm package. Maybe someone can enlighten me…
So devs please scrap appimage and make official flatpak and everyone will be happy.
1 Like
@kspearrin I found this thing called Gemfury that looks like it would do the job. It supports DEBs and RPMs, and appears to have a GUI and CLI interface if you want to automate things.