Dietpi banner upgrades

[timjolson]

Enhancing dietpi-banner.

• Changed custom entry to accept multiple commands
• Added network usage by namespace
• Added disk usage by pattern matching
• Added systemd and fail2ban status
• Standardized printing
• Organized color resources
• Added G_TRUNCATE_MID

[timjolson]

Outstanding items I know of:

• no IPv6 detection for the network traffic, only ipv4
• dynamic disk space usage is independent of the pre-existing disk space entries (what do we do with the existing options?)
• wrapping has not been tested or dealt with
• IP address and network information (retrieval and parsing) use different methods than are pre-existing in the script - need to work through what might be more robust / efficient and consolidate to helper functions
• no handling of permissions checking is in place yet
• there sometimes is an issue with the terminal not being properly cleared when running dietpi-banner 1, probably applies to dietpi-banner 0, as well. The issue occurs often when using VSCode and has not been verified in other terminals.

[MichaIng]

A great extension! But there is some cleanup/polishing needed to reduce the overhead (in code an UI), and make it work for expected use cases.

[MichaIng]

Just as an overview, the things I'd still want to do before merging. But will do so before DietPi v10.6 release (which will be delayed anyway because of a spontaneous holiday trip consuming some time this week):

• Move array index migration to https://github.com/MichaIng/DietPi/blob/master/.update/patches, so we do not need to carry the code here, but just do this once with a sed loop or so.
• Migrate existing /boot/dietpi/.dietpi-banner_custom and aDESCRIPTION[10] into the new custom command array.
• Migrate/Replace aENABLED[disk_rootfs] and aENABLED[disk_userdata] with aDISK_SPACE_PATTERNS.
• When adding a disk space pattern, findmnt -nro TARGET --real output lines, which are not matched yet, are offered in the menu directly, with "custom" allowing to enter a custom pattern. I'd also list all active pattern in the primary menu, showing the inputbox to edit them on select, removing them by emptying the inputbox, + the "Add" entry.
• Instead of scraping the df output, findmnt -nro TARGET,USED,SIZE,USE% --real might be the cleaner alternative. Though, interestingly it is much slower as I just recognized, taking about 3x more time to process. Alternative is df -h --output=target,used,size,pcent, and we skip the redundancy math + skip separate percent calculation? There is no reason to assume used or size wouldn't be available. Or if used wouldn't be for some special mounts, avail wouldn't be available either. If higher precision and/or aligned unit is wanted the -m flag could be used instead of -h to get MiB values, which can then be converted to GiB slightly simpler.
• Add IPv6 support for network usage and Fail2Ban stats.
• Reduce sudo calls in Print_Network_Usage: If namespaces are used, check via sudo -n -v once whether the current user can use sudo. If so, do the whole namespace processing loop in a single sudo -n dash -c 'declare -f func; func' 2>&1 call. Else, process the default namespace only.

[MichaIng]

I went through the open points you mentioned at the top. Regarding clearing the terminal in VS Code: See G_TERM_CLEAR() in dietpi-globals: It uses ANSI escape sequences, \n and \e[H to move the content into the scrollback buffer (where available) and move the cursor back to the top, rather than clear. I found it preferrable to keep the possibility to scroll back, rather then erasing the content. But it performs worse on certain terminals, where the content is visibly moved line by line. Possible that this does not work well in some dev terminals.

[timjolson]

• Instead of scraping the df output, findmnt -nro TARGET,USED,SIZE,USE% --real might be the cleaner alternative. Though, interestingly it is much slower as I just recognized, taking about 3x more time to process. Alternative is df -h --output=target,used,size,pcent, and we skip the redundancy math + skip separate percent calculation? There is no reason to assume used or size wouldn't be available. Or if used wouldn't be for some special mounts, avail wouldn't be available either. If higher precision and/or aligned unit is wanted the -m flag could be used instead of -h to get MiB values, which can then be converted to GiB slightly simpler.

I calculated the percent manually
1.so that a decimal place could be displayed
2.to attempt accommodating remote mounts not returning all the fields (I removed this logic)
3.there is also disagreement on USE% between polling methods (for example df shows different than findmnt)

I've updated to use a single findmnt call, then parse the paths, and calculate USE% inside mawk for minimal logic.

Next up: splitting dynamic patterns versus explicit paths and updating the menu

[timjolson]

• Migrate existing /boot/dietpi/.dietpi-banner_custom and aDESCRIPTION[10] into the new custom command array.

I'm looking at migrating the external script, but having a problem where, if we pull it into aCUSTOM_COMMANDS with
aCUSTOM_COMMANDS=([migrated]='bash \"$FP_CUSTOM\"')
unless we save a flag or move .dietpi-banner_custom, it would be re-migrated and added again each time dietpi-banner menu is run. How do you want to handle this, I see the below options:

1. (riskier and messy) rather than bash "$FP_CUSTOM", try to pull the full script into the array with <
2. combined with # 1, move or rename the file when migrated, so that it does not get loaded again
3. track and save a flag that the command was migrated already
4. always load the external script into aCUSTOM_COMMANDS, but do not save it (re-loaded from the external script each time). this would be closely aligned with previous behavior, but we should warn the user to manually migrate each time
5. similar to # 1 with # 2: rename the existing FP_CUSTOM file so it does not migrate again; add the command with bash "$FP_CUSTOM_NEW_PATH"; save the command to preferences, as expected and consistent with the new logic

I prefer 4 or 5, as they provide the most consistent behavior.
My concern with # 1 is that a multi-line script could cause issues, #!/bin/bash won't process correctly, etc.

• Move array index migration to https://github.com/MichaIng/DietPi/blob/master/.update/patches, so we do not need to carry the code here, but just do this once with a sed loop or so.

I am not familiar enough to move the multiple migrations over to patches, but it would be good to clean all that out of the script.

Edit 1:
I implemented # 4 - the most consistent with previous behavior. It needs more testing.