linux

Acquia BLT short Drupal8 howto

Working with vm’s makes everything simpler and easier. Easy to reproduce bugs, easy to reproduce features between environments and, most importantly, between developers.

In the past I’ve been working with different solutions, custom mainly, based on puppet, ansible…. Until I arrived to Acquia. Local environments as it happens is a recurrent topic on every team, a clear pattern… and when there is a pattern, you can write something to save some time to those lazy developers ;-). Enter BLT (Pronounced BOLT).
 
BLT is basically an environment that has everything ready for fast developer on-boarding, easy deployment on different environments (dev, staging, prod, … and of course, local), but also for quick automation of repetitive tasks, like rebuilding your sites, pulling databases...
 
Configuring BLT is very straightforward, but it will take some reading from you. Keep reading for a TL;DR version:
 
PRE-REQUIREMENTS
 
First, install the requirements: https://github.com/acquia/blt/blob/8.x/INSTALL.md
 
In Mac it is very easy to do it simply following the brew requirements.
 
 
Basically:
 
brew tap caskroom/cask

brew install php56 git composer ansible drush

brew cask install virtualbox vagrant
 
Once this is installed you have blt in your command line:
 
  blt --version
 
That’s it, you are ready.
Note: for other operating systems please visit: https://github.com/acquia/blt/blob/8.x/readme/local-development.md
 
INSTALLING YOUR NEW SITE(s)
 
Once we have all the tools installed in our computer we can start building apps. It couldn’t be simpler:
 
    composer create-project --no-interaction acquia/blt-project MY_PROJECT
 
That will create a base directory from which you can start building your Drupal app. First thing I’d do is moving this to your git repo, i.e. GitHub:
 
  $ git add .

  $ git commit -m "BLT-00 first commit."

  $ git remote add origin https://github.com/alex-moreno/blt_test.git

  $ git push -u origin master
 
Now, let’s move inside the repo and start doing the magic. Let’s initialise the vm (I am assuming here that we’ll be working on a virtual machine):
 
  blt vm
 
It will ask if you want to install Drupalvm, to which we’ll say yes, and afterwards if we want to boot it. Yes again.
 
At the end of the process you should see a green message like this one:
 
"Drupal VM booted successfully. Please use vagrant commands to interact with your VM from now on.”
 
Your vm is ready. Last stop, install a site:
 
  blt setup
 
This will install a default Drupal 8 site in docroot. You could put your custom site here, or for example install lighting (https://docs.acquia.com/lightning) instead of the default one. The best practice for that road would be using composer, although I’ll leave this for a different post.
 
CONNECTING EVERYTHING TO ACQUIA CLOUD
 
Now, next step you need is to actually connect your new vm to your Acquia Cloud (AC) environments. You have to do this drush level and BLT level, drush to be able to execute drush against the environments, BLT to be able to sync the databases, build artifacts, etc…
 
First bit, BLT settings. Edit:
 
blt/project.yml
 
And add in remotes the url to AC. You’ll find this url in AC. Go to https://cloud.acquia.com, select your application and, in the list of environments, you’ll see on top right an icon called “Application Information”. Click and the first url is what you need. IE: YOUR-APP@svn-6634.devcloud.hosting.acquia.com:YOUR-APP.git
 
Your yml file will look like this:
 
git:

  default_branch: master

  remotes:

   - 'lightningalex@svn-6634.devcloud.hosting.acquia.com:lightningalex.git'
 
Lastly, your drush settings. Go to your AC profile page: https://accounts.acquia.com/account
 
Select Credentials and, after confirming your password, you should see 'Drush integration’ in the new page. Download and place the hidden files in your $HOME.
 
DEPLOYING
 
Time to deploy your stuff to Acquia Cloud (or theoretically any other host provider). First thing, you’ll need to add your ssh keys to Acquia Cloud, just:
 
 
If you don't have any ssh keys yet there are some good short tutorials out there, it shouldn't take you more than 10 minutes to generate a new ones.
 
Ready to go, do:
 
blt deploy -Ddeploy.commitMsg='BLT-000: Deployment test' -Ddeploy.branch='master-build'
 
Answer ‘y’ to create a tag, return for the default commit message, and write your tag (i.e.: 1.0.3-build)
 
If your keys are good to go you should see some magic happening, and your artefact being deployed to the Acquia Cloud remote server. Now simply go to Acquia Cloud, select the tag that you have just created and deploy it in your environment. 
 
All done… although now I am thinking on changing the title of the article… not that short after all :-)
 
 
Bonus: Some commands
 
