beetboxvm / beetbox Goto Github PK

Due to the automated build structure set in place for this project there should be no need for duplicate functionality.

The box Vagrantfile could be built dynamically and overrides injected into placeholders if required.

relates to #91 & #65

what I did:

vagrant ssh
sudo su
mkdir /etc/private
mkdir /etc/private/ssl
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/private/ssl/certificate.key -out /etc/private/ssl/certificate.crt
chmod 400 /etc/private/ssl/*
chmod 500 /etc/private/ssl

Update the vhost as follows (/etc/apache2/sites-available/vhosts.conf):

DirectoryIndex index.php index.html


<VirtualHost *:80>
  ServerName sitename.local
  DocumentRoot /var/beetbox/docroot

  <Directory "/var/beetbox/docroot">
    AllowOverride All
    Options -Indexes +FollowSymLinks
    Require all granted
  </Directory>
</VirtualHost>

<VirtualHost *:443>
  ServerName sitename.local
  DocumentRoot /var/beetbox/docroot

  <Directory "/var/beetbox/docroot">
    AllowOverride All
    Options -Indexes +FollowSymLinks
    Require all granted
  </Directory>

  SSLEngine on
  SSLCertificateFile /etc/private/ssl/certificate.crt
  SSLCertificateKeyFile /etc/private/ssl/certificate.key
</VirtualHost>

then restart apache

service apache2 restart

Symbolically linking the project root into the relevant install profile directory via the drupal_distro setting doesn't work well with Drush and Drupal 8 as it ends up with an apparent recursion error due to the symbolically linked directory containing the docroot.

Ideally there'd be someway to exclude the docroot from the symbolically linked directory, or alternatively symbolically link all files and directories excluding the docroot directory.

From Drupal report page:

Your server is capable of displaying file upload progress, but does not have the required libraries. It is recommended to install the PECL uploadprogress library (preferred) or to install APC.

http://pecl.php.net/package/uploadprogress
http://us2.php.net/apc

It would be nice to have PostgreSQL and SQLite setup or available as options.

Currently Drupal is unable to use the temporary:// file scheme wrapper (ie, unable to save files to /tmp), which causes issues for modules like Hacked!.

I'll like to discuss the idea of setting the debug mode to on by default on the example project, as we could run into issues when master has moved on from the last base box build.

As part of this we should also update the root README.md to clearly state that the repo is only required for contributing and you only need the Vagrantfile to integrate into a project.

Kickstarting the idea of creating a vagrant plugin for beetbox that could:

*Prompt for some important config settings and create the config file.
*Automatically create the project Vagrantfile.
*Automatically create a circle.yml file so you can test your own implementation then you can potentially add you own project tests scripts.

Installation
vagrant plugin install beetbox

Example wordpress init
vagrant beetbox init wordpress

Add a beetbox-deploy role that could trigger other roles to allow circle CI to auto deploy your project to a PaaS provider.

so things like building a makefile that references a private repo can still build without erroring.

To speed up test builds.

https://circleci.com/docs/how-cache-works

Currently the default project and local config files are being created with root permissions, meaning that during provision the external config files can not be moved into place.

Offline provisioning, which was previously working, is now broken.

The offending task is Get software for Python-based control., which to be fair, doesn't exactly sound like an essential task.

Looking further into the issue.

This is useful for per-project customisation of the beetbox.

At the end of the provisioning step it would be nice if important credentials where spat out to simplify things for the user, such as the database user/password/name, the site URL and login details.

Currently, it is very confusing for an end-users which files should be used in their custom projects.

Is it possible to move ansible and test dirs under .beetbox dir and bring config.yml into the root,
so that the list of files an end-user can use is this:

• Vagrantfile
• config.yml
  *.gitignore
• README.md

Also, it is not clear why drupal8.make.yml is there and what it does. Especially, if beetbox targets non-Drupal platforms.

Another potential point of failure is the packer templates.
https://github.com/drupalmel/beetbox/tree/master/packer

These could be merged into the single template with variables.

However, there's an outstanding issue with pushing variables to Atlas -- hashicorp/packer#2598

0.2.4 introduced the ability to add custom pre & post provisioining ansible tasks we need some docs.

The XHProf role currently requires an internet connection during provision as it tries to install both the PECL channel and package regardless of whether it is already installed (which it is in Beetbox).

As such, it means that anyone trying to provision offline with the defaults (having XHProf role being installed) will not be able to do so.

I have already submitted a PR to the role that will resolve the issue (geerlingguy/ansible-role-php-xhprof#2), but until that PR is accepted we should consider a short-term fix.

The options I can see are:

• Remove XHProf from the defaults
• Apply the PR as a patch to the role
• Use a fork of the role

After trying to install the drupalgeddon module downloading regular modules is going into the wrong place.

 13:43:34  brian@aegir  ...Sites/Vagrant/maw  ♦️ 2.2.2   dev ✘ ✹ ✭ 
$ drush @maw.local en diff
Warning: Permanently added 'maw.local,172.28.128.4' (ECDSA) to the list of known hosts.
diff was not found.                                                    [warning]
The following projects provide some or all of the extensions not            [ok]
found:
diff
Would you like to download them? (y/n): y
Project diff (7.x-3.2) downloaded to /www/sites/all/modules/diff.      [success]
The following extensions will be enabled: diff
Do you really want to continue? (y/n): y
diff was enabled successfully.                                              [ok]

 13:43:49  brian@aegir  ...Sites/Vagrant/maw  ♦️ 2.2.2   dev ✘ ✹ ✭ 
$ drush @maw.local en drupalgeddon
Warning: Permanently added 'maw.local,172.28.128.4' (ECDSA) to the list of known hosts.
drupalgeddon was not found.                                            [warning]
The following projects provide some or all of the extensions not            [ok]
found:
drupalgeddon
Would you like to download them? (y/n): y
Project drupalgeddon (7.x-1.x-dev) downloaded to                       [success]
/home/vagrant/.drush/drupalgeddon.
Project drupalgeddon contains 0 modules: .
drupalgeddon was not found.                                            [warning]
The following projects provide some or all of the extensions not            [ok]
found:
drupalgeddon
Would you like to download them? (y/n): y
Install location /home/vagrant/.drush/drupalgeddon already exists. Do you want to overwrite it? (y/n): y
Project drupalgeddon (7.x-1.x-dev) downloaded to                       [success]
/home/vagrant/.drush/drupalgeddon.
Project drupalgeddon contains 0 modules: .
drupalgeddon was not found.                                            [warning]
The following projects provide some or all of the extensions not            [ok]
found:
drupalgeddon
Would you like to download them? (y/n): y
Install location /home/vagrant/.drush/drupalgeddon already exists. Do you want to overwrite it? (y/n): y
Project drupalgeddon (7.x-1.x-dev) downloaded to                       [success]
/home/vagrant/.drush/drupalgeddon.
Project drupalgeddon contains 0 modules: .
drupalgeddon was not found.                                            [warning]
The following projects provide some or all of the extensions not            [ok]
found:
drupalgeddon
Would you like to download them? (y/n): y
Install location /home/vagrant/.drush/drupalgeddon already exists. Do you want to overwrite it? (y/n): n
Skip installation of drupalgeddon to                                   [warning]
/home/vagrant/.drush/drupalgeddon.
drupalgeddon was not found.                                            [warning]
The following projects provide some or all of the extensions not            [ok]
found:
drupalgeddon
Would you like to download them? (y/n): n
There were no extensions that could be enabled.                             [ok]

 13:57:17  brian@aegir  ...Sites/Vagrant/maw  ♦️ 2.2.2   dev ✘ ✹ ✭ 
$ drush @maw.local drupalgeddon-check
Warning: Permanently added 'maw.local,172.28.128.4' (ECDSA) to the list of known hosts.
The drush command 'drupalgeddon-check' could not be found.  Run          [error]
`drush cache-clear drush` to clear the commandfile cache if you have
installed new extensions.

 13:57:31  ✘  brian@aegir  ...Sites/Vagrant/maw  ♦️ 2.2.2   dev ✘ ✹ ✭ 
$ drush @maw.local en site_audit -y
Warning: Permanently added 'maw.local,172.28.128.4' (ECDSA) to the list of known hosts.
site_audit was not found.                                              [warning]
The following projects provide some or all of the extensions not            [ok]
found:
site_audit
Would you like to download them? (y/n): y
Project site_audit (7.x-1.15) downloaded to                            [success]
/home/vagrant/.drush/site_audit.
site_audit was not found.                                              [warning]
The following projects provide some or all of the extensions not            [ok]
found:
site_audit
Would you like to download them? (y/n): y

 13:59:53  ✘  brian@aegir  ...Sites/Vagrant/maw  ♦️ 2.2.2   dev ✘ ✹ ✭ 

With Avahi having been added, and the updated Vagrantfile supporting plugin-less DHCP networking via Avahi for mac/*nix hosts and a fall back to the previously used plugins for Windows hosts, is there any valid reason not to default to DHCP/0.0.0.0?

ATM it's difficult to determine the current value of a variable as there's many levels of overrides.

It would be nice to expose a simple Web UI inside the box that can list all available variables and their current state. This could compile all the role defaults, beetbox.config.yml, the current vagrant.config.yml + local.config.yml applying overrides. and display a simple list tabbed by role.

This could potentially be extended to be editable and allow triggering a provision from inside the box, which would be useful for non Vagrant implementations..

The number of new functionalities is constantly growing, but the automated testing is very rudimentary; currently it really only tests if it builds successfully, not if things work as expected.

I personally don't have much experience with automated testing outside of web based/PHP stuff, which isn't much use in this case, so I'm open to suggestions.

Atlas is skipping over build errors and continuing to build.

https://atlas.hashicorp.com/beet/build-configurations/box/builds/3?expanded=virtualbox-iso

for consistency, since beet_site_name is used only with drush command to install a site.

It has been discussed multiple times, but there is still no tangible result.

This issue is a placeholder for all logo discussions.

It is not obvious when you start working with beetbox what the most expected options are.

I suggest to copy these lines from beetbox.config.yml to config.yml

beet_mysql_user: beetbox
beet_mysql_password: beetbox
beet_mysql_database: "beetbox_{{ beet_project }}"

Yet another Pear package we should have by default; Twig C extension: http://twig.sensiolabs.org/doc/installation.html#installing-the-c-extension

Rather than managing 2 different pre-provisioning scripts we should look to reuse tests/dependencies.sh which is linked to the CI builds.

Rather than requiring a custom Vagrantfile it would be nice if this was moved into the box so a new project can be initialised by just vagrant init DrupalMel/beetbox; vagrant up

Currently the Drush alias root uses beet_web, but if that isn't defined in .beetbox/config.yml then it will not work correctly.

We need to set a default/fallback in the Vagrantfile.

I would suggest the default being /www/docroot and also using that as the default for the beet_root variable.

Prior to the automated builds, we where running nightly builds of DrupalMel/beetbox-dev on Atlas, allowing us to identify changes made beyond our control that had a negative effect on the builds.

Unfortunately due to the change to the versioning pattern we can not continue to do this.

Instead, what we need is to have is a nightly CircleCI trigger, which would, if the test passed, trigger the nightly Atlas builds.

There is documentation on an Experimental feature of CircleCI that will allow for this at https://circleci.com/docs/nightly-builds

Currently you can change the repository for the the 'Check for updates'/auto-update functionality, but not the branch. Having this would be super useful for anyone who wished to have their own unique modifications made during provision in their own fork and/or feature branch that they want to test or use without (or before) the need to have the changes accepted into the master repo and a new box built.

The Git module (which is already in use) has support for a refspec parameter, so all that should be needed is a new variable (beet_repo_ref) and to add it to the task.

http://docs.ansible.com/ansible/git_module.html

With lots of different things that can be done with Beetbox it is imperative that we get some good documentation going or no one will know how to use the box.

It could be a bit confusing for beginners to use vagrant init DrupalMel/beetbox for a non Drupal project.

I propose that we migrate to the new Atlas beet org -- https://atlas.hashicorp.com/beet

and rename the main box to box making the init command --
vagrant init beet/box

As these bash scripts have become inter-dependant it would make sense to combine these, and therefore always ensure beetbox dependancies are installed before provisioning.

The result could be just /ansible/beetbox.sh

Relates to #96

To better match our main builds we should use circle CI's new ubuntu 14.04 image.

Witnessed myself during Mentoring and by Brian this morning, if a role is added to a task changes and a user has beet_keep_updated set to yes it will download the changed beetbox internals during provision or a fresh up, but it won't have the added roles during said provision.

To allow for easy management of local site settings in BeetBox it would be nice to have a task/role that adds a check for a .beetbox/beetbox.settings.php to the sites installed settings.php and if present includes it.

Rather than downloading directly from atlas we should look into cloning role from the source repo.

This will make it easier to push PR's back to the just by adding your fork as a remote.

This could be the default behaviour in the box itself but would add some overhead.

Currently it's up to either @thom8 or myself to trigger a new build of the base box, so ideally we should set up some automation.

My thoughts are:

• Nightly or per master commit builds to a alternate namespace (beetbox-dev)
• Release/Tag based builds to the primary namespace (beetbox)

Both of these could potentially be triggered from Circle CI accordingly.

Rather than having to change ports to make use of nginx, it would be easier to have a beet_webserver variable and make all the changes required based on this setting.

So Ansible 2.0.0 is out now, and as such it is breaking our builds.

I suggest we implement a quickfix of enforcing Ansible 1.x until we are ready to update to 2.x.

Not sure if this is on purpose, but XDebug IS enabled for apache and FPM, but not for CLI php. xdebug.ini file is missing in /etc/php5/cli/conf.d dir.

Manually copying xdebug.ini file from FPM config to CLI config solves this issue.

If there is a config variable that needs to be added to bettbox'es config, please state it her and I will try to submit documentation PR about it.

Rather than require a config file we should create a default file.

This might also have some default config such as beet_domain as this is likely to be changed per project.

Opening an issue as I don't think this needs to happen with any urgency.

We should focus on making these roles more stable before migrating and having to deal with issues in separate projects.

Spreadsheet lists current roles and we can decide to keep, split, migrate, push upstream, merge or remove.

https://docs.google.com/spreadsheets/d/1zWGNBduhSPh7Is-wWmVoG97Sl1v2IYh1j1Y03yiSazo/edit#gid=0

I was trying to follow this:

drush dl drupal-8.0.3
cd drupal-8.0.3
vagrant init beet/box
vagrant up

And I'm getting this:

$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Preparing master VM for linked clones...
    default: This is a one time operation. Once the master VM is prepared,
    default: it will be used as a base for linked clones, making the creation
    default: of new VMs take milliseconds on a modern system.
==> default: Cloning VM...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["clonevm", "4d69b8b5-7f7d-49b9-81ae-f651ccbc66cc", "--register", "--name", "temp_clone_1460376251604_56772"]

Stderr: VBoxManage: error: Could not find a registered machine with UUID {4d69b8b5-7f7d-49b9-81ae-f651ccbc66cc}
VBoxManage: error: Details: code VBOX_E_OBJECT_NOT_FOUND (0x80bb0001), component VirtualBoxWrap, interface IVirtualBox, callee nsISupports
VBoxManage: error: Context: "FindMachine(Bstr(pszSrcName).raw(), srcMachine.asOutParam())" at line 431 of file VBoxManageMisc.cpp

This has been failing on me for a while on different projects. I can fix it only by specifying v.linked_clone = false in custom Vagrantfile.

For the sake of the DrupalCon First Time Sprinters Workshop, we are planning on adding a section on setting up PHPCS and Coder for PHP linting; It'd be nice to somehow have something setup within BeetBox so that users of BeetBox can get everything setup nice and quick.

@alexdesignworks This might be up your alley?

installed_extras is difficult to override as you need to redefine everything and make changes.

It would be nicer if each feature had it's own variable to enable/disable, we can set defaults and it's easier to override a single item as required.

In Ubuntu, the default location for www dir is /var/www, but beetbox uses /www.

Can beetbox use /var/www so that web documents would be in expected location.