armbian-config RFC ideas

[balbes150]

Is it possible to run some functions (such as enabling or disabling overlay) directly from the command line without using the GUI ?

[Igor]

No and armbian-config needs to be written from scratch. We have talked about to:

- discuss how to do this @tparys

- make a plan

- divide work into several parts. 

It's a lot of work so we should plan it carefully. I would propose to finish desktop integration first - which is also a very big change, then we go for this. But we can already start talking about - "how to to do this?".

[Technicavolous]

I have successfully built images on my hardware, so I will try the command in the desktop thread.

 

I assume https://github.com/armbian/config

 

I will need some direction but can put in a few hours. I volunteered to work with C4 some time ago and aside from a couple spelling changes I've contributed almost nothing to the project. Maybe I can be of more help here.

 

 

On 2/1/2021 at 2:52 AM, Igor said:

But we can already start talking about - "how to to do this?".

For me it is to learn the basics of working with armbian-config.

Has anyone done a tutorial (hihi) :] ?

Edited February 2, 2021 by Technicavolous
dumb reference

[Igor]

More top level ideas:

- software install focused to Docker deployments

- switch our half solutions with better maintained surrogates (if exist)

- identical code for X and CLI

- parameter driven

- modular

- hooked on CI building since start

- hire 1-2 pro covered with help of crowdfunding campaign

[lanefu]

it would be nice if we could use it to just launch some ansible playbooks and roles.... a lot of the config and install code could be replaced by that.

 

Main thing is we'd want to run it in a pyenv just to assure user land doesn't get goofed from ansible dependencies

[SpontaneousDuck]

I would love to get involved with the redesign project! I don't have a ton of experience with CLI tools like this but really need to learn so this would be a good chance.

[tparys]

Sorry I'm a little late finding this thread. I had traded some messages with Igor on this subject and had spent a few afternoons thinking about it.

 

Though to be honest, if the push is towards Ansible, I must admit I'm not too familiar with the topic, and may not be much help.

 

However, in case it's useful as a talking point, the thoughts I had were along the lines of something I had done for work, to break up the menu system into subdirectories of scripts. A top level bash script scanned each directory, and provided menu options derived from the folder names. Submenus would be directories within directories, leading the top level script to recurse. An action or executable would simply be a script at some level.

 

And the best parts would be that it would be dead simple to add something to it. Drop a script in a directory with an appropriate name. Done. The filenames got a little long, so might want some better way to encode names, but I think it's a decent idea.

 

Additionally, per looking at this post, made me think that we might need something simpler for those who need reading assistive devices. There's nothing saying that you couldn't swap out the calls to "dialog" to bash's "select" call to provide an extremely simple text front end. I suppose you could do some sort of an X tool with TCL/TK, though it wouldn't look pretty at all.

[Igor]

20 hours ago, tparys said:

Though to be honest, if the push is towards Ansible, I must admit I'm not too familiar with the topic, and may not be much help.

I also have close to zero experience but its a possible path worth considering. I also doubt we can rely fully on Ansible, but could be wrong. Personally I am also more familiar with the classical ways, just made on a better ground. From the current perspective what tool does and what we could add it. And if made properly, mixing this and that technology can be done. Or set a ground for the future.

 

20 hours ago, tparys said:

However, in case it's useful as a talking point, the thoughts I had were along the lines of something I had done for work, to break up the menu system into subdirectories of scripts. A top level bash script scanned each directory, and provided menu options derived from the folder names. Submenus would be directories within directories, leading the top level script to recurse. An action or executable would simply be a script at some level.

Something like that, yes.
 

20 hours ago, tparys said:

 

Additionally, per looking at this post, made me think that we might need something simpler for those who need reading assistive devices. There's nothing saying that you couldn't swap out the calls to "dialog" to bash's "select" call to provide an extremely simple text front end. I suppose you could do some sort of an X tool with TCL/TK, though it wouldn't look pretty at all.

Parameter driven CLI, dialog and X based engine since start. I think that is must have. I would say primary focus should go initially to design this framework with one simple "hello world" functionality which should work in all three worlds is build into the package and distributed to the repository right after commit is made. Than we start playing and porting stuff from the existing. Each new added functionality is added to the automated testing so we will have full control over the functionality since start.

[TRS-80]

From little I know about Ansible, it seems like it may perhaps even be "the right" tool(?).

 

However, languages / frameworks that current (and likely future) maintainers already know and are comfortable with, IMO, should also be an important consideration.  Perhaps even more important?  I kind of lean this way, but... how willing are people to learn new tool and switch to it?  Especially if that would reduce work / maintenance burden in the long run (which I suspect is true, but do not even know for sure, maybe @lanefu can elaborate here as he seems to be the one with most experience with it)?

 

