I am trying to get into PHP app deployment with Capistrano. I have two config files that I need to be "edited" depending on where I deploy it. It's basic stuff like database name and root url (Codeigniter). Can I make Capistrano edit specified automatically? Let's say I want to edit the following in the file /system/config/edit.php:
$test = '';
// edit to
$test = 'Hello World';
Thanks,
Max
What I generally do in this kind of situation (even though I don't use Capistrano) is to have several config files commited to source control.
For instance :
config.php for development machines
this file is the one that's always used by the application
config.testing.php
config.staging.php
config.production.php
And when deploying the application to the server, I just have to copy the file corresponding to the current environment to "config.php" -- as this one is the one that's always used by the application.
It means that I have to do a file copy during the build process, yes, but :
it means there is no need for any search and replace, that can break
it also means every config files are commited to SVN (or whatever source control software you are using)
If your configuration files become too complex, and duplicate lots of stuff, you can think about having one "default" config file, that's always included, and sub-config files that only define what depends on the environment.
What that, what I said before still stands : just include the "default" file at the begining of each other.
My Unix is knowledge isn't quite up to scratch so I can't quite get the syntax perfect for what you want. However, Capistrano allows you to directly use the Unix command-line by invoking :run_method within your configs.
The Capistrano code might look something like the following:
run "grep -R --files-with-matches '$test = "";' /system/config/ | xargs perl -pi~ -e 's/\$test = "";/$test = "Hello World";/'"
I would check up on that find and replace function working as expected before implementing it live though.
If you need any more help, I'd recommend checking out the Capistrano Handbook, it should answer most of your questions.
Related
I'm looking through the documentation, but I'm not seeing any option to change the working directory used when running tests.
I'm using PhpUnit as it's included in Laravel. I want to be able to run vendor/bin/phpunit from my project's root directory, and have it run using the /public directory as the working directory.
I tried running ../vendor/bin/phpunit from the /public, but since the phpunit.xml file isn't in the public directory and I don't want to specify my config file path every time, that won't work.
Is there something I can add to my phpunit.xml file to tell it to run tests using the /public directory as the "cwd" (current working directory)?
Based on the feedback I received in the comments and the documentation, I determined the following:
It's probably not possible to change the cwd that phpunit uses by default (well, it's possible in PhpStorm, but not the command line without writing some kind of wrapper script)
Code that depends on being run from a specific directory is not a good idea.
What I had was some code in one of my classes like this:
$var = file_get_contents("../some_file.json");
This works fine -- until you try to add unit tests. The web server runs using the /public directory as the cwd, while phpunit will run using the root directory.
Rather than trying to force phpunit to always use a particular cwd (/public), I decided it's probably best to remove relative paths from the code that rely on a consistent cwd. So the line above becomes:
$var = file_get_contents(base_path("some_file.json"));
I didn't want to change production code that was already working just to get some tests in place, but this change seemed insignificant enough. (and it's an improvement anyway)
Well, you'd have to do the actual chdir in PHP, but you can define a bootstrap script in the XML (<phpunit bootstrap="./bootstrap.php">) and have that change the working directory.
Alternatively, you can put a setUpBeforeClass function into your test class that changes the working directory.
We're just getting up to speed on Capistrano and I could use some help. We're running codeIgniter and would like to allow our devs to run/test locally, push to the Git repo when we've got a complete module. The issue is that in order to run locally, you need to set up the environment to look for the system as well as the models, views and controllers.
Rather than write a bunch of conditional code into index.php that could get munged accidentally or some such, I'd rather have a static file called "index-server.php" and use Capistrano to rename index-server.php to index.php after a deployment is complete.
I'm not even sure what this would look like but I'm pretty sure it's possible.
I'm fairly new to capistrano as well, but I did manage to execute system commands on the deploy target by adding this to deploy.rb
namespace :deploy do
after :finishing, 'deploy:cleanup'
after :publishing, :restart
after :restart, :clear_cache do
on roles(:app), in: :groups, limit: 3, wait: 10 do
execute "/bin/mv #{File.join(release_path, 'index-server.php')} #{File.join(release_path, 'index.php')}"
end
end
end
Or something along those lines. Hope it helps!
Edit: this is with Capistrano 3
I have a a few php files which I call via AJAX calls. They all have a URL to my config.php. Now I've the problem that I always have to change the URLs to that config file by hand when I deploy a new version on my server.
Local Path:
define('__ROOT__', $_SERVER["DOCUMENT_ROOT"].'/mywebsite');
Server Path:
define('__ROOT__', $_SERVER["DOCUMENT_ROOT"].'/../dev.my-website.tld/Modules/');
I want to track changes in all of these PHP files. I'm searching for a solution to automatically change this path.
E.g.
This is my current workflow:
Local Environment:
(path version A)
do changes in the code
git add, git commit, git merge, git push to my server
Server:
git reset --hard
change path to version B
You are trying to run different code bases between development and live, which is not recommended -- they should be identical. The way I tackle this is to use an environment variable to specify which of several config files should be loaded.
In my Apache vhost I do something like this:
SetEnv ENVIRONMENT_NAME local
And then I use a function to read the environment name:
function getEnvironmentName()
{
$envKeyName = 'ENVIRONMENT_NAME';
$envName = isset($_SERVER[$envKeyName]) ? $_SERVER[$envKeyName] : null;
if (!$envName)
{
throw new \Exception('No environment name found, cannot proceed');
}
return $envName;
}
That environment name can then be used in a config file to include, or to retrieve values from a single array keyed on environment.
I often keep environment-specific settings in a folder called configs/, but you can store them anywhere it makes sense in your app. So for example you could have this file:
// This is /configs/local.php
return array(
'path' => '/mywebsite',
// As many key-values as you want
);
You can then do this (assuming your front controller is one level deep in your project, e.g. in /web/index.php):
$root = dirname(__DIR__);
$config = include($root . '/configs/' . getEnvironmentName() . '.php');
You'll then have access to the appropriate per-environment settings in $config.
A pure git way to achieve this would be filters. Filters are quite cool but often overlooked. Think of filters as a git way of keyword expansion that you could fully control.
The checked in version of your file would for example look like this:
define('__ROOT__', 'MUST_BE_REPLACED_BY_SMUDGE');
Then set up two filters:
on your local machine, you'd set up a smudge filter that replaces
'MUST_BE_REPLACED_BY_SMUDGE'
with
$_SERVER["DOCUMENT_ROOT"].'/mywebsite'
on your server, you'd set up a smudge filter that replaces
'MUST_BE_REPLACED_BY_SMUDGE'
with
$_SERVER["DOCUMENT_ROOT"].'/../dev.my-website.tld/Modules/'
on both machines, the clean filter would restore the line to be
define('__ROOT__', 'MUST_BE_REPLACED_BY_SMUDGE');
Further information about filters could be found in this answer and in the Git Book.
I have a php application that relies on several classes to function properly. If I take one of the application's class files
/my/folder/class.php
then move it somewhere else
mv /my/folder/class.php /my/other/folder/class.php
then in its place inside of
/my/folder/
I create a symlink to it called class.php via
ln -s /my/other/folder/class.php /my/folder/class.php
I would expect my application to be unaffected, but instead this is breaking it. I know the symlink is valid since at the command line I can do
nano /my/folder/class.php
and everything looks as I would expect it to. Am I missing something fundamental about the behavior of symlinks, and/or how apache or php processes them? Is it changing the working directory or $_SERVER['DOCUMENT_ROOT']? I can not figure out why this would have any affect on my application.
I am using Apache server in CentOs.
Thanks!
The only difference would be if you are using require_once or include_once and you are mixing the symlink path with the real file path. In this instance, the X_once is going to think those files are different and load it twice (which will of course cause problems if you define any classes or functions).
Would probably need an actual error message to guess any further.
I have a server that runs quite a few Drupal sites. Some of these are older and running Drupal 5, while some are newer and running Drupal 6. We're also beginning to implement Drupal 7.
Our organization uses one standard Website Administration password that we distribute internally only to our employees for maintenance of these websites. This may or may not be the best security practice, but it is how we do things at this time. Please assume that this won't change.
The problem we have is that when we have employee turnover, we must change this password and apply the change to every site we run in order to make sure that the employee cannot deface any of our clients' sites. This is more critical for firings, but we also do it for resignations as a best practice.
In the past, I ran a basic PHP script that used mysql_list_dbs on our Database server to iterate through every database and change the pass field of the users table where the name = admin. BasicallY:
while ($row = mysql_fetch_object(mysql_list_dbs($sql_connection))) {
mysql_query("UPDATE users SET pass=MD5('$newpassword') WHERE name='admin'", $row->Database);
}
This worked perfectly fine but it has two problems:
It's hacky and I hate hacky stuff. I'd rather do things that make use of the "official way" of doing things
Drupal 7 uses a different hashing system than D5 and D6 did, so this won't work for Drupal 7 sites. Now I have to check first that the existing value of pass matches the hash of the old password before updating so that I don't accidentally break a Drupal 7 site. In the meantime, I haven't yet figured out how to implement this for Drupal 7 sites.
So I'm looking for an alternative solution. I really think that I need to use a bash script that either iterates through Virtual Hosts from httpd.conf or uses find or something and one way or another, cd's into every site install directory inside very installation platform's "sites" folder (we have a pretty messy setup*) and runs drush upwd admin --password=$newpassword
This would be completely platform independent and would allow Drupal to define what happens when the password is changed.
I realize that Aegir may actually be a good solution for this, but we're not ready to implement Aegir quite yet, and I'm looking for more of a quick and dirty intermediate solution. I appreciate any input you might have.
*Just a sample of our messy setup:
/www
/cliena
/drupal-5.x
/sites
/clienta.com <-- contains settings.php for Client A
/clientb
/drupal-5.x <-- contains old code base for Drupal 5 site that's been migrated I shoudld probably have my drush/bash script ignore these sections....
/drupal-6.x <-- contains code base for current Drupal 6 site
/sites
/clientb.com <-- contains settings.php for Client B
/clientc
/drupal-6.x
/sites
/default <-- contains settings.php for clientc.com
/sub1.clientc.com <-- contains settings.php for sub1.clientc.com
/sub2.clientc.com <-- contains settings.php for sub2.clientc.com
/sub3.clientc.com <-- contains settings.php for sub3.clientc.com
/client_sites
/drupal-5.x
/sites
/clientd.com <-- contains settings.php for clientd.com
/cliente.com <-- contains settings.php for cliente.com
/clientf.com <-- contains settings.php for clientf.com
... and so forth... you get the picture. a Migration to Aegir is in order, but it'll take a while to clean this up.
you could improve and continue writing this script bellow...
for FILE in $(find /www -type f -name system.module); do
C_PATH=`dirname $FILE`
C_VERSION=`grep "define('VERSION'," $FILE | awk -F "'" {'print $4'}`
print "--- DEBUG --- "
print "Current path: $C_PATH"
print "Current version: $C_VERSION"
# Your logic here...
done
[]'s
Felipe
The script of Felipe looks good, i adopted it, to deal with the multi-site-installations and drush. In my setup it found every site in my installation. Please try it with a not-so-destructive drush command first:
PASSWORD='secret'
for FILE in $(find /www/ -type f -name settings.php); do
PATH=`dirname $FILE`
echo "Changing password for: $PATH"
drush -r $PATH upwd admin --password=$PASSWORD
done
Felipe and Nebel54 both gave me great starts. I ended up working mostly off of Nebel's, but still had to make some modifications. I found two problems with your script, Nebel.
1) It seems that "PATH" is a reserved word. When I tried to use it as a variable, it didn't work right. So I changed it to "DPATH".
2) It seems that passing the -r parameter to drush isn't sufficient. When I used that, it told me that I needed a higher bootstrap level to run my command. So I had to do a CD to the $DPATH before executing my drush command.
For testing I executed the sql-connect command first because that just outputs the sql connection string for review and doesn't make any changes. I'm about to run the password update now. Here's my final script:
PASSWORD='newpass'
for FILE in $(find /www/ -type f -name settings.php); do
DPATH=`dirname $FILE`
cd $DPATH
echo "Changing password for: $DPATH"
drush upwd admin --password=$PASSWORD
done