Can we upgrade from PHP 5.3?

[chris]

The Transition Network site is running on PHP 5.3 and it's got ​a very serious security issue which potentially enables a remote attacked to get the servers private SSL key. Would Drupal work OK with PHP 5.4?

[paul]

If we're already on 5.3 maybe it could work on 5.4. If you could wire the latest stage site up to PHP 5.4. I could have a look for any obvious problem?

Drupal 6: PHP 5.2.x only. PHP 5.3 and later may produce errors or unexpected behaviour.

​https://www.drupal.org/requirements

[chris]

Replying to paul:

If you could wire the latest stage site up to PHP 5.4.

Where on the files system is this site?

I'll have a look for the BOA documentation regarding how to set sites to use specific version of PHP...

[chris]

Replying to chris:

I'll have a look for the BOA documentation regarding how to set sites to use specific version of PHP...

Can this be done using the web interface?

[chris]

Paul, I found ​the following -- how does it sound is this something you can do?

#-### Support for PHP FPM/CLI version safe switch per Octopus instance

  This allows to easily switch PHP version by the instance owner w/o system
  admin (root) help. All you need to do is to create ~/static/control/fpm.info
  and ~/static/control/cli.info file with a single line telling the system
  which available PHP version should be used (if installed): 5.5 or 5.4 or 5.3

  Only one of them can be set, but you can use separate versions for web access
  (fpm.info) and the Aegir backend (cli.info). The system will switch versions
  defined via these control files in 5 minutes or less. We use external control
  files and not any option in the Aegir interface to make sure you will never
  lock yourself by switching to version which may cause unexpected problems.

  Note that the same version will be used in all platforms and all sites hosted
  on the same Octopus instance. Why not to try latest and greatest PHP 5.5 now?

[paul]

Replying to chris:

Replying to paul:

If you could wire the latest stage site up to PHP 5.4.

Where on the files system is this site?

/data/disk/tn/static/transition-network-d6-s012

I'll have a look for the BOA documentation regarding how to set sites to use specific version of PHP...

[chris]

Replying to paul:

/data/disk/tn/static/transition-network-d6-s012

Hmm, the files documented in comment:4 would be:

/data/disk/tn/static/control/fpm.info
/data/disk/tn/static/control/cli.info

And setting this to contain 5.4 would effect all the sites in /data/disk/tn/static -- does that include the live site or are these all dev sites?

[paul]

Replying to chris:

Replying to paul:

/data/disk/tn/static/transition-network-d6-s012

Hmm, the files documented in comment:4 would be:

/data/disk/tn/static/control/fpm.info
/data/disk/tn/static/control/cli.info

And setting this to contain 5.4 would effect all the sites in /data/disk/tn/static -- does that include the live site or are these all dev sites?

I think this would affect all sites on all platforms.

My guess ids that these files would need to go somewhere under: /data/disk/tn/static/transition-network-d6-s012

[paul]

Both stage/ production platform can be found under /data/disk/tn/static

[paul]

Replying to paul:

Both stage/ production platforms can be found under /data/disk/tn/static

[paul]

Chris, I'll catch you tomorrow / Monday

[chris]

Replying to paul:

Chris, I'll catch you tomorrow / Monday

OK, the following was written before your last two comments.

Replying to paul:

I think this would affect all sites on all platforms.

Yes, it looks that way, from comment:4:

  Note that the same version will be used in all platforms and all sites hosted
  on the same Octopus instance. 

My guess is that these files would need to go somewhere under: /data/disk/tn/static/transition-network-d6-s012

I don't think that is an option.

