Is downloading, editing (i.e, configuring for automatic base installation), and flashing DietPi images within open-source software an acceptable use case?

General Discussion
1

Hi! New user here, this is my first post on the forum.

First and foremost, thank you to the DietPi team for creating and maintaining DietPi! I recently discovered it while setting up a Raspberry Pi 5 device to function as a headless private cloud server. Setup was a breeze, and it was really cool to learn about and experience the optimizations this distribution provides.

Second, I’m writing this post to ask the question in the title after beginning to tinker on a small Rust application whose purpose is to scaffold the setup of a secure, self-hosted cloud agent infrastructure. It does so by enabling the user to download, edit, and flash a DietPi image from the terminal instead of having to use multiple tools.

For reference, the following is the step-by-step process which the application guides the user through:

  1. Downloads a DietPi image (from the /downloads/images/ page) on a user-selected supported hardware device (limited, for now, to just the Raspberry Pi devices)
    1. Verifies checksum and signature
  2. Decompresses the image file
  3. Makes edits to files in order to perform automatic base installation (as described in the documentation) based on user-selected preferences for connectivity and functionality
    1. dietpi.txt
    2. dietpi-wifi.txt
    3. /boot/Automation_Custom_Script.sh
      1. e.g., installation and initial setup of Tailscale, herdr (terminal multiplexer), one or more agent harnesses, nono (agent harness sandboxing tool), etc.
  4. Re-compresses the edited image
  5. Flashes the edited image onto a USB device the user has plugged in and selects for setup (e.g., a microSD card)
    1. This step effectively performs the same function which a tool like BalenaEtcher, Rufus, or Raspberry Pi Imager would

As of right now, the tool is still in development and lives in a private repository, but once it’s eventually stable, I would like to release it as free and open-source software just in case somebody else might find it useful. That said, before doing so, I wanted to ask if doing so would violate any kind of terms of use which may exist for DietPi or its hosted images.

I saw that the license in the GitHub repository for DietPi is GPL-2.0, which is copyleft, but I wanted to ask explicitly about the permissiveness of this use case out of respect for the maintainers and the work that has gone into this distribution. I also figured asking about it publicly on the forum could be useful for any existing or future projects that were considering implementing similar functionality.

For reference, there is one existing open-source project I found which has similar functionality (a Bash script that can download the image from URL, decompress, edit, and re-compress it, but not flash it) called DietPi Image Customization Script hosted in this GitHub repository which operates under the MIT License.

To my understanding (which can absolutely be flawed; please correct me if I’m wrong here), this use case does not modify DietPi images but rather provides a user with an “all-in-one” mechanism to download and interact with them. Specifically, the software enables modifying configuration files within the image in ways which are consistent with official documentation, but it does not modify the source code which acts upon this configuration. That is, I’m not changing how DietPi uses the config files (nor any other functionality of the distribution) and I don’t plan to. I’m also not hosting the images and don’t plan to do that either. Download functionality, just like the configuration, is influenced by user choice but is abstracted and automated in the sense that user-selected options are routed to a process running inside the program (e.g., the download occurs “in the background” after an option is selected; the user is not directed to the URL to perform a download manually from within a web browser).

With that in mind, is this use case supported in open-source software that would be distributed for free (under a similar license to GPL-2.0)?

If yes, yay! If not, what are the conditions, if any, that would make it so? For example, instead of downloads happening as described above, would it be necessary to link the user to the website where they themselves download the file and “upload” it to the user interface of the application?

2

this is something @MichaIng would need to answer as Maintainer

A few thoughts from me about the tool. Actually, it isn’t necessary to unpack the image, edit the files, and then compress the whole thing again. Normally, you can burn the entire archive without extracting it using tools like Rufus. On Unix, this also works directly with dd. Afterward, there should be a setup partition on the SD card. On the RPi, this has always been there, and we introduced it on other SBCs a while back. That’s where you can make all changes to the configuration files before booting the system first time. The only exceptions are x86 systems and VMs, since we use ISO files or container images there. But that’s not the target audience for this tool anyway.

3

That is moreless what our CI workflows for software builds and testing do, using and configuring the DietPi container images, to perform the desired tasks automatically as part of the first run setup.

No problem with the license, as long as it is transparent that DietPi images are downloaded. There is also a readme and license file shipped with the image (the two /boot/dietpi-* files), to formally satisfy these parts of the GPL license requirements. But any backlinks to our GitHub repo and/or website alone would do as well.

