I've just bough VPS account for testing and development.
Is there a function of PHP to parse Apache config file, PHP config, FTP Server config, zone files, etc? Also a way to insert data into config file.
I want to create a simple Control Panel to add ftp accounts and web account (with domain). If you have done it before - how did you do it?
It would be quite challenging to learn
Thanks.
No, PHP has no functions to parse the config files of those programs - you'll have to write a custom parser for most of those formats. However, for php.ini you might be able to use PHP's ini functions.
Most webhosting control panels either create the whole config file based on their database - i.e. they never read it but only (over)write it or they require you to include (apache and bind support that for example, for PHP you can use php_admin_value in the apache virtualhosts) their generated file - which is also never read by the tool.
If you really want to create a tool that actually modifies existing files, don't forget that you cannot simply skip comments as nobody would want an application to rewrite his config file stripping all comments.
You may be able to use the follow pear library to parse apache config files:
http://pear.php.net/manual/en/package.configuration.config.avail-container.apache.php
Parsing a php.ini file, depending on what you want to do, is probably best done with ini_get
I'm not aware of such functions and I highly doubt they exist for the simple reason that there are just too many HTTP / FTP / SMTP / ... server implementations. Control panels like cPanel, WebMin and others usually do the heavy lifting for you and some even provide an API to automatize things from PHP.
For the PHP configuration the following functions will probably do the trick:
ini_get()
ini_set()
ini_get_all()
get_cfg_var()
Bare in mind however that not all PHP configuration directives can be changed with ini_set().
Related
To load my ini file from a path outside the codebase I use apache to define the path and with php I use apache_getenv / getenv
It seems phpunit doesn't understand the apache_getenv command - is this a known issue and are there any solutions besides hardcoding paths?
When you run php from the commandline it does not use any of the Apache configuration. But you can still access environment variables. So, first change to use getenv everywhere (instead of apache_getenv). Then, if you're starting php from bash, run it like this:
export MY_CONFIG = "/path/to/my.ini"
phpunit
You only need to do the export once per bash session. You could wrap that up in a 2-line bash script.
This approach has one issue, which is that you have configuration in two places now. Murphy's Law tells us those two files will try really hard to get out of sync. So, an alternative approach is to use a custom entry in php.ini (*). And then in your code use get_cfg_var to fetch those values. Be aware that some people do not like this approach, e.g. create arbitrary values in php.ini Use it wisely: if your machine is dedicated to the application that needs this setting, then it is a fair choice. If it is just one script among many, and on a multi-user machine, then it is dubious.
A third approach is a symlink to your real ini file that is kept with your script. Then your script will always find it, however it is started. I like this approach best, but it is not so dynamic. I'm guessing the point of using an environment variable was because you use a different value for different virtual hosts, or something like that.
*: Make sure you use the php.ini file that is common to apache and cli: some setups also have a configuration file that is just for apache, and just for the cli. On Ubuntu machines I would create a file under /etc/php5/conf.d called myconfig.ini, as that is easier to maintain, and that directory is used by both apache and cli.
I noticed that most of the frameworks (CodeIgniter for example), do provide a default .htaccess file but don't force its use.
Why don't they force its use?
Does .htaccess work on all servers?
What are the alternatives?
.htaccess files only work on apache servers. When using other servers it highly depends on what you want to do - but usually you need to edit the server config to rewrite URLs, block directories, etc.
The fact that frameworks need .htaccess files is actually an annoying problem from the PHP world since 99% of all applications are stored inside the document root, thus giving users HTTP access to all their files unless they are somehow restricted (e.g. via .htaccess). On the other hand, if you have a WSGI-based python application, you usually store it outside the document root and "mount" it to a certain folder in the document root - this way not a single file can be accessed directly via HTTP.
1) I have to agree with Juhana. The question is: why should they force it? There is no need to restrict a framework with such a thing.
2) I heard that they are not working on IIS Server, where you have to translate it in special config files.
3) It depends on what you're doing. But because of the fact you do not really need .htaccess files, just let them be is a possible alternative :)
Because it does not work on all servers (esp. hosting providers can restrict its use) and there is really no good reason to enforce it.
See #1. Also, they tend to not work in the same way if you're not running Apache.
Very wide question. If you're running Apache it's pretty much the only way to configure the server while not being a privileged user. If you're not running Apache, it's dependent on the specific web server.
Some useful links;
Apache htaccess to nginx rewriterule converter
How to translate htaccess to IIS web.config
How to work around lighttpd's lack of directory specific config
I had a terrifying issue a few days ago. I was installing updates on my ubuntu server, which is a hosts for about 10 websites. During the update, something went wrong, and apaches mod_php became disabled. As a result, PHP support was gone, and for a few minutes (until I figured what's wrong) users got an invitation to download PHP scripts, instead of seeing a website. Needless to say, there is nothing worse then exposing your script sources to the whole world, especially when database credentials are kept inside.
The question: How can I configure apache, so this situation would not be possible in the future? What lines should I add to apache2.conf, so that PHP files could not be downloaded, if mod_php is disabled?
Just add the following to the .htaccess in the root directory
php_admin_flag engine on
In this case user will get HTTP 500 error trying to read any file from this dir and below because no module defines php_admin_flag directive in case mod_php is off.
A more secure approach would be simply to not put things you don't want accessed in the document root in the first place. See my answer here which provides more detail; the basic idea is, if you don't ever want a file accessed via URL, don't put the damn file in a URL accessible place. 99% of your app code should not be under the document root; then it doesn't really matter what you do to your apache/php setup, you're still safe.
I'm starting to use SVN repositories for all of our websites and wanted to know what the best practise was regarding website config files.
Should they be stored in the repository? The problem is the configuration of the websites need to be different for the working copies than that of the live sites. If I edit the config file for a working copy so that I can test on my machine when I commit back to the repository the config file will be updated there too and could then potentially get uploaded to the live site.
What do people generally do with config files, is there a way to tell SVN to skip config files when performing commits etc?
Generally, it's best to put config files into version control if they store significant information.
If you're talking ASP.NET sites here, I'd definitely place the config file in SVN. You can play a few tricks in ASP.NET config files using inheritInChildApplications and allowOverride (see How to: Lock ASP.NET Configuration Settings) which may allow you to force a local debug version to use different settings from the final production version despite using the same config file: just mount the website as a sub-directory in the local debug IIS and lock a few sections you wish to override. And of course, you could just include two config keys for particularly tricky bits and check in code which to load.
In general, it's good practice to make deploying anything from SVN a process involving as few manual steps as possible. That makes it more likely you'll do it correctly under time-pressure, and it makes disaster recovery easier to boot (say, when your datacenter springs a leak and you want to install the web site on some temporary box until you've got those backups sorted). Ideally, an svn checkout or export with at most a compile should suffice to get the web site up and running. I include even binary dll-dependencies directly in svn (stuff like javascript compressors and whatnot) so it'll run without requiring a bunch of custom library installs on the server, and compile on a dev machine with just msbuild.
For PHP, the principle is the same. However, you'll need different tricks. For instance, you might write the config file such that it checks some global system environment variable, and then overrides selected settings if it's a dev-machine. For instance, I've a setup similar to this where I check the IP address; all dev-machines are in a particular IP-block; unless a machine is in that IP block, it's considered a production machine (which doesn't enable various tracing etc. options). You could also check the host name, or simply any old environment variable which all developers agree to set on their development machines.
I think its best to keep config files in SVN. Regarding settings for staging/production environment, what we do is to have seperate config files for each environment, and then swap them out as part of our build process (using Ant and MSBuild). I.e. we can trigger a "production build", which will copy the production web.config file.
I would have the file in version control, absolutely, as it's generally pivotal to the function of the site. To stop it getting loaded to live, you could look at a build script (e.g. Web Deployment Project), which would switch out your development versions of the configuration with a 'live' version.
Sorry, ignore the link, just saw your comment about this being a PHP site - principle is the same however.
If the variables between your dev/live environments are limited to just connecionstrings and appsettings, then you can split your web.config into seperate files, and have a different file loaded in for each environment. That way, you can check everything into SVN and just update the filename reference in your webconfig depending on which environment you are deploying to.
http://kartones.net/blogs/kartones/archive/2009/09/29/asp-net-split-appsettings-and-connectionstrings-to-separate-files.aspx
Edit: Just seen you're talking about PHP.
In general the best-practice is to store all the custom configuration files under version control. You may want to keep a separate config file for the production and development versions.
If possible, try to extract all the config sections that depend on the deployment environment (connection strings, paths, etc) into separate files. Then link to them from the main (common) config file, so that it will be just a matter of updating the reference when you change your environment from development to production.
My friend asked me to update a PHP application that his company uses. I found out that the application uses .ini extension for DB configuration file. The file contains DB host address, username, and password!!. The problem is that I can access the file on web-browsers.
I am trying to understand why. Is there any particular reasons to use a regular php file with .ini extension??? I just don't get it.
Readability is one of the main reasons I've used ini filies for php script configs in the past. People who are not coders have run into an ini file at least once before, and can understand what it is much easier than even a simple php file.
The issue of ini files being readable by everyone can be prevented by server side configuration, or even better, by simply adding a single line of code inside a comment line at the top of the file.
That way php will output an 'Direct access forbidden' when the file is accessed via a browser, and the ini file will continue to function as before.
You can use Zend_Config_Ini. It is comfortable and easy. Just simply do not put config files where any user can reach them (for example public_html).
INI files are just one way of dealing with configuration, perhaps the developer came from a Windows-developing background and used whatever he was familiar with :). Besides, PHP offers a convenient way of parsing INI files through the parse_ini_file function.
You'll want to make sure the .INI file is not accessible from the web though. Move it below the docroot so your PHP script can still access it, but random browsers cannot.
For what it's worth, PHP has traditionally used php.ini to configure PHP. So maybe it's some kind of legacy thing?
Seems like this is just former programmer's wish to use different file type for configuration. If there is no other uses for this file, rename it to *.php and forget it. If not, configure webserver to parse ini as php or, better, move it to directory, not reachable from web-server.