As flushed out in the comments, it appears you are running Security-Enhanced Linux (SELinux) which adds an extra layer of security at the kernel level. In my experience and usage, I found that SELinux adds a force field around certain services so that they cannot access particular assets on the system. For example, if I want to serve html content from /home/src/web
, I have to tell the system that it is ok for the httpd service to access content in the /home/src/web
path. To do this I would issue the following command:
$ -> setsebool -P httpd_enable_homedirs 1
Basically, to allow cross-communication between services, you have to allow such access via a policy, much like "pinholing" a firewall to allow access to a specific port, except with SELinux you are not granting access to a port, rather you are granting access to another part of the system, or service. Fortunately for us, there are several built in policies which we can use the above setsebool
construct, rather than trying to define our own policies, which can be a pain. For a more complete explanation of SELinux check out the wikipedia page.
Now to answer your specific questions:
why should i use addServer instead of connect?
addserver()
will allow you to add multiple ips (or hostnames) to a list from which it is assumed that cached values are present, i.e. a pool of memcache servers. Whereas the connect()
will only allow you to connect to the single, specified server.
getsebool httpd_can_network_memcache, it returns off, Should it return on?
Yes, it appears that turning on this specific setting will allow you to connect to a memcache server, with SELinux enabled, however on my production servers I still have it set to off, but have the following set:
$ -> setsebool -P httpd_can_network_connect 1
I believe, that either setting will accomplish the objective, however with the above setting, if you have a memcache server on another host, httpd can still access it.
Here is a decent write-up on pinholing SELinux to allow httpd service access to other services.