Здравствуйте, Loki!
Возможно ли воплотить механизм автоматического обновления системы из-под админки, как например в WP? Какие трудности будет таить реализация, если это возможно. И стоит ли вообще? Просто ловлю себя на том, что переустанавливаю систему с переодичностью выхода версий. Ну для тестов я качал и ставил чистые - это как бы без проблем. Просто не каждую версию, насколько я понял, можно накатить простой заменой по ФТП. И не все пользователи будут знать об новых версиях и коснувшихся её изменений. возможно вывести в админке уведомление о новых версиях системы? На странице обновления есть изображение прозрачное с сылкой на новую версию, но я думаю это не совсем то Вопросы по реализации, такие-же, как и про обновление. Мне действительно интересно, не подумайте, что я умышленно стараюсь Вас чем-либо пригрузить. Мне очень понравилась система, я стал с ней работать, её рекомендовать. И мне хочется, что бы со временем она становилась только лучше.

На самом деле, накатить можно любую новую версию на любую старую. Я именно так и делаю. Нюансы были только при переходе со второй версии на третью, но это было давно и об этом было написано на сайте. Единственное, иногда приходится руками почистить каталог kernel/template_c.
 
В админке сейчас вставлено изображение, проверяющее наличие новой версии. Если ее нет, то оно однопиксельное и прозрачное, если есть - выводится соответствующий текст со ссылкой, так что тут все уже сделано
 
Я уже писал как-то что додумался до трех схем обновления:
 
1. когда скрипт сам обновляет файлы на сервере. Но для этого скрипту надо дать безумно много прав и напрочь забыть о безопасности.
 
2. скрипт подключается к серверу по FTP  и автоматически обновляет файлы. Этот путь мне в свое время не понравился, но WP пошли именно им. Не понравился он мне тем, что надо запрашивать у пользователя данные для доступа к FTP и где-то их хранить. Правда, можно их не хранить, а запрашивать непосредственно при обновлении. Кроме того, это достаточно медленно при большом количестве файлов - затянуть архив на сайт и развернуть его там не получится, по причине указанной в пункте 1. Кроме того, надо следить за целостностью файлов, так как при любом сбое концов потом не найти. То есть для транка такая система слишком обременительна (надо подготовить список измененных файлов, посчитать их хэши и обеспечить доступ к каждому файлу в отдельности). Кроме того, запросить у пользователя данные для доступа к FTP. Но для стабильных версий, возможно, имеет смысл такую реализовать. В общем-то, наверное, практически все можно автоматизировать, просто мой вариант мне показался более простым и контролируемым:
 
3. на сайт (или в репозиторий) выкладывается архив с новой версией, который можно спокойно развернуть поверх старой.

Всё доступно. Понял. Хотя для стабильных версий возможно и надо. Хотя Если пользователь скачал CMS, он ведь может скачать её ещё раз? И потом уже накатить новую версию на работающий сайт, ну и накатить чуть-чуть после успешного обновления
 
Я почему поднял вопрос - я именно таким образом обновлял сайт. Обновилось всё, и вроде бы работало, но то тут там появлялись артефакты в шаблоне. Видимо из-за того, что не очищал kernel/template_c. Но я об этом не знал. Впредь буду. Спасибо )

Да, надо будет придумать какую-то схему очистки кэша при изменении ревизии.

Здравствуйте, Loki!
Есть ли какой-нибудь алгоритм обновления LabCMS?
Может быть, я упустил какую-то деталь, как и в случае с активацией комментариев?
В LabCMS я столкнулся с тем, что после ручного обновления файлов при условии сохранения содержимого каталога /data получаю пустую страницу и сообщение об ошибке в логах Апача
 
[Tue Aug 16 22:42:40 2011] [error] [client 192.168.123.104] PHP Warning:  include(): Failed opening '/var/www/labcms/kernel/core/index.php' for inclusion (include_path='.:/usr/share/php:/usr/share/pear') in /var/www/labcms/index.php on line 9
 
Обновление cms.ini не помогло. Удаление install.lock открывает путь новой установке с удалением существующих данных. «Куда ни кинь, всюду клин».
 