Just $0.02 from someone who fancies themselves a bit of a strategic thinker and student of computer / tech history.

 

EDIT:  This may seem like a "small" decision, but I don't think it should be rushed.  "Complete re-writes" in different language / framework have been known to kill entire projects (some with much. much more resources behind them than we have).  Therefore the benefits should be clear and real, and not simply based on personal preferences.

Edited February 10, 2021 by TRS-80
add last paragraph

[lanefu]

17 hours ago, TRS-80 said:

From little I know about Ansible, it seems like it may perhaps even be "the right" tool(?).

 

However, languages / frameworks that current (and likely future) maintainers already know and are comfortable with, IMO, should also be an important consideration.  Perhaps even more important?  I kind of lean this way, but... how willing are people to learn new tool and switch to it?  Especially if that would reduce work / maintenance burden in the long run (which I suspect is true, but do not even know for sure, maybe @lanefu can elaborate here as he seems to be the one with most experience with it)?

 

Just $0.02 from someone who fancies themselves a bit of a strategic thinker and student of computer / tech history.

 

EDIT:  This may seem like a "small" decision, but I don't think it should be rushed.  "Complete re-writes" in different language / framework have been known to kill entire projects (some with much. much more resources behind them than we have).  Therefore the benefits should be clear and real, and not simply based on personal preferences.

Edited 17 hours ago by TRS-80
add last paragraph

 

Ansible is a fantastic tool for automating system config and installing stuff.... and its pluggable.   Lots of existing "roles" out there we can start from for popular things https://galaxy.ansible.com

Anyway..... to @TRS-80point...   I wouldn't approach Armbian-config as a complete re-write.. there's lots of great functionality.

I'd focus on improving the front-end's modularity, and then we can slow introduce ansible for some tasks.... again primarily I'm looking at software installation...  as a place to start...  Maybe there's one I should do an example on.

 

Ansible is also great for for doing a lot of system config.. but again. this can be done in a measured way.

[Igor]

OK. It seems we are sticking to BASH. What about desktop?

 

I open this Jira and put down few tasks, those which I am aware of at this moment. Feel free to add / remove things, so we can make some structure. Tasks are just a basic / quick draft.

 

https://armbian.atlassian.net/browse/AR-638

 

I am also cautious about not creating a project we would not be able to move forward. Which is why we have to count resources and see how we can handle this, to which extend and by when. 

[Werner]

8 hours ago, Igor said:

What about desktop?

Maybe do like Linux does? menuconfig ncurses based as we have it right now and xconfig which is....I don't know, whatever based but works?

[tparys]

So, there are GUI based dialog frontends. Where you would do something like this in dialog:

 

$ dialog --menu "Choose an option" 0 0 0 a argle b bargle

 

Or whiptail ...

 

$ whiptail --menu "Choose an option" 0 0 0 a argle b bargle

 

You could use a different frontend like zenity to do something similar. Obviously the arguments would change:

 

$ zenity --title "Choose an option" --column tag --column Description --list a argle b bargle

 

If you could distill it down to minimum information required to populate either list, you could have a bash wrapper that just calls the specified frontend, or just defaults to the GUI version if the $DISPLAY variable is set.

[Werner]

1 hour ago, tparys said:

...

From a quick test on WSL (yeah, I did not have anything else handy right now) it seems whiptail works oob while other would need some package installed. Having a framework that does not have dependencies would be nice.

[Igor]

3 hours ago, tparys said:

you could have a bash wrapper that just calls the specified frontend

 

Create own menu wrapper functions so menu functionality is not hard coded and we can switch between them easily.

[arox]

Have you ever thought of a web server ? (Like cups, openwrt or others ...)

 

You need of course some basic configuration utility in case the network connection can't be automatically established. 

[tparys]

As a fun little hack, here's a little example wrapper for the dialog program. Mark it executable, toss it in /usr/local/bin, and fire up armbian-config.

 

Obviously delete it afterwards. don't leave it there. That's probably a bad idea.

 

But might work as a brief tech demo of what an X11 driven armbian-config might look like ...

 

dialog

[Igor]

On 2/18/2021 at 4:17 AM, tparys said:

But might work as a brief tech demo of what an X11 driven armbian-config might look like ...

 

Great! Looks promising and IMO it's probably a way to go unless there are (much) better ways?

 

Now we need someone with some spare time and some experience in managing (such) projects  

 

We also need to have a complete design, plan of actions and some definition of done per sections. Some draft was initiated https://armbian.atlassian.net/browse/AR-638 

 

