So my group is trying to set up a shared-server environment for various and sundry web services. I think we've settled on setting disable_functions and disable_classes site wide in php.ini and php_admin_value to force open_basedir in each app's httpd.conf
for php scripts, and passenger's user switching for ruby scripts.
We still need to find something for python though. Passenger does support python, but not for per-application security for specific sub-directories (it's all or nothing at the domain level).
Any suggestions?
(And if any of the previous doesn't make sense - well, I'm the guy who's supposed to set up the python support, not the guy who set up the php or ruby support, so there's still some "and then some magic happens" steps in there from my perspective).
Well, there is a system called virtualenv which allows you to run Python in a sort of safe environment, and configure/load/shutdown these environments on the fly. I don't know much about it, but you should take a serious look into it; here is the description from its web page (just Google it and you'll find it):
The basic problem being addressed is one of dependencies and versions, and indirectly permissions. Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python2.4/site-packages (or whatever your platform's standard location is), it's easy to end up in a situation where you unintentionally upgrade an application that shouldn't be upgraded.
Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application.
Also, what if you can't install packages into the global site-packages directory? For instance, on a shared host.
In all these cases, virtualenv can help you. It creates an environment that has its own installation directories, that doesn't share libraries with other virtualenv environments (and optionally doesn't use the globally installed libraries either).
Related
I have been trying to run HHVM as standalone web server for multiple domains and it looks like they are switching to FCGI mode only https://github.com/facebook/hhvm/wiki/runtime-options
Is that the case or running it as standalone is still possible on production?
Yes, you should use FastCGI mode and let nginx/Apache/whatever deal with being the webserver. HHVM's old built-in webserver has been deprecated for quite a number of releases now -- I can't find the old the wiki page on its deprecation, but it's been about six months or so. This more closely mirrors how PHP is often used, and removes a whole host of complicated HHVM-specific configuration mess. Many people are already familiar with how to make nginx/Apache serve files the way they want, and so we can just keep the HHVM-specific stuff in HHVM and let the full-featured webservers do what they are good at.
The getting started guide has a very quick, basic intro to getting FastCGI set up if you're using our prebuilt debian/ubuntu packages, and the FastCGI wiki page contains all the details to get set up in some other environment.
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.
I'm attempting to rapidly deploy a PHP application under apache2/PHP on a Unix host. The sysadmin hasn't heard of PHP so I'm looking to build/install myself. Unfortunately root access is two weeks of bureaucracy away so I'm looking for a way to use PHP and its requisite libxml2 without installing.
You can be a non-privileged user and build Apache and PHP. You can have your own prefix paths for the installs, and if the development headers for the necessary libraries are available you can use them. You're going to hit issues in that as not-root you'll have to start Apache on a port > 1024. You're also not going to have the system package management available, so updates will have to be likewise built. In short, it's doable, but depending on which UNIX you're actually using, may not be horrendously pleasant. PHP in particular needs many many libraries (and if you're building from source, runtime isn't enough, you need the dev headers files) to have a usable system.
Good luck.
You can't avoid make install, but you can maybe use --prefix
I'm planning to build a CMS in PHP and MySQL, mainly for my own amusement and education. (Though who knows, I may come up with something useful and cool. Anything's possible.) I'll be asking questions about code architecture etc. later. For now, I'm more interested in development tools.
So far, all my playing with code has been done on a web server, and I've edited over FTP. I was thinking it might be quicker to use a localhost. Also, that way, I could use version control (which I've never done before).
So,
A. How do I set up a localhost server with many subdomains on an Ubuntu 9.10 computer. Is XAMPP for Linux the way to go, or should I use a standard Apache distro? (Or another webserver altogether?) For that matter, is it possible to set up more than one webserver on the same computer, and to use them for different localhost subdomains?
B. How do I set up a version control thingy covering all the code (which will be on several subdomains of localhost, and in a few shared folders)? I've read Joel Spolsky's HgInt tutorial, and it makes Mercurial look good. And simple, especially if you're working on your own.
C. Should I continue to use gEdit to write HTML/CSS/JS/PHP, or is there a better free editor out there for these languages?
A. Why would you use XAMPP when installing a LAMP stack is as easy as sudo tasksel install lamp-server? You can add as many domains to the configuration as you want using VirtualHosts for example (well theoretically anyway, in practice the amount will be limited by the available resources), you don't need multiple servers for that.
B. sudo apt-get install mercurial maybe? Of course, how to create a repository and add your projects is up to you - you should read the documentation of Mercurial.
C. Use Eclipse or NetBeans if you're planning to do any serious development work.
I'd recommend against using XAMPP, particularly if you're inexperienced as this would bypass all the package management functionality integrated in Ubuntu (so you need to manually track and apply security changes, if you need extensions not in the XAMPP distro you'll need to compile from scratch, similar for most of the external admin tools which might interact with the Apache install).
Yes - you can have lots of virtual hosts on the same webserver (rcently worked somewhere with 1200 named virtual hosts on each Apache webserver - start up took about 2 seconds rather than 0.5 - but after that you'd never have known the config files were HUGE).
If you're working on your own, then this is about the only scenario where using a distributed version control system offers no benefits over concurrent version control system, and a concurrent version control system offers no benefit over a conventional version control system. But even though it offers no advantage in the technology, it may be of benefit to you to acquire specific product skills.
What editor you use is matter of personal choice. Though personally I would list gEdit in my recommendations (I'd suggest NetBeans or Zend Studio for people who like standalone IDEs, otherwise vim, Eclipse, emacs).
A php documentor is (IMHO) a must (I like phpxref) along with some sort of testing toolkit.
HTH
C.
A: I've used Xampp for Linux successfully on Ubuntu. It's not hard to setup a normal apache installation, but I like the advantage of having a "temporary" web server where the changes are easy to reverse without affecting my normal installation.
If you want subdomains, configure apache to use virtualhosts.
B: I suggest subversion, but VCS is something of a religious issue. It doesn't matter what you use particularly. Once you've made a choice, then research the usage of a VCS.
C: Netbeans is much better than gEdit. That or Eclipse would be my preference. I use Netbeans under Ubuntu myself. A full IDE though will make development much easier than a text editor. Mostly because of code completion/integrated debugger.
I think stackoverflow.com is for programming questions. You'd want to ask those server questions on serverfault.com. Then again, they'd probably ask you to google it. Give it a try.
The editor question is cool. I use Kate, just because it comes with KDE and has syntax coloring.
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.