We have a project that has been in production for months (all its configs were working fine, no issues - including https and user access).
We rewrote part of code under Symfony 4 (no framework was used before that). Everything works perfectly on local, but, in production we started getting the following error in logs:
vendor/composer/ca-bundle/src/CaBundle.php is_dir(): open_basedir restriction in effect. File(/usr/local/etc/openssl) is not within the allowed path(s)
Any idea what might cause that (well... the error is obvious and one fix would be just to include that in allowed paths, but I don't want to do that until I understand the root cause of the problem)?
Important notes:
We did not include that particular bundle, is part of the composer.
Composer doesn't fail and no errors are received during composer install command.
The project SEEMS to work as expected despite the log line.
We have Cloudfare in front and https certificate is correcty handled there.
The list of used bundles is rather short but if needed I can provide a list.
We make no specific calls to functions from that bundle (if any are made, are made by something in symfony/3rd party bundles but a quick search in all code (including vendor) revealed nothing).
I'm kind of running out of ideas what might be causing the problem, especially since it doesn't happen on local and even in production the project seems OK.
The CA-bundle is trying to read from the usr/local/etc/openssl, and it fails because it's not in one of the allowed directories for the PHP process.
It happens in one machine and not in the other because your local openbase_dir settings do not match those in production (and are likely to be much lax, as it usually happens on development).
Your have two options:
Change your openbase_dir setting on production so it's more permissive, at least for that specific virtual-host.
Check which package you are installing depends on Ca-Bundle, and remove that package so it's no longer included.
Further reading:
How to set for specific directory open_basedir
Composer: how to know a package by what other package is required
Related
I am trying to get a Laravel 8 project up and running on Hostinger's shared hosting. I realize I'm already complicating things but have successfully set things up besides the components. I am using Povilas' Quick Admin Panel (Livewire ver), and it's this that requires components that are only 'missing' when on production server. Everything runs smoothly on localhost.
I've read that this may be caused by namespace issues - the environment may have case sensitivity (if so, how can I work around?). Other posts explained how each component should be visible in Http\View\Components as well as in resources\views\components. I've also read something on the existence of default/packaged components but can not find documentation on these individual ones.
I am looking for components 'x-application-logo', 'x-dropdown', 'x-dropdown-link', 'x-responsive-nav-link', and more. I do not see ANY of these in my local files, yet it all works fine in a local environment.
Yes, I've seen very many similar questions asked. However, in all of those cases, the askers were able to visually locate their component files, or were using self-declared components...
Has anyone working with Quick Admin Panel had similar issues?
I've attempted:
php artisan cache:clear, config:clear, view:clear,
php artisan optimize,
composer dump-autoload,
recompiling with npm then reuploading files,
composer install (and composer2 install)
I ended up installing a fresh instance of Jetstream to copy over its source files. After a few tweaks I got something to work without errors... As I've come to find out, the entire admin panel that I was working with had wiped itself, and for some reason started requiring an instance of Jetstream?? I have no recollection of touching any sort of configuration regarding this, so either there's a carbon monoxide leak in my home, or Hostinger is deciding to automatically mess with my Laravel files for one reason or another. Thankfully I have a proper local version of my project, which I will use to reattempt.
I've been running a project written in Laravel which has been fun to use.
The setup I use is the vagrant box Homestead configuration so I do the majority of my work on my local machine and push up to the development server once its ready to go. During the installation I had to push up the logs & vendor folder for it to work properly but now I'm at a stage where every commit I do via the command line includes storage/logs/laravel.log which when I then pull down it asks me to stash/commit on the server because they're different.
I've added it to the .gitignore file in the root directory of the project and it looks like this:
/node_modules
/public/storage
/.idea
Homestead.json
Homestead.yaml
/storage/logs/
/vendor/
Vendor doesn't cause me any problems unless I make changes to it so its not much of a bother, its just the logs which will not stop going up. If I use a GUI tool, I can manually tell it not to go up but I want to get it to the point that I can use the terminal to push it up and not worry about logs need stashing on the server.
I believe this is the same for the .env so I imagine a solution will work for both. I have also noticed that PHPStorm have said they're ignored but tracked with git if that helps.
If you take a look at the Laravel repo on GitHub, you'll find the following .gitignore file in the storage directory:
https://github.com/laravel/laravel/blob/master/storage/logs/.gitignore
This comes with the default installation to mark the logs directory as ignored. If you've deleted this by mistake, you should be able to reinstate it and resolve the issue you're having.
Just as importantly though, your workflow isn't following best practice. With respect to "Vendor doesn't cause me and problems unless i make changes to it" - you should never make changes to your vendor directory. This folder is home to third-party packages and plugins, modifying them directly causes multiple issues, chief amongst them:
You can no longer update a modified package without breaking your application.
Other developers won't be able to replicate your installation easily.
In fact, the vendor directory shouldn't be versioned at all. The best way to handle the files within it is using a package manager, like Composer, to do it all for you. This means you can easily switch between different versions of your packages and, by versioning only the composer files, other developers can run composer install or composer update to synchronise their development environment to yours quickly and accurately.
I've got a php-fpm 5.3.10 installation running on Ubuntu 12.04 on a remote server, and I'm trying to use PHPUnit from within PhpStorm 8 (as of yesterday). I don't have a local php installation.
I have installed PHPUnit on my server and can use it via the commandline.
I have (seemingly) successfully linked my PhpStorm to my remote server and remote interpreter, and configured the right deployment settings.
At first I had an issue where it would try to run my local paths remotely, but that issue has been sorted. However, I keep getting the error Cannot find PHPUnit in include path (.:/usr/share/php:/usr/local/bin). This is almost certainly a serverside error (PhpStorm also knows these include paths, it could be confusing them for local paths) as the paths change when I change my include path in my php.ini.
This is the same error it gives back if I don't install PHPUnit at all, so again it would seem this is a serverside issue.
I have tried installing PHPUnit through PEAR (which is deprecated and soon unsupported by PHPUnit but still mentioned in a lot of PhpStorm tutorials), through Composer (on the remote server, not in PhpStorm) and even just manually.
The server accepted these installation methods just fine (the PEAR method seems to install an older version of PHPUnit, 1.0.x instead of the apparently available 4.0.x) but they all give the same issue.
If I manually place PHPUnit in my include path (I'm unsure what kind of files it wants there, though. a .phar? Source files?) it does seem to pick up something, but I get an XDebug error instead and it tells me it can't find the necessary PHPUnit files so I assume it is not the way to go (it shouldn't have to be).
At this point I'm starting to run out of ideas and none of the Stackoverflow responses to similar issues or PhpStorm/PHPUnit documentations seem to be able to help me.
Edit 1: Included picture of settings, as requested.
(can't post images yet, not enough rep)
settings
Other than that it's probably worth noting I'm using a mounted folder for my deployment, which just refers to the filesystem of my server (it's in my local network)
Edit 2: Changed deployment to SFTP as suggested and updated my mappings, as PhpStorm is able to successfully validate my remote environment everything seems to be in order there.
After reinstalling PHPUnit via Composer and selecting the autoloader in my PHPUnit settings it was still giving the error about the include path (it shouldn't do when the autoloader is used, should it?) so I changed the include path to point to /usr/share/php/Composer/vendor/phpunit (and the two directories above it, for good measure).
It was still giving the error, however in the error it says it cannot find PHPUnit in the include path, while the installation is in a directory called phpunit (all lowercase). After changing the directory name to PHPUnit, it is no longer giving the include path error, but en XDebug error instead : Warning: include(/usr/share/php/Composer/vendor/phpunit/phpunit/PHPUnit/TextUI/ResultPrinter.php) [<a href='function.include'>function.include</a>]: failed to open stream: No such file or directory in /usr/share/php/Composer/vendor/composer/ClassLoader.php on line <i>382</i>
I'm unsure what this implies exactly, and I don't know whether the error is because I should not be changing the directory names (it seems as if that should not be necessary), because I haven't changed enough of them (other directories are likely still lowercase) or because these files should simply not be in the include path (composer should be managing my dependencies, shouldn't it?).
In some cases, this can be resolved extremely easily. PHPStorm looks for the folder PHPUnit in the include path(s), but I've found this is case sensitive! Installing through composer will install PHPUnit in a folder called /vendor/phpunit/phpunit/phpunit, this is all lower case. This means that PHPStorm will not be able to find the folder unless you change the folder name to 'PHPUnit'. The include path should therefore be: /usr/share/php/composer/vendor/phpunit/phpunit and in that folder, there should be another folder called 'PHPUnit' (case sensitive!). I'm sure this isn't the prefect solution, but it works.
Now before anyone says "No one can help you with that" please understand that the upgrade worked, this is just a weird bug.
Ok so I upgraded Joomla from 2.5.14 successfully and everything works, nothing out of the ordinary. Every component/module/plugin seems to be working as it should.
HOWEVER the extension manager has a strange behavior, it constantly says:
-1 Copy file failed
I would think file permission problems, but everything is writable. The wierdest thing is it actually installed perfectly, just get this error rather then it saying it worked. (Meaning that when I install the component, there is no error).
This also only happens with components.
Just strange, might be worthy of diving deeper into it in case others run into this with an upgrade. I do not know enough about how the extension manager works to try to identify the problem either, and the lack of a real (or accurate) error message makes it even harder. (the files did copy, so that error message seems out of place)
I will try to look a little deeper in it and see if I cannot isolate it, For those who want to try to recreate it, you can do it by upgrading from 2.5.14 to 3.1.5 though the update manager. The main components I have are no number extension manager, akeeba and admin tools that I feel might have something to do with it.
That most likely is a permissions issue. That error is a RuntimeException thrown by the JFolder class method copy() while trying to copy a file into a folder - src_folder/file to dest_folder/file.
Check your FTP settings in global configuration and then the directories permissions.
I had this error with my module and I did several tests. I removed one level to my image directories from my module and the upgrade finally work...
I've installed Nginx + FPM-PHP under Debian and ArchLinux. Both are working fine. However, I can't figure out how to get the PHP part to follow symlinks. I've also tried with Lighttpd, but to no avail.
Here is what I want to do:
Root directory configured as usual: /srv/http
Symlinks from each project to /srv/http (example: /home/user/projects/site1 to /srv/http/#site1), in such a manner that to test a local development, I just need to add the name of the site to the URL: "http://localhost/site1/xyz" or "http://localhost/site2/abc", etc;
I can make it work (after fixing permissions) with html and other static files, but whenever there is a PHP script, I get the famous "Primary script unknown" error. Inside the "real root" directory (/srv/http) there is not such an error. But when I tried to copy a subdirectory to another location (ie /home/user/projects/xyz) and symlink it to /srv/http/, I get that error.
I've followed many tutorials, including excellent posts by a Danish guy. But I can't make it work. I've tried to use all combinations of "fastcgi_param SCRIPT_FILENAME", ALIAS, etc, including hardcoding another directory into it to make sure this was (or not) the cause of the problem.
So, here are the questions:
Is it possible to use symlinks for PHP execution under nginx or lighttpd?
This setup is for development only, is there a reason not to use it?
What kind of magic would be necessary to make it work?
Since the target environment is going to be nginx (there are other projects already working), I would like to stick to nginx for development, if possible. For the sake of speed, I would also use lighttpd too. I would like to avoid Apache (only because of resources), if feasible.