blob: a126bbac219c16a1067453133b672271101e2fbc (
plain)
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
|
# 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 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?
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.)
|
