Concerned about prerequisites

[bwims]

Hi,

I would really like to use this under dietpi, which does not have a user pi with uid 1000 etc.

Am I doomed to failure?

Thanks!

Brian

[Paraphraser]

First off, please read this project is dormant.

Second, I honestly have no idea what DietPi actually is. I took a quick look at the web docs and it seems to be just another build of Debian for various hardware including the Raspberry Pi. Is that an accurate summary?

Assuming "yes" then there's probably no reason why IOTstack won't work. The last paragraph of the stated assumptions means what it says. It's really saying, as politely as it can, "if you move the goal-posts, please don't moan that IOTstack doesn't work properly because moving the goal-posts comes with the responsibility to sort it out yourself". Make sense?

IOTstack is a set of conventions for docker more than a "system" in its own right I've spun up core containers like Mosquitto, InfluxDB, Node-RED and Grafana on Docker Desktop on a Mac and they "just work" - up to the point of any hardware dependencies so getting Node-RED working on a Mac means deleting the device mappings shown below:

If you're using Raspberry Pi hardware AND DietPi implements those same devices then it should still work "as is".

The fact that I'm doing it on a Mac where pi=1000 doesn't exist has never been a software issue so I doubt that it will be an issue for you. It's true that, early on in IOTstack's evolution there were some hard-coded /home/pi. I think those have gone. There may be a few chmod pi:pi (which will cause trouble if pi doesn't exist) rather than chmod 1000:1000 (which won't cause trouble) but I haven't hit any recently. I'd actually be a little more worried about software dependencies that are in a vanilla Raspbian image (and are therefore implied assumptions for IOTstack that nobody really knows are dependencies) having been omitted from DietPi. As long as you understand you might wind up spending a bit of time chasing apt install, you'll probably be fine.

Last point. You might like to take a look at PiBuilder. There's a long list of packages in the 03 script which are either useful or essential. Plus, the 04 script installs docker and docker-compose correctly. For some time IOTstack itself has made a bit of a hash of docker-compose, which has the unfortunate side-effect of somehow damaging docker's version number, which the confuses the heck out of the IOTstack menu. You don't have those problems if you use the 04 script approach. Whether that will actually work "as is" on a DietPi is something I don't know so I really do mean "take a look" rather than "just run".

Hope this helps.

[bwims]

Thanks for taking the trouble to let me know all this. I did add user pi with the correct ids but I wound up with a menu that looked nothing like the one in the video and it was incredibly slow. As it happens, dietpi let me install docker and portainer, and since I use rpi-clone to copy the entire SSD in minutes, I thought the complexity of this project wasn't worth pursuing.

But thanks again! And I hope the original developer is ok 😟

[Paraphraser]

I hope he's OK too.

What you're seeing is what is referred to as "new menu". If you want the menu to be like the one in the video:

$ cd ~/IOTstack
$ git checkout old-menu

To go back, replace old-menu with master.

Personally, I prefer old menu. The main difference these days is old-menu puts the environment variables for each service in an .env file (eg ~/IOTstack/services/nodered/nodered.env while new menu puts them inline in docker-compose.yml. That's just the default and there's nothing stopping anyone from copying and pasting .env contents to their compose files (I do).

New menu has its own flavour of "override" system but I strongly recommend against using either system. It's much simpler to just edit the compose file. My basic recommendation is to use the menu (either one) to generate your basic set of containers, then study the result to see how it all hangs together, and after that stay the heck away from any menu and just edit the compose file by hand. You have a much quieter and saner life. Basically, the more time you spend in the menu and the more you try to use "tricks" like an override system, the more over-represented you are asking "why doesn't this work?" questions in issues and on Discord. 😎

It looks more complex than it is. IOTstack is just a set of conventions. The hidden folder ~/IOTstack/.templates contains one subdirectory per service. Each subdirectory contains a service.yml and, when you choose a service in the menu, those are concatenated to form the compose file. If a container needs persistent storage (most do) it will be a subdirectory in ~/IOTstack/volumes. If a container needs to expose ports, the mappings will have been chosen so there is no possibility of port conflicts (except for obvious situations like, say, PiHole and AdGuardHome where both will want port 53 and it makes no sense to try to run both).

Basically, the templates have already nutted-out the kinds of details you have to figure out for yourself if you follow compose instructions on the web. Every image provider assumes their personal choice of where to put persistent storage is the right one (and it probably is, for them) and assumes they can claim any ports or devices they want. IOTstack just gives you a better than even chance that any arbitrary set of containers you choose will cohabit successfully - out of the box - after which you can start tinkering.