[Feature Request] AppImage

[zero77]

Can you please provide an AppImage, this is basically just a standalone portable executable for linux, that doesn't require installation. Thanks

There are different ways to create AppImages:

Use Open Build Service (OBS)
Convert existing binary packages (.deb, .rpm, …)
Bundling your Travis CI builds as AppImages
Run linuxdeployqt on your Qt application
Using electron-builder for Electron-based apps
Create an AppDir manually

Documentation: https://docs.appimage.org/packaging-guide/ways.html https://github.com/AppImage/AppImageKit/wiki/Creating-AppImages

[Herve5]

I strongly second this, being myself unable to actually gather all the required details for compiling it on Linux (I don't have the right Go version and don't know Go, etc.) I understand and appreciate Simone is a single person doing an enormous lot of work, so I presume if someone else could prepare the AppImage for him it'd be even better -but I am still uncompetent, for this too :( Hervé

[rjzak]

The daemon process requires installation, since it runs in the background is controlled by systemd. I think only the control GUI could be made into an AppImage.

[zero77]

I think the best solution is.

Bundling your Travis CI builds as AppImages

But i haven't had a look yet.

[jeremiah]

Personally I'd prefer flatpak or a deb. I'll look into providing one or the other.

[tuqueque]

Anything but the current cumbersome way of installing (building) Opensnitch today... I'd go for Flatpak instead of .deb or even Snap. Flatpak is the most distro-agnostic of them all and really easy to use.

[dCo3lh0]

some applications have 2 releases of AppImages exactly because of this, one for the daemon the CLI version and another for the GUI, a single example of that is Retroshare. They call the server version i think.. and the GUI, I think this could work... Of course Flatpaks and debs would be cool too...

[karam72]

Both Flatpak and appImage are great!

[jeremiah]

If you're using a flatpak or an appImage, is the opensnitch instance able to view outside the existing flatpak'd or appImage network namespace? Is it able to see all traffic on the system? If so, what is the benefit of using the flatpak or appImage as they would then provide little containment and likely bring in a large and separate set of dependencies on the given system that need to be maintained separately?

[jeremiah]

I think the best approach, for now at least, is to either build from source or use the provided debs. Once various distributions catch up to the version of libc being used then you'll be able to address packages for a large installed base, like Ubuntu and Debian users, as long as they're using up to date versions of the same. The lack of a newer libc in Debian and in Debian derived OSes is a block for me for building upstream debs. More info in this issue: https://github.com/evilsocket/opensnitch/issues/494

[gustavo-iniguez-goya]

do you mean libc 2.32/33 versions?

[jeremiah]

Yes. Currently Debian GNU/Linux 11 (bullseye) has version 2.31-13+deb11u2 of the GNU standard C library. While I haven't checked the symbols like GLIBC_2.32 pthread_sigmask, I assume that feature is not in the bullseye version of Debian.

The next stable version of Debian, Debian GNU/Linux bookworm/sid, or just "bookworm" or "testing" already has 2.33-7 for it's libc library. This should make it easier to push the source code of opensnitch upstream into Debian and maintain the Debian package there. This allows for opensnitch to flow downstream into Debian derivatives like Ubuntu.

[gustavo-iniguez-goya]

Try compiling with Go 1.15, it doesn't require 2.32/33 libs. Newer versions depends on pthread_sigmask() which is only available on libc >= 2.32.

[jeremiah]

Oh, I didn't realize that. I will try with Go 1.15.

[RangerMauve]

This'd be great to have for immutable OSs like SteamOS on the SteamDeck (and similar)