Complete upgrade to Ubuntu 14.04 LTS Trusty Tahr

Hi. Actually, Ubuntu 12.04 LTS is supported until 2017 according to http://www.ubuntu.com/server:

That said, I'm open to moving to a newer version of Ubuntu before 2017. Thanks

+1 on upgrading to Trusty Tahr, maybe even before 2015. :)

+1

+1 for supporting/upgrading to Ubuntu 14.04 LTS

I've tried changing some of the config options this evening to pull down a 14.04 box

config.vm.box = "ubuntu/trusty64"
config.vm.box_url = "https://vagrantcloud.com/ubuntu/boxes/trusty64"

... although chef provisioning complains about authz_default (an apache mod) which is fixed by commenting it out in the recipe. Also, see here: https://tickets.opscode.com/browse/COOK-3883

Even once this is fixed there continues to be errors with Apache- which I've now lost and run out of time to report here.

Would appreciate if somebody more familiar with vagrant/chef/upgrade could provide some guidance on what is required to get this request progressed.

Thanks.

I would also like a 14.04 version.

The main issue would be PHP version, but unless you are running Drupal 6 or older you shouldn't have much trouble running on stock 14.04 package versions.

Also in my experience any shared hosting I use has already upgraded to or will soon upgrade to PHP 5.4 or 5.5 while discontinuing use of 5.3 & 5.2.

So people will have to start using PHP 5.4+ anyway unless they find some dodgy (or specialist) hosting or use a VPS/dedicated server.

Not using 14.04 is the only reason I haven't tried this out yet.

In reply to #5 Checkout out http://httpd.apache.org/docs/trunk/en/upgrading.html

This may help get it started down the right path.

With that said, I agree, 12.04 is sporting an obsolete version of PHP

Got burned by a PHP 5.3 fatal error today. Would love it if someone tackled this. I attempted it, but I'm new to Chef and had difficulties getting the recipes configured.

+1 Probably in github there are some Vagrant configurations that we can take inspiration from
https://github.com/search?q=ubuntu+14.04+php+5.5+chef+vagrant&type=Code&...

Thanks for work.

Whether it is worth waiting for ubuntu 14?

What is this talk of waiting for ubuntu 14?

It is 2015.
Ubuntu 14.04 has already been out nearly a year.