We just recently talked about per-distro flashing tools: Raspberry Pi Imager is well known. In the meantime there is also Armbian Imager: https://imager.armbian.com/
If it shall have a benefit over Rufus and others, which support flashing xz-compressed images directly, a rich GUI pre-configuration would be nice, indeed. And there are some other things it could do, to raise its value. But it depends on the scope and internal features of the tool, i.e. whether it is planned to have crates for partitioning and in case ext4 (write) access on board. The latter actually might not be easily possible on a non-Linux host:

  • Raspberry Pi images have a boot FAT partition with config files in it. But non-RPi images have a trailing FAT partition instead (DIETPISETUP label), from which the config files are imported into the ext4 partition on first boot, before it is removed. If the flashing tool can write/edit configs on the ext4 partition directly, and remove the trailing FAT partition after pre-configuration, that would reduce first boot efforts. But as said, given the never successful ext4 drivers for Windows, I don’t think this is possible platform independent.
  • Similarly a benefit would be if partition and filesystem are expanded at the host, and in case an ext4 journal added. This is all done on first boot otherwise, but requires some reboots depending on partition table type, initramfs availability etc. Doing such on the host is safer and cleaner. Partition expansion shouldn’t be hard platform independent, and that alone would be a benefit already. Touching the ext4 is likely possible on Linux only, and having per-host-platform features is probably out of scope.
  • About your step 4: re-compressing the image seems unnecessary, especially if flashing is step 5. If the aim is to give the user a compressed pre-configured image for future usage, I’d do that afterwards, maybe with a dialogue which asks whether the flashed image shall be kept, compressed, or binned, which a flag to remember the choice.
4

Thank you @Joulinar and @MichaIng for your thoughtful responses and comments, I appreciate it!

On permissiveness of this use case and meeting license requirements

Understood, thanks for confirming. I’ll be sure to make it clear that DietPi images are downloaded, as well as explicitly display their source (i.e., the corresponding URL for a given image). The README and license files (dietpi-README.md and dietpi-LICENSE.txt) will not be modified by the configuration process, so their unadulterated presence should formally satisfy the GPL license requirements.

On questioning the necessity of re-compressing the image file if it will be flashed anyways

Really good point! Not re-compressing would definitely make development simpler.

This is my first time building software which can flash an operating system image, and my previous experience with flashing images using other software was just using the compressed image from a download page, not extracting it first. So, I just assumed that it needed to be compressed before flashing, but I see now that doesn’t really make any sense, haha.

On the choice to give users a compressed pre-configured image for future usage

I like this idea in theory and appreciate you proposing the option and a way to implement it with the dialogue and flag. That said, I feel concerned about the risk of downstream distribution of a pre-configured image by a user in order to enable bypassing using the application and creating some kind of security vulnerability.

I’ve developed small FOSS projects which “configured” other FOSS before, like themes for static site generators + CMS tools (e.g., 11ty, ghost), but those operated on a completely different attack surface (i.e., those pertaining to a web application’s deployment, not an operating system’s), so I’m trying to be as cautious as possible.

For example, a core configuration option I plan to implement is headless installation using WiFi (as demonstrated in this video), which would require a user to enter a WiFI SSID and key into the application. After that happens, those details would be inputted in the corresponding fields in the dietpi-wifi.txt file. Another example, automating the registration of a Tailscale node using an auth key can occur in the post-installation script if the user provides an authentication key during the configuration flow.

In theory, the distribution of a pre-configured file which has these set up could somehow expose credentials (network, service, etc.) to an unauthorized party. The likelihood of this, I would hope, is extremely low, but I really don’t want to take any unnecessary risks here. As such, I’ll limit my application to never permanently save the image after configuration in any form to the user’s drive.

However, (re)usable and shareable customization is good to have, and there could be a way to implement it safely. For example, a configuration “profile” can be created where a user can specify their preferences (e.g., which agent harness(es) they want installed, which agent sandbox(es) they want installed, etc.), not their credentials. That can live in a simple file, or an encoded string, and use some kind of universally-readable key-value structure that can be optionally saved at the end of the configuration flow.

On the scope of rich GUI pre-configuration

Interesting to hear about potential useful features being writing/editing configs on the ext4 partition directly and expanding the partition and filesystem on the host. Those items definitely lay beyond my expertise, at least for now, so they unfortunately are out of scope at this time. Maybe in the future, though, they would be very cool to implement!

Right now, the tool’s scope and purpose is explicitly tied to the setup of a secure cloud agent infrastructure, which requires a mechanism to pre-configure the image. As such, I’m framing its scope as an “all-in-one”-style solution which addresses both items, plus image flashing, in a safe, efficient, and reproducible way (i.e., not asking an agent to do all of this autonomously). That said, I see no obstacle to decoupling the pre-configuration functionality from everything else, especially since the overwhelming majority of that cloud agent infrastructure setup would live in the post-installation script. For now, though, I think it would be best for me to focus on getting everything working together before honing in on one of the components.

5

Right, this is moreless what Raspberry Pi Imager does. So previously applied settings can be applied for the next flash again, without requiring to enter all information another time.

Fair. So in how far the image content is touched it then very clearly defined, as limited to the known DietPi automation text files and optional scripts. I guess boot(loader) configuration files, like config.txt and such, are out of scope as well for now. So the only SBC-specific part is to detect the correct partition to access the text files. As said, on non-RPi images, it is a trailing FAT partition with DIETPISETUP label, either partition 2, or partition 3 (if there is another leading EFI partition or non-FAT boot partition).