dlandon

I updated MariaDB on my main instance of ownCloud and after an update and a restart this is the log: ownCloud startup: PHP 7.4.33 *** Running /etc/my_init.d/999_advanced_script.sh... *** Booting runit daemon... *** Runit started as PID 692 Oct 31 07:28:24 ccc2338ece1c cron[699]: (CRON) INFO (pidfile fd = 3) Oct 31 07:28:24 ccc2338ece1c cron[699]: (CRON) INFO (Running @reboot jobs) ownCloud startup: MariaDB 10.11.19-MariaDB-log 261031 07:28:24 mysqld_safe Logging to '/config/database/ccc2338ece1c.err'. 261031 07:28:24 mysqld_safe Starting mariadbd daemon with databases from /config/database mysqld is alive Oct 31 07:28:29 ccc2338ece1c mariadb: MariaDB system-table upgrade completed. Oct 31 07:28:29 ccc2338ece1c mariadb: This installation of MariaDB is already upgraded to 10.11.19-MariaDB. Oct 31 07:28:29 ccc2338ece1c mariadb: There is no need to run mysql_upgrade again. Oct 31 07:28:29 ccc2338ece1c mariadb: You can use --force if you still want to run mysql_upgrade You can see php 7.4.33 and MariaDB 10.11.19. The last step to get to supported php 8.x will come when I update to ownCloud 11. Until the apps are compatible, I will hold off on that. Too many are not yet compatible. @Samsonight Hopefully this addresses your concerns about ownCloud security and EOL php and MariaDB. Thanks for letting me know about these issues with the ownCloud container.

I released a new docker container. My main server ownCloud updated and is running. *** Running /etc/my_init.d/30_redis_server.sh... Starting redis-server: redis-server. *** Running /etc/my_init.d/40_get_owncloud.sh... *** Running /etc/my_init.d/50_set_config.sh... *** Running /etc/my_init.d/60_gen_ssl_keys.sh... [ssl] Generating self-signed keys in /config/keys (missing/empty cert/key), you can replace these with your own keys if required [ssl] Self-signed certificate generated (valid 825 days, SAN=localhost/127.0.0.1) *** Running /etc/my_init.d/70_initialize_database.sh... *** Running /etc/my_init.d/80_first_run.sh... Oct 30 10:47:33 8d8f31f9381f crontab[644]: (root) REPLACE (root) ownCloud startup: PHP 7.4.33 <================= *** Running /etc/my_init.d/999_advanced_script.sh... *** Booting runit daemon... *** Runit started as PID 651 Oct 30 10:47:33 8d8f31f9381f cron[658]: (CRON) INFO (pidfile fd = 3) Oct 30 10:47:33 8d8f31f9381f cron[658]: (CRON) INFO (Skipping @reboot jobs -- not system startup) ownCloud startup: MariaDB 10.6.23-MariaDB-0ubuntu0.22.04.1-log <================= 261030 10:47:33 mysqld_safe Logging to '/config/database/8d8f31f9381f.err'. 261030 10:47:33 mysqld_safe Starting mariadbd daemon with databases from /config/database Notice the two highlighted log lines. These give you the php and database versions running on your system. I will wait a while before updating my database. I won't update ownCloud until the apps I use are updated to run on ownCloud 11. Again I caution you that updating to ownCloud 11 with get php 8.3, but the apps not being updated may limit your ability to use ownCloud as you wish.

I've been testing the new docker container and it is looking good. The one thing I find after upgrading my test server to ownCloud 11 is that there are a lot of apps I use like the 'Next Backup' that are not compatible with ownCloud 11 yet. I will hold off upgrading to ownCloud 11 until more of the apps are updated. You should evaluate what apps you use and see if they are ownCloud 11 ready before making the upgrade to ownCloud 11. You can check them at the ownCloud Marketplace here.

I'm working on a new container that will handle the existing ownCloud installations and install ownCloud 11 and MariaDB 10.11 for new installs. The new container will keep an existing ownCloud version and MariaDB 10.6 as it is. You can then update the MariaDB to 10.11 and ownCloud to 11.x when you are ready. Owncloud recommends you are updated to ownCloud 10.16.x before updating to ownCloud 11.x. The new container will adjust the php version to what the installed ownCloud version requires. I believe the best migration path for minimal probems would be: Make a backup of your appdata/ownCloud/ directory before performing any update. Update the docker container when it is avaiable. This step by itself addresses the latest php security issues but leaves you using php 7.4 that is at EOL. Run ownCloud for a while to be sure there are no issues. Update the MariaDB database to 10.11. This step updates MariaDB to the latest supported version. Again, run ownCloud for a while to be sure there are no issues. Update to ownCloud 11.x. This step updates to php 8.3 and off of php 7.4 that is EOL. The upgrade for MariaDB and ownCloud are documented in the second post of this forum thread. The steps may change before final release of the updated container. I have done some initial testing and the steps all worked. I'll release a new ownCloud container after some more testing.

Updated ZoneMinder Docker image I’ve updated the image to use Ubuntu 22.04 (Jammy), PHP 8.4, and ZoneMinder 1.38. I tested a fresh install and an update using existing appdata. The database updates completed successfully. I also verified the web UI over HTTP and HTTPS, both directly and through Tailscale. Back up your existing appdata before starting the updated image for the first time. I’ll be spending more time with the new ZoneMinder settings and will share anything noteworthy.

