Дикие тормоза при входе в aceadminpanel

Вопросы
Ребята, никто не сталкивался с такой проблемой — вход в aceadminpanel длится 10 а иногда и 20 секунд… просто тормоза дикие. Причем на шаблоне social нормально заходит, на шаблонах fortune и vintage вход неприлично долгий. Вполне возможно что шаблоны тут ни при чем… Но что тогда? Все на одном VPS, отключал все плагины кроме aceadminpanel и все равно вход 20 секунд. Может кто то сталкивался? Какие мысли есть на этот счет? Буду благодарен за любую подсказку или помощь.

35 комментариев

avatar
Кстати да, тоже заметил такое дело. У Вас на каком шаблоне?
avatar
fortune, vintage и atlas:(
avatar
Попробуй на другом хостинге.
avatar
А что хостинг? Я думаю fastvps EVO-8-SSD Intel® Xeon™ 2 Core 50 GB SSD 8 GB DDR4 выше крыши для сайтов с нулевой посещаемостью. И два других сайта на нем же — все летает и айспанель тоже…
avatar
Заметил такую особенность:
— на сайтах, где панель нормально быстро работает при ее открытии на странице информации в разделе Активные плагины написано так:
aceAdminPanel: v.2.0.392 - Ok

На сайтах с тормозами админки прописано так: 
aceAdminPanel: v.2.0.392 -


Вроде оно как бы и ни о чем… но нет Ок:))) Посмотрите пожалуйста на своих проектах, если есть на разных шаблонах. Почему на одном сервере такая разница в тормозах…
avatar
Ппц… шаблоны тоже походу ни при чем… На одном из сайтов тоже social — и такая же хрень, тормоза до 30 секунд доходят… Может в настройках apache и nginx сравнить домены… Что то уже ума не приложу куда копать…
avatar
Вообще эта админка давно не поддерживается, выводы делайте сами (если простым языком то автор плагина скорее всего обнаружил глобальные ошибки в коде и просто не стал допиливать в виду не перспективности).
avatar
Да… наверное надо забить на нее… Отключу ее на проблемных сайтах, включу если уж совсем припрет:)
avatar
Я использую её только для бана и то редко.
avatar
есть подозрения, что тормозов с админкой не будет только на чистой БД, а если проект не новый, то начинается беда
avatar
Миллион раз сказано не пользоваться этой админкой из-за её глючности.
avatar
Сказано миллион раз согласен… только альтернативы что то никто не предложил. Сделали бы не глючную админку да в каталог ее — я бы первый купил:)
avatar
Сделали бы не глючную админку да в каталог ее — я бы первый купил:)
админка, которой можно управлять конфигом — уже есть.
avatar
Вы имеете ввиду обычный site.ru/admin и все делать прописывая настройки в cofig.local.php? Подскажите тогда такой конфиг чтобы можно было просматривать, банить или удалять пользователей, а также выполнять сброс системы (очистка кеша данных и смарти).
avatar
нет, я про catalog.livestreetcms.com/addon/view/292/
avatar
Так это настройка конфигурации сайта, а автору нужен способ рулить топиками, юзерами, блогами.
avatar
этого нет
avatar
А в aceadminpanel какие-то глобальные косяки или можно поправить? Кстати думаю многие бы с удовольствием закупили плагин «управление пользователями», может вырезать кусок кода из aceadminpanel и оформить в виде плагина?
avatar
А в aceadminpanel какие-то глобальные косяки или можно поправить?
Там генератор случайных багов от фазы месяца, до сих пор неясно почему она так работает. Есть факты что от неё движок начинает лихорадить, не работают многие плагины или работают не так как нужно. Таких фактов об ошибках — сотни. Никто не разбирался что в ней не так т.к. код той админки выбесит даже самого стойкого разработчика.

Кстати думаю многие бы с удовольствием закупили плагин «управление пользователями»
есть похожее catalog.livestreetcms.com/addon/view/272/

может вырезать кусок кода из aceadminpanel и оформить в виде плагина?
про её страшный код я написал выше. Если за столько лет к ней никто не притронулся — значит на то есть причины.
avatar
Посмотрел catalog.livestreetcms.com/addon/view/292/ это не то, что мне нужно.
avatar
В общем методом многих тыканий нашел таки… можно сказать случайно:) Проблема в этой строке главного конфига 
$config['module']['ls']['send_general'] = true;	// Отправка на сервер LS общей информации о сайте

Меняем true на false, сбрасываем кеш и все ОК. Открывается быстро, надпись в разделе активных плагинов не такая 
aceAdminPanel: v.2.0.392 -
а правильная 
aceAdminPanel: v.2.0.392 - Ok


