My team are generally .Net developers but we are currently building a Drupal site, so I am less familiar with standard practice for the LAMP stack.
We finally have the servers configured how we need them to be, so I want to make sure the relevant config files are put into our source control system, so we can track any changes.
I have taken copies of the files below, but I'm not sure if there are any other files that I've missed:
httpd.conf
php.ini
.htpasswd
We already have a strategy for storing the Drupal modules and so on and we don't have any .htaccess files, but are there any other config files that I should be storing for a LAMP-based Drupal site?
Depending on your configuration, you may have used virtual host files and might need to reference /etc/apache2/sites-available/vhost and/or /etc/apache2/apache2.conf as well as /etc/apache2/conf.d/servername.conf.
You may also have certain settings in /etc/php5/apache2/php.ini, but again it depends on how you set up your lamp-stack.
As well as .htaccess, you should reference the drupal file settings.php, if only for security.
Related
I would like to have a scalable infrastructure for my wordpress site. We currently have the following:
A cloudfront that serves the website
A load balancer and target group with only one registered target in it
An RDS.
The WP server (on which config, and wp-content is).
We have several thousands of pages in the wordpress instance, and sometimes we need to make changes, invalidate caches in the cloudfront to serve the new content. Doing this on a lot of pages can create a huge load on the server, and make it unreachable or super slow. So we thought about adding an autoscaling group, which would spin up new instances if the load is too high, and remove then when necessary.
To do so, I believe we need to move the wp-content folder to a shared directory (between all the servers). Is it a correct assumption first of all?
So I naturally created an EFS, which I mounted on a copy of my wordpress server, then rsync all the files with permissions in the efs.
Then as suggested all over the net, I added the following in my wp-config.php:
define('WP_CONTENT_DIR', '/mnt/efs/wp-content'); where /mnt/efs/wp-content is directory on the efs.
From this point, the website worked as expected, I could see some traffic on the EFS monitoring page when viewing pages.
To make sure all the files are correctly shared and copied in the wp-content, I deleted /data/app/wp-content/ folder (it shouldn't be used, as I referenced wp-content to be in my efs).
And my site started acting weirdly. Some formatting disappeared, buttons are native and not customized etc. The console shows a lot of 404 also with following errors:
www.mysite.eu/:1 Access to font at 'https://www.mysite.fr/wp-content/themes/mysite/dist/fonts/icomoon/icomoon.ttf' from origin 'https://www.mysite.eu' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
GET https://www.mysite.fr/wp-content/plugins/js_composer/assets/lib/bower/font-awesome/webfonts/fa-solid-900.woff net::ERR_FAILED 200
Looks like there are no fonts, no plugins, no themes anymore.
So, quite a few questions:
Do I need to keep both local wp-content and shared wp-content? If so, if I install a plugin or a theme, would it be available for other servers as well?
Do I really need an EFS? Or data is fully stored in DB, and wp-content can live on its own for each server?
Are there any other steps in moving the wp-content folder? Maybe specific steps for some plugins?
Is my architecture lacking anything for what I would like to achieve (scale up and down based on demand), or does that make sense?
Thank you!
Don't put wp_content on a shared file system (s3 bucket). It contains a lot of theme and plugin code, and running code from s3 can cause performance trouble and crank up IOPS costs. Instead, use a plugin to offload your site's uploaded media files (jpg, etc) to the s3 bucket, then clone the site.
Use a shared persistent object cache if you can. redis is a good choice.
AWS has a tutorial about doing this, without the cache, on Lightsail. https://aws.amazon.com/getting-started/hands-on/launch-load-balanced-wordpress-website/
I am relatively new to Drupal. I have a drupal site on my staging but I would like to transfer the site to production server. My question is: Is doing drush archive-dump enough to do this? I tried doing this and it seems like the site is not loading the configurations correctly? I already executed the sql commands from the file generated by the dump.
There are three components to moving a Drupal site to another server:
Database
Code
Files (e.g. files uploaded by content creators; usually sites/all/public)
drush archive-dump is specifically there to grab all three and tar them. So yes, that is all the data you need. There can be other issues (e.g. server permissions; software versions; DB credentials; etc...)
To go live you need to:
Test your site in the same environment as production site have.
Move code to production server.
Move database to production server.
That's all.
Please read:
http://www.slideshare.net/erikwebb/the-basics-of-smart-drupal-deployment
https://www.drupal.org/best-practices
Almost. It seems that archive-dump will not include the Private Files Directory if it resides outside the DocumentRoot.
Some administrators will place the Private Files in a directory such as DOCROOT/sites/default/files/private/ and although Apache 2.x should deny access to this directory directly via .htaccess rules, placing this outside the DocumentRoot entirely ensures that protection regardless of HTTPD service...
So no, archive-dump is coming up short if you have Private Files outside your DocumentRoot directory.
I have recently moved a drupal site. (both servers run on a debian based LAMP stack) Everything works great here, including the uploading of images via a CCK filefield. Original url:
dev.example.com/foo
Deploying it to a test folder on the production server to a test folder for an environmental shakedown cruise lead it here:
www.example.com/foo
Everything works here too, including image uploads. After adjusting sites/default/settings.php, then making it readonly again, I renamed the folder to its production name:
www.example.com/bar
Everything works fine here except for image uploading. I've adjusted the webroot variable within settings.php .
Things I have tried so far:
Gave php system user write permissions to sites/default/files (images are set to go in sites/default/files/images but imagecache just puts them in sites/default/files)
Enabled file php file uploading for www.example.com/bar/sites/default/files
Are there any other configuration settings I should be looking out for here? I'm running low on relevant solutions.
Edit: I had quite the typo there, I adjusted sites/default/settings.php, not sites/default.settings.php .
Your question is slightly confusingly framed. default.settings.php has no impact on Drupal -- its merely a template. The file that contains the actual database connection information and other configuration is settings.php.
You may also want to look at your .htaccess file in your root Drupal folder and try changing the RewriteBase directive to the folder you are accessing your site on. Usually you should not have to change the $base_url directive in the settings.php file that you may/may not have done. Reverse that change for now if you have (you may need to play around with that later though).
imagecache will always upload the image derivatives in sites/default/files but imagefield will upload the original image in the folder you specify (within sites/default/files). You will get a setting for the imagefield under Manage Fields->[Name of Image field]->Configure under Path Settings.
Please google to understand the difference between imagecache and imagefield. Make sure your sites/default/files (and subfolders) are writable by the apache user (usually www-data).
In such situations, its usually a good idea to pick up a book on apache (if you haven't already) and try to understand how it works. It will be time consuming but will help you out in the future when you encounter configuration issues like this.
This worked for me. When having issues uploading images to a cck field, I gave write permissions to directory:
sites/default/files/field/image
I'm using multisite to host my client sites.
During development stage, I use subdomain to host the staging site, e.g. client1.mydomain.com.
And here's how it look under the SITES folder:
/sites/client1.mydomain.com
When the site is completed and ready to go live, I created another folder for the actual domain, e.g. client1.com.
Hence:
/sites/client1.com
Next, I created symlinks under client1.com for FILES and SETTINGS.PHP that points to the subdomain
i.e.
/sites/client1.com/settings.php --> /sites/client1.mydomain.com/settings.php
/sites/client1.com/files --> /sites/client1.mydomain.com/files
Finally, to prevent Google from indexing both the subdomain and actual domain, I created the rule in .htaccess to rewrite client1.mydomain.com to client1.com, therefore, should anyone try to access the subdomain, he will be redirected to the actual domain.
This above arrangement works perfectly fine. But I somehow feel there is a better way to achieve the above in much simplified manner. Please feel free to share your views and all advice is much appreciated.
Since it seems you want to reuse the files/ directory and settings.php from your development domain, I'd suggest using the default/ directory + symlinks to achieve your goals.
ie, during development
sites/default/settings.php
sites/default/files/
sites/client1.domain.com -> sites/default (symbolic link)
once you're ready to switch over to their domain:
sites/client1.com -> sites/default
You can then remove client1.domain.com from your virtual host (or continue with your rewrite, etc...).
It will accomplish the same as your method, but you get the added "protection" of all requests going to default in case you add an additional domain at a later date as an alias (for example).
If you're simply sharing core and module files between the sites, you can use a different symlink layout.
In my setup I have all of the shared files in a common, non-web-accessible directory:
/var/www/drupal
/var/www/drupal/sites/all/modules
then for each deployment, common files and folders are symlinked to those files.
/var/www/client1/public_html/index.php -> /var/www/drupal/index.php
/var/www/client1/public_html/includes -> /var/www/drupal/includes
...
/var/www/client1/public_html/sites/all -> /var/www/drupal/sites/all
Then you can place the site's settings.php and any modules or themes for only that site in the default sites directory
/var/www/client1/public_html/sites/default
This layout also offers you the flexibility to override any common files as necessary, such as .htaccess.
To move from staging to production, you will just have to modify your virtual-host configuration from the staging to production domain name.
If you don't like a ton of symlinks, another option is using the Aliased Multi-Site Support patch:
http://drupal.org/node/231298#comment-1420180
This will allow you to specify in configuration that any requests for client1.domain.com should actually use /sites/client1.com/ instead of /sites/client1.domain.com/.
Then when you move to production, you can just remove the configuration setting (though it doesn't hurt anything if you don't).
This feature is part of Drupal 7, but as a new feature won't be added to Drupal 6. More good news is that you won't even need to use it in D7 just for file paths, since instead of storing the full path to files in the database, they use a schema such as public:// or private:// which Drupal then maps to the correct file system path, allowing multiple storage types/locations with much better portability.
I know that there at least two approaches to leverage the web.config file:
using the configSource attribute which was introduced in .NET 2.0 - here is a good blog entry about it.
The file attribute of the appSettings tag which lets you point to an external file with a relative path. Described in the MSDN documentation on the appSettings element.
Now, my problem is that both approaches work well only for physical paths. But I need to address a config file which is in a virtual directory.
Which other method could I use to put my config resources in a virtual directory?
Note: I want to do it this way, because I have multiple instances of my web application on the same server (and that on many servers). To keep deployment easy and clean, I want to keep one directory for all the files (aspx, ascx, images, css, js etc.) and point the web apps in IIS for different customers (=domains, https etc.) to this single directory. In every IIS web I would have a virtual directory called "custom" which points to a different folder for each web.
Update: I'd like to point out that this virtual directory "custom" is not suited to contain an inherited web.config - that web.config would be valid only for the custom folder which doesn't contain aspx/ascx files.
I have the same scenario and after reading you post I realised that asp.net won't let you do this for various security reasons.
Therefore I turned to the OS to find an equivalent to the Linux soft link function which in turn led me to the Junction utility from sysinternals. This can create a directory that is actually any other directory on that volume and asp.net can't tell the difference and so happy loads the config sections that are not actually in a subdirectory of you website. Works for me :)
Virtual Directories can be set as applications, and you can just place another web.config there.
It will inherit any changes from the parent config, and you can add custom settings in it.
I was looking to do the same thing but it did not work, so I decided to do the opposite, as you know the web.config can be inherited, so I pointed IIS to a folder containing the client config (connection string, file path etc) files and the website files i put them on a virtual directory with the rest of the webconfig (where it load dll and other application files needed)
So basically i can use the website files to multple clients and the clients with their own Database connection string and other specific client settings.