Currently I’m planning to dockerize some web applications but I didn’t find a reasonably easy way do create the images to be hosted in my repository so I can pull them on my server.

What I currently have is:

1. A local computer with a directory where the application that I want to dockerize is located
2. A “docker server” running Portainer without shell/ssh access
3. A place where I can upload/host the Docker images and where I can pull the images from on the “Docker server”
4. Basic knowledge on how to write the needed Dockerfile

What I now need is a sane way to build the images WITHOUT setting up a fully featured Docker environment on the local computer.

Ideally something where I can build the images and upload them but without that something “littering Docker-related files all over my system”.

Something like a VM that resets on every start maybe? So … build the image, upload to repository, close the terminal window, and forget that anything ever happened.

What is YOUR solution to create and upload Docker images in a clean and sane way?

Since some time now the Steam Flatpak cannot start up and I have no idea why this happens.

Web research leads to basically nothing that is related to what I experience so I assume it has something to do with my system. Other Flatpaks start up normally and I can use them.

When resetting everything related to the Steam Flatpak and reinstalling it from Flathub it loads and installs the Flatpak and then installs all necessary stuff

[various update-related stuff]
setup.sh[4598]: Forced use of runtime version for 32-bit libcurl.so.4
setup.sh[4598]: Found newer runtime version for 32-bit libSDL2-2.0.so.0. Host: 0.2400.0 Runtime: 0.2600.5
setup.sh[4598]: Forced use of runtime version for 32-bit libgtk-x11-2.0.so.0
setup.sh[4598]: Found newer runtime version for 32-bit libvulkan.so.1. Host: 1.3.224 Runtime: 1.3.239
setup.sh[4598]: Forced use of runtime version for 32-bit libdbusmenu-glib.so.4
setup.sh[4598]: Forced use of runtime version for 32-bit libcurl-gnutls.so.4
setup.sh[4598]: Forced use of runtime version for 32-bit libdbusmenu-gtk.so.4
setup.sh[4598]: Forced use of runtime version for 64-bit libcurl.so.4
setup.sh[4598]: Found newer runtime version for 64-bit libSDL2-2.0.so.0. Host: 0.2400.0 Runtime: 0.2600.5
setup.sh[4598]: Found newer runtime version for 64-bit libvulkan.so.1. Host: 1.3.224 Runtime: 1.3.239
setup.sh[4598]: Forced use of runtime version for 64-bit libcurl-gnutls.so.4
steam.sh[2]: Steam client's requirements are satisfied

So everything looks good up to this point. The small Steam update windows poppend up several times indicating the running installation/update. The output then continues:

[2023-08-17 22:47:50] Startup - updater built Jul 28 2023 18:44:09
[2023-08-17 22:47:50] Startup - Steam Client launched with: '/home/dirk/.var/app/com.valvesoftware.Steam/.local/share/Steam/ubuntu12_32/steam' '-no-cef-sandbox'
08/17 22:47:50 Init: Installing breakpad exception handler for appid(steam)/version(1690583737)/tid(5467)
[2023-08-17 22:47:50] Loading cached metrics from disk (/home/dirk/.var/app/com.valvesoftware.Steam/.local/share/Steam/package/steam_client_metrics.bin)
[2023-08-17 22:47:50] Failed to load cached hosts file (File 'update_hosts_cached.vdf' not found), using defaults
[2023-08-17 22:47:50] Using the following download hosts for Public, Realm steamglobal
[2023-08-17 22:47:50] 1. https://cdn.steamstatic.com, /client/, Realm 'steamglobal', weight was 1, source = 'baked in'
[2023-08-17 22:47:50] Verifying installation...
[2023-08-17 22:47:50] Verification complete
XRRGetOutputInfo Workaround: initialized with override: 0 real: 0xf0d328f0
XRRGetCrtcInfo Workaround: initialized with override: 0 real: 0xf0d311c0
GetWin32Stats: display was not open yet, good
GetWin32Stats: display was not open yet, good

(The last line gets printed twice, yes.)

The first startup process then hangs there for a few seconds and continues with this.

steamwebhelper.sh[5473]: Running under Flatpak, disabling sandbox
steamwebhelper.sh[5473]: CEF sandbox already disabled
CAppInfoCacheReadFromDiskThread took 0 milliseconds to initialize
src/steamUI/steamuisharedjscontroller.cpp (540) : Failed creating offscreen shared JS context
src/steamUI/steamuisharedjscontroller.cpp (540) : Fatal assert; application exiting
08/17 22:48:39 Init: Installing breakpad exception handler for appid(steam)/version(1690583737)/tid(5467)
assert_20230817224839_27.dmp[5771]: Uploading dump (out-of-process)
/tmp/dumps/assert_20230817224839_27.dmp
dirk ~ $ 

