Issues with cURL connections - error setting certificate verify location - php

We have been struggling with cURL since we've had our new server (no issues previously). In the last 6 months we've searched and tried to fix the issue at the root, with no success.
We are running an Ubuntu 16.04 server, with a Codeigniter project on PHP and Nginx.
The (composer) package we are currently having the issue with is the Mailgun API (which extends the composer package php-http)
Below is the error that we get when connecting via cURL
An uncaught Exception was encountered
Type: Http\Client\Exception\RequestException
Message: error setting certificate verify locations: CAfile: /etc/ssl/certs/ca-bundle.crt CApath: /etc/ssl/certs
Filename: /var/www/ domain /vendor/php-http/curl-client/src/Client.php
Line Number: 137
The only solution that has worked for us so far disabling CURLOPT_SSL_VERIFYPEER, but we've had to do that inside the composer package, which obviously is not a proper solution.
I'm hoping someone here can please shed some light on how we might be able to resolve the issue.
What we have tried so far:
Checked the date on the server
Disable CURLOPT_SSL_VERIFYPEER, but not a viable solution
Set .curlrc file (but issue is that webserver user is executing, so no place to put it?
Checked the /etc/ssl/certs/ folder to see if the files exist.
sudo update-ca-certificates --fresh
File permissions on the folder
root#Ubuntu-1604-xenial-64-minimal /etc/ssl/certs # ls -la ca*
lrwxrwxrwx 1 root root 37 Apr 26 11:17 ca6e4ad9.0 -> ePKI_Root_Certification_Authority.pem
-rwxrwxrwx 1 root root 274340 Mar 8 17:09 ca-bundle.crt
-rwxrwxrwx 1 root root 274340 Apr 26 11:25 ca-certificates.crt
-rwxrwxrwx 1 root root 261889 Jan 18 06:12 cacert.pem
-rwxrwxrwx 1 root root 261889 Jan 18 06:12 cacert.pem.txt

As I have been struggling with this for a long time and haven't been able to find the answer anywhere, but found it due to the help of # Deadooshka in a not so related post, I'll leave my question and answer here.
For me the solution what that the /etc/ssl folder needed execute permission. I have no idea where this has gone wrong, but the solution for me was the following:
$ /etc # chmod o+x ssl
When the permissions were wrong, I could not read the certificate file using file_get_contents(/etc/ssl/certs/ca-certificates.crt) in a PHP script in the web root, executed from the browser. After the fix, the file was read.

Related

Why does switching to secure folder (httpsdocs) break the PHP file upload function

Server version: Apache/2.4.34 (Unix)
NOTE: This is not a Plesk or control panel questions. This is a custom PHP application hosted on a Rackspace dedicated server with no control panel.
I'm trying to utilize an existing SSL certificate for several sub-directories of a domain, but the architecture for the domain separates out two directories for non-secure/secure:
httpdocs
httpsdocs
I copied everything from httpdocs to httpsdocs and also forced traffic to https using .htaccess. Everything worked great until I tried the PHP file upload functionality.
Here's the bit of code that is failing from the secure side:
$path = "uploaded_files/".$row_query[0].'/'.$file_name;
copy($temp_file, $path);
In doing some debugging, I found that the temp file gets created:
/tmp/phpanKT4N
but the error I see in the logs is:
copy(uploaded_files/New Sub Folder/30052_testing.txt): failed to open stream: Permission denied in /var/www/vhosts/.com/httpsdocs/demo/resource/add_resource.php on line 108
I tried changing copy() to move_uploaded_file() but here's the error for that:
PHP Warning: move_uploaded_file(uploaded_files/test/30054_testing.txt): failed to open stream: No such file or directory in /var/www/vhosts/<thedomain>.com/httpsdocs/demo/resource/add_resource.php on line 111
PHP Warning: move_uploaded_file(): Unable to move '/tmp/phpOC9YEF' to 'uploaded_files/test/30054_testing.txt' in /var/www/vhosts/<thedomain>.com/httpsdocs/demo/resource/add_resource.php on line 111
I searched stack and saw that ownership must match, but the permissions appear to be the same for httpdocs and httpsdocs.
The /tmp folder is owned by root:root and like I said this works perfectly from the non-secure folder. The non-secure and secure upload folders are identical:
httpdocs:
drwxrwxr-x+ 8 theuser apache 4096 Sep 22 2015 uploaded_files
httpsdocs:
drwxrwxr-x+ 8 theuser apache 4096 Sep 22 2015 uploaded_files
Is this a configuration, permissions issue, or what?
Figured this out... Ran the following:
First find apache's user:
egrep -i '^user|^group' /etc/httpd/conf/httpd.conf
Result:
User apache
Group apache
Then ran this and it solved all the PHP file upload issues in httpsdocs:
chown -R apache:apache /var/www/vhosts/<thedomain>.com/httpsdocs/
chmod -R g+rw /var/www/vhosts/<thedomain>.com/httpsdocs/

PHP Artisan Tinker Cannot Write to Config Path

I have used Tinker before but suddenly it stopped working, no matter what project, what version, new or existing. I am on a macbook pro 2013, mac os Sierra, iterm2 with zsh. I have researched all over and not found anything of relevance with exception of one reference in stack overflow to https://github.com/bobthecow/psysh/issues/382 which doesn't show resolution, is not laravel specific but seems to be involving the psy shell (all other artisan commands are fine):
vagrant#homestead:~/Code/application$ php artisan tinker
[ErrorException]
Writing to /home/vagrant/.config/psysh is not allowed.
Is the error I am shown. Vagrant is set up through virtual box running homestead-7.
When I ssh into vagrant and ls -la I see the .config folder but cannot access it nor can I mkdir mvdir due to access denied errors. (Which if I am learning from the stack trace below is where the error is being triggered? Top of the trace where the touchfilemkdir is at?) The folder itself is owned by vagrant. I can make out where the error is triggering but I don't know why it could possibly be triggering regardless of what version of laravel I use, whether it is an existing project or a new download.
Within the laravel projects themselves, I have
"laravel/tinker": "~1.0",
in the composer.json and
/*
* Package Service Providers...
*/
Laravel\Tinker\TinkerServiceProvider::class
is located in app/cofig/app.php.
I did run a verbose stack trace though I'm not exactly sure just what it is pointing to as to what has broken or why.
Exception trace:
() at
/home/vagrant/Code/lightpointLP/vendor/psy/psysh/src/Psy/ConfigPaths.php:213
Illuminate\Foundation\Bootstrap\HandleExceptions->handleError() at n/a:n/a
trigger_error() at /home/vagrant/Code/lightpointLP/vendor/psy/psysh/src/Psy/ConfigPaths.php:213
Psy\ConfigPaths::touchFileWithMkdir() at /home/vagrant/Code/lightpointLP/vendor/psy/psysh/src/Psy/Configuration.php:361
Psy\Configuration->setHistoryFile() at /home/vagrant/Code/lightpointLP/vendor/psy/psysh/src/Psy/Configuration.php:409
Psy\Configuration->getHistoryFile() at /home/vagrant/Code/lightpointLP/vendor/psy/psysh/src/Psy/Configuration.php:546
Psy\Configuration->getReadline() at /home/vagrant/Code/lightpointLP/vendor/psy/psysh/src/Psy/Shell.php:82
Psy\Shell->__construct() at /home/vagrant/Code/lightpointLP/vendor/laravel/tinker/src/Console/TinkerCommand.php:53
Laravel\Tinker\Console\TinkerCommand->handle() at n/a:n/a
call_user_func_array() at /home/vagrant/Code/lightpointLP/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php:29
Illuminate\Container\BoundMethod::Illuminate\Container\{closure}() at /home/vagrant/Code/lightpointLP/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php:87
Illuminate\Container\BoundMethod::callBoundMethod() at /home/vagrant/Code/lightpointLP/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php:31
Illuminate\Container\BoundMethod::call() at /home/vagrant/Code/lightpointLP/vendor/laravel/framework/src/Illuminate/Container/Container.php:539
Illuminate\Container\Container->call() at /home/vagrant/Code/lightpointLP/vendor/laravel/framework/src/Illuminate/Console/Command.php:182
Illuminate\Console\Command->execute() at /home/vagrant/Code/lightpointLP/vendor/symfony/console/Command/Command.php:264
Symfony\Component\Console\Command\Command->run() at /home/vagrant/Code/lightpointLP/vendor/laravel/framework/src/Illuminate/Console/Command.php:167
Illuminate\Console\Command->run() at /home/vagrant/Code/lightpointLP/vendor/symfony/console/Application.php:874
Symfony\Component\Console\Application->doRunCommand() at /home/vagrant/Code/lightpointLP/vendor/symfony/console/Application.php:228
Symfony\Component\Console\Application->doRun() at /home/vagrant/Code/lightpointLP/vendor/symfony/console/Application.php:130
Symfony\Component\Console\Application->run() at /home/vagrant/Code/lightpointLP/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php:122
Illuminate\Foundation\Console\Kernel->handle() at /home/vagrant/Code/lightpointLP/artisan:35
If any other information may be required I'll be glad to provide it, I'm truly at a loss as to what has happened or how to fix it.
Thank you
UPDATE AUGUST 31
So I have found that when I am in vagrant#homestead and I sudo su when I then am in root#homestead:/home/vagrant# and I enter .config there is a configstore directory and a psysh directory but it was owned by root. I changed the owner to vagrant, exited, reloaded vagrant and the same error.
drwx------ 2 root root 4096 May 4 00:55 configstore
drwxr-xr-x 2 vagrant vagrant 4096 Aug 31 23:37 psysh
So then I tried sudo -i and got root#homestead but found that the contents of .config were different. This time it has .composer directory and no psysh existing. So I added the psysh directory with vagrant as owner
drwxr-xr-x 2 root root 4096 Feb 26 2017 composer
drwxr-xr-x 2 vagrant vagrant 4096 Aug 31 23:59 psysh
but this still also does not work. I also exited, reloaded vagrant, I config:cleared on both but I get the same unable to write error.
I am so at a loss, any insight would help, please. Thanks!
Answer on https://laracasts.com/discuss/channels/servers/tinker-doset-work-in-shared-hosting?page=1&replyId=604794
#You need to create a config file for PsySH with runtimeDir variable.
# Just create a file ~/.config/psysh/config.php with:
<?php
return [
'runtimeDir' => '~/tmp'
];
Looks like it's an issue with PsySH http://psysh.org/.
I can't answer the question but it looks like this guy had the same issue. It may be worthwhile to get ahold of him and asked how he fixed it.
https://github.com/bobthecow/psysh/issues/382
Have you tried running composer update? Good luck.
I had this exact same issue and it persisted for days. I fixed it by running composer dump-autoload from the project directory. I previously tried the command but it didn't work because I was trying it without internet access, make sure you are connected to the internet when you run the command. Goodluck!
I tried composer update, dump-autoload but nothing worked. Simply changed the permission on the ~./config folder and it worked. You can set 755 or higher (I am not talking about the production environment here).
I've executed the next commаnd on my terminаl:
sudo chmod -R 775 ~/.config

PHP can't see any files on a mounted filesystem

I have a new file server (FilServerB) that I have had up and running for a few months. I've been moving all my processing servers over to use FileServerB for their PHP code. I recently found a server (server name is susan) that I had missed, and it was still connecting to the old file server (FileServerA). When I mounted FileServerB on susan, none of the code would run on it anymore. In ssh, when I go to a directory with PHP code in it, and run "php cleanISL.php", it says this:
Fatal error: Unknown: Failed opening required 'cleanISL.php' (include_path='.:/local/online/live/common:/local/online/pear') in Unknown on line 0
If I create a new php file on the local filesystem, it runs just fine. If I try an is_file or is_directory for a file or directory that I know exists on the mounted filesystem, it always returns false. However, I can glob directories, and it shows the files in there just fine.
I've tried changing (and removing completely) my include_path, I've tried going back to the old file server (which works), and then unmounting the old one and mounting the new one the exact same way (still doesn't work), and a few other things. I can't tell if the issue is with PHP, or somehow with the way the server is mounted, or something else. I've made sure SELINUX is disabled. The issue seems to be only affecting PHP, and only when I mount the new FileServerB, and only on this particular server (susan). But I'm baffled at what could be causing it or how to fix it.
Also, I have mounts to other servers (for data/media) on this same server (susan), and those work just fine, ie, PHP can see and read files on those mounts too.
UPDATE 1, strace info
This is the relevant line of the strace on a failed is_dir:
stat64("/online/live/tools/test/fixes/", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
And this is the output of a stat command on the same dir:
File: `/online/live/tools/test/fixes/'
Size: 4096 Blocks: 8 IO Block: 32768 directory
Device: 18h/24d Inode: 11815229588 Links: 3
Access: (0775/drwxrwxr-x) Uid: ( 1004/ UNKNOWN) Gid: ( 1010/ UNKNOWN)
Access: 2016-07-06 07:28:46.606024801 -0600
Modify: 2016-06-24 16:23:42.206547505 -0600
Change: 2016-06-24 16:23:42.206547505 -0600
And this is a namei -m result:
dr-xr-xr-x /
lrwxrwxrwx online -> /mnt/code/online/
dr-xr-xr-x /
drwxr-xr-x mnt
drwxr-xr-x code
drwxr-xr-x online
drwxrwxrwx live
drwxrwxr-x tools
drwxrwxr-x test
drwxrwxr-x fixes

php apache file ownership and creation problem

I am trying to do a really basic rename of a file to another name in my code. However there seems to be some ownership/permissions problem that is stopping this working correctly.
This is my (simplified) code:
ini_set ("display_errors", "1");
error_reporting(E_ALL);
$St_Num = '7940';
$Co_Code = 'RDCO2';
rename("$St_Num-$Co_Code-1.jpg", "$St_Num-$Co_Code-4.jpg");
These are my permissions of the files I am trying to change:
Code:
-rw-r--r-- 1 apache dev 4065 Oct 22 17:57 7940-RDCO2-3.jpg
-rw-r--r-- 1 apache dev 4276 Oct 28 09:39 7940-RDCO2-2.jpg
-rw-r--r-- 1 apache dev 4336 Oct 28 09:39 7940-RDCO2-1.jpg
This code was working, and it seemed to work when apache was the creator of the file. However, when I changed the ownership to 'apache' it stopped working. Does PHP/Apache have a concept of knowing who the creator of a file was? Would this stop a rename() from working?
I'm stumped with this one now - any help is appreciated.
Thanks,
Picco
do chmod(0666) [on the server] to give all users (including apache) write rights
You have to set read-write ownership for that specific directory to public-www.

Zend Cache - problem with deleting cache files

I have an strange problem with Zend Cacke (File Backend) running on linux with apache and php 5.2
The files are stored in /myspace/tmp1
Directory has the persmission:
drwxrwxrwx 2 nobody nogroup 8192 2010-09-20 13:35 tmp1
The created temp file has the following permissions:
-rw------- 1 nobody nogroup 317 2010-09-20 13:40 content---a51607ba255692370eae1155c7f45856
If if i do:
$cache->clean(); inside my script, than the method returns true, but the file is not removed (no error in php error log).
On my local development machine running under win xp everything works fine. I think it is some kind of permission problem? The Apache is running as "nobody"
Any suggestions are welcome!
I think you need to use Zend_Cache::CLEANING_MODE_ALL as by default it cleans only outdated AFAIK.

Categories