Поэтому и хотелось бы узнать: существует ли алгоритм обновления с сохранением данных, или пока что возможна только новая установка и восстановление данных из дампа вручную?
Расскажите, пожалуйста, поподробнее! Или укажите ошибку.
И, кстати, в разделе документация инструкцию по установке Вы написали, а вот по поводу обновления я в следующей статье нашел только несколько строчек, и то только по поводу обновления из репозитория.
Еще два вопроса. Если ответы трудоемки или очень специальны, попробуйте «на пальцах»
1. Какую роль играет каталог /kernel/install в уже установленной системе и не влияет ли его наличие на безопасность? Как я себе представляю, просто сохраняется, чтобы не заливать каждый раз заново, а переписывать измененные файлы.
2. Каков механизм работы файлов /updates/**-**.php?
 
MaxSite обновляю в значительной степени точечной заменой файлов, поскольку пришлось «натоптать» в системе, в том числе благодаря тотальному перемешиванию кода и разметки. А БД там используется как накопитель для контента, комментов, типов страниц, метаданных, сведений о юзерах/группах/разрешениях, так что при обновлении не затрагивается.
 
Я, конечно, разбалован MODx, который при существующей БД и конф. файле сам предлагает обновить систему, сохраняя существующие параметры, в противном случае делает новую установку.
Может быть попробуете в ознакомительных целях установить MODx Evolution?
дистрибутив
А потом снова добавить каталог /install и обновиться.Пройдя все шаги Вы, возможно, почерпнете что-нибудь полезное на будущее, конкретно в части обновления системы.
 
Мне очень нравится их реализация установки и обновления. В том числе, мне нечасто приходилось получать пустую страницу, если что-то пошло не как надо. Хотелось бы, чтобы и LabCMS пришла со временем к похожему функционалу

jen:

В LabCMS я столкнулся с тем, что после ручного обновления файлов при условии сохранения содержимого каталога /data получаю пустую страницу и сообщение об ошибке в логах Апача
 
[Tue Aug 16 22:42:40 2011] [error] [client 192.168.123.104] PHP Warning:  include(): Failed opening '/var/www/labcms/kernel/core/index.php' for inclusion (include_path='.:/usr/share/php:/usr/share/pear') in /var/www/labcms/index.php on line 9

Я бы предположил что у Вас просто произошел сбой при заливке файлов, потому что файл index.php состоит фактически из одной строчки:

и раз она выполниться не смогла (может файл /kernel/core/index.php не залился или залился с какими-то кривыми правами), то ни о каких алгоритмах обновления и речи не идет (раз уж скрипт тормознулся на первой же строчке).
 

jen:

Обновление cms.ini не помогло. Удаление install.lock

Править руками cms.ini не нужно за исключением настолько редких случаев, что я и придумать-то их не могу Это же касается и install.lock.
 

 

jen:

1. Какую роль играет каталог /kernel/install в уже установленной системе и не влияет ли его наличие на безопасность?

Там хранится скрипт первоначальной установки, файл config.xml, где хранится описание возможных настроек сайта и файлы с номерами версий. После установки реально используется только config.xml и файлы версий (для автообновления). Наличие этой папки на безопасность никак не влияет, так как по прямым ссылкам она не доступна и подключается только в случае отсутствия install.lock
 

jen:

2. Каков механизм работы файлов /updates/**-**.php?

в файле cms.ini хранится текущая версия установленного движка, а в файле /kernel/install/version.php хранится версия кода. Если версии не совпадают, то производится поиск файла /updates/current_ver-*.php, который отвечает за обновление версии. Если же такой файл не найден или найдено несколько таких файлов, то работа будет остановлена и выведено сообщение об ошибке структуре обновлений.
 

jen:

MaxSite обновляю в значительной степени точечной заменой файлов, поскольку пришлось «натоптать» в системе, в том числе благодаря тотальному перемешиванию кода и разметки.

Именно поэтому я и спроектировал систему таким образом, чтобы можно было спокойно "топтать" в собственном скине или модулях, не опасаясь что это перезатрется при обновлении.
 

jen:

А БД там используется как накопитель для контента, комментов, типов страниц, метаданных, сведений о юзерах/группах/разрешениях, так что при обновлении не затрагивается.

А если требуется изменить ее структуру в новой версии?
 

jen:

Мне очень нравится их реализация установки и обновления. В том числе, мне нечасто приходилось получать пустую страницу, если что-то пошло не как надо. Хотелось бы, чтобы и LabCMS пришла со временем к похожему функционалу

Собственно, мне и в LabCMS пустую страницу видеть не приходилось Да и логи в Вашем случае показывают что речь идет об ошибке заливки файлов, а не об ошибке алгоритма обновления.

Ну что делать, снова приходится извиняться
 
Который раз наступаю на те же грабли: менеджер архивов Ubuntu, если извлекать не целиком каталог upload, а его содержимое, почему-то распаковывает файлы с правами на каталоги только первого уровня вложенности 700, и я каждый раз их правлю, потому что настроек у него нет, и аргументов командной строки касательно прав нет. А тут вышла осечка, не уследил. А права на остальные каталоги и файлы правильные!
Вспомнил все случаи появления пустой страницы, всегда были кривые права.
Можно попросить Вас дописать в руководстве по установке несколько строчек про обновление (для таких как я пользователей Ubuntu), особо обратив внимание на то, чтобы следили за правами?
 
Спасибо, что потратили время, виновата только моя невнимательность!

jen:

Можно попросить Вас дописать в руководстве по установке несколько строчек про обновление (для таких как я пользователей Ubuntu), особо обратив внимание на то, чтобы следили за правами?

Ну в общем-то принято считать, что пользователи Linux отдают себе отчет в собственных действиях
Тут скорее всего негативно сыграл тот фактор что Вы не знали что система должна корректно обновляться. Поэтому и в голову не пришло проверять доступны ли файлы для работы вообще, а сразу предположили ошибку обновления (хотя, текст логов должен бы был Вас насторожить )