Skip to main content ↑ ↓
Topic: Non-standard upgrade/maintennance for containerized. (Read 925 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Non-standard upgrade/maintennance for containerized.

For various reasons that are not important here, I run elkarte in a podman container. This particular container is a php-nginx setup , with php 7.4, and latest nginx. Using Caddy 2 as a reverse proxy, and for automatic certificates. The platform fits into other things I am doing with the server(s), and is a primary consideration. Nevertheless this setup has some gotcha's.

I don't have ftp on the platform, so there is no mechanism to download and install packages through the elkarte admin mechanism. I can ssh into the container, and I can manually download and unzip files, alter permissions, etc. I am currently running 1.1.5, and would very much like to urgently upgrade to 1.1.8 (via each intermediary release, presumably). If I download a patch (1.1.6) I can't seem to trigger an upgrade (permissions? database schema?). If I download the install package, i have to install a complete instance, and set it up, and I don't see an obvious mechanism to get it to reflect the existing site.

Currently the container I am using is /webdevops/php-nginx:7.4-alpine. At what point between 1.1.5 and 1.1.8 can, or should, i upgrade this to php8?

Clearly, this is not as intended, but I would appreciate any advice as to a possible mechanism to investigate to best achieve upgrades.

Additionally my existing site, for historical reasons does not conform to a secure site. It has mixed content from other sources. I think because of the members use of external images. I can make them stop that, but i would appreciate any pointers as to what to look for, so as to achieve conformance, and how that might impact what I need to do on the server (increase storage space, and image size, so that pictures can be uploaded locally before being used?).

I've had a look around, and there are various hints to some of this, but i would appreciate opinion based on currently where things are.

I'd also like to remove bbcode, and use markdown, and change my historical mysql (mariadb) database for postgres (which containerizes more elegantly, and I can provision via an operator for HA).

Thanks in advance for your comments.

Re: Non-standard upgrade/maintennance for containerized.

Reply #1 –

Quote from: tetricky – For various reasons that are not important here, I run elkarte in a podman container. This particular container is a php-nginx setup , with php 7.4, and latest nginx. Using Caddy 2 as a reverse proxy, and for automatic certificates. The platform fits into other things I am doing with the server(s), and is a primary consideration. Nevertheless this setup has some gotcha's.

I run my development environment in docker containers so I understand some of what you are doing.  I actually run each "thing" in its own container, so nginx is in one, my php version of choice in another, and then my db of choice in another.  It lets me say stop php7 and start php8.   Same for the db, which works swapping mysql to mariadb, but generally those all have their own files so its not a clean unnoticeable swap.

Quote from: tetricky – I don't have ftp on the platform, so there is no mechanism to download and install packages through the elkarte admin mechanism. I can ssh into the container, and I can manually download and unzip files, alter permissions, etc. I am currently running 1.1.5, and would very much like to urgently upgrade to 1.1.8 (via each intermediary release, presumably). If I download a patch (1.1.6) I can't seem to trigger an upgrade (permissions? database schema?). If I download the install package, i have to install a complete instance, and set it up, and I don't see an obvious mechanism to get it to reflect the existing site.

To upgrade to 1.1.8 you can download the full package, unzip it over your existing install, then point your browser to yourInstall/install/upgrade.php and it should go from there.  However if you have done modifications, addons, themes, tweaks, hacks etc then you will need to step through installing patch files in sequence.

Of course please always make a backup for your install and db, it only takes a few minuets and avoids loosing a pair of undies if things go wrong.  There should be nothing preventing you from installing FTP in your container, you can always stop the FTP service when you are done.  Just to note, the FTP client in ElkArte is in need of an overhaul, its not IPV6 aware and its not really TLS capable either.

Quote from: tetricky – Currently the container I am using is /webdevops/php-nginx:7.4-alpine. At what point between 1.1.5 and 1.1.8 can, or should, i upgrade this to php8?

Clearly, this is not as intended, but I would appreciate any advice as to a possible mechanism to investigate to best achieve upgrades.

1.1.8 should be working just fine on 8.0.
Quote from: tetricky – Additionally my existing site, for historical reasons does not conform to a secure site. It has mixed content from other sources. I think because of the members use of external images. I can make them stop that, but i would appreciate any pointers as to what to look for, so as to achieve conformance, and how that might impact what I need to do on the server (increase storage space, and image size, so that pictures can be uploaded locally before being used?).

I've had a look around, and there are various hints to some of this, but i would appreciate opinion based on currently where things are.
That is what the image proxy is used for.  https://elkarte.github.io/addons//enhancement/Image-Proxy.html  It will create a local version of the http image so it can be served from your https site.  That addon will optionally purge the local images after some time of them not being accessed (to conserve space).  If someone goes back to an  old post it will re-download the image, assuming its still available (thats the risk of the purge). Also what it creates locally is a reduced size image to avoid being a scrapper, so its space efficient.

Quote from: tetricky –
I'd also like to remove bbcode, and use markdown, and change my historical mysql (mariadb) database for postgres (which containerizes more elegantly, and I can provision via an operator for HA).

Thanks in advance for your comments.
That can be done but it would require an addon to fully work.  The markdown processor is contained within ElkArte but not integrated with the editor.  I did some basics of this in the SimplePortal addon, where it allows you to use markdown in the articles section.

Re: Non-standard upgrade/maintennance for containerized.

Reply #2 –

What I am thinking to do, based on your reply, is the following:

Spin up a php8-nginx container, copy the existing files into it, unzip 1.1.8 in the directory, run the installer against the (backed up) database. Then I can point to that container with my reverse-proxy, and run the installer. Should that work? Are there any file permission changes I need to consider?

If I wanted to install the image-proxy, can that be done manually, or will I need to install an ftp server and connect to that via the package management? I have no experience with ftp servers (except years ago when provided by a hosting company). What should I be looking for? The containers I'm using are alpine, to stay low resource. in principle I could use something else (and swap later).

In installing the image-proxy, can it correct existing problems? Do I need to increase, or otherwise modify, settings in elkarte to accommodate it?

Thank you very much for your quick and helpful answer.

Re: Non-standard upgrade/maintennance for containerized.

Reply #3 –

Sounds like that will work.  Again as long as you have not installed addons or made your own file tweaks, simply copying the 1.1.8 files over your existing install is the fastest way to go.  Then run update which will make any db adaptions needed (I honestly do not remember if there were any from 1.1.5)

You should be able to simply copy the image proxy zip to your packages directory and go from there.  I'm not sure why you are seeing permission issues.  With Nginx I'm assuming you are running php-fpm, so in its web pool config it should be set to the uid/gid of the actual web site files.  That way 755 on dir and 644 on files will be fine and PHP will be able to do what it needs to do permission wise.

I'm not sure what ftp options you have on Alpine, I do run that as well in my containers but have not had the need to set FTP up in them.  If you do, don't bother with any TLS since as I said the FTP client in ElkArte will not be able to use that. 

Re: Non-standard upgrade/maintennance for containerized.

Reply #4 –

Thank you very much. I'll give that a go.

Re: Non-standard upgrade/maintennance for containerized.

Reply #5 –

I'm working some more on this, but coming across other problems that may be related to my environment of choice.

I don't recall how email works on the forum (it obviously doesn't in my setup). I would like to try to get it working for password retrieval and the suchlike. I haven't been able to find any obvious information or guidance. Within this containerised environment, is there anything I can do to get email send working for these purposes? What might I need? I have a suitable email provider, but I need somewhere to set up the forum to use that account!