How is life in 2015 rooby ? We got in a time loop here, a la Groundhog Day :(
Did Drupal 8 got released ?

I'm all in favor of moving to 14.04 64bit. Patches welcomed. Thanks

Updating the Apache and PHP cookbooks seemed to fix most of the problems caused by changes between 12.04 and 14.04. Apologies for the mega-patch caused by Berkshelf updating things - the important bits are at the very beginning and very end of the patch.

@DragonBoots: I would like to test your patch, but may I ask you which box did you use? I don't have a ubuntu 14.04 prepared for this Vagrantfile and the ones I found aren't working.

Thanks!

I used the official one, here.

Hi,
I tested it, it seems ok for me. I installed Drupal8 and I used the mailcatcher also. I didn't test webgrind, the other things seem to work for me.

Thanks!

Patch from #16 works fine, need to move webgrind from /var/www/ to /var/www/html/ to get it working.

Thanks.

Patch from #16 works for me as well. I do have a few queries about this b/c the patch failed at a couple of the berks cookbooks but I was able to fix those so they were no big deal. However, I was thinking about this tonight while swapping one of my development boxes over to this (mainly b/c I wanted an upgraded php without having to write the script to update it postinstall) and I think that changing all of those files may not be the best solution. We have a berksfile with a list of the cookbooks that the project needs. Why can't we just let that handle the cookbook downloads? I know that we would have to make sure the user has the vagrant plugin but that is pretty easy to accomplish by placing a plugin install script at the beginning of the Vagrantfile:
%x(vagrant plugin install vagrant-berkshelf) unless Vagrant.has_plugin?('vagrant-berkshelf')
then the plugin would install the correct cookbooks. We could also make different configuration berksfile's this way, like if a developer wanted to stick with the 12.04 and php 5.4 we would load that berksfile with default being 14 and php 5.5. I've used several different Vagrant boxes and setups over the years and this is by far the best one that I have came across but I think we could really amp it up with a couple of those options added. I've also came up with some more ideas on my local install that I think could help but I really would like to see this addition added. But like I said the patch works basically, if anyone really wants this out and thinks it needs to be rerolled just let me know. I could add the piece mentioned earlier also, there would be quite a few deletions but I think it would make it easier to upgrade VDD in the future without having to change all the files.

Thanks
Jeremy

I noticed that there was this one warning in the patch:
warning: 1 line adds whitespace errors.

No big deal. But how do we go applying this?

The docs here seem out of date https://www.drupal.org/node/2008802

Seems that we have to start with installing https://downloads.chef.io/chef-dk/

I don't think I'm heading in the right direction...

Thoughts on how to get this up and running with this patch?

My goal was to get the latest D8 commit up and running on VDD. The patch from this issue and from https://www.drupal.org/node/2488300 did that for me.

+1 for committing this patch.

If this makes it to the recommended download, I believe the project page will need modifying to remove reference to it working with D6. Merely an observation as most people working with D6 have their way of working already.

the patch #16 throws a warning

vdd-consider-upgrading-2327263-16.patch:10236: trailing whitespace.
default['php']['package_options'] = "" # Use this to customize your yum or apt command
warning: 1 line adds whitespace errors.

Same goal and same outcome as wheatpenny.

+1 to commit this patch.

Regarding #26 and #27, when are the warnings thrown? Is it coder, or while chef provisions the machine? If it's something that coder picks up, I would assume that we shouldn't worry about .erb files which are have been provided by other external projects.

#26 and #27 can be ignored (the patch is missapplied to external dependencies.)
i have been thinking about the suggestion from #21 to use berks to update the cookbooks. but it seems that would introduce chefdk as a new dependency. so maybe using the megapatch from #16 including the cookbooks is better after all?
(that patch was/is rtbc)

here is a patch that relies on berks (provided by chefdk)

not sure if i prefer this approach.

shouldnt have removed .gitignore during cleanup. here it is again

I just tried #32 in Windows 7 (using file system type 'smb') and then again in Ubuntu Linux (using file system type 'nfs'). Both are working well so far! I had to install chefdk, but installation was straightforward for both OS's.

I just realized that I can no longer browse to http://192.168.44.44/phpmyadmin/ as a result of applying Patch #32.

This appears to be a result of a mis-configured directory in apache2.conf.erb. Revised #32 and resubmitting as Patch #34. See interdiff for what I revised.

The introduction of berkshelf on the host mentioned in #21 and #31 makes VDD fail for me. I think we should reconsider whether berkshelf is needed on the host. I have attached patch #35 without this feature. I have tested with success on OS X Yosemite.

I've done some limited testing of the patch @KimNyholm added in #35. It provisioned with no problems whatsoever and I was able to install Drupal 8 with no problems (after applying the patch in #2488300: xdebug.max_nesting_level too low)

What other things should we be testing and reviewing?

I tested this patch to the best extent I know possible.

I destroyed my local vagrant machine, deleted all downloaded boxes, and removed the vdd directory. I then downloaded the latest VDD repo, applied the patch from #35, and ran vagrant up. The correct box downloaded, and I was able to install Drupal 7.

Once again, I destroyed my local vagrant machine, deleted all downloaded boxes, and removed the vdd directory. I redownloaded the latest VDD repo and applied the patch from #35 as well as the patch #2 from https://www.drupal.org/node/2488300. After vagrant up, I was able to install Drupal 7 and Drupal 8 without issues.

I'm marking this patch as RTBC.

I installed this from the git repo, applied the patch without problem by following #37

I did get this error on the D8 install:

xdebug.max_nesting_level is set to 200.
Set xdebug.max_nesting_level=256 in your PHP configuration as some pages in your Drupal site will not work when this setting is too low.

but it can just be changed in:
chef/cookbooks/core/vdd/templates/default/vdd_xdebug.ini.erb

But that is already noted #2488300: xdebug.max_nesting_level too low

Thanks everyone for your work on this.

This commit made for a very confusing situation for me, and I imagine it has by this point likely done so for others as well. Because it means that VDD ships with a number of additional Chef recipes *that you can't use*, or it breaks provisioning.

If the bulk of the recipes had been updated, as in patch #16, there would be no issue. Or if VDD was set up to be able to update these itself via vagrant-berkscase, as in patch #34, it wouldn't be a problem either.

But somehow it ended up to where the files weren't patched *and* the mechanism for patching was taken out. At that point, if I'm looking to do something slightly outside of the defaults, I'm 1) going to have to find out the hard way that I can't use the recipes VDD includes without breaking something, since that's not documented; 2) end up having to install ChefDK anyway; and 3) *then* get to actually editing the actual VDD config files -- at that point, I would've been as well off to just have set the Vagrant box up from scratch, because VDD didn't actually save any time or effort. (As you can imagine, the above is not a hypothetical for me.)

Seems to me the options are:
1) commit #16, have a good number of recipes working out of the gate,
2) undo the 34/35 interdiff, have end users have to wait a while for Berkshelf to do its update and dependency magic but at least things will work when they "vagrant up" if they added a recipe or two to the default role file,
3) prune the unused recipes and remove them from the project, and commit to being a bare-bones install that people can bring their own cookbook management to if they like.

