Zend_Cache with Memcachier - zend-framework

Can I use memcachier with ZendFramework 1.12 ?
The provider that I am useing(AppFog) only offers Memcachier (Memcached is comming soon from 10 Months) And My app will need a lot of caching when it starts. I don't want to stick with APC so I have no other good alternative.

So this is just a half answer right now, I'll try to figure out the rest. I work for MemCachier by the way, so please shoot us an email on support#memcachier.com if you have more questions.
PHP includes two memcache bindings by default: memcache and memcached. The first one (memcache) is its own implementation of the memcache procotol, while the second one (memcached) is a php binding to the libmemcached C++ library.
The memcached binding for php does support SASL these days (since version 2.0.0). Sadly it isn't documented. It also is an optional part of the memcached module, so you'll need to make sure it is compiled on your machine (or AppFog) with the SASL support enabled. The steps to do that roughly are:
Install libmemcached. I used version 1.0.14.
Install php-memcached. Make sure to pass the "--enable-memcached-sasl" option to it when running ./configure.
When building both of these you can sanity check the output of "./configure" to make sure that SASL support is indeed enabled, sadly right now it can be tricky.
Edit you php.ini file. Put the following line into it:
[memcached]
memcached.use_sasl = 1
I did all of this on OSX 10.8 using homebrew. If that is the case for you the following should work:
$ brew install libmemcached
$ brew edit php54-memcached
// you'll need to add the line:
args << "--enable-memcached-sasl"
// to the brew file.
$ brew install php54-memcached
Now to actually use SASL support, here is a test file that demonstrates it and is a good sanity check.
<?php
/**
* Test of the PHP Memcached extension.
*/
error_reporting(E_ALL & ~E_NOTICE);
$use = ini_get("memcached.use_sasl");
$have = Memcached::HAVE_SASL;
echo "Have SASL? $have\n";
echo "Using SASL? $use\n\n";
$mc = new Memcached();
$mc->setOption(Memcached::OPT_BINARY_PROTOCOL, true);
$mc->setSaslAuthData("user-1", "pass");
$mc->addServer("localhost", 11211);
$mc->set("foo", "Hello!");
$mc->set("bar", "Memcached...");
$arr = array(
$mc->get("foo"),
$mc->get("bar")
);
var_dump($arr);
?>
Adapting this to work in the Zend Framework is unknown to me right now. I'm not familiar with it so may take me some time to install and figure out. It seems very doable though given one of the backends works with SASL auth.

Related

Problems when using Chapel 1.19 along with GASNet PSM (OmniPath) substrate

