palantirnet / devkit Goto Github PK

I've seen and heard about a number of new features in development or being released for drupalbox...

As a Palantiri,
I would like little more formal view into the work going on on drupalbox,
So that I can be a more informed engineer, ask better questions of the DevOps team, and better troubleshoot issues on my own.

I think this could be great in the form of a changelog, but more in-depth documentation in /docs would be great too. Thanks!

Add memcache to the base box.

Set up GitHub webhooks to trigger builds on Atlas. This would probably be just for new tags, but I'd like to understand more about exactly when it makes sense to run an Atlas build before we proceed with any development on this issue.

It looks like the latest drupalbox is reporting PHP Version 5.6.23-1+deprecated+dontuse+deb.sury.org~trusty+1. Is this intentional? Is there a newer version or a different source that we should be using?

We should have some serverspec tests to verify that certain PHP modules are installed. These are the ones we've run into issues with when they were missing in the recent PHP package source change:

• xml
• dom
• mbstring

It would also make sense to test for modules that we're specifically installing or otherwise generally relying on:

• gd
• imagick
• memcached

Some clients still are using Vagrant and needs to be updated to PHP 7.4 since php 7.3 will be deprecated soon.

This project needs a README.md, which should cover:

• What this project is
• What external projects or services it depends on -- for developing/updating, and for using the products
• Where to submit tickets
• How to update the vagrant box that you're using
• How to make and test changes to the box templates
• How to generate a box (or more likely, link to external docs on this)

The base box should include Solr, but ideally it would not be running by default -- we could switch it on with per-project provisioning, probably via a role in palantirnet/the-vagrant that would not be included in the default playbook.

I think we would want Solr 5, but we should double check the appropriate version for the Drupal 8 search_api_solr module.

When Carl set up Harris, the Vagrant box constraints were >= 0.0.6, < 1.0.0; since it was his first time using vmware on a project, he got the new 0.1.1 box!

Unfortunately, the vhost didn't seem to work correctly -- requests to http://harris.local timed out.

Pinning the box to 0.0.8 fixed the issue.

Did the 0.1.1 changes affect the apache configuration, and mean that the-vagrant's vhost template need to be updated? Or is this a bug in 0.1.1?

As an engineer,
I would like to have the ability to inspect my dev dbs in the native app of my choosing,
So that I know what voodoo Drupal does in its database.

As noted by Claudio in Coders Lounge on Sep-2 5:26PM:

inside vagrant: "/etc/ssh/sshd_config" ... the line "AllowTcpForwarding yes" (change no by yes)

Acceptance criteria:
With no additional config in the vagrant box, I should be able to connect to the drupal database via SSH tunnel from my native OS using an IDE or app like Sequel Pro.

Possible caveats:
I understand that the newest drupalbox version supports direct connect using the drupal / drupal user/pass but given that this should be a relatively trivial fix, I believe it could be useful to get into the current version of the box.

We should take Drupal Console out of this dev kit and use the version included with the project repo in {webroot}/vendor/bin instead.

https://github.com/palantirnet/devkit/blob/master/provisioning/roles/drupal-console/tasks/main.yml

And add a serverspec test!

For compatibility with Acquia / stricter YAML parsing. See https://docs.acquia.com/article/pecl-yaml-serialization-errors for details.

/cc @lukewertz

Update from Ubuntu 14.04 to 18.04, the current LTS release. EOL for 16.04 is April 20201.

Based on slack conversation starting with: https://palantirnet.slack.com/archives/C88TK42TY/p1548186659057700

@becw determined that the mail-related errors we were seeing were due to an unset sendmail_path setting in the vm's php.ini (at least for PHP 7.1)

For the cilver lining project, I followed these steps to fix it:

• set it to /usr/local/bin/mailhog sendmail [email protected] (following the step from this gist, using the out put from which mailhog to get the path to mailhog)
• restarted apache with /etc/init.d/apache2 restart and authenticating with vagrant when prompted

Seems like setting the sendmail_path value here would be helpful: https://github.com/palantirnet/devkit/blob/develop/provisioning/vars/dev/php.yml

Are there crucial or fragile components of the box that we should create tests for?

I'd like a list of these items (probably as separate issues) before proceeding with any development on this issue.

• PHP7 can only be run via PHP FPM (no more mod php)
• So we'll need to run a reverse proxy (php mod proxy?)
• Jetty doesn't exist under 16.04
• Also you're not supposed to use Jetty with newer versions of Solr anyway (Solr has its own http server)

Open questions

• How does .htaccess work with the php mod proxy?
• Should we switch to nginx at this point?

Is XDebug installed on the drupalbox? If so, how do you connect to it? Are there still performance issues associated with running Composer with XDebug enabled, or is there a workaround for that now?

I think @patrickfweston has worked on this on individual boxes, so if there are questions about our specific usage with Drupal, he will be a good resource for this issue.

Should we change the release cycle so that the version numbers for the three boxes (drupalbox, ubuntu1404, ubuntu1604) are in sync? So when one box was updated, all would receive the same version bump.

@mathewpeterson brought this up today when talking about the new drupalbox functionality he's working on.

Boxes should use a CHANGELOG to document updates between box versions. There should be stub/initial versions of these; it would be helpful if they initially contain a general review of historic changes.

What happens to email? Does this box send mail, or does it trap mail somewhere? What I've seen is that when Drupal tries to send mail, it can not--but I'm not sure if there's just missing wiring somewhere.

Ideally the box should send but trap all mail, and there should be some documentation about where to find the mail logs/sent mail.

Tracing through the dependency chain...

• drush/drush:8.1.7 requires
• consolidation/annotated-command:~2 which requires
• squizlabs/php_codesniffer:^2.7 which requires
• PHP extension simplexml.

This thread implies that adding php5.6-xml to the list of php_modules will fix the problem, and I've tested this using $ sudo apt-get update $ sudo apt-get install php5.6-xml on my box. I'd recommend we add php5.6-xml to https://github.com/palantirnet/devkit/blob/dab94a579f1cba5cbdb50cc4496835da1c79b33c/provisioning/roles/php5/defaults/main.yml