Another Debian 13 question

https://pastebin.com/QHTgQafX
I no longer have the .php-fcgi-starter access right from before I changed it
I get my image from my host provider, can't tell you much more ...

 

just changing the permission without restarting apache fixed my problem.
https://www.scaleway.com/en/dedibox/
with a debian 12 it worked fine, did not check the umask ...

 

glad if it helped
thx for you support

 

Dear Till,
I'm happy that you ping some other peoples using cloud base image.
This is what I find and you can 100% replicate this if you ever want to confirm or denied this, just stating facts:
1. using Debian13 iso that you use when you install OS on bare metal, and install debian via installer (cli), you always end up with umask 0002 (this is true for 13.3 version)
2. by using official genericcloud image raw or qcow2 provided by debian you end up with umask 0022 (this is what you been reporting back), this image is base for any other vps hosters to make template for selling debian vps, and this is the thing I was calling cloud flavored.

imho, the autoinstaller already chmod the culprit files already so changing it there would be simple as few character fix. Some people (like me) still prefer to install OS via iso, as this is sometimes faster way than deploying qcow2 image based disk (i'm talking to you cloud-init).

I understand why you asking me this, even when I wrote many times that I just edit hosts, change ip, install resolved.
But now, I dont use custom bashrc, nor ENV, .profile. But I understand were you coming from, I do that myself with customers, because if you as old as I'm know that end-users lies (or skip information).

Yeah, if installing system thru iso is not a norm anymore, than you are right.

If this is a Debian BUG or just something for psychopaths who still use ISO, I don't know if its a security-add-on because cloud system are more likely on public internet.
I now know I can RIP

 

from https://wiki.debian.org/Permissions#:~:text=The umask of a 'stock,and execute but not write.

loot at https://wiki.debian.org/UserPrivateGroups , it seems something changed in user private groups in debian 13.
I'm not expert but it seems related to what your are saying

 

Other than umask difference, cloud image include systemd-resolved pre-installed, iso does not leave you to pick your poison (systemd-resolved or openresolve).

 

Uh... hijacked thread..
Well.. anyhow..

till.. I managed to figure it out.. apparently this 500 error happened when I moved /var/www to a secondary disk and apparently locked ISPConfig out of setting permissions and such for the folders and files.. When I skipped moving the folder to a secondary disk, it now "works".

However, Let's Encrypt just won't work.. nothing gets into the acme.log file.. I found that if I only have one vhost I can't run acme.sh manually either.. However, adding 00000-adefaultsite.tld makes it multi-vhost capable.. blabla.. you understand more than I do.. and then magically acme.sh works..

However, I still don't get anything in the acme.log when I enable LE+SSL in the ISPConfig GUI for the domain that I want SSL on..

I don't know which logs to check for this - well apparently acme.log is empty still of course.. but are there any other logs? Is server/cron.php running properly? I have no idea... GUI just has the red dot (1) staying for an extended period of time and then disappears.. and when I go into the vhost in the GUI again, both LE and SSL is unchecked - of course.