Build the PHP memcached extension with sasl support.

[dmikusa]

This is required for talking to most public service providers as they need it authentication.

Changes:

• don't install libmemcached from Ubuntu, this doesn't seem to support sasl
• download and install libmemcached from source, this can be configured with sasl support
• change the extension to compile with sasl support

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: https://www.pivotaltracker.com/story/show/101243366.

[dmikusa]

I tested PHP 5.5 and 5.6 binaries built using this change with the new session persistence support and it worked fine.

Here's the binaries if you need them. I'll keep them up for a week or so in case you need them.

https://s3.amazonaws.com/dmikusa/php_bp/php/php-5.5.27-linux-x64-1439496842.tgz
https://s3.amazonaws.com/dmikusa/php_bp/php/php-5.6.12-linux-x64-1439498860.tgz

Dan

[flavorjones]

This seems like a reasonable and non-invasive change. We'll discuss at IPM. Thanks!

[jvshahid]

I'm confused. This bug report claims that ubuntu compiles libmemcached with SASL support and was in fact marked invalid. Is this something that was changed recently ?

[dmikusa]

When I submitted this request, the version of libmemcached that you could install with apt-get did not have SASL supported compiled into it. I don't know if that's still true as I haven't looked since Aug of last year. If it does now support SASL that would be great and would simplify this PR.

The PR is still necessary though as the PHP extension itself needs to be compiled with SASL support enabled. That is most definitely not the case now. See phpinfo() output.

Dan

[RochesterinNYC]

@dmikusa-pivotal can you please rebase the pr on top of master? There has been major refactoring in the binary builder and we would like you to make sure the rebase is successful and correct given you have the most context.

[jvshahid]

@dmikusa-pivotal sorry for the earlier confusion. It turns out that trusty only ships an old version of libmemcached (version: 1.0.8) which doesn't support sasl. We are currently not sure if your approach is acceptable. Our main concern is that php users won't be getting security updates for libmemcached anymore as part of the rootfs. So far buildpacks manifests only contained binary dependencies. /cc @Dannyzen & @flavorjones, thoughts ?

[dmikusa]

@RochesterinNYC - I'll try. I'm not sure when I'll have time. I was just out on PTO and have a ton of stuff that I need to catch up on.

@jvshahid - I'm not sure I understand the concern here. I could see if it were pulling in something that's high profile and changes a ton like libssl, but libmemcached changes very infrequently (last release was 2014-02-09). It also does not require any additional dependencies (at least ones that are not already found in the rootfs). I think our liability would be to simply keep up on the very infrequent libmemcached upgrades, which doesn't seem too difficult. Hopefully the underlying need for this will also change in the next Ubuntu LTS, and then we won't need to include the custom libmemcached.

Dan

[jvshahid]

@dmikusa-pivotal Fair enough. Just one more question, is there any reason why we shouldn't be using a pure php memcached library ? For example https://github.com/memcachier/PHPMemcacheSASL

[dmikusa]

Not sure, perhaps it could work. I haven't tried that project though.

First thing that come to mind would be speed and maturity of feature support. The PHP memcached extension and libmemcached will probably be faster (written in C) and both have definitely been around longer so are probably more stable / feature rich. Those are just assumptions though, you could certainly test to see if this project could be a sufficient replacement.

We also need support for a session.save_handler. A quick glance seems like the project supports that interface, but again more testing would be necessary to confirm.

[RochesterinNYC]

We will be able to enable SASL support once this story is complete: https://www.pivotaltracker.com/story/show/117829871

[RochesterinNYC]

We are closing this pull request. Context is present here: cloudfoundry/php-buildpack#96 (comment)

[gberche-orange]

Hi,

Disclaimer: I'm studying release management for the php buildpack and am taking this PR as an example to better understand how upgrades to php buildpacks dependencies are handled, and what additional qualifications/tests need to be done by PHP buildpack consummers. This PR looks fine and I agree with low risk mentionned in #8 (comment)

I'm wondering whether the tests suites from the potentially impacted php core and php extensions are currently running as part of the buildpack-ci (builds logs such as 37299 referenced in the story) not being publicly accessible makes it hard for the community to understand what is tested without actually running the pipeline or reverse engineering the ci code).

Here are some related tests I identified:

• session module http://gcov.php.net/viewer.php?version=PHP_5_5&func=tested_functions section "session" i.e. https://github.com/php/php-src/tree/PHP-5.6.12/ext/session/tests
• memcache extension, with test sources being in http://git.php.net/?p=pecl/caching/memcache.git;a=tree;f=tests;h=8dd442f8c23281b948f56b3b79b514f31ba6b902;hb=HEAD

I could not spot execution of php or PECL tests as part of the binary builder's php execution in its base class, or its mini_portile base class

Since the libmemcache compile options are different from the ones used by canonical when running related memcache pecl tests, I guess theorically, the memcache PECL module could have undetected regression not covered by manual tests done in #8 (comment) (I did not find session integration tests into https://github.com/cloudfoundry/brats/blob/master/cf_spec/integration/php_spec.rb#L36-L55 )

As a more general question, are tests currently invoked during binary builder compilation ? If not could this be a considered option ?

Thanks in advance for your help,

Guillaume.

[gberche-orange]

I had missed php sources tests apparently in the binary-builder-ci sources at https://github.com/cloudfoundry/buildpacks-ci/blob/80ee898162dbbc8ec6e82e82ede4a6203f89f4ef/pipelines/binary-builder.yml#L212 and the associated story https://www.pivotaltracker.com/story/show/113122547 "get unit tests for binaries passing".

This story might be an interesting example for @Dannyzen 's comment in the story "Understand if (unit tests for binaries) there's long term value"

I'm not yet clear whether PECL modules tests are launched from the "php-test" job.