Please hold off on upgrading existing ownCloud installations to 11.x I’m developing a new container that will support both existing installations and new ownCloud 11.x installations. Please don’t manually upgrade an existing installation to ownCloud 11.x until the new image and its migration instructions are ready. The current container is built around ownCloud 10.x, PHP 7.4, and MariaDB 10.6. Changing the ownCloud version before the container can provide the matching PHP and database runtimes could leave the installation unable to start. The plan is to use one image that selects the PHP runtime based on the installed ownCloud version. A new installation will start with ownCloud 11.x, PHP 8.3, and MariaDB 10.11. Existing installations can continue using their ownCloud 10.x version, PHP 7.4, and MariaDB 10.6 until the user chooses to upgrade. Both PHP versions will be included in the image, avoiding a lengthy PHP installation during container startup. The ownCloud application upgrade and the MariaDB engine migration will be deliberate user actions. The container will not silently migrate an existing database. I’ll provide instructions for backing up and migrating the database when the image is ready.

I set it up specifically so you could install the version of LMS that was best for you and the level of risk you wanted to take.

Look at the first post on installing the latest (9.1.1), stable (9.1.2) and dev (9.2.0) versions. They were all updated yesterday.

The PHP security issue has been addressed in the updated image posted today. The larger work is safely modernizing the rest of the stack without breaking existing installations. ownCloud tightly couples its releases to specific PHP versions. Changing PHP to 8.x in the image would prevent older ownCloud versions that require PHP 7.4 from running. The ownCloud upgrade and PHP change need to be tested together, with users able to choose when to make that major-version move. MariaDB also needs attention: the image’s MariaDB 10.6 line is now end-of-life. ownCloud’s 10.16 documentation recommends MariaDB, but its Ubuntu 22.04 example is 10.6.12 and it doesn’t name a currently maintained target. Upgrading an existing database requires preparation in ownCloud, a backup, and MariaDB’s upgrade procedure; it isn’t just a package-version change. ownCloud’s database upgrade guide describes those steps. I’ll plan on the MariaDB upgrade while preserving the current ownCloud/PHP combination, then evaluate the ownCloud/PHP 8 migration separately. I don’t want a container rebuild to force existing users into a major ownCloud upgrade.

After updating the container, you can verify the installed versions with: docker exec ownCloud dpkg-query -W -f='${Package} ${Version}\n' php7.4-fpm libapache2-mod-php7.4

I’ve rebuilt the ZoneMinder container on Ubuntu 22.04 Jammy and included the PHP security fix. PHP 7.4 remains in this build; the move to PHP 8 will be evaluated separately. The build now checks that both php7.4-fpm and libapache2-mod-php7.4 are version 1:7.4.33-31 or newer. After updating the container, you can verify the installed versions with: docker exec Zoneminder dpkg-query -W -f='${Package} ${Version}\n' php7.4-fpm libapache2-mod-php7.4

Thanks for the detailed report and for identifying the PHP issue. I’m rebuilding the existing container so the PHP security fixes are included in the image. I’m also adding a build-time version check to prevent an image from being built with the vulnerable PHP package. Users with automatic OS updates enabled should restart their container and verify the installed php7.4-fpm version. Moving to a PHP 8.2-based ownCloud image is a separate effort. It will require compatibility testing, so I’m keeping this security rebuild on the existing PHP version while I evaluate that change. I also saw your report about the web updater timing out while creating a checkpoint. I haven’t addressed that in this rebuild; I’ll review the nginx timeout handling separately. I recommend using the container’s Tailscale support to access ownCloud privately, rather than exposing it directly to the Internet.

The Event Server was having issues on the initial Tailscale implementation release connecting to the Event Server port 9000. Today's release fixes the Event Server notifications in ZmNinjaNg.

Tailscale support addedThe ownCloud container now supports Tailscale for secure remote access without requiring public DNS, router port forwarding, a static public IP address, or a publicly managed SSL certificate. I have tested the following through Tailscale: ownCloud browser access ownCloud Android application access File uploads and synchronization Tailscale-managed HTTPS certificates Because ownCloud uses an internally generated self-signed certificate, set the Tailscale Serve Target to: https+insecure://localhost The Tailscale WebUI and client URLs must not include the container’s :8443 port. Including the port connects directly to ownCloud and presents its self-signed certificate instead of the trusted Tailscale certificate. The container’s Tailscale hostname must also be added manually to the trusted_domains array in ownCloud’s config.php. Complete setup, client configuration, certificate, and rollback instructions have been added to the first post in this thread.

Tailscale support addedThe ZoneMinder container now supports Tailscale for secure remote access without requiring public DNS, router port forwarding, a static public IP address, or a publicly managed SSL certificate. I have tested the following through Tailscale: ZoneMinder browser access ZoneMinder API access zmNinjaNG access Tailscale-managed HTTPS certificates ZoneMinder uses an internally generated self-signed certificate, so the Tailscale Serve Target must be set to: https+insecure://localhost This allows Tailscale Serve to connect to ZoneMinder internally while presenting a trusted Tailscale certificate to clients. Complete setup and testing instructions have been added to the first post in this thread.