After the command prompt is shown agein, this gets printed:

assert_20230817224839_27.dmp[5771]: Finished uploading minidump (out-of-process): success = yes
assert_20230817224839_27.dmp[5771]: response: CrashID=bp-f62fb7e8-d024-452e-a937-9c6672230817
assert_20230817224839_27.dmp[5771]: file ''/tmp/dumps/assert_20230817224839_27.dmp'', upload yes: ''CrashID=bp-f62fb7e8-d024-452e-a937-9c6672230817''

At the given location there is no dump file.

Do you guys have any Idea why this happens and how I can fix it?

Involved software:

$ flatpak --version
Flatpak 1.15.4

$ flatpak remotes
Name    Optionen
flathub system

$ flatpak info com.valvesoftware.Steam | grep Version | awk '{print $2}'
1.0.0.78

$ uname -rms
Linux 6.4.10-arch1-1 x86_64

$ openbox --version | head -n1
Openbox 3.6.1

$ pacman -Qi xorg-server | grep Version | awk '{print $3}'
21.1.8-2

In opposition to this post ... Name your most favorite upsides of software being federated.

Basically the title. When writing .. it is converted to …. Also every string being any amount of dots is also being converted to …, even when it makes no sense.

.. -> ..
../relative/path/file.txt -> ../relative/path/file.txt
................................... (used as visual separator) -> ...................................

Automatically changing ... to the otherwise hard to type ellipsis symbol … is a good idea, but everything else should, not be changed.

Are we still doing ancient memes?

I was in need of using different signing keys (but same mail address) and had a little adventure in the advanced Git documentation I'd like to share.

In your `~/.config/git/config`` remove the [user] section and add this instead:

[includeIf "hasconfig:remote.*.url:https://your-remote-url/**"]
    path = ~/.config/git/user_a

And in ~/.config/git/user_a use this:

[user]
    email = username@example.com
    name = User Name                                                                
    signingkey = the_16_digit_GPG_key_ID

Repeat as often as you need. Just add another includeIf section for each of your remote hosts.

You can also keep a “stub” user section in your ~/.config/git/config if you always use the same user name and mail address but want to use different keys.

[user]
    email = dirk@0x7be.de
    name = Dirk

In your includeIf’d files simply set the signingkey:

[user]                                                                          
    signingkey = the_16_digit_GPG_key_ID

Git automatically combines the two as needed.

A minimal working example:

File ~/.config/.git/config:

[user]
    email = username@example.com
    name = User Name

[commit]
    gpgsign = true

[tag]
    gpgsign = true

[includeIf "hasconfig:remote.*.url:https://hostname_A/**"]
    path = ~/.config/git/config-A

[includeIf "hasconfig:remote.*.url:https://hostname_B/**"]
    path = ~/.config/git/config-B

File ~/.config/git/config-A:

[user]                                                                          
    signingkey = 16_digit_key_id_used_for_a

File ~/.config/git/config-B:

[user]                                                                          
    signingkey = 16_digit_key_id_used_for_b

Now when you push commits or tags to hostname_A or hostname_B the correct key is used to sign those (in the example, using same name and mail address) without having to manually edit this for all your local repositories.

I can't help but feel overwhelmed by the sheer complexity of self-hosting modern web applications (if you look under the surface!)

Most modern web applications are designed to basically run standalone on a server. Integration into an existing environment a real challenge if not impossible. They often come with their own set of requirements and dependencies that don't easily align with an established infrastructure.

“So you have an already running and fully configured web server? Too bad for you, bind me to port 443 or GTFO. Reverse-proxying by subdomain? Never heard of that. I won’t work. Deal with it. Oh, and your TLS certificates? Screw them, I ship my own!”

Attempting to merge everything together requires meticulous planning, extensive configuration, and often annoying development work and finding workarounds.

Modern web applications, with their elusive promises of flexibility and power, have instead become a source of maddening frustration when not being the only application that is served.

My frustration about this is real. Self-hosting modern web applications is an uphill battle, not only in terms of technology but also when it comes to setting up the hosting environment.

I just want to drop some PHP files into a directory and call it a day. A PHP interpreter and a simple HTTP server – that’s all I want to need for hosting my applications.