Another way I could ask this question is:
How do I set pages served by Apache to have higher privileges? This would be similar to me setting an Application Pool in IIS to use different credentials.
I have multiple Perl and Python scripts I am publishing through a web front end. The front end is intended to run any script I have in a database. With most of the scripts I have no issues... but anything that seems to utilize the network returns nothing. No error messages or failures reported. Running from CLI as ROOT works, run from WEB GUI as www-data calling same command fails.
I am lumping Python and Perl together in this question because the issue is the same leading me to believe it isn't a code issue, it is a permissions issue. Also why I am not including code, initially.
These are running on linux using Apache and PHP5. Python 2.7 and Perl5 I believe. Here are examples of apps I have that are failing:
Python - Connecting out to VirusTotal API
Perl - Connecting to Domains and Creating a Graph with GraphViz
Perl - Performing a Wake On LAN function on a local network segment.
So after I posted this I looked into Handlers like I use for IIS. That led me down the path of SUEXEC and through everything I tried I couldn't get Apache to load it. Even made sure that I set the bits for SETUID and SETGID.
When I was researching that I ran across .htaccess files and how they can enable CGI scripts. I didn't want to put in .htaccess files so I just made sure the apache.conf was configured to allow CGI. That also did not help.
So finally while I was studying .htaccess they referred to ScriptAlias. I believe this is what solved my issue. I modified the ScriptAlias section in an apache configuration file to point to my directory containing the script. After some fussing with absolute directories and permissions for the script to read/write a file I got everything to work except it isn't going through the proxy set by environment http_proxy. That is a separate issue though so I think I am good to go on this issue. I will attempt the same solution on my perl LAMP.
Related
I've successfully deployed the Laravel application to Heroku.
It works online.
But when I try to run "heroku local" I get:
vendor/bin/heroku-php-apache2: No such file or directory
Which makes sense, since looking into "vendor/bin", the only thing listed is:
psysh -> ../psy/psysh/bin/psysh
So, where's my heroku-php-apache or how do I fix this?
You should have these lines in your composer.json
"require-dev": {
"heroku/heroku-buildpack-php": "*"
}
be sure to run composer update after you add them.
After extensive research, trial and error and talking to the Heroku Support team, I found out that, although Slow Loris's answer was a part of the process, the following answer was given to me by Heroku's Support:
To cut a long story short, heroku local is not officially supported for PHP >applications. The reason is that unlike all the other languages we support on the >platform, PHP has no web servers written in userland. Instead, we use PHP-FPM >together with Apache or Nginx, and the boot scripts (vendor/bin/heroku-(php|hhvm)-(apache2|nginx)) dynamically inject the correct configuration for port >binding and the FastCGI comms sockets.
This works with vanilla PHP and Apache builds, provided that:
1) the current user has all the correct permissions (in your case, >/var/log/apache2/ isn't writable);
2) the correct proxy modules are loaded in the main httpd.conf;
3) the main httpd.conf doesn't bind to a port at all, or at least not to one >under 1024 (which are reserved for superusers).
The main config also needs to be handled by each user on their own, because >sometimes, the modules to be loaded are in libexec/, sometimes in >lib/apache2/modules/, and so forth. Just too many variations; otherwise, we could >ship a full Apache config to users and the experience would be much better.
But the problems don't end there. FPM does not work at all on Windows, and on >most Linux systems, httpd is not a command that works; instead, apache2ctl >handles starting and stopping, and thus, running a server in the foreground is >not possible. In the end, there are simply too many possible permutations in >system configs that make it impossible to ensure every user has a great >experience.
It's simply the current reality in PHP land. Ruby, Python, Node, Java all have >web servers that are written in each respective language, and you don't need >external servers. Which also makes it possible to stream file uploads, handle web >socket upgrades, and so forth. Maybe with PHP 7 we'll see something like that >emerge soon (in PHP 5 it's simply not feasible at all, because a fatal error >kills the engine, so your web server would be gone too).
I know this question is a little dated but I recently deployed a heroku app for the first time and was unable to get heroku local to work for me. I'm on the current branch of Laravel which is 5.8, I am also on Windows 10 using VS Code. I searched all over trying to rectify this issue and could not get it to work no matter what.
I did come up with a solution to be able to work on this locally with only a few lines in terminal.
In VS Code, I used gitbash terminal, once in my heroku project folder composer require laravel/homestead --dev, once that is complete, then we need to install homestead, vendor/bin/homestead make, and then once that is complete, simply run vagrant up and your app will be accessible through localhost:8000.
Docs - https://laravel.com/docs/5.8/homestead
Hope this helps someone!
I am strictly a LAMP dev but an ad agency I work with is courting a government agency whose RFP requires that their site be delivered via a Windows server.
What advice do folks have on this? Are there specific pitfalls? It seems like I have heard that file uploads and folder permissions are very different on Windows servers.
Any advice would be greatly appreciated.
IME, IIS can behave very oddly at times.
The permissions model is primarily ACL based - so its certainly possible to design a system which mimics the way Unix works - but (just as with Unix) get the permissions model right - and don't tinker with permissions / ownership in your code.
And of course you'll get yourself tied in knots if you try to move up directory hierarchies and cross over 'drives'.
Add to that a complete absence of the services you might invoke via popen(), and the POSIX tools.
Yes, people keep telling me its a nice place to visit but I wouldn't want to live there.
OTOH, a self-contained set of PHP files will run quite happily there.
PHP on a windows server is definitely trying on your patience. Problems that I've run into are making sure that IIS is configured to use the correct php.ini file, and as you said, writing to files on the server as well as folder permissions.
That being said, if you can get it working correctly, it's not a bad production environment.
I would suggest getting your dev environment as similar as possible to what production will look like. That way you run into as few problems as possible when you deploy.
I can see some pitfalls for using PHP on IIS
Since IIS is multithreaded unlike
linux which is multiprocess. Some
PHP scripts might be unsafe.
Because of this PHP should be installed and
run as a CGI extension. CGI is
slower than IIS's ISAPI and worse
when compared to Apache's mod_php.
Another pitfall I can think of is URL rewriting. IIS, versions below
v7 do not support url rewriting.
Configuration of PHP with IIS is really a pain. But when you do configure it, make sure you use the same configuration, exact mirror images everywhere you are developing because a lot can go wrong with just one glitch.
PHP v5.2.8
Windows Server 2003 SP2 (IIS 6, I believe, though I can't find a version # anywhere in IIS manager)
The full error is:
"CGI Error
The specified CGI application misbehaved by not returning a complete set of HTTP headers."
I installed the WAMP stack from bitnami.org, and the PHP pages work completely fine when visiting via Apache, which I have running on port 8888. However, due to network configuration and firewall reasons, I have to get this working on the IIS server on port 80. There are other websites running on port 80, including a default website that can't be changed. Unfortunately, I also have to have this running as a virtual directory, such as www.myserver.com/phpapp, instead of as it's own website such as phpapp.myserver.com. The reason for this is that the firewall, beyond my control, requires new passthrough rules to allow access on a new subdomain.
This same WAMP stack from Bitnami is working fine on another server when the php app runs as it's own "website" in IIS, since I can add a new PHP ISAPI filter - but that tab/option is not available on virtual directories.
I've installed the php "Web Service Extension" in IIS Manager. I have tried both php-cgi and the php5isapi.dll in the web-service-extensions. Furthermore, I have tried both of those as the "application extension" under the websites "configuration" mappings.
I've also tried mix/match combinations of the php5isapi.dll and php-cgi.exe for the "web service extensions" and the websites "configuration" extension mappings.
I've tried tweaking a few things in php.ini, (including making sure the doc_root is blank). However, as I mentioned before, this website works fine when visited via the Apache port. IIS points to the exact same directory.
What on earth is causing this error? I've spent quite a bit of time searching online, and it seems this error pops up for a few different reasons. If one had a PHP app that did a raw write to the response without writing the headers first would cause this error. Some PHP apps can cause this error when there is a PHP error resulting in some malformed redirect.
My php error logs are missing in action. In my php.ini I have
error_reporting = E_ALL
display_errors = On
log_errors = On
display_startup_errors = On
error_log = "c:\temp\php.error.log"
But there is never a log file in c:\temp. I also tried escaping the slashes, and tried forward slashes in the path, and the log file never shows up.
Again, I feel compelled to mention that this all works fine via apache, so it doesn't seem like PHP itself is bailing due to some strange configuration (even though I can't find the log file) Not to mention this is the same php.ini that I use on the other computer where this is working fine via IIS (where the php app is it's own "website" instead of a virtual directory).
I don't know what other info to provide - but I'm at my wits end after battling this off and on for several days. If I drop an HTML page in, I can visit that just fine via IIS under this virtual directory. What can be causing this?
The app I'm trying to run is vBulletin. Not sure that it matters a whole lot other than to give credence to the correctness of the PHP in the app.
This should have solve all it, takes care of these issues.
IIS Aid PHP Installer
http://www.iis-aid.com/iis_aid_php_installer
My school internal webserver is still running PHP v4.. (Not sure exactly). I went ahead and wrote all the labs and assignments on my local machine, which is running 5.2.5. Now, none of my code works on the school machine because the functionality simply is not there.
I have access to a slew of compilers, and have downloaded the PHP v5.2.9 source code, and am going to compile it for use as a CGI.
My problem? The school has disabled .htaccess files for our accounts, and thus I can't magically redirect all requests to go through my brand new v5.2.9 install.
Does anyone have any ideas, suggestions, hacks, or workarounds to get all requests to go to my cgi version rather than the mod_php version? Is there any way to do this with 301 redirects or something?
Thanks a ton.
See if you have a /cgi-bin directory in your web root. Even if it's not there, try creating it and putting your scripts there. Many web servers will by default assume that files in that directory are scripts.
Additionally, you will want to try:
Renaming your scripts with a .cgi extension
Putting a "shebang line" at the top to indicate what interpreter to use. For example:
#!/path/to/php5
Note that it has to be the first line with no spaces.
You can do the redirect with… PHP4. Use the header function. Or you can execute your CGI from a PHP4 script using passthru.
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.