CentOS/Rocky/Alma/RedHat support

[jurrejelle]

It is stated that only Ubuntu 24 is supported. I want to run this on a Rocky 8 machine, it seems the biggest changes would be adding an if statement in update_deps that checks if dnf or apt is used, and uses the correct one.

Is there interest in this? If so, I will make a PR over the following weeks (if I succeed). If not, I'll drop it and only use said install script internally 👍

Thanks in advance!

[BenediktMKuehne]

I just have to limit my own support to 1 OS version, because it would create to much overhead.
But we of course would like to see EMBA & EMBArk on more systems.
If you get it running a PR would be 👌 super

Just a quick note, since the orchistrator is still in it's early stages: the EMBA backend requires currently either kali or ubuntu so you would also have to make some changes there.
Without that you will only be able to use EMBArk as the server without it's own firmware analysis capabilities. (Only possible with working orchistrator-worker setup)

[jurrejelle]

I just have to limit my own support to 1 OS version, because it would create to much overhead. But we of course would like to see EMBA & EMBArk on more systems. If you get it running a PR would be 👌 super

Just a quick note, since the orchistrator is still in it's early stages: the EMBA backend requires currently either kali or ubuntu so you would also have to make some changes there. Without that you will only be able to use EMBArk as the server without it's own firmware analysis capabilities. (Only possible with working orchistrator-worker setup)

Ah, I didn't know the limitation was specific to the emba backend too, rather than just the frontend / embark
I will see what I can do but that does make it more likely that we'll make an exception and run ubuntu in our environment x3
Appreciate the reply :)

[m-1-k-3]

Hi @jurrejelle, just for info EMBA is currently limited to Ubuntu and Kali as host system. EMBA itself is based on a Kali container that is quite big. So, you should use the Kali Container with all dependencies. Nevertheless, the host dependencies are not that complicated. It is primarly docker and some little stuff. These other little deps should not be a big issue. But, as we do not plan for further supporting other host operating systems, it would be good if you are also interested in maintaining it in the future.

[jurrejelle]

After reconsideration I have started porting and have made a decent amount of progress. Thanks m-1-k-3 for the information, the bulk of the work indeed happens under the docker image so it's less work than I expected. I'll use this issue as a way for me to track progress, along with
e-m-b-a/emba#1712
and
#270

One question I have is, I see embark uses a pinned commit on the emba folder that is 3 months old, is that a periodic update that happens to pull to the new master when it's deemed stable enough / when a release happens?

[jurrejelle]

Nevermind, I have found out about the git submodule initialization :) On my progress: the EMBA image now builds and the PR for emba should be ready (pending any lint/checks, I haven't gotten those running on my system yet so am waiting on approved workflows for that x3)

I'm currently working on getting EMBArK running, specifically the python packages with the pipfile.lock, which seems it might pose a bigger challenge. Will keep this issue updated :)