I think we either need to install another version of Octopus (something I would need to research how to do) or we should try 5.4 on the live site, see if anything breaks and if it does revert to 5.3 till we have a better solution... does that sound like a plan? Is this something we could prhaps try tomorrow night (I'm too tired to stay up much longer tonight) or some other time?

[chris]

Replying to chris:

Is this something we could perhaps try tomorrow night (I'm too tired to stay up much longer tonight) or some other time?

Sorry, count me out tonight, but if you are up for it please experiment -- Sunday night one of the times when the site has the least users, so I think making it run with a later version of PHP 5.3 and looking at what, if anything, breaks would be OK -- if anything is broken it won't impact many users.

Having said that, if anyone has a local copy of the site they can try with a version of php later than 5.3 that might be best.

[paul]

Chris

I had a look around on PHP 5.5.4. The most important warnings that I see are connected with the Views module:

Strict warning: Non-static method view::load() should not be called statically in view::load() (line 906 of /Users/paul/Sites/clients/transition-network/transitionnetwork-org/www/sites/all/modules/contrib/views/views.module).

Strict warning: Declaration of views_plugin_style_default::options() should be compatible with views_object::options() in views_include_handler() (line 76 of /Users/paul/Sites/clients/transition-network/transitionnetwork-org/www/sites/all/modules/contrib/views/includes/handlers.inc).

Strict warning: Declaration of views_handler_filter_boolean_operator::value_validate() should be compatible with views_handler_filter::value_validate($form, &$form_state) in views_include_handler() (line 76 of /Users/paul/Sites/clients/transition-network/transitionnetwork-org/www/sites/all/modules/contrib/views/includes/handlers.inc).

Strict warning: Declaration of views_handler_filter::options_submit() should be compatible with views_handler::options_submit($form, &$form_state) in views_include_handler() (line 76 of /Users/paul/Sites/clients/transition-network/transitionnetwork-org/www/sites/all/modules/contrib/views/includes/handlers.inc).

Strict warning: Non-static method views_many_to_one_helper::option_definition() should not be called statically, assuming $this from incompatible context in views_handler_argument_many_to_one->option_definition() (line 35 of /Users/paul/Sites/clients/transition-network/transitionnetwork-org/www/sites/all/modules/contrib/views/handlers/views_handler_argument_many_to_one.inc).

Strict warning: Declaration of views_handler_argument::init() should be compatible with views_handler::init(&$view, $options) in views_include_handler() (line 76 of /Users/paul/Sites/clients/transition-network/transitionnetwork-org/www/sites/all/modules/contrib/views/includes/handlers.inc).

Strict warning: Non-static method view::load() should not be called statically in view::load() (line 906 of /Users/paul/Sites/clients/transition-network/transitionnetwork-org/www/sites/all/modules/contrib/views/views.module).

Notice: Undefined variable: more in include() (line 48 of /Users/paul/Sites/clients/transition-network/transitionnetwork-org/www/sites/all/themes/transition2/panels-pane.tpl.php)

Also the main content on the front page is not showing.

Other notices.

Notice: Undefined variable: form in nodeauthor_user() (line 47 of /Users/paul/Sites/clients/transition-network/transitionnetwork-org/www/sites/all/modules/contrib/nodeauthor/nodeauthor.module).

Investigating some of the errors..

[paul]

I could try the following tomorrow:

Patch file for Views 6.x-2.x-dev to work with PHP 5.4.x
​https://www.drupal.org/node/1543434

Another option is to try upgrading Views to 6.x-3.x-dev

Views 6.x-2.x to 6.x-3.x upgrade bug?
​https://www.drupal.org/node/2126687

The best option (if possible) would probably be to patch the current version of PHP.

[paul]

It looks as though PHP 5.3 is not going to get any security updates any time soon. If the security patches for 5.4/5.5 are not too complicated we could try back porting to 5.3. Maybe we could contact the PHP security experts at SektionEins?.

​https://www.sektioneins.de/en/stories/php-backporting.html

[ed]

if this is a critical security issue in php, making D6 is vulnerable to it, and has issues moving to a different version of php because of all the views etc. then there must be discsussions going on about this issue in drupal.org? those views options don't look comfortable.

[chris]

Replying to ed:

if this is a critical security issue in php, making D6 is vulnerable to it, and has issues moving to a different version of php because of all the views etc. then there must be discsussions going on about this issue in drupal.org?

You would hope so wouldn't you...

Let's do some more research on this before we decide what to do?

[paul]

Sounds good. I'll see what I can find out ..

[paul]

In this post we will detail the phpinfo() type confusion vulnerability that we disclosed to PHP.net and show how it allows a PHP script to steal the private SSL key. We demonstrate this on an Ubuntu 12.04 LTS 32 bit default installation of PHP and mod_ssl. Unfortunately this kind of problem is not considered a security problem by PHP.net and therefore this security vulnerability does not have a CVE name assigned to it, yet.

It looks as though an attacker would already need to have permissions on the server to write php scripts. I'll just double check that the PHP input format is disabled ..

[paul]

All PHP permissions are allocated to the developer / administrator roles.
​https://www.transitionnetwork.org/admin/user/permissions

PHP Input format (PHP evaluator filter) restricted to the developer role.
​https://www.transtionnetwork.org/admin/settings/filters/5

All the other Input formats do not use the PHP evaluator filter.

I think given that were always on top of server security updates and the site is configured correctly - around PHP filters - the probable likelihood of being a victim of this vulnerability is very low.

[annesley]

sounds sensible to me. i think that adequate disaster recovery is more important for us than attempting a very expensive high level of security.

what off-site data storage, file backup and quick setup do we have?

[chris]

Replying to paul:

It looks as though an attacker would already need to have permissions on the server to write php scripts.

Thanks for clarifying that. It's also worth noting that the server supports PFS so for clients with modern browsers there will be a ephemeral key generated for their HTTPS session.

Replying to annesley:

what off-site data storage, file backup and quick setup do we have?

The 3 virtual servers have their file system mounted off a BSD/NFS/ZFS file server and the whole file system is backed up and stored onto another BSD/ZFS server in the same data centre. We did have backups also being copied to a server in Manchester but this is currently off-line as the Manchester server needs a disk swapping and rebuilding as a BSD/ZFS server.

[chris]

Replying to annesley:

sounds sensible to me. i think that adequate disaster recovery is more important for us than attempting a very expensive high level of security.

what off-site data storage, file backup and quick setup do we have?

I have opened a new ticket on this with a suggested way forwards, see ticket:763.

[chris]

Replying to paul:

It looks as though PHP 5.3 is not going to get any security updates any time soon.

Thankfully there has been a final release of ​PHP 5.3.29, which we will get with BOA-2.3.0, see ticket:784

[chris]

Also note that the new BOA adds this functionality:

  This allows to easily switch PHP version by the instance owner w/o system
  admin (root) help. All you need to do is to create ~/static/control/fpm.info
  and ~/static/control/cli.info file with a single line telling the system
  which available PHP version should be used (if installed): 5.5 or 5.4 or 5.3

So it should now be possible to test a development version of the site with PHP 5.4 without impacting on the live site -- Paul is this something you could have a go at after the BOA upgrade has been done?

[chris]

The BOA upgrade which has been done on ticket:844 has resulted in this email:

Hello,

Your Aegir Hosting System has been upgraded to version BOA-2.4.2

  https://tn.puffin.webarch.net

This new BOA release includes 15 updated Aegir platforms,
13 new software versions, plus over 23 bug fixes and improvements.

IMPORTANT!

Please note that this is the last BOA upgrade which still allows
to use deprecated PHP 5.3 by default, even if it is no longer
maintained, so it will never receive fixes for many bugs and
known security issues.

Next BOA upgrade (2.4.3) will force PHP 5.5 on all hosted Aegir
instances, unless you will explicitly opt-out *before* that upgrade
using PHP version control files, as explained in our docs at:

  https://omega8.cc/how-to-quickly-switch-php-to-newer-version-330

We recommend that you try to switch to PHP 5.5 or even 5.6 as soon
as possible, so you could effectively detect any possible issues
with your site(s) and switch them explicitly to PHP 5.3 until
you will be able to fix problems and start using the latest,
much faster and secure PHP version.

If you will not configure PHP version as explained in our docs,
your instance will be automatically switched to PHP 5.5 during
the *next* BOA upgrade, expected in June 2015.

We recommend that you upgrade your sites using this safe workflow:

  https://omega8.cc/your-drupal-site-upgrade-safe-workflow-298

You can find all details on how to use new features, along with all
other changes explained in the release notes and changelog available at:

  https://omega8.cc/boa-242-full-edition-353

It is always highly recommended that you read extensive release notes
and changelog posted on our website for previous BOA Editions, so you
could keep track on the progress and learn more about great features
and improvements we have made over the last few years, no matter when
you have started using Aegir powered by BOA:

  https://omega8.cc/updates


Questions? Comments? Please contact us:

  https://omega8.cc/support
  https://omega8.cc/sales
  https://omega8.cc/billing

Thank you!
Omega8.cc Team

Paul, what do you think? Can you test a dev version of the site on PHP 5.5?

[paul]

I can take a look on my local server. My expectation is that upgrading PHP
will break the site.

Would you like me to spend an hour or two on this on Monday ?

From drupal.org:

Drupal 6: PHP 5.x only (5.2.5 or higher recommended). Warning: support for
PHP 4.x has been dropped. *Drupal core should work with PHP 5.3.x, but PHP
5.3.x and higher may produce errors or unexpected behavior especially for
contributed modules* and themes.

https://www.drupal.org/requirements

On Fri, May 1, 2015 at 11:23 PM, Transition Technology Trac <
trac@tech.transitionnetwork.org> wrote:

> #754: Can we upgrade from PHP 5.3?
> -------------------------------------+-------------------------------------
>            Reporter:  chris          |                      Owner:  chris
>                Type:  maintenance    |                     Status:  new
>            Priority:  critical       |                  Milestone:
>           Component:  Live server    |  Maintenance
>            Keywords:                 |                 Resolution:
> Add Hours to Ticket:  0              |  Estimated Number of Hours:  0.0
>         Total Hours:  2.125          |                  Billable?:  1
> -------------------------------------+-------------------------------------
> Changes (by chris):
>
>  * cc: ed (removed)
>  * cc: ade (added)
>
>
> Comment:
>
>  The BOA upgrade which has been done on ticket:844 has resulted in this
>  email:
>
>  {{{
>  Hello,
>
>  Your Aegir Hosting System has been upgraded to version BOA-2.4.2
>
>    https://tn.puffin.webarch.net
>
>  This new BOA release includes 15 updated Aegir platforms,
>  13 new software versions, plus over 23 bug fixes and improvements.
>
>  IMPORTANT!
>
>  Please note that this is the last BOA upgrade which still allows
>  to use deprecated PHP 5.3 by default, even if it is no longer
>  maintained, so it will never receive fixes for many bugs and
>  known security issues.
>
>  Next BOA upgrade (2.4.3) will force PHP 5.5 on all hosted Aegir
>  instances, unless you will explicitly opt-out *before* that upgrade
>  using PHP version control files, as explained in our docs at:
>
>    https://omega8.cc/how-to-quickly-switch-php-to-newer-version-330
>
>  We recommend that you try to switch to PHP 5.5 or even 5.6 as soon
>  as possible, so you could effectively detect any possible issues
>  with your site(s) and switch them explicitly to PHP 5.3 until
>  you will be able to fix problems and start using the latest,
>  much faster and secure PHP version.
>
>  If you will not configure PHP version as explained in our docs,
>  your instance will be automatically switched to PHP 5.5 during
>  the *next* BOA upgrade, expected in June 2015.
>
>  We recommend that you upgrade your sites using this safe workflow:
>
>    https://omega8.cc/your-drupal-site-upgrade-safe-workflow-298
>
>  You can find all details on how to use new features, along with all
>  other changes explained in the release notes and changelog available at:
>
>    https://omega8.cc/boa-242-full-edition-353
>
>  It is always highly recommended that you read extensive release notes
>  and changelog posted on our website for previous BOA Editions, so you
>  could keep track on the progress and learn more about great features
>  and improvements we have made over the last few years, no matter when
>  you have started using Aegir powered by BOA:
>
>    https://omega8.cc/updates
>
>
>  Questions? Comments? Please contact us:
>
>    https://omega8.cc/support
>    https://omega8.cc/sales
>    https://omega8.cc/billing
>
>  Thank you!
>  Omega8.cc Team
>  }}}
>
>  Paul, what do you think?  Can you test a dev version of the site on PHP
>  5.5?
>
> --
> Ticket URL: <https://tech.transitionnetwork.org/trac/ticket/754#comment:26
> >
> Transition Technology <https://tech.transitionnetwork.org/trac>
> Support and issues tracking for the Transition Network Web Project.
>



-- 
Best

Paul Booker
Drupal Developer & Linux Systems Administrator
Website: http://www.paulbooker.co.uk
Drupal.org: https://www.drupal.org/u/paulbooker
Twitter: @paulbooker <https://www.twitter.com/paulbooker>
Tel: +44 01922 861636

[chris]

Replying to paul:

Would you like me to spend an hour or two on this on Monday ?

I would but it's not my decision, this is one for Ade. Note that the next version of BOA is due out in 5 weeks (​June 7, 2015) so ideally we would have resolved any issues with upgrading to PHP 5.5 by then.

[chris]

On ticket:844#comment:16 paul wrote:

I just had a quick look at the TN site on my local server, using PHP 5.5.3, and I can see lots of PHP strict warning messages but no reported errors. Also, when browsing the site I can't see anything that's obviously broken.

How much time would be involved to set up a dev copy of the live site for testing on PuffinServer using the functionality documented here ticket:754#comment:25 -- I'd suggest that having a few people testing the site with PHP 5.5 before considering switching the live site might be a good idea?

[paul]

It should not take more than a couple of hours as we already have a copy[*] of the site of the site on the server that we could use.

[*] ​https://booker-stage-20150319.transitionnetwork.org/

[chris]

According to ticket:754#comment:25 all that we need to do to run the ​stage copy of the site on PHP 5.5 is:

create ~/static/control/fpm.info and ~/static/control/cli.info file with a single line telling the system which available PHP version should be used (if installed): 5.5 or 5.4 or 5.3

That shouldn't take long to do (creating the two text files) and once that is done people should be able to login to the ​stage copy to check that things still work?

[paul]

As long as there are no problems it should not take more than half an hour.

[sam]

Hi Paul

I'm aware that Ade is deep in reports this week so going offline.

It sounds like work that needs doing so 30mins seems reasonable.

I say go for it. I'm so confident that Ade will cough up the £15 I'll
pay it out of my own pocket if he doesn't..

Cheers

Sam


On 5 May 2015 at 16:40, Transition Technology Trac
<trac@tech.transitionnetwork.org> wrote:
> #754: Can we upgrade from PHP 5.3?
> -------------------------------------+-------------------------------------
>            Reporter:  chris          |                      Owner:  chris
>                Type:  maintenance    |                     Status:  new
>            Priority:  critical       |                  Milestone:
>           Component:  Live server    |  Maintenance
>            Keywords:                 |                 Resolution:
> Add Hours to Ticket:  0.125          |  Estimated Number of Hours:  0.0
>         Total Hours:  2.25           |                  Billable?:  1
> -------------------------------------+-------------------------------------
> Changes (by paul):
>
>  * hours:  0.0 => 0.125
>  * totalhours:  2.25 => 2.375
>
>
> Comment:
>
>  As long as there are no problems it should not take more than half an
>  hour.
>
> --
> Ticket URL: <https://tech.transitionnetwork.org/trac/ticket/754#comment:32>
> Transition Technology <https://tech.transitionnetwork.org/trac>
> Support and issues tracking for the Transition Network Web Project.

[paul]

Thanks Sam.

I schedule 30 minutes and no more.

Best, Paul

On Tue, May 5, 2015 at 5:25 PM, Transition Technology Trac <
trac@tech.transitionnetwork.org> wrote:

> #754: Can we upgrade from PHP 5.3?
> -------------------------------------+-------------------------------------
>            Reporter:  chris          |                      Owner:  chris
>                Type:  maintenance    |                     Status:  new
>            Priority:  critical       |                  Milestone:
>           Component:  Live server    |  Maintenance
>            Keywords:                 |                 Resolution:
> Add Hours to Ticket:  0              |  Estimated Number of Hours:  0.0
>         Total Hours:  2.375          |                  Billable?:  1
> -------------------------------------+-------------------------------------
>
> Comment (by sam):
>
>  {{{
>  Hi Paul
>
>  I'm aware that Ade is deep in reports this week so going offline.
>
>  It sounds like work that needs doing so 30mins seems reasonable.
>
>  I say go for it. I'm so confident that Ade will cough up the £15 I'll
>  pay it out of my own pocket if he doesn't..
>
>  Cheers
>
>  Sam
>
>
>  On 5 May 2015 at 16:40, Transition Technology Trac
>  <trac@tech.transitionnetwork.org> wrote:
>  > #754: Can we upgrade from PHP 5.3?
>  >
>
>  -------------------------------------+-------------------------------------
>  >            Reporter:  chris          |                      Owner:
>  chris
>  >                Type:  maintenance    |                     Status:  new
>  >            Priority:  critical       |                  Milestone:
>  >           Component:  Live server    |  Maintenance
>  >            Keywords:                 |                 Resolution:
>  > Add Hours to Ticket:  0.125          |  Estimated Number of Hours:  0.0
>  >         Total Hours:  2.25           |                  Billable?:  1
>  >
>
>  -------------------------------------+-------------------------------------
>  > Changes (by paul):
>  >
>  >  * hours:  0.0 => 0.125
>  >  * totalhours:  2.25 => 2.375
>  >
>  >
>  > Comment:
>  >
>  >  As long as there are no problems it should not take more than half an
>  >  hour.
>  >
>  > --
>  > Ticket URL:
>  <https://tech.transitionnetwork.org/trac/ticket/754#comment:32>
>  > Transition Technology <https://tech.transitionnetwork.org/trac>
>  > Support and issues tracking for the Transition Network Web Project.
>
>  }}}
>
> --
> Ticket URL: <https://tech.transitionnetwork.org/trac/ticket/754#comment:33
> >
> Transition Technology <https://tech.transitionnetwork.org/trac>
> Support and issues tracking for the Transition Network Web Project.
>



-- 
Best

Paul Booker
Drupal Developer & Linux Systems Administrator
Website: http://www.paulbooker.co.uk
Drupal.org: https://www.drupal.org/u/paulbooker
Twitter: @paulbooker <https://www.twitter.com/paulbooker>
Tel: +44 01922 861636

[paul]

You can only change the PHP version used on the fly for each Octopus instance not on a site by site basis.

I could set up the site on my pantheon account. This would take one hour to setup.

[chris]

Replying to paul:

You can only change the PHP version used on the fly for each Octopus instance not on a site by site basis.

Very sorry, I assumed you could run different sites using different versions of PHP, but I was wrong:

the same version will be used in all platforms and all sites hosted on the same Aegir Octopus instance

​https://omega8.cc/how-to-quickly-switch-php-to-newer-version-330

[ade]

Hi All,
I apologise for coming into this conversation late.
I understand that the upgrade of the PHP version is a mission critical
upgrade and as such appreciate that this needs to be done over the next 3
weeks.

Paul & Chris,
I would really appreciate it if you could advise on time required to make
the required updates, and any impacts that we need to be aware of. I fully
appreciate the effort that has been done to date with Paul testing the site
on a sandbox server to check for issues. Many thanks for that.

Could you please advise on a date that would be good for you both to
undertake this upgrade.
Do you have a procedure that we should undertake to make the upgrade in a
controlled manner?
Are there any issues you know of now that we need to take into account
prior to the upgrade?
Is there any testing that you will need to schedule that would you would
appreciate help with?
Do we need to advise the editors/users of any down time for this upgrade?

Again, sorry for the late reply to this concern. I am now all ears for
making a plan on how to handle this requirement going forward.

best regards
Ade


On 6 May 2015 at 12:54, Transition Technology Trac <
trac@tech.transitionnetwork.org> wrote:

> #754: Can we upgrade from PHP 5.3?
> -------------------------------------+-------------------------------------
>            Reporter:  chris          |                      Owner:  chris
>                Type:  maintenance    |                     Status:  new
>            Priority:  critical       |                  Milestone:
>           Component:  Live server    |  Maintenance
>            Keywords:                 |                 Resolution:
> Add Hours to Ticket:  0              |  Estimated Number of Hours:  0.0
>         Total Hours:  2.875          |                  Billable?:  1
> -------------------------------------+-------------------------------------
>
> Comment (by chris):
>
>  Replying to [comment:35 paul]:
>  > You can only change the PHP version used on the fly for each Octopus
>  instance not on a site by site basis.
>
>  Very sorry, I assumed you could run different sites using different
>  versions of PHP, but I was wrong:
>
>  > the same version will be used in all platforms and all sites hosted on
>  the same Aegir Octopus instance
>  >
>  > https://omega8.cc/how-to-quickly-switch-php-to-newer-version-330
>
> --
> Ticket URL: <https://tech.transitionnetwork.org/trac/ticket/754#comment:36
> >
> Transition Technology <https://tech.transitionnetwork.org/trac>
> Support and issues tracking for the Transition Network Web Project.
>



-- 
Ade Stuart
Web Manager - Transition network

07595 331877

The Transition Network is a registered charity
address: 43 Fore St, Totnes, Devon, TQ9 5HN, UK
website: www.transitionnetwork.org
TN company no: 6135675 TN charity no: 1128675

[chris]

As far as I'm aware Paul is waiting for the go-ahead to set up a trial version of the site using his pantheon account, see ticket:754#comment:35. Another way to do some testing this would be to take a snapshot of the PuffinServer and to them change the IP address of the snapshot and run it and then experiment with the newer version of PHP on it. The thing to be careful about with copies of the site is ensuring that they don't sent out email to users.

[paul]

Hi Ade,

I could get the site set up on my pantheon account and we can then all test
the site on a web server running a recent version of PHP?

Best, Paul

On Mon, May 18, 2015 at 12:51 PM, Ade Stuart <
adestuart@transitionnetwork.org> wrote:

> Hi All,
> I apologise for coming into this conversation late.
> I understand that the upgrade of the PHP version is a mission critical
> upgrade and as such appreciate that this needs to be done over the next 3
> weeks.
>
> Paul & Chris,
> I would really appreciate it if you could advise on time required to make
> the required updates, and any impacts that we need to be aware of. I fully
> appreciate the effort that has been done to date with Paul testing the site
> on a sandbox server to check for issues. Many thanks for that.
>
> Could you please advise on a date that would be good for you both to
> undertake this upgrade.
> Do you have a procedure that we should undertake to make the upgrade in a
> controlled manner?
> Are there any issues you know of now that we need to take into account
> prior to the upgrade?
> Is there any testing that you will need to schedule that would you would
> appreciate help with?
> Do we need to advise the editors/users of any down time for this upgrade?
>
> Again, sorry for the late reply to this concern. I am now all ears for
> making a plan on how to handle this requirement going forward.
>
> best regards
> Ade
>
>
> On 6 May 2015 at 12:54, Transition Technology Trac <
> trac@tech.transitionnetwork.org> wrote:
>
>> #754: Can we upgrade from PHP 5.3?
>>
>> -------------------------------------+-------------------------------------
>>            Reporter:  chris          |                      Owner:  chris
>>                Type:  maintenance    |                     Status:  new
>>            Priority:  critical       |                  Milestone:
>>           Component:  Live server    |  Maintenance
>>            Keywords:                 |                 Resolution:
>> Add Hours to Ticket:  0              |  Estimated Number of Hours:  0.0
>>         Total Hours:  2.875          |                  Billable?:  1
>>
>> -------------------------------------+-------------------------------------
>>
>> Comment (by chris):
>>
>>  Replying to [comment:35 paul]:
>>  > You can only change the PHP version used on the fly for each Octopus
>>  instance not on a site by site basis.
>>
>>  Very sorry, I assumed you could run different sites using different
>>  versions of PHP, but I was wrong:
>>
>>  > the same version will be used in all platforms and all sites hosted on
>>  the same Aegir Octopus instance
>>  >
>>  > https://omega8.cc/how-to-quickly-switch-php-to-newer-version-330
>>
>> --
>> Ticket URL: <
>> https://tech.transitionnetwork.org/trac/ticket/754#comment:36>
>> Transition Technology <https://tech.transitionnetwork.org/trac>
>> Support and issues tracking for the Transition Network Web Project.
>>
>
>
>
> --
> Ade Stuart
> Web Manager - Transition network
>
> 07595 331877
>
> The Transition Network is a registered charity
> address: 43 Fore St, Totnes, Devon, TQ9 5HN, UK
> website: www.transitionnetwork.org
> TN company no: 6135675 TN charity no: 1128675
>
>
>
>


-- 
Best

Paul Booker
Drupal Developer & Linux Systems Administrator
Website: http://www.paulbooker.co.uk
Drupal.org: https://www.drupal.org/u/paulbooker
Twitter: @paulbooker <https://www.twitter.com/paulbooker>
Tel: +44 01922 861636

[chris]

One question regarding using a pantheon account -- would the database be uploaded vai an encrypted route and would the admin interface only be available via an encrypted interface? I'm concerned that the user account data isn't made available to a man in the middle attack via an unencrypted transfer.

[paul]

Yes, everything is done over SSL. Is it possible to install the website on
one of your web servers?

On Mon, May 18, 2015 at 2:34 PM, Transition Technology Trac <
trac@tech.transitionnetwork.org> wrote:

> #754: Can we upgrade from PHP 5.3?
> -------------------------------------+-------------------------------------
>            Reporter:  chris          |                      Owner:  chris
>                Type:  maintenance    |                     Status:  new
>            Priority:  critical       |                  Milestone:
>           Component:  Live server    |  Maintenance
>            Keywords:                 |                 Resolution:
> Add Hours to Ticket:  0              |  Estimated Number of Hours:  0.0
>         Total Hours:  2.875          |                  Billable?:  1
> -------------------------------------+-------------------------------------
>
> Comment (by chris):
>
>  One question regarding using a pantheon account -- would the database be
>  uploaded vai an encrypted route and would the admin interface only be
>  available via an encrypted interface? I'm concerned that the user account
>  data isn't made available to a man in the middle attack via an unencrypted
>  transfer.
>
> --
> Ticket URL: <https://tech.transitionnetwork.org/trac/ticket/754#comment:40
> >
> Transition Technology <https://tech.transitionnetwork.org/trac>
> Support and issues tracking for the Transition Network Web Project.
>



-- 
Best

Paul Booker
Drupal Developer & Linux Systems Administrator
Website: http://www.paulbooker.co.uk
Drupal.org: https://www.drupal.org/u/paulbooker
Twitter: @paulbooker <https://www.twitter.com/paulbooker>
Tel: +44 01922 861636

[chris]

Replying to paul:

Yes, everything is done over SSL. Is it possible to install the website on
one of your web servers?

Yes, we could either copy PuffinServer and then change it's IP address or we could provide a brand new server to install BOA on and then the site could be cloned to that using the BOA tools.

[paul]

I'm happy to leave this in your hands Chris: if you have the time?

On Mon, May 18, 2015 at 5:18 PM, Transition Technology Trac <
trac@tech.transitionnetwork.org> wrote:

> #754: Can we upgrade from PHP 5.3?
> -------------------------------------+-------------------------------------
>            Reporter:  chris          |                      Owner:  chris
>                Type:  maintenance    |                     Status:  new
>            Priority:  critical       |                  Milestone:
>           Component:  Live server    |  Maintenance
>            Keywords:                 |                 Resolution:
> Add Hours to Ticket:  0              |  Estimated Number of Hours:  0.0
>         Total Hours:  2.875          |                  Billable?:  1
> -------------------------------------+-------------------------------------
>
> Comment (by chris):
>
>  Replying to [comment:41 paul]:
>  >
>  > Yes, everything is done over SSL. Is it possible to install the website
>  on
>  > one of your web servers?
>
>  Yes, we could either copy PuffinServer and then change it's IP address or
>  we could provide a brand new server to install BOA on and then the site
>  could be cloned to that using the BOA tools.
>
> --
> Ticket URL: <https://tech.transitionnetwork.org/trac/ticket/754#comment:42
> >
> Transition Technology <https://tech.transitionnetwork.org/trac>
> Support and issues tracking for the Transition Network Web Project.
>



-- 
Best

Paul Booker
Drupal Developer & Linux Systems Administrator
Website: http://www.paulbooker.co.uk
Drupal.org: https://www.drupal.org/u/paulbooker
Twitter: @paulbooker <https://www.twitter.com/paulbooker>
Tel: +44 01922 861636

[chris]

Replying to paul:

I'm happy to leave this in your hands Chris: if you have the time?

If we could all agree a way of doing this that would help, I don't think we are there yet?

We seem to have 3 options:

1. Paul uses his Pantheon account to set up a test site.
2. Webarchitects sets up a snapshot of PuffinServer on another IP address as a test server.
3. Webarchitects creates a new virtual server, installs BOA and ​xboa is used to copy the site to the new test server.

Option 2. and 3. will not only require a fair amount of my time (and probably Alans for option 2.) but there will also be the cost of the additional virtual server, though it could have substiantially less resources than PuffinServer has (eg 2GB of RAM rather than 8GB) and we might only need to run it for a week or so. I think my perfered way of doing it would be option 3. with Paul doing the xboa migration steps, but I suspect that option 2. might be quicker, I don't have a view either way regarding option 1.

What do other people think? How should we best do this?

[chris]

Note that (as usual!) I made some typos in the above comment, ticket:754#comment:44, the key one being that I wanted to say that I suspect option 2. might be quicker that option 3 (this has already been corrected in the web version of the comment, see ​the diff.).

[paul]

Hello.

Maybe this could be a good time to discuss whether we should continue to use Aeigir, .. and what the alternatives could be? If it's better to build new web server(s) that doesn't use Aeigir ,.. we could then build the new web server(s) and copy the current site to the new server. Later we could update the database and switch the DNS over to the new web server(s).

Another item to consider is that our website will soon - no longer supported by the security team - so we also need to consider if we're going to continue running the site on Drupal. If we're going to continue running the site on Drupal then we need to begin work now on migrating the site to Drupal 7.

Best, Paul

[chris]

BOA 2.4.3 came out 7 days ago, see: ticket:854.

We need to decide:

1. Do we want to test the site with PHP 5.5 on the live PuffinServer?
2. Do we want to set up a new development server to test the site with PHP 5.5 on?

If we decide on 2. above then we need to decide how to do this, the options discussed so far are:

1. Paul sets up a dev server using Pantheon.
2. Chris copies PuffinServer, changes the IP address of the copy and makes it live for testing.
3. Chris creates a new server and installs BOA 2.4.3 and then Paul uses ​xboa to copy the site to the new server.

I think 3. is probably the most sensible option, but 2. might be a little quicker.

[paul]

I guess 3 could give me problems; as I don't understand the platform
architecture. So my preference would be 2.

Best, Paul

On Tue, May 26, 2015 at 11:37 AM, Transition Technology Trac <
trac@tech.transitionnetwork.org> wrote:

> #754: Can we upgrade from PHP 5.3?
> -------------------------------------+-------------------------------------
>            Reporter:  chris          |                      Owner:  chris
>                Type:  maintenance    |                     Status:  new
>            Priority:  critical       |                  Milestone:
>           Component:  Live server    |  Maintenance
>            Keywords:                 |                 Resolution:
> Add Hours to Ticket:  0              |  Estimated Number of Hours:  0.0
>         Total Hours:  3.125          |                  Billable?:  1
> -------------------------------------+-------------------------------------
>
> Comment (by chris):
>
>  BOA 2.4.3 came out 7 days ago, see: ticket:854.
>
>  We need to decide:
>
>  1. Do we want to test the site with PHP 5.5 on the live PuffinServer?
>  2. Do we want to set up a new development server to test the site with PHP
>  5.5 on?
>
>  If we decide on 2. above then we need to decide how to do this, the
>  options discussed so far are:
>
>  1. Paul sets up a dev server using Pantheon.
>  2. Chris copies PuffinServer, changes the IP address of the copy and makes
>  it live for testing.
>  3. Chris creates a new server and installs BOA 2.4.3 and then Paul uses
>  [https://github.com/omega8cc/boa/blob/master/docs/MIGRATE.txt xboa] to
>  copy the site to the new server.
>
>  I think 3. is probably the most sensible option, but 2. might be a little
>  quicker.
>
> --
> Ticket URL: <https://tech.transitionnetwork.org/trac/ticket/754#comment:47
> >
> Transition Technology <https://tech.transitionnetwork.org/trac>
> Support and issues tracking for the Transition Network Web Project.
>



-- 
Best

Paul Booker
Drupal Developer & Linux Systems Administrator
Website: http://www.paulbooker.co.uk
Drupal.org: https://www.drupal.org/u/paulbooker
Tel: +44 01922 861636

[ade]

Hi Chris, Paul

So can we please confirm that this is the agreed way forward?


* 2. Chris copies PuffinServer, changes the IP address of the copy and
makes it live for testing.*

Chris, can you please give a timeline of when you can do this, and time
required to do it.

Can I please then confirm requirements? Is the idea to install the new php
version on the newly created Puffin replicated instance or does Paul need
to do this?

We can then look at testing? Or are there things we need to take into
account?

Many thanks for all your input,
best regards
Ade

[chris]

Replying to ade:

2. Chris copies PuffinServer, changes the IP address of the copy and makes it live for testing.

Chris, can you please give a timeline of when you can do this, and time required to do it.

I need to have a chat with Alan at Webarchitects about this, I'll answer these questions after I have had some feedback from him.

Can I please then confirm requirements? Is the idea to install the new php version on the newly created Puffin replicated instance or does Paul need to do this?

No, PuffinServer already has PHP 5.5 on it, it is simply a matter of using a control file, see:

• ​https://omega8.cc/how-to-quickly-switch-php-to-newer-version-330

Alternatively we could upgrade the copy of the server to BOA 2.4.3 and that should do it.

We can then look at testing? Or are there things we need to take into account?

Yes, the things we have to ensure don't cause problems are things like emails -- we will need to disable sending emails on the copy of the server. I'm also unsure how BOA will cope with all the domain names being changed for the server -- we might need to edit our local /etc/hosts files to be able to access the copy of PuffinServer.

[paul]

Sounds good.

Agreed. Disable the email gateway on the webserver.
https://wiki.transitionnetwork.org/BOA_Server/Development_workflow





On Tue, May 26, 2015 at 1:18 PM, Transition Technology Trac <
trac@tech.transitionnetwork.org> wrote:

> #754: Can we upgrade from PHP 5.3?
> -------------------------------------+-------------------------------------
>            Reporter:  chris          |                      Owner:  chris
>                Type:  maintenance    |                     Status:  new
>            Priority:  critical       |                  Milestone:
>           Component:  Live server    |  Maintenance
>            Keywords:                 |                 Resolution:
> Add Hours to Ticket:  0              |  Estimated Number of Hours:  0.0
>         Total Hours:  3.125          |                  Billable?:  1
> -------------------------------------+-------------------------------------
>
> Comment (by chris):
>
>  Replying to [comment:49 ade]:
>  >
>  > > 2. Chris copies PuffinServer, changes the IP address of the copy and
>  makes it live for testing.
>  >
>  > Chris, can you please give a timeline of when you can do this, and time
>  required to do it.
>
>  I need to have a chat with Alan at Webarchitects about this, I'll answer
>  these questions after I have had some feedback from him.
>
>  > Can I please then confirm requirements? Is the idea to install the new
>  php version on the newly created Puffin replicated instance or does Paul
>  need to do this?
>
>  No, PuffinServer already has PHP 5.5 on it, it is simply a matter of using
>  a control file, see:
>
>  - https://omega8.cc/how-to-quickly-switch-php-to-newer-version-330
>
>  Alternatively we could upgrade the copy of the server to BOA 2.4.3 and
>  that should do it.
>
>  > We can then look at testing? Or are there things we need to take into
>  account?
>
>  Yes, the things we have to ensure don't cause problems are things like
>  emails -- we will need to disable sending emails on the copy of the
>  server. I'm also unsure how BOA will cope with all the domain names being
>  changed for the server -- we might need to edit our local `/etc/hosts`
>  files to be able to access the copy of PuffinServer.
>
> --
> Ticket URL: <https://tech.transitionnetwork.org/trac/ticket/754#comment:50
> >
> Transition Technology <https://tech.transitionnetwork.org/trac>
> Support and issues tracking for the Transition Network Web Project.
>



-- 
Best

Paul Booker
Drupal Developer & Linux Systems Administrator
Website: http://www.paulbooker.co.uk
Drupal.org: https://www.drupal.org/u/paulbooker
Tel: +44 01922 861636

[chris]

Replying to chris:

Replying to ade:

2. Chris copies PuffinServer, changes the IP address of the copy and makes it live for testing.

Chris, can you please give a timeline of when you can do this, and time required to do it.

I need to have a chat with Alan at Webarchitects about this, I'll answer these questions after I have had some feedback from him.

How is this plan:

1. Shutdown PuffinServer
2. Copy the disk image of PuffinServer
3. Start PuffinServer
4. Mount the copied disk image as a loopback device
5. Edit things like the IP address and email settings on the copied disk
6. Unmount the disk
7. Edit the Xen settings, Mac address, paths to the disks, etc
8. Boot the copy of PuffinServer

I'll try and do the above either tonight or Sunday night to minimise disruption (on Sundays the site has the least traffic), it shouldn't take more than 30 mins or so. Once the copy of PuffinServer is up and running we should aim to do the testing on it as quickly as possible in order to minimise the cost of running it, (it will be £41 a week as it's a ​8GB VM).

[chris]

I'm going to shutdown PuffinServer in order to copy it now. I'll bring it back up as soon as it has been copied.

[chris]

xm shutdown puffin.webarch.net
cd /mnt/xendomu/domains/
cp -a puffin.webarch.net/ puffin-copy.webarch.net/
cd /etc/xen
xm create puffin.webarch.net.cfg

That took quite a while, sorry for the downtime, it's on it's way back up now, loading the firewall takes ages, I'll edit and mount the copied disk tomorrow.

[chris]

I have copied the Xen config, changed the IP to 81.95.52.13, changed the Mac address and also the disk path.

Mounting the disk and editing some key config files:

mkdir /mnt/puffin-copy
mount -o loop /mnt/xendomu/domains/puffin-copy.webarch.net/disk.img /mnt/puffin-copy
vim /mnt/puffin-copy/etc/network/interfaces
vim /mnt/puffin-copy/etc/hosts
vim /mnt/puffin-copy/etc/hostname
vim /mnt/puffin-copy/etc/mailname
grep -lR 81.95.52.103 /mnt/puffin-copy/
vim /mnt/puffin-copy/data/disk/tn/config/includes/nginx_vhost_common.conf 
vim /mnt/puffin-copy/data/disk/tn/.drush/server_master.alias.drushrc.php 
vim /mnt/puffin-copy/data/disk/tn/.drush/sys/provision/http/Provision/Config/Ngin/Inc/vhost_include.tpl.php
vim /mnt/puffin-copy/data/disk/tn/.drush/sys/provision/http/Provision/Config/Nginx/subdir.tpl.php
vim /mnt/puffin-copy/data/disk/tn/log/setupmail.txt 
vim /mnt/puffin-copy/data/disk/tn/log/setupmail.txt 
wim /mnt/puffin-copy/data/disk/tn/aegir/distro/*/profiles/hostmaster/modules/hosting_advanced_cron/hosting_advanced_cron.module
vim /mnt/puffin-copy/root/.barracuda.cnf
vim /mnt/puffin-copy/root/.local.IP.list 
vim /mnt/puffin-copy/root/.local.IP.list.allow
vim /mnt/puffin-copy/root/00_puffin.conf 

I think these are the key files, there will be others but who knows what or where these will be...

Unmount and start the server:

umount /mnt/puffin-copy
cd /etc/xen
xen create -c puffin-copy.webarch.net.cfg

So the server should be available at puffin-copy.webarch.net / 81.95.52.13 however it can't be pinged, there is no ssh access and it is not responding to HTTP requests...

So, I'm not sure if I should spend more time trying to sort this out or if we should try my prefered approach, option 3. in ticket:754#comment:47.

The next thing to try would be to shutdown and root the server (I don't think we have a login to it as we always use keys, but perhaps one can be found?).

[chris]

Very sorry about the downtime caused this morning, the problem however has been found, I forgot to change the vifname in the xen config file, this has now been fixed:

vif         = [ 'ip=81.95.52.13,mac=00:16:3e:19:68:33,vifname=puffin-copy,bridge=xenbr0' ]

So I'll try and boot the copy again now.

[ade]

Hi Chris,
My understanding is that BOA needs this change to take place if we intend
to install the June update.

I feel that we need more time to a) make a decision and b) to implement any
changes.
To this end, is it possible that we can stop BOA from doing the upgrade to
PHP5.5 and so give ourselves more time?

By doing this I understand that it should give us a couple of months
leeway, is that correct?

Cheers
Ade




On 1 June 2015 at 10:11, Transition Technology Trac <
trac@tech.transitionnetwork.org> wrote:

> #754: Can we upgrade from PHP 5.3?
> -------------------------------------+-------------------------------------
>            Reporter:  chris          |                      Owner:  chris
>                Type:  maintenance    |                     Status:  new
>            Priority:  critical       |                  Milestone:
>           Component:  Live server    |  Maintenance
>            Keywords:                 |                 Resolution:
> Add Hours to Ticket:  1              |  Estimated Number of Hours:  0.0
>         Total Hours:  3.375          |                  Billable?:  1
> -------------------------------------+-------------------------------------
> Changes (by chris):
>
>  * hours:  0.0 => 1.0
>  * totalhours:  3.375 => 4.375
>
>
> Comment:
>
>  I have copied the Xen config, changed the IP to 81.95.52.13, changed the
>  Mac address and also the disk path.
>
>  Mounting the disk and editing some key config files:
>
>  {{{
>  mkdir /mnt/puffin-copy
>  mount -o loop /mnt/xendomu/domains/puffin-copy.webarch.net/disk.img /mnt
>  /puffin-copy
>  vim /mnt/puffin-copy/etc/network/interfaces
>  vim /mnt/puffin-copy/etc/hosts
>  vim /mnt/puffin-copy/etc/hostname
>  vim /mnt/puffin-copy/etc/mailname
>  grep -lR 81.95.52.103 /mnt/puffin-copy/
>  vim /mnt/puffin-copy/data/disk/tn/config/includes/nginx_vhost_common.conf
>  vim /mnt/puffin-copy/data/disk/tn/.drush/server_master.alias.drushrc.php
>  vim /mnt/puffin-
>
>  copy/data/disk/tn/.drush/sys/provision/http/Provision/Config/Ngin/Inc/vhost_include.tpl.php
>  vim /mnt/puffin-
>
>  copy/data/disk/tn/.drush/sys/provision/http/Provision/Config/Nginx/subdir.tpl.php
>  vim /mnt/puffin-copy/data/disk/tn/log/setupmail.txt
>  vim /mnt/puffin-copy/data/disk/tn/log/setupmail.txt
>  wim /mnt/puffin-
>
>  copy/data/disk/tn/aegir/distro/*/profiles/hostmaster/modules/hosting_advanced_cron/hosting_advanced_cron.module
>  vim /mnt/puffin-copy/root/.barracuda.cnf
>  vim /mnt/puffin-copy/root/.local.IP.list
>  vim /mnt/puffin-copy/root/.local.IP.list.allow
>  vim /mnt/puffin-copy/root/00_puffin.conf
>  }}}
>
>  I think these are the key files, there will be others but who knows what
>  or where these will be...
>
>  Unmount and start the server:
>
>  {{{
>  umount /mnt/puffin-copy
>  cd /etc/xen
>  xen create -c puffin-copy.webarch.net.cfg
>  }}}
>
>  So the server should be available at `puffin-copy.webarch.net` /
>  `81.95.52.13` however it can't be pinged, there is no ssh access and it is
>  not responding to HTTP requests...
>
>  So, I'm not sure if I should spend more time trying to sort this out or if
>  we should try my prefered approach, option 2. in ticket:754#comment:47.
>
>  The next thing to try would be to shutdown and root the server (I don't
>  think we have a login to it as we always use keys, but perhaps one can be
>  found?).
>
> --
> Ticket URL: <https://tech.transitionnetwork.org/trac/ticket/754#comment:55
> >
> Transition Technology <https://tech.transitionnetwork.org/trac>
> Support and issues tracking for the Transition Network Web Project.
>



-- 
Ade Stuart
Web Manager - Transition network

07595 331877

The Transition Network is a registered charity
address: 43 Fore St, Totnes, Devon, TQ9 5HN, UK
website: www.transitionnetwork.org
TN company no: 6135675 TN charity no: 1128675

[chris]

Replying to ade:

is it possible that we can stop BOA from doing the upgrade to PHP5.5 and so give ourselves more time?

Yes, see ticket:754#comment:26:

Next BOA upgrade (2.4.3) will force PHP 5.5 on all hosted Aegir
instances, unless you will explicitly opt-out *before* that upgrade
using PHP version control files, as explained in our docs at:

  https://omega8.cc/how-to-quickly-switch-php-to-newer-version-330

By doing this I understand that it should give us a couple of months leeway, is that correct?

It would allow the last BOA update (BOA 2.4.3 came out on 19th May, see ticket:854) and future updates for everything else to be applied, but we would be in heading into the territory of running unmaintained and potentially insecure systems... Whether this is something we could get away with or not is something that we can only know with hindsight -- I don't think it is a good idea.

[paul]

Another option to consider is asking the PHP experts at SektionEins? if they would be interesting in supporting our installation of PHP for one year.

​http://www.sektioneins.com/en/stories/php-backporting.html

[chris]

Has it, in effect, been decided to no longer update BOA (and with this no longer update any packages it complies, eg Redis)?

Or are we going to stick with the existing PHP and continue to update BOA?

Or are we still at the needing more time to make a decision stage?

[chris]

The latest ​php5 security update for Debian Squeeze backports lots of fixes from later versions to 5.3.

When is a replacement Transition Network site running on Drupal 7 due? If it is not going to be ready for deployment in the next few months then we are going to need to run the Drupal 6 site for quite a while yet?

I'd suggest we consider a move away from BOA and look at spiltting the server up into a couple (or more) of smaller servers:

• A Debian Squeeze server running MySQL, memcache, php5-fpm or Apache and mod_php just for the .php files.
• A Debian Jessie server running Nginx as a reverse proxy for .php files and directly serving all other content.

We can have the same file system mounted on both servers, it could be read-only on the Nginx server. We could also run memcache and MySQL on other servers if needs be.

Note that Debian 6 “Squeeze” is ​supported until February 2016, so this would give us around 5 months of running a security updated supported version of PHP (something we are not doing at the moment).

Can we discuss this suggestion here on on the ttech list or on a conference call?

[paul]

That all sounds good to my mind.

I think we may also need to add a PHP cache.  Also having Git will be
helpful for development.

We can then later update our infrastructure when we have the site running
on a more recent version of Drupal.

Best, Paul


On Tue, Sep 8, 2015 at 11:06 AM, Transition Technology Trac <
trac@tech.transitionnetwork.org> wrote:

> #754: Can we upgrade from PHP 5.3?
> -------------------------------------+-------------------------------------
>            Reporter:  chris          |                      Owner:  chris
>                Type:  maintenance    |                     Status:  new
>            Priority:  critical       |                  Milestone:
>           Component:  Live server    |  Maintenance
>            Keywords:                 |                 Resolution:
> Add Hours to Ticket:  0.15           |  Estimated Number of Hours:  0.0
>         Total Hours:  4.625          |                  Billable?:  1
> -------------------------------------+-------------------------------------
> Changes (by chris):
>
>  * hours:  0.0 => 0.15
>  * totalhours:  4.625 => 4.775
>
>
> Comment:
>
>  The latest [https://lists.debian.org/debian-lts-
>  announce/2015/09/msg00002.html php5 security update] for Debian Squeeze
>  backports lots of fixes from later versions to 5.3.
>
>  When is a replacement Transition Network site running on Drupal 7 due? If
>  it is not going to be ready for deployment the next few months then we are
>  going to need to run the Drupal 6 site for quite a while yet?
>
>  I'd suggest we consider a move away from BOA and look at spiltting the
>  server up into a couple (or more) of smaller servers:
>
>  * A Debian Squeeze server running MySQL, memcache, `php5-fpm` or Apache
>  and `mod_php` just for the `.php` files.
>  * A Debian Jessie server running Nginx as a reverse proxy for `.php` files
>  and directly serving all other content.
>
>  We can have the same file system mounted on both servers, it could be
>  read-only on the Nginx server. We could also run memcache and MySQL on
>  other servers if needs be.
>
>  Note that Debian 6 “Squeeze” is [https://wiki.debian.org/LTS supported
>  until February 2016], so this would give us around 5 months of running a
>  security updated supported version of PHP (something we are not doing at
>  the moment).
>
>  Can we discuss this suggestion here on on the ttech list or on a
>  conference call?
>
> --
> Ticket URL: <https://tech.transitionnetwork.org/trac/ticket/754#comment:61
> >
> Transition Technology <https://tech.transitionnetwork.org/trac>
> Support and issues tracking for the Transition Network Web Project.
>



-- 
Paul Booker
Drupal Support for Websites and Linux Servers
Website: http://www.paulbooker.co.uk
Tel: +44 01922 861636

[chris]

Replying to paul:

I think we may also need to add a PHP cache.

Yes, with 5.3 I think ​APC is the best bet, PHP 5.5 and later comes with Zend Opcache.

Also having Git will be helpful for development.

Yes, we could either have our own Git repo or use Github, I'd suggest considering to former as it would probably be faster when updating the live site via git as it would involve requests over the LAN.

We can then later update our infrastructure when we have the site running on a more recent version of Drupal.

Yes, I was thinking if we have one server just for PHP then we could swap that out and keep everything else more-or-less the same...

[paul]

I would be happy to go in this direction; it seems like the right way to go
for the project.

On Tue, Sep 8, 2015 at 11:54 AM, Transition Technology Trac <
trac@tech.transitionnetwork.org> wrote:

> #754: Can we upgrade from PHP 5.3?
> -------------------------------------+-------------------------------------
>            Reporter:  chris          |                      Owner:  chris
>                Type:  maintenance    |                     Status:  new
>            Priority:  critical       |                  Milestone:
>           Component:  Live server    |  Maintenance
>            Keywords:                 |                 Resolution:
> Add Hours to Ticket:  0.15           |  Estimated Number of Hours:  0.0
>         Total Hours:  4.775          |                  Billable?:  1
> -------------------------------------+-------------------------------------
> Changes (by chris):
>
>  * hours:  0.0 => 0.15
>  * totalhours:  4.775 => 4.925
>
>
> Comment:
>
>  Replying to [comment:62 paul]:
>  >
>  > I think we may also need to add a PHP cache.
>
>  Yes, with 5.3 I think
>  [https://secure.php.net/manual/en/apc.configuration.php APC] is the best
>  bet, PHP 5.5 and later comes with Zend Opcache.
>
>  > Also having Git will be helpful for development.
>
>  Yes, we could either have our own Git repo or use Github, I'd suggest
>  considering to former as it would probably be faster when updating the
>  live site via git as it would involve requests over the LAN.
>
>  > We can then later update our infrastructure when we have the site
>  running on a more recent version of Drupal.
>
>  Yes, I was thinking if we have one server just for PHP then we could swap
>  that out and keep everything else more-or-less the same...
>
> --
> Ticket URL: <https://tech.transitionnetwork.org/trac/ticket/754#comment:63
> >
> Transition Technology <https://tech.transitionnetwork.org/trac>
> Support and issues tracking for the Transition Network Web Project.
>



-- 
Paul Booker
Drupal Support for Websites and Linux Servers
Website: http://www.paulbooker.co.uk
Tel: +44 01922 861636

[chris]

Closing as wontfix -- we have stopped updating BOA, the last update was ticket:844, we have commented out all the BOA root cron jobs, see wiki:PuffinServer#LoadSpikes, the plan is to switch to WordPress around April 2016, see ticket:846#comment:86.