After Changing to version 1.19, but using Omnipath implementation, I'm randomly receiving the following error: ERROR calling: gasnet_barrier_try(id, 0).
I know that the Omnipath implementation of GASNet is no longer supported by the current version of Chapel. However, I would like to use some features available only in version 1.19, and the cluster I use runs over an Omnipath network.
In order to use the PSM substrate (OmniPath), I proceed as suggested by Chapel's Gitter community:
export CHPL_GASNET_ALLOW_BAD_SUBSTRATE=true
wget https://gasnet.lbl.gov/download/GASNet-1.32.0.tar.gz
tar xzf GASNet-1.32.0.tar.gz
rm -rf $CHPL_HOME/third-party/gasnet/gasnet-src
mv GASNet-1.32.0 $CHPL_HOME/third-party/gasnet/gasnet-src
Then, I setup other variables:
export CHPL_COMM='gasnet'
export CHPL_LAUNCHER='gasnetrun_psm'
export CHPL_COMM_SUBSTRATE='psm'
export CHPL_GASNET_SEGMENT='everything'
export CHPL_TARGET_CPU='native'
export GASNET_PSM_SPAWNER='ssh'
export HFI_NO_CPUAFFINITY=1
Next, I build the runtime, etc.
However, when I run experiments, I randomly receive the following error:
ERROR calling: gasnet_barrier_try(id, 0)
at: comm-gasnet.c:1020
error: GASNET_ERR_BARRIER_MISMATCH (Barrier id's mismatched)
Which finishes the execution of the program.
I cannot find in GASNet documentation the reason for this error. I could only find a bit of information on GASNet's code.
Do you know what's the cause of this problem?
Thank you all.
I realize this is an old question, but for the record the current version of Chapel (1.28.0) now embeds a version of GASNet (GASNet-EX 2022.3.0 as of this writing) that provides CHPL_COMM=gasnet CHPL_COMM_SUBSTRATE=ofi (aka GASNet ofi-conduit) that provides high-quality support for Intel Omni-Path.
In particular, there should no longer be any reason to clobber Chapel's embedded version of GASNet-EX with an ancient/outdated GASNet-1 to get Omni-Path support, as suggested in the original question.
For more details see Chapel's detailed Omni-Path instructions.

Syslog with Phalcon on CentOS

Anyone out there working with Phalcon on CentOS?
I'm trying to use Syslog from Phalcon\Logger\Adapter\Syslog but can't find where can I see the output. AFAIK, CentOS send syslog messages to '/var/log/messages', but I've looked at almost all files in '/var/log' and found nothing.
Currently I'm constructring the Syslog this way:
$logger = new SyslogAdapter(null);
Is there any setting that I'm missing on Phalcon or my OS?
Looking at https://github.com/phalcon/cphalcon/blob/master/ext/logger/adapter/syslog.c#L125 and https://github.com/phalcon/cphalcon/blob/master/ext/logger/adapter/syslog.c#L185 it seems that Phalcon proxies all calls to the default syslog.
I'd sugget to goggle "centos php syslog" and make it work in pure php without Phalcon. It feels this is the keystone to the problem.
Update
Just looking over your piece of code, the actual class is called Syslog, not SyslogAdapter, unless you do use Phalcon\Logger\Adapter\Syslog as SyslogAdapter;, which I can't tell from the code above :) If syslog via php works, then most likely the issue is with your code. I just tried the below, it works as expected:
$logger = new Syslog(null);
$logger->log('test', 'hello world');
// 27/04/2014 19:15:24.922 php[24030]: hello world

Perl Net::LDAPS SSL version negotiation

Platform
OS: RHEL 5.4
Perl: 5.8.8
OpenSSL: 0.9.8e
Net::LDAP: 0.33
Details
We have a perl script which monitors LDAP servers used by our application and sends alerts if these are not reachable or functional in some way. On the whole this works well except for a particular LDAP server which is only accepting SSLv2. The LDAP object creation looks as follows
my $current_server = Net::LDAP->new('ldaps://10.1.1.1:636/,
verify => 'none',
sslversion => 'sslv23',
timeout => 30 )
Notice sslv23, which according to the documentation, allows SSLv2 or 3 to be used. The relevant entry in the docs is
sslversion => 'sslv2' | 'sslv3' | 'sslv23' | 'tlsv1'
However, the above does not work. When I change the "sslversion" to be "sslv2" then the script does work.
Conclusion
How can I get Net::LDAPS to retry with sslv2 if sslv3 does not work?
Thanks,
Fred.
To answer my own question - I could not find a way to make the library fall back to SSLv2 if SSLv3 fails so I did that in my own code by first trying SSLv3 and, if that fails, SSLv2. This works for my specific situation.
I encourage anyone who has more information to comment.
Which version of IO::Socket::SSL are you using?
Which version of Net::SSLeay are you using?
If you look at the source code for IO::Socket::SSL, you will see that sslv23 means it will use Net::SSLeay::CTX_new() which is equivalent to Net::SSLeay::CTX_v23_new(). SSLv2 may have been dropped from your library's CTX_v23_new implementation.

Enable FIPS on PostgreSQL database

Can someone please specify the steps to enable FIPS on Postgres Database? I have googled but was not able to find anything concrete.
Can someone please specify the steps to enable FIPS on Postgres Database?
I don't believe you can run Postgres in "FIPS mode" because of its use of non-approved cryptography. From a past audit, I know it makes extensive use of MD5 (see, for example, Postgres Mailing List: Use of MD5. So lots of stuff is going to break in practice.
Notwithstanding, here are the steps to try and do it via OpenSSL. There are three parts because Postgres is not FIPS-aware, and you need to make some modifications to Postgres.
Step One
You have to build OpenSSL for the configuration. This is a two step process. First you build the FIPS Object Module; and second, you build the FIPS Capable Library.
To build the FIPS Object Module, first you download `openssl-fips-2.n.n.tar.gz. After unpacking, you perform:
./configure
make
sudo make install
After you run the above commands, the fipscanister will be located in /usr/local/ssl/fips-2.0. The FIPS Capable Library will use it to provide the FIPS Validated Cryptography.
Second, you download openssl-1.n.n.tar.gz. After unpacking, you perform:
./configure fips shared <other options>
make all
sudo make install
The critical part is the fips option during configure.
After you run the above commands, you will have a FIPS Capable Library. The library will be located in /usr/local/ssl/lib. Use libcrypto.so and libssl.so as always.
The FIPS Capable Library uses the fipscanister, so you don't need to worry about what's in /usr/local/ssl/fips-2.0. Its just an artifact from building FIPS Object Module (some hand waiving).
Step Two
Find where Postgres calls SSL_library_init:
$ grep -R SSL_library_init *
...
src/backend/libpq/be-secure.c: SSL_library_init();
src/interfaces/libpq/fe-secure.c: SSL_library_init();
Open be-secure.c and fe-secure.c, and add a call to FIPS_mode_set.
/* be-secure.c, near line 725 */
static void
initialize_SSL(void)
{
struct stat buf;
STACK_OF(X509_NAME) *root_cert_list = NULL;
#if defined(OPENSSL_FIPS)
int rc;
rc = FIPS_mode();
if(rc == 0)
{
rc = FIPS_mode_set(1);
assert(1 == rc);
}
#endif
if (!SSL_context)
{
#if SSLEAY_VERSION_NUMBER >= 0x0907000L
OPENSSL_config(NULL);
#endif
SSL_library_init();
SSL_load_error_strings();
...
}
...
}
If the call to FIPS_mode_set succeeds, then you will be using FIPS Validated cryptography. If it fails, you will still be using OpenSSL's cryptography, but it will not be FIPS Validated cryptography.
You will also need to add the following headers to be-secure.c and fe-secure.c:
#include <openssl/opensslconf.h>
#include <openssl/fips.h>
Step Three
The final step is to ensure you are using the FIPS Capable Library from step one. Do that via CFLAGS and LDFLAGS:
cd postgres-9.3.2
export CFLAGS="-I/usr/local/ssl/include"
export LDFLAGS="-L/usr/local/ssl/lib"
./config --with-openssl <other options>
...
For PostgreSQL on Red Hat Linux, the https://public.cyber.mil/stigs/downloads/ web site has a Security Technical Implementation Guide for PostgreSQL 9.x which has this check.
Rule Title: PostgreSQL must implement NIST FIPS 140-2 validated
cryptographic modules to protect unclassified information requiring
confidentiality and cryptographic protection, in accordance with the data
owners requirements.
STIG ID: PGS9-00-008200
Rule ID: SV-87645r1_rule
Vuln ID: V-72993
The "Fix Text" reads
Configure OpenSSL to be FIPS compliant.
PostgreSQL uses OpenSSL for cryptographic modules. To configure OpenSSL to
be FIPS 140-2 compliant, see the official RHEL Documentation:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-Federal_Standards_And_Regulations-Federal_Information_Processing_Standard.html
For more information on configuring PostgreSQL to use SSL, see supplementary
content APPENDIX-G.
Joseph Conway pointed out "the Appendix G the STIG refers to is in the PostgreSQL STIG supplement, not the [postgresql.org] docs. You can get the supplement (and the rest of the STIG) here: https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_PGS_SQL_9-x_V2R1_STIG.zip
As I understand your question you are looking at trying to ensure that you can encrypt data transferred to and from PostgreSQL using AES algorithms. While FIPS goes well beyond that, and well beyond what can be asked in Q&A, that question at least is easily answerable.
The simple solution is to use SSL with a certificate authority of your choice (if you are using Active Directory, you could use Certificate Server, and if not you could use OpenSSL to run your own certificate authority). You could then specify which encryption standards to use (see official docs). From there encryption will be used and your server will be authenticated to your clients. You can also set up client certs and require those to be authenticated as well.

Capistrano deploy how to use use_sudo and admin_runner

I'm trying to configure Capistrano so that it works for our server setup. We are deploying symfony projects so i'm also using capifony. I'm still experiencing some problems with permissions.
On our server every project runs as a project user, so every project has it's own user. So i configured use_sudo and set it to true and i configured the admin_runner to be the user of the project. But it still didn't work so i modified the capifony to start using try_sudo in stead of the regular run. Which made it work a little bit better. But i'm a bit confused about what to use in which case. You have try_sudo, sudo and run. But which is needed for which use-case?
When you use run i think it'll always be your local user
try_sudo i think will check if the use_sudo flag is true if so it will use the sudo command if not it will use the local user. If you have admin_runner configured it will sudo to the user configured as admin_runner
sudo will always try to sudo
Now my problem is the deploy:symlink method this is also just a regular run command so it executes as the local user, which gives permission problems when i try to view the website.
So can anyone tell me if my description of the 3 commands is correct? and also does anyone know how the admin_runner and use_sudo is suposed to be used, so that the symlink is also being done correctly (and also all other commands done by capistrano)?
kind regards,
Daan
Apologies for such a tardy answer Daan. Your understanding of Capistrano is correct. Note also that the :use_sudo flag defaults to true.
In Capistrano 2.11.2, you'll find lib/capistrano/configuration/variables.rb:
_cset(:run_method) { fetch(:use_sudo, true) ? :sudo : :run }
and lib/capistrano/recipes/deploy.rb:
def try_sudo(*args)
options = args.last.is_a?(Hash) ? args.pop : {}
command = args.shift
raise ArgumentError, "too many arguments" if args.any?
as = options.fetch(:as, fetch(:admin_runner, nil))
via = fetch(:run_method, :sudo)
if command
invoke_command(command, :via => via, :as => as)
elsif via == :sudo
sudo(:as => as)
else
""
end
end
Perhaps your permissions problem involves your server, running as a normal user, not being able to read the contents of the release directory that your current symlink is pointing to?