-
Notifications
You must be signed in to change notification settings - Fork 1
03. Technical Details
This page was created in order to give more technical details regarding the functioning of this script, as well as give context to different aspects of the development of this program.
I used VSCode to write the script, and used VirtualBox for testing on other operating systems and package managers.
GitHub is mainly used as a repository of stable, working releases, rather than actual development.
This program, and others in the suite, use a fairly basic versioning system, as seen below:
(Major).(Lesser).(Small)
Major: Major updates include complete re-writes of critical portions of the project (examples include version 1.0.0, where argument reading was completely changed)
Lesser: Lesser, or Medium updates include new features, such as new arguments, or customisable/modifiable arguments.
Small: Small, or Minor updates are typically bug fixes, changes in Descriptive arguments, or changes in comments.
In this section, you will find different features of the script that you might notice, and provide context/explanation for said features.
Users who read the code might notice a very peculiar lack of a shebang #! in the beginning of the script. While it is true that a Shebang is recommended for most, if not all shell scripts, it is not useful in the context of this program.
Update_full-UNIX is written with maximum compatibility with a variety of commonly-found shells (Specifically, BASH, SH, ZSH, KSH, and ASH) in mind. Specifying a specific shebang for a specific script bring about several problems:
- Not all UNICES have one specific shell pre-installed. While BASH is universal in Linux, OpenBSD does not have BASH pre-installed at all.
-
Even if a UNIX system has most shells pre-installed, not all of them might be up-to-date. This is especially problematic with MacOS, which has BASH installed, but it is outdated and likely insecure. Instead, it has ZSH as its default shell since MacOS Catalina (10.15).
- But this leads to another problem, being:
-
Having several different versions of Update_Full-UNIX to accommodate different shells would be more difficult to manage and would delay development of new features.
- While in some instances, such as potentially CSH or TCSH, this will be required, there are some shared features that the shells have (read below).
This said, UNIX systems use their default shell when using(/) to execute a script. Using the MacOS example, the default shell in newer versions (Catalina (10.15) and higher) is an up-to-date and safer version of ZSH. Without the shebang, the script will be run in ZSH.
This leads to
What further helps is that the commonly-found shells that this script supports do have a level of 'mutual intelligibility'; the unique syntax found in the different shell versions is only found when using certain things.
The read command is the best example for this program, as ZSH has a different, unique form of the read command with a prompt than ASH or BASH does. Nevertheless, there is a way to write it as to be compatible with all versions listed.
The desire for maximum POSIX compliance and portability is also a reason why printf is mostly used instead of echo, especially when it comes to formatted text. One example was between Ubuntu and Rocky Linux. Using echo, Ubuntu would notice the exit symbols used for intending, bolding, and changing color, but in Rocky Linux, the text was printed literally, with the escape characters not being respected. Using printf solved this, as features such as escape characters are more universally recognized and respected.
With version 1.5.4, there is a dependency-checker function that checks the dependencies that the script used, namely CURL and WGET. This is useful for extracting the checksums, something mentioned later in the Checksums section. Systems that have neither installed cannot work with the script, and the script will respond by quitting.
Many users may notice that not only does Update_Full allow for saving a log file which can save statistics on the package managers used or any errors that might occur, but that it additionally allows for a user to make comments!
These logs can be very useful for troubleshooting, or for monitoring when updates through the scripts happens. Comments can be used to give extra context, or to potentially simplify what is going on for less technical users. Since version 1.2.1 (April 01st 2023), the commenting aspect can be disabled by adding :no-comment / :nc modifier to the --save-statistics / -ss argument. This allows for the script to save logs and be run as a Cron Job.
This project is constantly evolving, with different features being introduced, or even being removed with each new release.
This section can be treated as a sort of extended changelog, seeing the long-term advances in the program.
Prior to version 1.0.0, there was a complex score system to accept arguments and apply them. Specifically, each argument was given a different point, counted by multiples of 2, and depending on the combination of these points the arguments would be implemented.
Although it worked, it was difficult to diagnose and solve potential issues, and it additionally made adding arguments and features slower and tedious. It was also more difficult to catch issues with the arguments, namely duplicate arguments, conflicting arguments, and too many arguments.
Since version 1.0.0, there has been a complete re-write of how arguments are accepted. Now, it works by using nested if/elif/else statements, which makes catching duplicate and/or too many arguments easier. Arguments are also now implemented using a 'flagging' system comprising of boolean variables. If certain variables are true or false in certain combinations, the script will either execute them, or return an error statement, depending on the arguments. This results in faster development of new features and arguments, something that I am personally very executed for.
Version 1.2.1 has also improved how arguments are accepted, primarily by using case statements to evaluate the arguments. Argument modifiers have also been introduced, which will allow for more flexibility in how the script works.
Being aware of the security of the program has been something that I have prioritized in development. In order to be useful to others, especially in more professional environments if that ever happens, it needs to be easy to use and trustworthy. One major step in this is to provide checksums:
Since version 1.0.0, there has been a repository named uf-CHECKSUM-STORAGE that acts as a trusted source of the checksums for the update scripts. They are not included in the Update_Full-UNIX repository, since the default permissions are open for writing by anybody, potential malicious actors included.
Since version 1.4.3 (June 6th, 2023), there is a function that automatically compares the file's SHA512 and SHA256 sums to those in the uf-CHECKSUM-STORAGE repository. If neither checksums match, then a warning will appear, and the script will automatically quit. If the end user uses the -oc / --override-checksum_ arguments, the script will continue running, adding a warning .txt files in the user's $HOME directory'. However, this feature was broken with ZSH, which specifically could not identify the Checksum-Checker function in the first place.
This has been fully patched with version 1.5.4 (August 17th, 2023), where ZSH, and other shells, now fully work with the Checksum-Checker function. The function now works by downloading a separate script that then downloads the checksums and compares both checksums to the updating script. After completion, the script deletes itself and the two downloaded checksums.
If that separate script reports an issue, namely mis-matching checksums or a missing updater script, it will report the error and quit with the exit code 1. Otherwise, the update script will continue as normal.
File permissions for this script are essential, with good and secure permissions being key to using this script safely. Even before the versioned releases, Update_full-UNIX contains a script named uf-first-setup.sh, that automatically sets up the permissions of the script. If the default settings (Writing and executing only available for ROOT, reading for everyone else) are nor appropriate for a user's specific needs, they may use custom permissions, either using the script or manually setting them themselves.
The uf-first-setup.sh script automatically self-destructs in order to prevent potential tampering.
Update_Full-UNIX has its own security policy, as well as a GitHub security advisory. The full text is available under the Policies page.
Update_Full has always, and will always have a privacy policy. In short, nothing is collected by the developer. Full text available in the Policies page.
Here is a list of possible ideas that I will be considering and possibly developing (in no particular order):
- Updater (possibly fused with checksum checker)
- Log message encryption?
Give this project a star and let others know if it helped you!