I have had this working years ago, under a different setup, but I just can't remember how, or see what I need to do. Any pointers would be much appreciated.

Re: Non-standard upgrade/maintennance for containerized.

Reply #6 –


Quote from: tetricky – I have a suitable email provider, but I need somewhere to set up the forum to use that account!
Have a look into ACP > Maintenance > Email > Settings. There you can set up the email sending process, you can use an external SMTP or use PHP.

Re: Non-standard upgrade/maintennance for containerized.

Reply #7 –

That's where it is! Thank you!

Re: Non-standard upgrade/maintennance for containerized.

Reply #8 –

The upgrade process I suggested didn't work for me.

The upgrade script wouldn't run under php8, so I went for running the upgrade under 7.4 and then I was planning to upgrade the container to php8.

The database amendments seemed to run (took four hours!), but the upgrade script hung after that (I could see in the container logs that the database changes had been made).

Any attempt to access the site put me back to the upgrade script. Which wouldn't run. I could delete the install directory, and then access the site, but the theme was all borked.

I attempted to install the bare install package, but couldn't run the upgrade script, without an ftp server.

So after around 6 hours, I'm pretty much back where I started, running the backup site on 1.1.5.

Re: Non-standard upgrade/maintennance for containerized.

Reply #9 –

I've tried various ways of containerizing an ftp server, to access elkarte's html directory...but there are various levels of permission problems that means this is not a productive avenue to pursue.

Is it actually possible to run an upgrade of elkarte (I'm starting from 1.15), without having a functioning ftp server? My current guess is not.

Re: Non-standard upgrade/maintennance for containerized.

Reply #10 –

You can try running the individual patch files 1.1.5->1.1.6->1.1.7 etc 

You can upload those with the package manager and see if they will install, it all depends on what permissions PHP has in your directories. 

I'll assume you can SSH into the constrainer as root or do sudo -s and then simply chmod files and directories to 777 for the upgrade and then set them back to 644 and 755 or whatever they need to be for your setup (if you need to)