Right now, VDD's situation is basically #3 but with the addition of a number of recipes that the average user may be tempted to try, but would break the box. Worst of both worlds, it would seem. My vote for fixing is option 1: I'd think it most reasonable that one would expect (most of) the contents of the tarball to work straight out of the gate. In fact, if the files are mostly updated, the argument in #35 for removing Berkshelf could be remade -- and would be a lot more defensible since it wouldn't be needed for the files in the tarball to actually work without breaking things.

(I was tempted to just make a new issue for this -- I hate being the one to reopen a closed issue, and what I'm describing could well be characterized as a "bug" -- but as the solutions themselves are all here, I ended up thinking of it not as a new "bug," but as the same old "feature request" that happens to not be fully complete and thus "needs work." I hope that's an understandable decision.)

Seeing as I am the one advocating for a fix to the problem I described, I figured I better put my money where my mouth is. (And with 16.04 LTS coming out soon, it seemed all the more important that the issue I raised be addressed, so we are not in the near future dealing with *two* full versions' worth of unsupported packages.)

Patch enclosed to update all VDD components to work with Ubuntu 14.04 Trusty Tahr. The goals with this patch were to bring every component up to compatibility with Trusty, in a comprehensive fashion -- but to do that by upgrading the necessary components as *minimally* as possible to comply with 14.04, with very few exceptions. (As opposed to, say, just bringing every component up to its current build; the patch is already almost 600k; imagine the size it would be if we were updating every component to the current version!) Primarily those exceptions are things like minor-version bumps for security patches and such.

There is one "exception," though, that I did not make but I wish I would have. I looked at the manifest for the earliest version of ChefDK listed on the Chef site as supporting Trusty (0.3.4), among other resources, for determining minimum versions of certain things (including the bump to Chef 11.16.4). One of the things in that earliest Trusty-supported ChefDK that I did not immediately incorporate into this patch is the use of Ruby 2.1.x. I figure that that's a big enough change to where it may be worth its own issue, though I think the (years-ago) unsupported and insecure status of Ruby 1.9.x and 2.0.x make it a critical one to look at -- so much so that I even created a version of this patchset that incorporates that upgrade for my own use. If it's okay with everyone, I'll add a link to the new "implement Ruby 2.1.x" issue here once I've made it.

(What I would *actually* wish we'd do, if I had my druthers, would be to use one of the many automated installers for all this -- either Chef Omnibus/Omnitruck within the VM, or Vagrant Omnibus outside it. I don't even think Chef has instructions for installing individual gems on its site anymore; besides, I don't like the idea of reinventing the wheel, especially when upstream wheel is almost always better maintained and all we have to do is require 'wheel'.)

Oh, and a final note: I am very hard pressed to believe that the change in #35 was in any way necessary -- at least without a much more specific description of the failure that was seen. It hardly seems that including the Berkshelf plugin would have *any* effect on VDD running. I wasn't about to re-enable it and refight that fight -- but I did put the lines back into the Vagrantfile, and simply commented them out so they're there for anyone who wants to enable it.

A quick note for folks looking to test this: currently, 8.x-1.x-dev will not complete Chef provisioning, so obviously neither will this patch. That is due to #2697107: Mailcatcher dependency chain broken in Ruby 1.9.x, which is an upstream bug and may not resolve for a while (it's more likely we'd move to Ruby > 1.9.x first, I'd think). There is a workaround in that patch that will allow provisioning to complete. (I believe you can also just remove vdd::mailcatcher from the Chef default role and provisioning should complete that way as well, plus take a little less time to boot, but I haven't tested that.)

A note to #44. If it is a requirement that Chef is installed on the host, the 'failure' mentioned in #35 is not relevant.

Just bumping for an update.

Is the consensus that ubuntu 14.04 will not be installed until the 12.02 reaches EOL?

I've run into an issue installing Drupal 8 because ubuntu 14.04's default PHP version is too old. I'm considering forking and creating a VDD with:

* Latest stable PHP
* Composer preinstalled

However I don't want to do double work if this is already in motion so to speak.

Thanks,
Pierce

I see that Patch #35 was committed and 8.x is on 14.04.04 (trusty) is there a reason to keep this open. @gnassar could you please give us a summary of the diffrenced between #35 and #43 and perhaps an interdiff ..

I created a clean install using the current -dev version and had no problems, it installed 14.04 just fine. If there are specific, documentable problems then please open a new issue.