- Rebuild your local with the remote db:
 
blt sync
 
Equivalent to: drush sql-sync @remote @local
 

Apache not sending changes in js and css (virtual box)

I am using a solution of vbox (virtual box) and shared folders in our windows work environment (yes, unfortunatelly, but the IT team is in his right to decide which machines we have to use).

Everytime the vbox start, it mounts "automagically" one of the shared folders in the linux host (centos and archlinux, one day I will explain why). So then, apache has all what he needs in /var/www/html/ (simply mounted with "mount /var/www/html") (see automatically mount directories in vbox).

So far, everything was working fine... until I started to make small changes in small files. Absolutely surprising because when I deleted the complete code in the css or js file, for example, and I updated the browser, the screen appeared white, so everything seemed ok. But not at all, dealing with small changes, like adding a line in your css simply add no effect, the change is here, but seems that Apache or the browser didn't like it, simply it was being ignored.

After a while struggling about the browsers cache and even restarting the virtual box I finally decided to dig into Google.

I found the problem in the frankooh blog and it seems that it is a vbox problem, exactly a vboxsf problem with Apache.

The solution is simple, go to you apache configuration (in centos /etc/http/conf/httpd.conf) and uncomment the line:

EnableSendfile Off

After restarting Apache all the changes were sended to the browser without problems, even the small ones.

PS: be carefull with case sensitive off != Off 

warning: date(): It is not safe to rely on the system's timezone settings

The error is quite enoying:

warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'GMT/0.0/no DST' instead

But it is quite simple to correct. It is not a drupal problem, but a linux/apache. Just go to your php.ini, for example /etc/php.ini in CentOS and add this line:

date.timezone = Europe/London

reboot apache and the problem will have dissapeared.

categorias: 

changing vhost.conf without restarting apache

Sometimes you need to change some parameters to your apache virtual host. Then, when you need to check the changes, in plesk you'd probably will have to execute the next command to see the changes:

/usr/local/psa/admin/sbin/httpdmng --reconfigure-domain exampledomain.com

Otherwise, restarting apache (/etc/init/apache2 restart) could not make the trick.

I allways forgot this little trick... never more, because Programadores Web will remind it me :-).

categorias: 

Developing under Linux Apache in windows

Contradictory? Yes, a bit, but you cannot allways choose the systems and architecture in which you are working.

solution? Runing apache under linux instead of runing wamp or some weird solutions like that (i don't like at all, sorry).

First, install vbox: https://www.virtualbox.org/

Second, download the iso of your preffered linux distro, and install it.

Third, when you machine is running, go to Devices>install guest additions.

Now you have to come back to your linux machine, and install a few things, kernel upgrades included (if needed).

 

  • yum install gcc -y
  • yum install kernel sources -y
  • yum install kernel-devel -y

 

 

Reboot your system, and mount:

 

  • mkdir /media/VirtualBoxGuestAdditions
  • mount -t vboxsf /dev/cdrom /media/VirtualBoxGuestAdditions

 

 

 

categorias: 

Centos tips

 

 

  • Configuring your network to start when booting: chkconfig network on (via http://nixcraft.com/centos-rhel-fedora/18643-centos-linux-6-2-eth0-netwo...)
  • configuring services to start apache (or any other daemon) when system boots: chkconfig --level 2345 httpd on
  • ... more coming
  • Override Apache permissions problem: "You don't have permission to access ... on this server". Simply execute: setenforce 0

 

categorias: 

Accessing centos apache/httpd from vbox host

This is the scenario. You installed vbox in your Mac, windows or Linux computer. Then you´ve installed Centos or Red Hat (or any other Red Hat flavor) in this virtual box.

Next step, installed httpd (apache2) and... even it is running and httpd status confirms it with a "running" message, it cannot be accesible from your host machine.

The problem is on iptables. Red Hat by default denies access to this machine from other (external) machines. Solution? Very easy, open iptables file:

vim /etc/sysconfig/iptables

(vim is my favourite editor for a loooong long time)

Look for this line:

-A INPUT -m state –state NEW -m tcp -p tcp –dport 22 -j ACCEPT

and after that, add this one:

-A INPUT -m state –state NEW -m tcp -p tcp –dport 80 -j ACCEPT

Restart your services and everything done:

service iptables restart

Thank to http://www.fliquidstudios.com/2009/06/18/creating-a-virtual-development-...

categorias: