v0.2.0-beta.9

What's Changed

• Tailscale starts by itself; hook follows the new id tailscaled by @UniqueDroid in #48
• System apps declare their service in app.json (S90services, no more hooks) by @UniqueDroid in #49
• Private app folder for accounts without Dateien (ShareOS.fs root "app") by @UniqueDroid in #50
• App frame and terminal: allow the clipboard (fullscreen, autoplay) by @UniqueDroid in #51
• autobrr: system app, service and permission autobrr by @UniqueDroid in #52
• Fix DNS-325 boot loop and first installation by @benoitm76 in #53
• One release: 0.2.0-beta.9 (no beta.10/beta.11 sections) by @UniqueDroid in #54

New Contributors

• @benoitm76 made their first contribution in #53

Full Changelog: v0.2.0-beta.8...v0.2.0-beta.9

---

• Tailscale starts by itself: the daemon now runs as soon as the system app tailscaled is installed and after every restart – it waits for the sign-in, and a box that was signed in connects again by itself. Before, only an app's Verbinden started it.
• Services of system apps are declared in their app.json: "service": { "control": "tailscale", "on_install": "start", "delay": 5 } – ShareOS starts it at boot (/etc/init.d/S90services, after its delay, in the background), right after installing if asked, and stops it when the app is removed or the box shuts down. The work is done by the firmware's controller /usr/sbin/shareos-<control>, which states what it can do (shareos-service: boot start stop-all); a package cannot bring its own, so only reviewed code starts daemons as root. One init script and no removal hooks replace S93tailscale, S94vpn, S95transmission, S96dlna and /usr/lib/shareos/apphooks – renaming a system app can no longer break its start. Packages built before carry no "service" yet; ShareOS knows their entries.
• Services → Status / Autostart list the services of installed system apps (Tailscale, VPN, Transmission, media server) with their state; start, stop and switching the autostart off work for them as for the other services (the names stay tailscale, vpn, transmission, dlna).
• System apps are submitted to the ShareOS repository (sysapps/), web apps to ShareOS-Apps: sysapps/README.md explains both kinds with an example each – a program (tree) and a service with its controller (mosquitto) in docs/examples/sysapps/.
• Copying in apps shown in the page works: the frame of an app inside the ShareOS page (permission embed) and the web terminal now allow the clipboard (allow="clipboard-read; clipboard-write", plus fullscreen and autoplay for players). Before, a copy button in such an app failed with "The Clipboard API has been blocked because of a permissions policy".
• Apps keep their data on the box also for accounts without "Dateien": an app with the permission files opened by such an account gets one private folder of its own – /mnt/<apps drive>/.shareos/userdata/<account>/<app> (the account's, 0700) – as its only folder in ShareOS.fs (root app, private: true). The account's personal folder, the shares and the file browser stay closed, and other permissions (torrent, media …) still need "Dateien". Before, ShareOS.fs was missing and apps like ShareNotes fell back to the browser. Removing the app removes these folders; deleting an account with its data removes them too.
• autobrr (download automation): the system app autobrr (autobrr 1.84, 32 MB with its web interface, on the apps drive) watches IRC announce channels and RSS feeds and picks releases by your filters. One autobrr for the whole box: shareos-autobrr runs it as its own user autobrr on 127.0.0.1:7474 with a Go memory limit (GOMEMLIMIT=48MiB), its database on the apps drive; the first start signs it up (user admin) and makes an API key for ShareOS (root only). Found torrents go to the Transmission of one account: autobrr's action Watch dir writes them into the hand-over folder /mnt/<apps>/.shareos/autobrr-drop (the account's, group autobrr, 2770), which that account's Transmission watches. Optionally autobrr's own web interface on http://<box>:7474 (its own login, password set from ShareOS). Starts after installing and at boot ("service": { "control": "autobrr" }), listed under Services.
• Permission autobrr for apps (needs files), admin accounts only: ShareOS.autobrr – status, start, set (on/off, web interface, account for the hand-over), password, accounts, log and api(method, path, body): autobrr's REST API through /_shareos/cgi/autobrr with the key of ShareOS (rpcd shareos.appautobrr; not /api/keys or /api/auth). The app itself comes from ShareOS-Apps.
• DNS-325: first start on real hardware (rev A1). The beta.7 .bin for the DNS-325 made the box restart in a loop: the kernel booted, printed INITRD: 0x00800000+0x001ff000 overlaps in-use memory region - disabling initrd, found no /init and panicked (panic=10 restarts after 10 s), so neither the first installation nor the rescue system ever ran. The initramfs of the DNS-325 is now loaded at 0x01000000 instead of 0x00800000 (post-image.sh makes one header per model; it checks the address in each finished image, and tests/check-initrd-address.sh checks the bundles in CI). With the new address the DNS-325 boots from flash. The DNS-320L and the DNS-320 keep 0x00800000 until someone has tried the new address on them (a wrong address is a reboot loop that needs a serial console); the kernel is the same on all models, so what is in use at 0x800000 on the DNS-325 depends on the board or its U-Boot – not found yet.
• First installation / shareos-install-ubi on the DNS-325: the tool refused the image partition ("unexpected size 0x06600000, expected 0x06400000"). The DNS-325 has 102 MB there (no my-dlink partition), the DNS-320L 100 MB; both are accepted now, any other size is still refused. The DNS-320 rev A shares the DNS-325's flash layout in Alt-F's device trees (not seen on hardware yet). New test tests/test-install-ubi.sh.
• Checked on a DNS-325 rev A1: model and RAM (256 MB), 1 Gbit/s Ethernet, temperature sensor, clock, USB, the 6 flash partitions, the LEDs, the three fan presets (quiet, balanced, cool) and the box starting again by itself after a power cut (with the drives stopped by shareos-storage shutdown first). The power, reset and USB buttons do not work on this box yet (shareos-buttons finds no input device; a separate change fixes it), and a complete first installation from a freshly flashed .bin still needs a test (DEVICES.md). A DNS-325 that already runs beta.7 and restarts in a loop needs a serial console to recover (the old initramfs is in its flash). The DNS-320L, DNS-320 rev A/B boxes are not tested with the new address yet.