Started in this thread but moved here because off-topic over there.
Unfortunately there is no an app for SFOS that satisfy the backups need of all the users and this is the main reason for this new thread.
Here below a list of positive contributions.
MY BACKUP APP
This apps is well-known and widespread but still have limits and issues:
Important: do not uninstall MyBackup versions 1.0.5 and older. Due to what seems to be a bug in busybox, the uninstall script can end up doing rm -fr / on some versions of Sailfish OS. Update the app prior to uninstalling it - update is safe, it doesn’t run that script.
about this bug
This is the bugfix commit:
and here below the related code
%postun
if [ "$1" == 0 ] ; then
for u in $(getent passwd | cut -d: -f1); do
eval rm -fr ~$u/.local/share/openrepos-mybackup ||:
for d in $(getent passwd | cut -d: -f6) ; do
if [ "$d" != "" ] && [ "$d" != "/" ] && \
[ -d "$d/.local/share/openrepos-mybackup" ] ; then
rm -fr "$d/.local/share/openrepos-mybackup" ||:
fi
done
fi
The command getent passwd here would do almost the same of cut -d: -f1 /etc/passwd for user or -f6 for user folders and guess what? Some users might have their home folder in / root. In SFOS, a quick way to find the users (humans) is to do `grep ^users: /etc/group because the others are system users. This is the code to find the home folders:
for i in $(grep ^users: /etc/group | cut -d: -f4 | tr ',' ' ');
do grep "^$i:" /etc/passwd; done | cut -d: -f6 |\
grep -E "^/home|^/root"
The last grep grants for mistakes: only users that have a home folder in root or home can be managed. The others? The others should not exist or they are system users. Therefore the code - the @slava shell scrip uninstall code - is not completely fixed, yet.
However, to stay safe despite the script trying to challenge 114 users currently present in SFOS 4.5.0.19 /etc/passwd while usually 2 o 3 are involved (defaultuser, guest and root), it check for the existence of its own folder creation:
[ -d "$d/.local/share/openrepos-mybackup" ]
dealing safely with paths
At this point, I took a look to the current version 1.0.6 of the RPM spec file:
%install
rm -rf %{buildroot}
and I found another recursive deletion without any sanity check. Whatever someone can say about the RPM %{buildroot} macro, there are two main rules to safely handling the path in combination with recursive deletion especially if operate by elevated privileges:
- double quoting the path strings
- always check that their content is safe and possibly within a range of expectations
- when the path is a folder always append / at the end of the path (twice does not hurt)
In the code above @slava leveraged the second part of the second point to grant that the script is going to delete the right folder (or at least not a completely arbitrary one).
double quoting paths
Here below just a glimpse of what could happen with not doubled quoted paths:
This is bash when correctly configured (and -e when you wish to see everything crashing like there were no tomorrow usually on Friday at 4pm):
~$ set -uo pipefail # into /etc/profile
~$ unset x; echo "~$x/y"
bash: x: unbound variable
This is busybox when you do things VS when you use a path for real:
# rpm -q busybox
busybox-1.34.1+git2-1.8.1.jolla.aarch64
# ash
# unset x; echo ~$x/y
~
# unset x; echo "~$x/y"
~/y
# set -uo pipefail
# unset x; echo ~$x/y
-bash: x: parameter not set
I am not blaming you because missing the quotes, because I do constantly me too BUT it is wrong and usually on Friday 4pm you will discover in production HOW MUCH it is wrong.
always check paths
Before executing critical or irreversible operations, always check the path even when operating in a development / constrained environment.
%install
rm -rf %{buildroot}
In order to limiting the operation above, one could check for something specific in that folder that should exists but it usually has a near-zero chance to exist in every other relevant paths, like:
%install
test -f "%{buildroot}/$specfile" && rm -rf "%{buildroot}"
plus double quotes, obviously.
about the design
Usually it is not a good idea to do with compiled code those tasks which are usually considered system administration like user backup and restore. The compiled code is fine for the GUI but the GUI should use shell scripts. Because the shell scripts are arch-independent, because they are easy to modify and fix or just customize.
The console is the ultimate tool for rescue a system and the system administrators should be able to operate also without the GUI or - in particular - when the GUI is down or in rescue mode. Moreover, separation between GUI shell scripts brings - not only a useful separation between the GUI and the sysadmin level - but also tends to deliver better and more reliable code/apps.
SCRIPTING APPROACH
The scripting approach is far away to be completed and it seems that everyone developed its own solution in one way or another depending on their personal needs but the general problem has not been challenged yet.
post flagged
Your post was flagged as inappropriate : the community feels it is offensive, abusive, or a violation of our community guidelines.
Please, feel free to positively contribute to the correction of this post OR to explain your critics, instead of flagging. Moreover, what may be offensive for you, can be useful for others.
Please, take also in consideration that few newly subscribed forum users (or just a person behind multiple fake accounts) can flag a large number of posts or targeting few forum users causing a denial of service or a temporary censorship. Abusive behaviors can be the result of an action of posting or of flagging.
Post and flag, consciously. 