HumHub - social network software

[girish]

@atrilahiji ah, great stuff! Ideally, the app shouldn't update itself and the code should be readonly. Is that possible? It's best to keep updates consistent i.e from Cloudron dashboard.

[A Former User]

@girish I can definitely try. Much like Moodle, it has a lot of plugins or "modules" people use. I think in this instance they are all in a single directory though. I'll take a look.

[girish]

@atrilahiji thanks! let me know if you hit any bumps and I can take a look as well.

[A Former User]

@girish Sure, thanks! I'll shuffle some things around in the package and see what I can do. My hope is I can just symlink everything that is needed in a migration to /app/data, which will also make updates a lot easier.

[A Former User]

@girish Actually, I just thought of something. If the modules folder is symlinked and the app is expecting to write to the modules folder in /app/code, it will error right? I imagine it wouldn't just look at the actual folder in /app/data. The trouble here is there is a "module store" of sorts built right into the app.

[girish]

@atrilahiji maybe you can symlink /app/code/modules to /app/data/modules and that way it will become writable.

To give a high level idea, let's say humhub app comes with some default modules. Then, in Dockerfile, you would move them to some other location like:

RUN mv /app/code/modules /app/code/modules_orig && ln -s /app/data/modules /app/code/modules

Then in start.sh:

mkdir -p /app/code/modules
cp -r /app/code/modules_orig/* /app/data/modules

In many apps, instead of the blind copy above, we try to symlink each "module". So, there will be a symlink from /app/data/modules/x to /app/code/modules_orig/x . This sometimes works or not depending on the app. But hopefully you get the idea!

[A Former User]

@girish my confusion here is if the app still tries to write to /app/code/modules it would hit permissions issues no?

[A Former User]

@girish Running into issues here: https://docs.humhub.org/docs/admin/installation/#file-permissions

There appears to be no way to configure where Hubhub looks for those files, so it will just keep trying to write to the symlink in /app/code and fail. In fact, you cant even get the site to load after installation without having the assets directory writable. This is something it has to do on startup. I can still make an update script for this, but I think it will have to sit in /app/data just based on how this was written. Unless I'm missing something?

[fbartels]

@atrilahiji said in HumHub - social network software:

if the app still tries to write to /app/code/modules it would hit permissions issues no?

no, that should not be the case (at least when the symlinked dir has proper permissions for this).

[A Former User]

@fbartels Weird... it seemed to think it didn't have permission to write...

[A Former User]

[scooke]

@atrilahiji Never stop never stopping! You're doing great!

[fbartels]

@atrilahiji can you push your current wip? I'd like to give the code a look.

[A Former User]

@fbartels Sure thing: https://git.atridad.dev/alt-ron/cloudron-humhub-app/-/tree/harden-app-code

Thanks! I'm convinced this is 1) impossible or 2) something so simple yet I have not noticed it somehow

[fbartels]

@atrilahiji for me this works with

➜  cloudron-humhub-app git:(harden-app-code) git rev-parse --short HEAD
0b5df1c

Steps I tried:

• Install app (in debug mode, but only so that i could override and start the start.sh manually)
• finished Humhub installation
• went into admin and selected modules
• installed a module
• activated a module
• no php error can be seen

[A Former User]

@fbartels Huh so you manually started start.sh from the terminal in recovery mode? I get the exact same error doing that. Did you do something else to modify the permissions?

[fbartels]

@atrilahiji no, no changes at all. maybe some leftovers from a previous installation of yours?

Yes, you can run cloudron install --debug where then the init script is not run. you then need to exec into the app and run it manually.

[A Former User]

@fbartels ahhh I see what you mean. I'll try that.

[A Former User]

@fbartels Oh weird yeah that works... no clue why it wouldn't work if the start.sh is run normally during an install...

IDK if you saw the same error but if I don't start in debug mode and switch to Recovery Mode, running start.sh results in a permission error for PHP again.

EDIT: Nvm I think I figured it out...

[fbartels]

@atrilahiji ah nevermind, i forgot that part of debug is that the container is not read-only. Looking at the code now a bit closer.