[WIP] Issue #320: add a dashboard

[oxyc]

First take at a dashboard mentioned in #320. I'm not sure how we would want to add this to the webserver actually? At the moment it doesn't work 😄 It works if you set apache_remove_default_vhost: false hehe

Also I've only tested minimally (only apache for example).

I used bootstrap so this wouldn't work if the user is offline. I feel that's still okay (the stylesheet is loaded at the end of the document not to pause the rendering), maybe add some minimal styling for such cases.

One minor hack is the Adminer link for each database. This links to adminer.drupalvm.dev/?username=root&db=drupal, which is actually an auto-login feature, but it fails due to not being configured. Instead it redirects the user back to login screen with an error message AND also pre-fills the fields.

[oxyc]

Should probably be replaced with the Drupal VM logo instead

[geerlingguy]

I think @oxyc is trying to win contributor of the millenium award. I think I owe you something like six beers now. This is already awesome, and looks exactly like what I would like.

Since it's using the default path (at least for Debian, have to verify for RedHat) for the default server, the IP address of the domain should just open up to this, correct? We might need to set the apache/nginx roles to not delete the default vhost file though.

[oxyc]

That's what I thought, that it would only take over the IP, but then it took over the hostname too. Not that familiar with configuring apache though.

Haha, I'm running low on tasks at work so I'm trying to find other things to spend the day doing.

[oxyc]

Typo:

Drupal VM is A VM...

Appears in https://github.com/geerlingguy/drupal-vm/blob/master/docs/index.md as well.

[oxyc]

I got it working as expected if I changed the filenaming so that 000-default.conf loads last, and then added a ServerAlias * to it.

But I feel like it's supposed to work out of the box. Is there some hostname variable somewhere that says the IP maps to the hostname locally?

Edit: also works if I set the ServerName to the IP (then the order the files are loaded doesnt matter).

[oxyc]

So some more research for apache under ubuntu.

If you omit the ServerName directive from any name-based virtual host, the server will default to a fully qualified domain name (FQDN) derived from the system hostname. This implicitly set server name can lead to counter-intuitive virtual host matching and is discouraged.
https://httpd.apache.org/docs/trunk/vhosts/name-based.html

So the default vhost resolves to the hostname due to the following in /etc/hosts:

127.0.1.1 drupalvm.dev drupalvm 

Guess we should really be creating a new vhost using the IP. Then we dont need to care about saving the default vhost file either.

Easiest would be to continue bloating example.config.yml I guess. Any other ideas?

 - servername: "{{ vagrant_ip }}" documentroot: "/var/www/dashboard"

[oxyc]

So this works for both nginx and apache on Ubuntu at least.

diff --git a/example.config.yml b/example.config.yml index 3072d80..c402358 100644 --- a/example.config.yml +++ b/example.config.yml @@ -97,6 +97,9 @@ apache_vhosts: extra_parameters: | ProxyPassMatch ^/(.*\.php(/.*)?)$ "fcgi://127.0.0.1:9000/usr/share/php/pimpmylog" + - servername: "{{ vagrant_ip }}" + documentroot: "/var/www/dashboard" + apache_remove_default_vhost: true apache_mods_enabled: - expires.load @@ -125,6 +128,10 @@ nginx_hosts: root: "/usr/share/php/pimpmylog" is_php: true + - server_name: "{{ vagrant_ip }}" + root: "/var/www/dashboard" + + nginx_remove_default_vhost: true # MySQL Databases and users. If build_makefile: is true, first database will diff --git a/provisioning/tasks/dashboard.yml b/provisioning/tasks/dashboard.yml index 142f198..bf52847 100644 --- a/provisioning/tasks/dashboard.yml +++ b/provisioning/tasks/dashboard.yml @@ -1,6 +1,11 @@ +- name: Ensure the dashboard directory exists + file: + path: /var/www/dashboard + state: directory + mode: 0755 + - name: Copy dashboard page into place. template: src: ../templates/dashboard.html.j2 - dest: /var/www/html/index.html - force: yes + dest: /var/www/dashboard/index.html mode: 0644

Any other ideas?

[geerlingguy]

Easiest would be to continue bloating example.config.yml I guess. Any other ideas?

Let's do it. I have some long term ideas for config.yml... but I'm happy to keep it growing for now as long as little features like this are enabled by that growth!

[oxyc]

Still requires a bit of testing I think.

Also: geerlingguy/ansible-role-php-xhprof#9

[geerlingguy]

The XHProf role has been updated, and 1.1.1 contains the new install_dir variable.

[oxyc]

Needs fixup if #408 gets merged.

I'm ending up defining dashboard_docroot everywhere (needs ot be blacklisted for drush aliases too). Maybe set it as a variable (dashboard_install_dir) in example.config.yml and then use that instead of hardcoding the path? That would be a breaking variable addition though.

[geerlingguy]

That would be a breaking variable addition though.

I'm planning on bumping the minor release (at least) for the next revision of Drupal VM. Sheesh, with all these little improvements adding up to something huge, it's worthy of 3.x imo :/

I'm okay with a breaking variable change—we have had a couple in the 2.x cycle already, let's keep adding a tiny bit of pain and then I'll try to re-stabilize once we get the rest of these sweeping architectural fixes in place.

[oxyc]

I could also add a revertable commit that uses a temporary default filter in the spirit of #425 if you prefer.

Edit: Just realized we have another breaking change already though: build_makefile path #412 (comment)

[oxyc]

I'm having some very odd connection issues (I cant fetch the roles O.o) where I'm located at the moment so cant provision this locally. It still needs testing

[oxyc]

fatal: [localhost] => {'msg': "AnsibleError: file: /var/www/drupalvm/provisioning/templates/dashboard.html.j2, line number: 110, error: expected token '=', got 'end of statement block'", 'failed': True}

So the block set tag wasnt added until Jinja 2.8 which apparently isnt available on CentOS.

[geerlingguy]

Yeah, macros are a little more widely supported in my experience (though I generally avoid using them if possible because templates start getting more logic-y—in this case it's definitely necessary).

[oxyc]

Yeah, set-block was a lot more readable :/

Unfortunately I have no clue what's going on with my connection, so I cant test this locally until next week. @geerlingguy any requests or changes to get this merged?

I guess the template is a bit complex but I feel it needs to be in this case. I cant really see anything that could be stripped away... To me everything looks useful.

[geerlingguy]

Yeah, as long as the template is contained, I'm fine with it being a little complex. Rather that than add complexity to one of the other bits of the system!

[geerlingguy]

Could you add (for backwards compatibility, and to give people a way to disable it if they want):

 when: dashboard_install_dir is defined 

To both this task and the next? Or if it looks cleaner, inside provisioning/playbook.yml.

[oxyc]

Sure, I would also need to add a check to the drush alias templates. That's no biggy though.

[oxyc]

So the default filter does not work in the set assignment. O.o

[oxyc]

@geerlingguy I force updated the last commit so it uses a variable file instead of that redefinition of devtool_docroots. Besides fixing ansible+jinja limitations I think it's a lot nicer. Probably something that could be useful in the future as well. I prefixed this variable with an underscore so it's easier to understand it's an internal variable.

Tested on ubuntu 14.04 and centos 7 with and without the dashboard_install_dir.

[geerlingguy]

WIP no more... I'm loving this, and we can tweak things in a follow-up. Everything about this screams AWESOME!