Quote

 

Current subtasks
 

AR-639 Create POC with simple functionality

AR-640 Prepare a crowdfunding campaign

AR-641 Refactor documentation

AR-652 Secure long term maintaining

 

 

but someone has to step up and keep an eye on the overall project execution structure and speak up when needed. I have time to help here and there, to cheer up, but can't drive development or do much of coding since I already drive too many things. My performance would be terrible and most of current contributors are also in the same situation. This should be an opportunity for fresh people which have a desire to help on community projects with their know-how and scriptfu.

 

Who can work on this and how much? Finding and calling out people that were complaining or recommending things related to this script, those who were filing an issue might also be good way to start? This is their opportunity to add their 2c directly to the code instead opening an issues that were actually never addressed.

[jeanrhum]

I can try to help on some features to port them (obviously the one concerning device tree), but I don't consider that I'm a bash expert (that was my first real bash script).

Moreover, I may be quite busy in the coming weeks...

[tparys]

I don't mind taking a swing at a proof of concept. Might not be immediately. Still trying to ID an issue on my M4V2.

 

Also not sure what sort of CI processes or Docker deployments you have in mind.

 

[lanefu]

2 hours ago, tparys said:

I don't mind taking a swing at a proof of concept. Might not be immediately. Still trying to ID an issue on my M4V2.

 

Also not sure what sort of CI processes or Docker deployments you have in mind.

 

Well we have a big arm server already configured as a github runner. I suppose we could chroot an armbian rootfs or place in a container 

 

So i guess something that can test armbian-config works as expected

[tparys]

I suppose my question was less where you would run it, and rather what exactly you would want to test.

 

Unit tests are great for functional libraries with known inputs/outputs, but are somewhat trickier with user interfaces.

 

Testing the individual scripts should be more possible if you're looking for actual run products (eg - changes to /etc/apt/sources, or edits to config files).

[lanefu]

Fair point

[Igor]

I think we are looking on a bare concept now - as modular as possible(needed) and with requirements we come up with. When POC is working, then CI. It can be any platform, since this configurator is/hast to remain arch independent.

[JMCC]

I've been thinking about all this project. I had in mind that it would be best to make armbian-config modular since some time ago, before this project came up. I used to work in such kind of projects a long time ago, I guess I could dust off my knowledge.

 

@tparys @Igor How about creating a Github repo with the new proof-of-concept, to start working on it? I can do that if you agree.

 

@tparys If you have something already, we can start with that. Otherwise, I can start it with a simple structure I have in mind.

[Igor]

1 hour ago, JMCC said:

to make armbian-config modular since some time ago, before this project came up. I used to work in such kind of projects a long time ago, I guess I could dust off my knowledge

I think we have knowledge to make this tool right, we lack momentum, time, effort ...  IMO we just need to set some draft frame and get going.

 

1 hour ago, JMCC said:

How about creating a Github repo with the new proof-of-concept

 

"armbian-config-ng" or just "configurator" ?

[JMCC]

45 minutes ago, Igor said:

armbian-config-ng

+1

[tparys]

armbian-reconfig

 

As the old joke goes. There's only two things hard in computer science.

• Naming things
• Cache invalidation
• Off by one errors

I'm probably going to take a stab at it this weekend. More to follow (hopefully).

[tparys]

So, started playing around a bit. Mostly just mocking up ideas.

 

https://github.com/tparys/armbian-reconfig

 

The script currently is recursively driven by a directory system. When it hits a script, it simply executes it. Should be pretty easy to extend. Just drop a script in place and it should use it.

 

I mulled over how to "name" the various scripts and directories, and eventually settled on using gettext, which also provides internationalization support as well. Basically takes the relative menu location like "/system/firmware" and "translates" into the appropriate language. In the case that only partial translations exist, it falls back to English, which i figured wasn't a horrible default.

 

And for testing, I added some translations of the top level menu to Spanish. I did use Google Translate, as my bash-fu is strong and my Spanish is quite rusty.

[Igor]

2 hours ago, tparys said:

So, started playing around a bit. Mostly just mocking up ideas.

 

We are moving!  I hope I will able to add my 2c soon.

 

2 hours ago, tparys said:

recursively driven by a directory system. When it hits a script, it simply executes it. Should be pretty easy to extend. Just drop a script in place and it should use it.

This way. Plain, clear and easy extendable.
 

2 hours ago, tparys said:

which also provides internationalization support as well

 

Haven't even thought about that ...  Great! I think we can cover most used languages within this community in no time. It will also not be much text. Google translate sound funny sometimes, so native speaker proofreading is definitely needed here.