1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
|
# Why?
updater.phar is useless.
1. It creates a backup FIRST inside the data dir (security implications through this explicitly?
None known so far... yet.)
(I did the separate file and database backups anyways ever since my instance'S inception - so
that _is_ reliable and I see no need to rely on "blackboxes".)
2. It THEN proceeds to the download which may be hilariously slow (Version 31.x.x: the servers
delivered a 255MiB file in over 15 minutes to a machine with download speeds of 30+MiB/sec)
so the backup may already be dated when we proceed
3. It then does stuff with nextcloud in an undocumented [^1] manner. Given that some utterly stupid
morons decided that within Nextcloud (nice software) everything needs to be writable by
the web server user (utterly insane), we don't want to rely on such a construct too much.
(Nextcloud don't give a fuck about security principles that are aaaaages old? Fuck your meta
layers, then, we don't trust you anymore, because fuck you.)
4. Solution? Create own scripts which take over downloads, download verification, and then
execute occ commands (well, they're still occ commands, but more granular and potentially
less fucked by imbecile decisions).
# What?
## State of Things
1. Work in progress. (!!!) (Some parts may not have enough exception handling yet, some parts
are too dependent on the scripter's setup - I hope I will be getting there eventually.)
2. A few files which complement each other to achieve download-backup-extraction-upgrade.
The entrypoint is nextcloud-update. (nextcloud-pharupdate is an old one still using
updater.phar, that one's isolated.)
## To-Dos
1. Finallise app-update sections once we have apps available for update to parse `update:check` output
2. See 1. under "State of Things"
3. Kind of related to 2. - we still need to build a package and make the script calls independent
of /usr/local/bin
4. Maybe move anything except nextcloud-update to a "lib dir" - the scripts should be executable
on their own, but the main idea is "call stuff and let the script decide what to do"
5. Make the current verbose output dependent on a CLI option, choose to also offer syslog and
scheduler friendly output (i.e. only hard results on output for e.g. systemd timers, and ofc
to logger)
# Footnotes
[^1]: Well, the code is open. Nonetheless, consider this: the PHP file has 41887(!) lines of code at the
time of writing including some binary code. We had 707 lines overall when this remark was created.
That's a monstrosity. Nobody wants to read that. Plus, it's always good to have documentation at hand
also outlining paradigms of the code. Inside updater.phar, there is _a bit_ of documentation and
zero outlines. (Is the name "humbug" intentional? :-) )
|
