I’m hoping someone can help me figure out what’s going on with my current situation.
I have a PHP application that I have successfully launched via a Cloud environment by using wget to grab a zip of it from a github release, unzipping it into a directory inside “webroot”, then using a symlink inside of “ROOT” referencing the app’s public folder. I go through all the installation steps and can reach the application via my browser. I haven’t had to change any directory/file permissions because the defaults in Cloud are suitable for everything to work properly.
I’m trying to deploy this same app in another environment, but via its git repo master branch using the Development Manager. I set up everything else exactly the same. But in this git repo master branch version, I’m getting a 403 error when trying to go to the associated webpage. I’ve tried specifically running chmod -R 755 for the app directory, but this didn’t fix the issue.
Any suggestions for what’s going on and how to overcome it?
A little bit of additional information now known:
I can successfully install the PHP application using wget and the zip. Then, if I delete this, the zip, and the symlink, and try to install via Dev Man in the same environment, I get the 403. But also, if I then wipe this (and the symlink) and try to install via wget and the zip once again - still in the same environment - I now get the 403 for this too. To get it working again, I have to delete the entire environment and start from scratch.
I’d probably recommend grabbing the error log to see if you get more details on what the 403 is actually complaining about, that’ll help to know the best fix to recommend. You can see logs for an app here:
Thank you so much for this lead!
After trying this again and checking the dummy-host error log, I can see that, when deploying with Development Manager pointed at the repo, the environment is trying to serve up the directory where I have that repo going. I think this means the Document Root for the URL is somehow getting changed to where I told the repo to get loaded (in my case, the directory webroot/kora/)? This is getting to the edge of my knowledge.
Here’s the log:
[Tue Aug 11 01:53:34.811102 2020] [autoindex:error] [pid 23368] [client 192.168.1.17:41703] AH01276: Cannot serve directory /var/www/webroot/kora/: No matching DirectoryIndex (index.php,index.html,index.html.var) found, and server-generated directory index forbidden by Options directive
This is different from when I deploy via wget and unzip, because in this wget way of doing things, the environment never changes Document Root (ETA I’m pretty sure I’m wrong about this; but I can say, when visiting my environment’s URL in this case, it correctly finds the symlink described next), so it remains pointed at webroot/ROOT. I think this is why setting up a symlink inside ROOT/ and pointed at something inside webroot/kora/… works in this wget way of doing things.
Is there a way to, when using Development Manager to point at a git repo, specify which directory is to be Document Root for the environment’s URL? I think this is the question I want to ask, anyway.
Yep, when you use the deployment manager the “Path” setting here is what you want to pay attention to. ROOT should normally be default but if there is already stuff there sometimes it may default to something else.
So, I used PATH to specify the directory into which the repo was transferred; it sounds to me like there’s no way to keep the Document Root as ROOT while transferring the git repo into some other directory.
This answers my questions, thank you.
I may not be following the whole workflow but it’s worth noting you can change the DocumentRoot for an application server fairly easily. That could also be wrapped in a post-deploy hook so it happens automatically after each deploy if necessary.
I’ve double and triple-checked the specified DocumentRoot (in all its locations) in httpd.conf and it wasn’t ever changed from webroot/ROOT
At this point, I think the issue might be with the application and not the environment, but I honestly can’t figure out how to confirm this. As I said, the symlink method works when the app is grabbed via wget and unzipped, but doesn’t work when the app is grabbed straight from the repo master branch by dev man, when everything else is equal. The wget-grabbed zip file is built from the master branch, so it isn’t like there’s a difference between them (aside from a .git folder that’s present in the dev man version; I’ve deleted it and tested with no effect).
But, changing the name of the symlink in the dev man version magically fixes the problem! Which has me at the ‘throw up my hands and decide nothing is meaningful’ stage of this process. I don’t see a single reason why the symlink with a specific name works in one case but not the other, but in the case where it doesn’t work, changing the specific name to something else magically works.
I think this is all to say, thank you Tim for trying to help me out, but at this point I can’t be sure the issue I’m having is with a setting I don’t yet know about in Reclaim Cloud and not instead with the app itself, so I don’t want you to feel like your continued work on this issue is warranted.
1 Like
