harald@hub.volse.no

@*jayrope Normally you should have one php.ini that is the base used by all PHP apps. This is typically located in /etc/php/php.ini on most Linux based systems. Adding the setting there should set it for all apps.

You can override specific settings in the php-fpm or apache configuration for each app if they need something specific.

@*jayrope Add it to your php.ini file.

@Mark Nowiasz Absolutely agree! Definitely apply the mitigation, but be aware it's not sufficient for all (most?) attack vectors.

@Mark Nowiasz Thanks, that's a likely stopgap measure for one of the problems, the other is not so easily mitigated. It's still advisable to upgrade as soon as the patch is dropped.

@*_jߍyrope Associating with the Romans should always be a choice. After all, what have they ever done for us?...

@*_jߍyrope The nice thing about magic potions is the magic :)

Not sure how much of the Mastodon API they need, or how much effort it would be to implement that in Hubzilla. However, like pretty much everything else in Hubzilla the API system is designed to be extendable. Inquisitive minds could probably look into implementing the required parts. Could even be done as an addon :)

@Hubzilla Support Forum

Is there anything which could be done about it?

Sure, we could implement the fields, and possibly API's needed to conform to whatever they are looking for. Looks like it could be just some profile fields in the webfinger response.

@Hans van Zijst There's a few things I can think of: Check your xconfig table. I've had issues with it growing a lot for different reasons in the past. Sometimes the real size of the data may be way smaller than the space they occupy on disk, due to frequent updates leading to fragmentation.

You can find some useful queries in framagit issue #1927.

In that case it seemed some indexes had disappeared from the database, which is also worth checking. That caused a lot of duplicate entries in the db.

Another issue I've seen more recently was that the queueworker built up a huge number of jobs. This seems to be due to trying to fetch parents and all downstream comments from messages arriving at the hub somehow. Check the queueworkers page in admin, and the workerq table in the db.

Again, this table is updated frequently, so may be subject to fragmentation.

See framagit issue #1972 for some more background on this.

Other than that. Just see which table are taking up the space in your DB. It should be the items table, and pretty much everything else should be small in comparison. If that's not the case, some investigation is needed.

Good luck!

@𝓒𝓱𝓻𝓲𝓼 https://framagit.org/hubzilla/core/-/merge_requests/2338

@Der Pepe (Hubzilla) ⁂

no, there’s no suitable documentation…

But there are people willing to help you understand. Ask the community (not some slop machine,) and we all learn in the process!

@Jupiter Rowland I don't think anyone is arguing that Hubzilla should not be accessible, but getting it there is work someone has to do.

Demanding that someone else should spend their free time on this will not get us there.

@Saiwal That was easier than I feared. Seems to fix the issue.

Now, to analyze if those headers are secure or not...

@Der Pepe (Hubzilla) ⁂ I think we already cocluded with that. I hope to get time to look into it today.

@Alfred Bühler Thanks for confirming. It seems to be something with my setup that's borked.

@Saiwal Thanks. Definitely on my end, then... Yay, another thing to debug :/

@Saiwal Thanks, probably on my end then. Just to be on the safe side, which version are you running? I'm on 11.4.1.

@Mario Vavti But do we still want it as an addon, or would it be just as well to integrate this into core directly?

@Alfred Bühler Yes, when you know how. WordPress is even easier, but they still benefit from being a "one-click" option in cpanel and other common site admin tools.

@𝓒𝓱𝓻𝓲𝓼 I agree!

Most likely a shared hosting provider will have something like cpanel or similar management tools installed. Which will make things like scheduling tasks and stuff easier.

Perhaps making some sort of cpanel-integration would be a good investment.

@𝓒𝓱𝓻𝓲𝓼 There's an intro to crontabs and scheduling tasks here: https://en.wikibooks.org/wiki/Guide_to_Unix/Explanations/Scheduling_Jobs

The FreeBSD Handbook also has a decent section on scheduling and cron here: https://docs.freebsd.org/en/books/handbook/config/#cron-periodic

(The periodic system I believe is particular to FreeBSD.)

While there's no need to be an expert to host a Hubzilla server, a bit of basic unix knowledge is very useful :)

I think the idea is cool! The data should already be available via the Hubzilla API, so it should be possible to do this without any significant extra work on the server side.