А как у Вас подключен PHP? Есть тонкость, если как CGI и процесс PHP всегда завершается после выполнения скрипта, то кеширования действительно не будет, ибо при новом запросе будет создан новый экземпляр PHP, где того самого кеша уже не будет. Вот если процессы PHP висят в idle и ожидают новых запросов, то тогда кеширование действительно есть.
Плагин для WHMCS по API передает данные пользователя в GET параметре: http://ru.ispdoc.com/index.php/API_result_is_%22ok%22, в итоге в логах подобное:
GET /manager/ispmgr?func=reseller&authinfo=данные_пользователя&out=json HTTP/1.1
Права на файл 640, Вы правы.
Не скажи... Писал плагин на ограничение числа файлов для пользователей ISPmanager 5, в итоге наблюдал интересную картину. cl-quota --user=имя_пользователя -H 100000 -S 100000 выдавало пользователь не найден. Писало так только для пользователей, которые были созданы через ISPmanager. Пообщавшись с поддержкой CloudLinux, сказали, что поддержки панели ISPmanager 5 с их стороны нет, они её только вот-вот добавили и порекомедовали обновить lve-utils из тестового репозитория, что помогло. Ошибка была вроде бы в том, что cl-quota искала список пользователей и тарифов (это файл /etc/container/user_plan.cache, а там было на подобии error: unknown panel).
А что с CageFS и Apache ITK пока непонятно... несколько лет работала такая связка, правда Apache ITK брал не из пакетов, а собирал из исходников с патчем от CloudLinux.
Я не специалист по безопасности, но как писал ранее - спится гораздо спокойнее, если даже /etc/passwd для пользователей закрыт :)
В ISPmanager 4 знаю, что если стоит проксирование и запросы в панель обрабатываются NGINX, то пароли всех пользователей светятся в /var/log/nginx/access.log, в 5 версии вроде бы всё хорошо в этом плане.
Речь идет об обходе ограничения CageFS, а не о чтении файлов другого пользователя. За счет выставленных прав в указанной Вами документации прочитать чужой каталог действительно невозможно, но полазить по системе - вполне можно за счет обхода CageFS.
Также, если я верно понимаю, то в случае, если запрос не попадает в LVE, перестают работать ограничения установленные для пользователя на процессор, память, число соединений и процессов, что тоже не хорошо :)
Я вчера и сегодня общался с поддержкой CloudLinux, они подтвердили наличие проблемы конкретно на моём сервере. Также сказали, что клиентов с ISPmanager 5 у них мало и к ним пока с данной проблемой никто не обращался. В понедельник пообещали продолжить исследование работы подняв свою тестовую площадку. /usr/sbin/httpd.itk из их пакета с необходимыми патчами, Вы правы, V(o)ViK.
В режиме Apache Prefork работает корректно, запросы погружаются в LVE, в режиме ITK запросы не уходят в LVE из-за чего не работает CageFS.
Затрагивает ли Вас проблема можно проверить путем запуска команды:
cat /var/log/messages | grep "Can't enter lve from a slave context"
Если увидите сообщения вида:
Значит Вы под угрозой.
У меня зашло без проблем. Проверьте антивирус, фаервол, может что-то блокирует доступ. Хотя, может новый Anti-DDoS так работает...
Значит касается только CentOS 6.
На CentOS 6, после конвертации системы (локальный узел) в файле /etc/sysconfig/httpd есть строка HTTPD=/usr/sbin/httpd.itk, apachectl -V выдает Server MPM: ITK, в top соответственно висят процессы /usr/sbin/httpd.itk, yum provides /usr/sbin/httpd.itk выдает Repo: epel. rpm -qa | grep httpd действительно выдает httpd-2.2.15-53.el6.cloudlinux.x86_64, но он не используется.
Система ставилась на прошлой неделе.
Они проверяют доступность сервера пингом, проверьте, стабилен ли он и пингуется ли вообще сервер.
