New appimaged: Optional daemon that registers AppImages with the system

Developers
1

appimaged is an optional daemon that watches locations like ~/bin and ~/Downloads for AppImages and if it detects some, registers them with the system, so that they show up in the menu, have their icons show up, MIME types associated, etc. It also unregisters AppImages again from the system if they are deleted. If firejail is installed, it runs the AppImages with it.

A precompiled version can be found in the last successful Travis CI build, you can get from https://github.com/AppImage/AppImageKit/releases.

Usage in a nutshell:

./appimaged

It will register the AppImages in with your system from the following places:

  • $HOME/Downloads
  • $HOME/bin
  • /Applications
  • /isodevice/Applications
  • /opt
  • /usr/local/bin

Run appimaged -v for increased verbosity.

NOTE: It may be necessary to restart (or xkill) dash, nautilus, to recognize new directories that didn’t exist prior to the first run of appimaged. Alternatively, it should be sufficient to log out of the session and log in again after having run appimaged once.

If you have AppImageUpdate on your $PATH, then it can also do this neat trick:

screenshot from 2016-10-15 16-37-05

Here is an easy way to get the latest AppImageUpdate onto your $PATH:

APP=AppImageUpdate
nodeFileName=$(wget -q "https://bintray.com/package/files/probono/AppImages/$APP?order=desc&sort=fileLastModified&basePath=&tab=files" -O - | grep -e '-x86_64.AppImage">' | cut -d '"' -f 6 | head -n 1)
wget -c "https://bintray.com/$nodeFileName" -O "$APP"
chmod a+x "$APP"
sudo mv "$APP" /usr/local/bin/

NOTE: This works only with the new, squashfs-based type 2 AppImages so far.

2

Does this daemon automatically make AppImages executable? No more right-clicking and setting options?

Also, as for the update feature: does the upstream developer have the ability to set the location of future binaries? (So they can be kept up to date on our own servers?)

3

Does this daemon automatically make AppImages executable? No more right-clicking and setting options?

Correct, no more right-clicking and setting options. The AppImage will run in a Firejail sandbox for which it is not necessary to mark it as executable. You can test this already now with type 2 AppImages. Possibly unsigned AppImages will run under tighter confinement (e.g., no write access, no network access) than signed AppImages, but this is not decided yet and I’d appreciate thoughts on this.

Also, as for the update feature: does the upstream developer have the
ability to set the location of future binaries? (So they can be kept up
to date on our own servers?)

I don’t understand this idea. If you use AppImageUpdate, then the new updated version will end up in the same directory as the original one. You can decide, as an upstream developer, where to store the files for the update on your download server. I use Bintray, but you might use any HTTP server that can handle HTTP Range Requests (normally used for video streaming).

4

This answers my question regarding that. I have a few ideas to begin an era where this is a widely accepted format. I will report back after I’ve worked on them a bit in concept.

5

Very cool! Looking forward to it :slight_smile:

6

This has now landed in https://github.com/probonopd/AppImageKit, yay!

7

Is there a way to run this service on demand?
Namely instead of background service I run it, it scans, updates what needs to be updated and close itself.

8

appimaged checks the filesystem for changes, and acts whenever it detects a change. What would we gain by making it quit itself? In this case, some other process (systemd?) would need to check for the filesystem changes, and invoke our code to do the AppImage system integration when being called. Instead of running a background service, we would have an executable that would get called by some other background service.

Actually, interesting thought. I have opened https://github.com/AppImage/appimaged/issues/8 for it. More investigation needed.

9

The whole idea of using AppImage style applications is keeping the system as on its first day to run.
I don’t want more processes or anything in the background which changes the system.

This is why I like the PortableApps concept.

10

I think you are confusing a couple of things:

  • Running a per-user background process vs. “system privileges”. When you run a per-user daemon (background process) it has no more privileges than an application running in the “system tray”
  • Portable applications vs. “leaving no traces”. The fact that an application is “porable” (i.e., can run without the need for installation, can run from different locations in the file system) does not mean that the application can “leave no traces”. For this you need either sandboxing (which can limit functionality), or a system that “forgets” its state on each reboot. I, too, like the concept of “keeping the system as on its first day”, but I am using Live ISOs booted by SystemImageKit for this purpose - every boot gives me a clean system
11

Well, we can always inspire for the closest we can get.
For me Portable which leaves no trail means:

  1. Requires no special privileges - Built In into AppImage.
  2. Writes its configuration data into the folder the program resides in (Built In into AppImage under the assumption the application uses $HOME system environment variable to set the location of writing configuration and application data).

Deamon for me is like background processes in Windows.
I don’t like that.
I prefer well shown program in the System Tray.
Only viruses and system services should hide themselves (From different reasons) from the user.
Pay attention that I don’t mean it can’t be a Daemon, I mean it should be visible to the user in the places he looks for programs - Taskbar / System Tray. Not in the processes menu to stop it.

12

Just for fun, start a “new” Linux installation, open a terminal, type ps ax and be amazed at how many “background processes” are running… it will be an eye-opener.

Isn’t appimaged something like a “system service” (only that it doesn’t come with the system in most cases)?

13

Well, those are what I agreed to when I chose the distribution.
What I don’t want is to add another one.
Especially if it is something I have hard time interacting with since it doesn’t have System Tray icon.

That’s the point.
I don’t want it to act as a System Service.
I want it to act as a background application which the user can interact with and configure using System Tray icon.