Не берусь судить что там где криво:) то ли почта не настроена, то ли движок долго ищет ее чтобы отправить данные на LS, но без отправки нет этих диких тормозов при входе в админку. Сейчас везде поставлю false.
avatar
Выводи решение в отдельный пост, чтобы не потерять.
avatar
Ну «решением» я бы это не назвал:) Просто случайно определил что проблема в строке конфига. Если разработчики обратят внимание и что то поправят — то это и будет решением. А так достаточно и этого поста, он как раз по этой теме:)
avatar
хм, это отключают всегда, это так сказать настройка ускорения )
avatar
Сегодня выяснил, что предыдущий вывод неверный:( Долго возился с сайтом, все в конфиге настроил — пофиг, вход в админку — full time:60.198 Сменил права так: с того что было www-data:www-data
на выполнил вот это:
sudo chown -R admin:admin /var/...../
Тормоза исчезли:) Самое интересное, что потом я снова вернул www-data:admin и потом совсем обратно вернул к www-data:www-data и все работает без тормозов.
Если честно, то я нифига не понял, но дело явно было в правах.
В связи с этим подскажите пожалуйста светлые головы как правильно задать владельца и группу для сайта? Кто должен быть владельцем и группой для корневой папки сайта а кто для всего остального, что лежит внутри корневой папки. Прошу обоснованно подсказать тех, кто разбирается в администрировании серверов и какие варианты допустимы и безопасны. Знаю здесь есть разбирающиеся люди и заранее спасибо:)
avatar
Нет… все таки www-data:www-data не дают нормально работать админке, вернул обратно admin:admin. Напишите хотя бы у кого как на ваших проектах, чтобы сформировалось какое то определенное мнение.
avatar
На счет тормозов не скажу, однако можно как-то так.

Вариант 1 (простой)

— Файлы не только этого плагина, но и движка, должны принадлежать пользователю под которым работаем из FTP/SFTP, т.е. admin:admin (юзер: группа) (не root).

— Файлы/каталоги в которые идет запись с сайта можно сделать www-data:www-data (юзер: группа). Например (что-то мог пропустить, в админке вроде пишет в tmp, точно не знаю):

/uploads
/logs
/tmp
/templates/cache
/templates/compiled
/plugins/plugins.dat


— Права. По правам момент спорный, есть варианты, однако никаких 777 быть не должно. На каталоги можно поставить 755 или даже 744 в данном случае.

Вариант 2 (посложнее)

— Как и первый в основном
— Чтобы юзер мог писать в любой каталог, который принадлежит www-data. Нужно добавить юзера admin в группу www-data.
— Права в этом случае должны быть 774.

Далее.

— Каждый сайт, что есть на сервере, должен принадлежать своему пользователю, а не работать от одного. site1 = user1, site2 = user2, etc.
— Юзеры не должны иметь доступа в SSH консоль (на всякий случай).
— Так же у каждого юзера должна быть своя база данных (привилегии), а не работать под root юзером.

P.S. Это самые простые меры, без углубления. Для большинства проектов этого за глаза. Мы же не хостинг делаем. Если есть панелька управлением сервером, то проще, если нет, немного муторно настраивать, за-то раз настроил и забыл, платить лицензию не надо.
avatar
Права в этом случае должны быть 774.

Это на те что пишутся с сайта. /uploads и т.д.
avatar
Лучше ставить root:www-data
за исключением перечисленных директорий, куда нужно дать права на запись, там — www-data:www-data

750 на каталоги
640 на файлы

должны быть 774
Тогда уж 770. Будет равносильно.
avatar
Не думаю, что работа под рутом лучшая идея.
avatar
Какая еще работа под рутом? Речь идет о владельце и группе-владельце файлов и директорий. Когда вы ставите владельцем рута, только он имеет права на запись и чтение (в моем примере 640 — файлы, 750 — каталоги), а группа www-data получает только права на чтение (кроме директорий uploads и т.д.). Таким образом, если в движке есть уязвимость которая позволит получить привилегии с которыми исполняется логика движка (www-data), внести изменения в файлы или подсунуть какие-нибудь свои php-скрипты злоумышленник не сможет. Еще одна фишка владельца в том что только владелец (или рут, что в моем случае одно и то же) может менять права и самого владельца файлов. Таким образом разница между моим и вашим вариантом с юзером следующая:
— В моем варианта чтобы получить все что полагается владельцу нужен рут (а если он у злоумышленника, есть то уже поздно пить боржоми).
— В вашем случае чтобы что-то такое такое сделать достаточно привилегий user, что по определению должно быть проще. Получение привилегий user не влияет на систему так, как получение рута, однако вы даете юзеру право на чтение, запись и смену владельца/прав файлов движка.
avatar
Хорошо, если владелец файлов root, то как работать с этими файлами и каталогами пользователю? Не это ли работа из под root или добавление в группу совместную? При чем на всех сайтах.

Подключаясь по тому же sftp/ftp, вы получите кукиш с маслом при попытки что-то отредактировать или залить.

При взломе, даже если каким то образом он получит доступ к самому юзеру, в целом серверу ничего не будет.

Чем опасна работа из под root, и так очевидно, писать нет смысла. По FTP/SFTP и подавно, даже только потому, что пароли хранятся в открытом виде, а в первом случае еще и передаются в открытом виде, и как минимум большая часть на винде. Вопрос времени в общем.

На этом предлагаю закончить, тема легко гуглится.
avatar
Редкостный бред. Один абзац противоречит другому. Если после того что я выше написал ты мне пишешь про то как удобно ходить по фтп на продуктив из под обычного юзера, разговаривать с тобой не о чем. Иди и правда погугли «юникс для чайников» или что-то в этом духе.
avatar
Народ и время рассудит. Спорить с вами не вижу смысла. Да свидание.
avatar
Спасибо огромное за ответы, остановился на варианте user:user а для каталогов на запись user:www-data.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.