I run some PHP websites on a FreeBSD server which was recently updated to PHP 5.2.17, after which exec("something") stopped working, and I was required to write exec("/full/path/something").
Since the scripts run on different machines where executables are in different places writing full paths is not acceptable.
Running passthru("set") from PHP reveals the PATH variable (for user "www") to be:
PATH=/sbin:/bin:/usr/sbin:/usr/bin
I need PATH to point to the PHP safe_mode_exec_dir directory:
PATH=/usr/phpsafe_bin
Running putenv("PATH=/usr/phpsafe_bin") in PHP resolves the problem, but I need a solution that fixes the problem on a global level for all PHP scripts running on this machine, in other words changing php.ini, Apache settings, or other system settings.
Hope someone can provide a good solution to this, maybe even an explanation why this changed in the PHP update. There seems to be no PHP documentation on how the search path for exec() and friends is determined.
It's not a pleasant solution, but it's all I could think of. Create a script file that does the change you've suggested and then use the "auto_prepend_file" in php.ini or .htaccess to include this script. Then in effect every php script that is run will have this file run before it gets executed and thus your directory is changed.
Caution: You need to be very careful using this since any errors, extra white space etc in the prepend script can break whole pages, existing features such as download scripts, or any number of unknown effects.
Read More: http://php.net/manual/en/ini.core.php
Related
Search on DDG and in here didn't get any interesting results. I've heard they're different, but I want to know what makes them different and what advantage is there in having two different configurations ?
EDIT : Yes, I am running them both from the CLI.
phpinfo() is a language function that will display its output regardless of whether the script that it's executed in is called through the web SAPI or from CLI;
php -i is purely a command line switch to get information about PHP from the command line.
Why different configurations for web sapi and for CLI? Because you might have different requirements; often devs will run long command line scripts and don't want the web sapi timeout applied, similarly with memory settings; and max file/post size ini settings are meaningless for CLI, so why bother having them in the cli ini file when they're only needed for the web?
Depending on your server distribution, there may be separate php.ini
files for the command line and web server.
Source:
Pro PHP
Patterns, Frameworks, Testing and More
By Kevin McArthur
https://books.google.pl/books?id=CpUhDavmgSMC&pg=PT410&lpg=PT410&dq=%22php+-i+command%22&source=bl&ots=iljmNZ96ZU&sig=iRrX8_UjJWiOzlLtRz0zwJOtQJc&hl=pl&sa=X&ved=0ahUKEwicoq6NrsLLAhVjQZoKHeSSA8wQ6AEIPDAE#v=onepage&q=%22php%20-i%22&f=false
php -i gives you the same info you got using phpinfo() but:
can use a different set of INI files than your web server (so you can different values for some configuration parameters)
it formats the data in a console-friendly way (no html tags, for example)
Edit:
don't digged the sources, but I can bet both uses the same code to extract their info .. in other words php -i is "calling phpinfo()" in a console-aware way and context
I know this may be a long and general question but I am struggling with it for the past two days and have achieved nothing.
I am a C# .net developer and I use Visual Studio IDE for my development which does all the back-end work for me when creating projects, setting virtual hosts, publishing the project and etc.
Now for some reasons I have to do a project in PHP and I chose PhpStorm as my IDE. I installed XAMPP and the Apache server is working ok, and I set its' php executable as an php interpreter in PhpStorm.
I don't want all my projects to be in xampp/htpdocs so I choose another location (d:\projects\phpStorm\<name of the project>) as my working space when I first created a project.
I installed xdebug using the tutorial it gave me:
Download php_xdebug-2.4.0rc4-5.6-vc11.dll
Move the downloaded file to C:\xampp\php\ext
Edit C:\xampp\php\php.ini and add the line
zend_extension = C:\xampp\php\ext\php_xdebug-2.4.0rc4-5.6-vc11.dll
Restart the webserver
And I can confirm that it is installed using phpinfo() in a php file located in xampp/htpdocs.
My problem is with the debugging. When I click Run->Run in an opened php file in PhpStorm, it uses a free port and opens the php file with a url like this: localhost:port_number/<name of the project> and everything is ok.
Now I followed this tutorial to configure the xdebug. In step two, when I go to Run->Web Server debug validation, fill the Path to create validation script with d:\projects\phpStorm\<name of the project> and Url to validation script with localhost:port_number/<name of the project> (as mentioned above) and click validate I get this information (and an error in the last line):
Server Name: PhpStorm 10.0.3
Loaded php.ini: C:\xampp\php\php.ini
No debug extension is loaded
Follow this links to configure Xdebug or Zend Debugger. If you have
already configured debug extension in php.ini file check possible
reasons why it was not loaded:
You forgot to reload web server after changes in php.ini file.
You are configuring debug extension in the wrong php.ini (see the
loaded php.ini files below).
There are errors on attempt to load debug extension, e.g. version
incompatibility.
I want to know what should I do?
I really really want to set my projects in another location other than xampp/htpdocs to organize them properly, just like I do it in Visual Studio. So please don't suggest solutions involving me changing my working directory.
Thanks in advance.
P.S.: In JetBrain's tutorial, I see that the xdebug's IDKEY is PHPSTORM whereas mine is my pc's username, it it ok?
I really really want to set my projects in another location other than xampp/htpdocs to organize them properly, just like I do it in Visual Studio. So please don't suggest solutions involving me changing my working directory.
Well you're really going to hate this then, but unfortunately Apache (which is what php runs on) only recognizes htdocs (or public_html, or www, depending on what specific server you are running, but anyhow in your case only htdocs) as a valid directory for php execution. Sooooo...
That doesn't really mean this is hopeless, but you might have to jump through some silly hoops to get it to work this way.
Option 1
You may have some luck creating a symbolic link from .htdocs to your projects folder from the command line:
ln -s C:xampp/htpdocs d:/projects/phpStorm
If you're on windows, this probably won't work. It also likely won't work between drives. It also may not work depending on your Apache configuration in XAAMP.
PROS: If it works, will do exactly what you want.
CONS: Probably won't work, if it does, will require nightmarish levels of config fiddling
Option 2
Use a remote development server, and sync over FTP with your IDE. I'm not super familiar with PhpStorm, but I can pretty easily do this in Netbeans or Eclipse. This is a good option when you need a local archive of a project retained. You might be able to set up an FTP server on your machine and accomplish this, however you are going to wind up with two copies of your project; one in your projects folder and the other in htdocs.
PROS: Your projects stay organized where you want them without much issue.
CONS: File duplication, they will have to be in htdocs anyhow for Apache to run php
Option 3
Accept that the technology is not designed to work this way and just put everything in htdocs where it belongs. Resisting the way technology works because you are used to a different workflow is how design flaws and really bad bugs happen. Use it the way it was meant to work and don't be scared of learning new things.
PROS: No conflicts with the XAAMP stack whatsoever
CONS: You specifically stated you don't want to do it this way, but this is really the best way
Option 4 (Don't do this)
Install PHP as a globally accessible command line utility across your entire system, and consequently get all kinds of crazy viruses and errors that you may not be able to fix ever.
PROS: Minor alleviation of aggravation with foreign workflows
CONS: All of the things. The worst things.
Option 5 (probably not going to work)
Try using VirtualHosts. There's a bunch of caveats with this though. First, doing this between different drives is nearly impossible to configure correctly due to security policies in your operating system that are difficult to overrule. Second, if you're on Windows (I assume you are if you are using XAAMP), you need to do all of the following:
-In apache.conf, you need to enable your hosts file.
-In the vhosts file, you need to create a new vhost.
-In the windows hosts file, you also need to create a host, because for whatever reason windows likes to arbitrarily add redundant steps. On every other OS, this step is not neccessary. Also, you need to run your text editor as administrator to even do this at all.
-Restart apache when it's all set up
-Pray your machine will let you do this between drives (C: -> D:), or not take a million years to enable.
I've got a batch file rigged up to do Mysql backups on two different servers, both running IIS7, both with their "Path" environment variables now including the path to MySQL's bin subdirectory (path is the same on both systems).
On one system, I'm having no problems. On the other, the batch file keeps giving:
'mysqldump' is not recognized as an internal or external command, operable program, or batch file.
I dropped to DOS. The DOS window "knew" where mysqldump was, just fine. So, scratching my head, I went into IIS Manager and checked PHP. I used phpinfo() to look at the Path settings. They are NOT showing my addition of the mysql bin directory. So, I cycled the application pool. the sever (in the "tree" right above the app pool)... no change.
I really don't want to reboot the server if I don't have to, as it's a production server with people using it right now.
But I'm not sure what I need to do to get PHP to "take" that System Environment Variable / Path update. Any thoughts?
Try to set LoadUserProfile to True in the Application Pool that runs the PHP script.
i just found the answer here: https://serverfault.com/a/193614/388136
basically, iis loads the environment variables on startup and never refreshes them, so if you've made changes you have to restart the service itself. the optimal way to do that is running iisreset from the command line
Something iis reset doesn't work or load profile true is on default.
Most of the cases the path variable is not updating because php loads the path variables on its initial runtime. Something shutdown/ restarts fixes it but the optimal solution is:
Open task manager
Close all the php executables like php.exe and php-cli.
Go to your iis php directory and click on php.exe and php-cli or you can restart your computer this will open them again with the latest configs.
I have a (possibly dumb) question.
I have a script made in php, constructed for cli usage. Works fine when I run it from the command line, no problem there. The problem is that the site I'm working on has ssh restrictions on the hosting server and I cannot ssh there to run it. Hence my question: how can I run the script from another php that is web-accessible? Already tried with exec(), system(), etc.
The main problem is that I need he $_SERVER['SHELL'] variable set, and when the call is comming from a web browser of course php doesn't set it.
Any ideeas will be greatly apreciated, thanx.
There are many possibilities why exec() and related function calls are not working for you.
Your webhost does not have PHP-CLI installed. Just a webserver module
You need to use the full path to the php binary for lack of a decent shell environment. E.g. /usr/bin/php <script> instead of php <script>.
Your webhost has installed PHP-CLI on a non-standard path (e.g. /usr/local/bin/php, or /opt/php5/php)
The webserver user does not have rights to access the php binary
Et cetera..
maybe update the php script to be both an include and a cli script.
use
__FILE__
to check if it's a file, then read the params. otherwise do nothing.
and as an include just call the function you want directly.
Has anyone been able to get xinc to run correctly under OpenBSD's chrooted default Apache? I'd like to keep our development server running fully chrooted just like our Production server so that we make sure our code runs just fine chrooted.
Have you posted the issue on the Xinc bug tracker? Xinc itself should run fine as it runs both as a daemon and as a web app. As you alluded to, the issue may be that the daemon is not running in a chroot'ed environment where as the web interface is, leading to either side not grabbing the files.
#dragonmantank
In Xinc's case, I hope you used PEAR to install it.
pear list-files xinc/Xinc
This should do it, and show you where your Xinc install put its files. So even though Xinc is "just" one big PHP script, it's still spread out into rc scripts and all those other things which are necessary to make an application run. I'm sure you don't need to add all paths listed there, but probably some in order to make it run.
Aside from Xinc itself, I think it also needs phpUnit and a bunch of other PEAR libs to run, so what I'd propose is this:
pear config-get php_dir
And then you need to add that path (like Henrik suggested) to the chroot environment.
Having never used xinc myself, I can only hint as to how I usually get to chrooting apps.
First step would be to gather information on everything the app needs to run; this I usually accomplish by running systrace(1) and ldd(1) to find out what is needed to run the software.
Go through the output of
systrace -A -d. <app>
ldd <app>
and make sure that everything the app touches and needs (quite a lot of apps touch stuff it doesn't actually need) is available in the chroot environment. You might need to tweak configs and environment variables a bit. Also, if there is an option to have the app log to syslog, I usually do that and create a syslog socket (see the -a option of syslogd(8)) in order to decrease the places the app needs write access to.
What I just described is a generic way to make just about any program run in a chroot environment (however, if you need to import half the userland and some suid commands, you might want to just not do chroot :). For apps running under Apache (I'm sure you're aware that the OpenBSD httpd(8) is slightly different) you have the option (once the program has started; any dynamic libraries still needs to be present in the jail) of using apache to access the files, allowing the use of httpd.conf to import resources in the chroot environment without actually copying them.
Also useful (if slightly outdated) is this link, outlining some gotchas in chrooted PHP on OpenBSD.
First step would be to gather information on everything the app needs to run; this I usually accomplish by running systrace(1) and ldd(1) to find out what is needed to run the software.
I'll give this a try. The big issue I've found with xinc is that while it is a PHP application, it wants to know application installation paths (yet it still spreads stuff into other folders) and runs some PHP scripts in daemon mode (those scripts being the hardest to get running). So, for example, I told it to install to /var/www/xinc and then made a symlink of
/var/www/var/www/xinc -> /var/www/xinc
and it partially worked. I got the GUI to come up bit it refused to recognize any projects that I had set up. I think the biggest problem is that part of it is running a chroot and the other half is running outside.
If all else fails I'm going to just have to build something as we program inside chrooted environments since our production is chrooted. We've run into issues where we code outside of a chroot and then have to back track to find what we need to make it work inside a chroot.