I have root access to my dedicated server, and when I run phpinfo() it says my php.ini file is in the etc/ directory, using ssh i can't seem to find it there, i don't know where i can find it thanks :))
This may not be a question for SO, but here's a couple potential solutions, all depending on your distro of course:
locate php.ini
Should give you the directory that php.ini resides in (You may need to do updatedb first)
Otherwise, there's always find.
find / -name "php.ini"
As described in the PEAR installation manual, you can discover the ini files that PHP uses by running
$ php --ini
Configuration File (php.ini) Path: /etc/php/cli-php5
Loaded Configuration File: /etc/php/cli-php5/php.ini
Scan for additional .ini files in: /etc/php/cli-php5/ext-active
Additional .ini files parsed: /etc/php/cli-php5/ext-active/php_gtk2.ini,
/etc/php/cli-php5/ext-active/xdebug.ini
a quick command to see which php.ini file you're using via command line / terminal
php -i | grep /php.ini
or
php --ini | grep /php.ini
Related
I'd like to rsync specified files from a specific server folder to my local directory (in which I am running the command).
However, I'm getting the error failed: No such file or directory (2). There seems to be something wrong with my syntax and I'm not sure its picking up the source directory properly
This is my command...
rsync -az . remoteSite.com::remoteFolder/remoteSubFolder/ --files-from=filelist.txt
filelist.txt, which it seems to be finding, contains filenames within remoteSubFolder
file1.xml
file2.xml
etc
What am I doing wrong?
Thanks to #Gordon Davisson.
I now understand that the full stop represents the local directory and goes after the remote host and directory.
rsync -az --files-from=filelist.txt remoteSite.com::remoteFolder/remoteSubFolder/ .
When i tried to configure the webserver through the path cd /opt/nginx/conf/ an error appears /opt/nginx/conf.Hope some one will have the answer here.Thank you
probably your config is under /etc/nginx, to check which directories nginx is using you can use the command whereis nginx
I've created a nginx server in a chroot at /srv/http with php-fpm. Both services use the http user and it works fine. The problem comes when I try to run an exec command such as
echo shell_exec('/usr/bin/ls');
There is no output at all on the web page or in the errors. I've also tried
error_log(shell_exec('/usr/bin/ls');
and still nothing.
Things I've Tried or Know:
safe mode off
exec enabled
user is http (using phpinfo())
display_errors = on
error_reporting = E_ALL
sudo /usr/bin/chroot --userspec=http:http /srv/http ls works fine
Can create file and read from it using file_puts_content and fopen/fread
tried shell_exec,exec,system, and passthrough - nothing worked
tried appending 2>&1 to the end of the command and nothing
I've copied all the executables and libraries necessary over
all libraries, binaries, and everything under /srv/http/www (where the webpages are) have executable and read permissions
doc_root is www
As far as I know, everything works in the chroot, except shell commands through php-fpm. Anyone have any idea where I went wrong and how to fix it?
This may sound stupid but you must just copy /bin/sh (not /bin/bash!) to you chroot.
For example see this question: How do I change the shell for php's exec()
If you chroot to some directory, then this directory becomes the root for all your PHP scripts. That means, that if you execute /usr/bin/ls from within PHP, it will try to exectue /srv/http/usr/bin/ls instead.
You can copy the executable to that directory - but be aware of the security implications. If you copy critical system executables into the chrooted directory you basically bypass the positive effects of chroot.
I get no output for
echo shell_exec('/usr/bin/ls');
either. Presumably because ls isn't a file but a built-in command. Running:
echo shell_exec('ls');
outputs:
css demos favicon.ico images js path.php robots.txt routing.php test
which is the list of files in my root directory for the site.
I've recently installed PHPUnit on a Mac (10.8.3) (running PHP 5.4.7). When I attempt to a run a test phpunit testfile.php for example, I receive:
Warning: require_once(File/Iterator/Autoload.php): failed to open stream: No such file or
directory in /Users/myusername/pear/share/pear/PHPUnit/Autoload.php on line 64
Fatal error: require_once(): Failed opening required 'File/Iterator/Autoload.php'
(include_path='.:') in /Users/myusername/pear/share/pear/PHPUnit/Autoload.php on line 64
The file, /Users/myusername/pear/share/pear/File/Iterator/Autoload.php exists.
php.ini correctly lists the pear directories in the include path:
.:/php/includes:/usr/local/apache/lib/php:/Users/myusername/pear/share/pear/
Yet when I var_dump(get_include_path()); inside of the PHPUnit/Autoload.php file, it prints .: as if it's empty.
Dumping the value of php_ini_loaded_file instead, simply returns false.
Using php -i |grep php\.ini and php --ini only show one php.ini being used/loaded:
Configuration File (php.ini) Path => /usr/local/apache/lib
Loaded Configuration File => /usr/local/apache/lib/php.ini
I repeated the var_dumps of the include_path and the loaded_ini_file from a simple test.php file I ran from the command line and they print out the correct info. So something involved with phpunit is not loading the right/any php.ini.
I'm not using any configurations that are different than default - phpunit was just installed on this machine today.
Make sure the php.ini file you are using is the one loaded for cli php. At least on my install of PHP on Linux, I have two php.ini files, one at /etc/php/cgi-php5.4/php.ini, and the other at /etc/php/cli-php5.4/php.ini. If you change the cgi version, it won't by default affect the cli version, and would cause the include path to be empty.
Another place to check is the phpunit.xml file. It has a section to specify the include path. See here for options available. I'm not sure why phpunit would reset the path but this might be a way to solve the issue.
The solution was:
After running
`pear config-get php_bin` -i | grep -E Configuration\ File\|include_path
It showed that Pear was using a different ini path than php-cli was:
Configuration File (php.ini) Path => /etc
Loaded Configuration File => (none)
include_path => .: => .:
Turns out, Pear had been configured by the original/default Mac OS copy of PHP, not by the custom version I had installed later on.
A quick fix that may not be best long-term was to symlink the ini file it was trying to find:
sudo ln -s /usr/local/apache/lib/php.ini /etc/php.ini
Afterwards, phpunit FakeTest commands are work, and the tests run.
Eventually I need to re-install/re-configure Pear to work with the version of php I've loaded.
I'm trying to configure Symfony2 framework in MAMP.
In php.ini I have correctly set date.timezone, however, it appears that MAMP somehow overrides the setting and uses system time instead.
As a result, Symphony's config.php page sends this warning:
Warning: date_default_timezone_get()
[function.date-default-timezone-get]: It is not safe to rely on the
system's timezone settings. You are required to use the
date.timezone setting or the date_default_timezone_set() function. In
case you used any of those methods and you are still getting this
warning, you most likely misspelled the timezone identifier. We
selected 'America/New_York' for 'EST/-5.0/no DST' instead in
/Applications/MAMP/htdocs/Symfony/app/SymfonyRequirements.php on line
434
Symfony fails to show start page until this has been fixed. What would be the solution?
Thank you!
Check if there are two php.ini files in your system. You may be adding the date.timezone line in one of them but MAMP is using the other.
If that doesn´t work for you try adding the following line at the beginning of your web/app.php and web/app_dev.php files, (as the error message suggests):
date_default_timezone_get('Europe/London');
Hope it helps.
I am still working on figuring out why and how MAMP overrides the php.ini date.timezone settings, however, I have found the quick fix solution within Symfony php files, which solved the problem, at least for now.
I added the following bit of code:
date_default_timezone_set ('America/New_York');
-- at the top of Symfony's config.php and app_dev.php files, immediately after the opening php tag, at the very top of the script. This removed the warning message and got Symfony working on MAMP.
I foresee having to add the same code to some other php files inside Symfony as I keep hacking at it, which shouldn't be a problem. Or I may figure out how to override MAMP's overriding.
Still, this is a workable solution.
copy
cp /etc/php.ini.default /etc/php.ini
change permisions
chmod -R 775 /etc/php.ini
edit
sudo vi /etc/php.ini
search for date.timezone and change it to (example):
date.timezone = "Europe/London"
Are you in command line? cause command line may get a different php.ini than MAMP.
To see which is your php.ini from command line, you can do:
$ php -i | grep 'Configuration File'
(reference: How to find the php.ini file used by the command line?)
Try to set "date.timezone" in "/etc/php.ini", or wherever it says is your php.ini file.
You can also change your php.ini file:
$ php -help | grep "php.ini"
-c <path>|<file> Look for php.ini file in this directory
Like...
$ php -c /Applications/MAMP/conf/php5.5.14/php.ini ...
For example:
$ php -c /Applications/MAMP/conf/php5.5.14/php.ini -i | grep 'Configuration File'
If your problem is how to make changes in php.ini file on MAMP PRO, try to edit the template.
File -> Edit Template
You can see in MAMP manual, page 24
More info is here
In MAMP 3.0.1 the php.ini file in the corresponding php folder version you are using has the value date.timezone declared after a semicolon which turns it into a comment rather than a command. In the php.ini in C:\MAMP\conf\php5.5.12 (or your php version) delete the semicolon in line 703 and define your local time according to guidelines http://php.net/manual/en/timezones.php.
Hope this works for you :)
Like Pedro Luz mentioned, you have to set the timezone in your mac's php.ini and not MAMP's.
Don't forget to restart your mac's apache:
sudo /usr/sbin/apachectl restart
This solution worked for me:
[OK]
Your system is ready to run Symfony2 projects