Настройка Ikiwiki в Debian
Mar. 5th, 2012 11:34 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vitus_wagnerПочему после долгих и продолжительных раздумий я выбрал ikiwiki? Потому что:
1. На мой взгляд ikiwiki обладает главным свойством, требуемым для веб-приложений на домашней машине - не занимает ресурсов, когда не используется.
2. Второй - то что оно устойчиво к кратковременным всплескам посещаемости, связанным с публикацией ссылок на посещаемых ресурсах. Потому что для чтения это - статика.
3. Обладает уже готовой возможностью пускать пользователей по их аккаунтам во всяких прочих системах ЖЖ, Гугль, FB etc. Это очень полезно для маленького, но публичного сайта. Чтобы не заставлять всех желающих регистроваться на yet another сайте.
4. Работает с произвольными системами версионирования.
5. Хорошая поддержка в Debian.
6. Как это ни странно для современного OSS проекта, в команде есть кто-то кто имеет представление об информационной безопасности.
Недостатки у ikiwiki тоже есть.
1. Отсутствие внятной introductory documentation. (восполнить этот недостаток отчасти призван этот пост)
2. Я пока так и не понял как кастомизировать внешний вид сайта. Для сайта вида "личная записная книжка" это и не важно.
3. Внятного руководства "что делать, если что-то не работает" тоже нет.
Шаг первый, установка
При установке пакета ikiwiki внимательно изучите список Suggests. Потому что в нем есть множество пакетов. которые необходимы для работы тех или иных плагинов ikiwiki. Вообще-то в багрепортах давно висит пожелание вынести эти плагины в отдельные deb-пакеты, чтобы можно было зависимости писать в Depends. Но пока до этого не дошло.
Мне для подключения всего лишь двух плагинов - search и attachment понадобилась ручная установка для первого - xapian-omega и libsearch-xapian-perl, для второго - libfile-mimeinfo-perl.
Что характерно, web-сервера с поддержкой cgi в зависимостях вообще нет. И это правильно. Вообще-то наличие web-сервера на машине где стоит ikiwiki совершенно необязательно. Можно все делать в оффлайне, а выпихивать на сервер rsync-ом. Но наша задача сейчас не в этом. А в том, чтобы получить wiki, которую можно редактировать через браузер.
Поэтому web-сервер, умеющий исполнять cgi нам понадобятся. Впрочем любители nginx могут воспользоваться этим советом.
Конфиг виртуального сайта для apache2 у меня выглядит так:
Настройка прав доступа
По некоторому размышлению я завел для wiki отдельного пользователя. Благо ikiwiki для операций, выполняемых через web-интерфейс или post-commit-хуки системы версионирования, имеет suid-врапперы, так что можно не делать директорию с данными writable для того юзера, от которого работает web-сервер. Но делать это от рута - тоже соврешенно лишнее.
Этому пользователю должны быть доступны на запись каталоги
1. Тот, откуда раздается web-сервером сгенерированный html (в вышеприведенном конфиге /var/www/wiki)
2. staging area, в котором имеется рабочая копия wiki, выписанная из системы управления версиями откуда генерируется html (я использую эту же директорию в качестве домашней для юзера wiki)
3. Репозиторий системы версионирования.
Поскольку в качестве системы версионирования для вики я использовал subversion (git, bazaar, mercurial и monotone - поддерживаются) и не только держу репозиторий на той же машине, но и работаю на ней же локально, соответственно и web-интерфейс, и я сам используем протокол file://, мне потредовалось чтобы в ту же группу что и юзер wiki, входил я, любимый, иirene_dragon. Но если у вас доступ в репозиторий осуществляется по протоколам, которые не завязаны на локальных системных пользователйе, вам этого не надо.
(Варианта в котором местоположение репозитория и машина, где из хранящихся в репозитории файлов генерируется html не совпадают, я пока не рассматривал).
Конфигурирование ikiwiki
Читаем файл /etc/ikiwiki/auto.setup и обнаруживаем что он содержит не совсем то, что нам надо.
Копируем его в скажем ~wiki/wiki.setup, отрываем всю интерактивность (в смысле вызовы IkiWiki::Setup::Automator::ask
и вместо этого вписываем все что надо в вызов Ikiwiki::Setup::Automator->import.
После этого запускаем
и, если мы не наглючили в конфигурации, обнаруживаем, что случилось следующее:
1. В систему контроля версий зачекинен модуль для будущей wiki
2. Создана staging area.
3. в файле указанном в опции dumpconfig содержится куда более развесистый конфиг, чем тот что был у нас иззначально.
Вот этот конфиг мы теперь можем подредактировать, добавив в первую очередь нужные плагиныв список add_plugins.
и опции их конфигурации ниже.
после каждого изменения конфига не забываейте выполнить sudo -u wiki ikiwiki --setup файлконфигурации
Полагаться на websetup не рекомендую, с конфигом - проще.
Заполнение wiki
Начиная с этого момента можно пытаться работать через web-интерфейс. Но очень рекомендую держать под рукой
рабочую копию выписанную из системы управления версиями. Поскольку, например, для перемещения файлов из одного каталога в другой в web-интерфейсе средств не предусмотрено.
Опять же, web-интерфейс не предлагает, например средств для создания файла robots.txt, в то время как зачекинив его в систему управления версиями мы получаем сразу то, что надо.
1. На мой взгляд ikiwiki обладает главным свойством, требуемым для веб-приложений на домашней машине - не занимает ресурсов, когда не используется.
2. Второй - то что оно устойчиво к кратковременным всплескам посещаемости, связанным с публикацией ссылок на посещаемых ресурсах. Потому что для чтения это - статика.
3. Обладает уже готовой возможностью пускать пользователей по их аккаунтам во всяких прочих системах ЖЖ, Гугль, FB etc. Это очень полезно для маленького, но публичного сайта. Чтобы не заставлять всех желающих регистроваться на yet another сайте.
4. Работает с произвольными системами версионирования.
5. Хорошая поддержка в Debian.
6. Как это ни странно для современного OSS проекта, в команде есть кто-то кто имеет представление об информационной безопасности.
Недостатки у ikiwiki тоже есть.
1. Отсутствие внятной introductory documentation. (восполнить этот недостаток отчасти призван этот пост)
2. Я пока так и не понял как кастомизировать внешний вид сайта. Для сайта вида "личная записная книжка" это и не важно.
3. Внятного руководства "что делать, если что-то не работает" тоже нет.
Шаг первый, установка
При установке пакета ikiwiki внимательно изучите список Suggests. Потому что в нем есть множество пакетов. которые необходимы для работы тех или иных плагинов ikiwiki. Вообще-то в багрепортах давно висит пожелание вынести эти плагины в отдельные deb-пакеты, чтобы можно было зависимости писать в Depends. Но пока до этого не дошло.
Мне для подключения всего лишь двух плагинов - search и attachment понадобилась ручная установка для первого - xapian-omega и libsearch-xapian-perl, для второго - libfile-mimeinfo-perl.
Что характерно, web-сервера с поддержкой cgi в зависимостях вообще нет. И это правильно. Вообще-то наличие web-сервера на машине где стоит ikiwiki совершенно необязательно. Можно все делать в оффлайне, а выпихивать на сервер rsync-ом. Но наша задача сейчас не в этом. А в том, чтобы получить wiki, которую можно редактировать через браузер.
Поэтому web-сервер, умеющий исполнять cgi нам понадобятся. Впрочем любители nginx могут воспользоваться этим советом.
Конфиг виртуального сайта для apache2 у меня выглядит так:
<VirtualHost *:80>
ServerAdmin webmaster@wagner.pp.ru
ServerName wiki.wagner.pp.ru
AddDefaultCharset utf-8
AddHandler cgi-script .cgi
DocumentRoot /var/www/wiki
ErrorLog ${APACHE_LOG_DIR}/wiki_error.log
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/wiki_access.log combined
</VirtualHost>Настройка прав доступа
По некоторому размышлению я завел для wiki отдельного пользователя. Благо ikiwiki для операций, выполняемых через web-интерфейс или post-commit-хуки системы версионирования, имеет suid-врапперы, так что можно не делать директорию с данными writable для того юзера, от которого работает web-сервер. Но делать это от рута - тоже соврешенно лишнее.
Этому пользователю должны быть доступны на запись каталоги
1. Тот, откуда раздается web-сервером сгенерированный html (в вышеприведенном конфиге /var/www/wiki)
2. staging area, в котором имеется рабочая копия wiki, выписанная из системы управления версиями откуда генерируется html (я использую эту же директорию в качестве домашней для юзера wiki)
3. Репозиторий системы версионирования.
Поскольку в качестве системы версионирования для вики я использовал subversion (git, bazaar, mercurial и monotone - поддерживаются) и не только держу репозиторий на той же машине, но и работаю на ней же локально, соответственно и web-интерфейс, и я сам используем протокол file://, мне потредовалось чтобы в ту же группу что и юзер wiki, входил я, любимый, и
irene_dragon. Но если у вас доступ в репозиторий осуществляется по протоколам, которые не завязаны на локальных системных пользователйе, вам этого не надо.(Варианта в котором местоположение репозитория и машина, где из хранящихся в репозитории файлов генерируется html не совпадают, я пока не рассматривал).
Конфигурирование ikiwiki
Читаем файл /etc/ikiwiki/auto.setup и обнаруживаем что он содержит не совсем то, что нам надо.
Копируем его в скажем ~wiki/wiki.setup, отрываем всю интерактивность (в смысле вызовы IkiWiki::Setup::Automator::ask
и вместо этого вписываем все что надо в вызов Ikiwiki::Setup::Automator->import.
После этого запускаем
sudo -u wiki -H ikiwiki --setup wiki.setup
и, если мы не наглючили в конфигурации, обнаруживаем, что случилось следующее:
1. В систему контроля версий зачекинен модуль для будущей wiki
2. Создана staging area.
3. в файле указанном в опции dumpconfig содержится куда более развесистый конфиг, чем тот что был у нас иззначально.
Вот этот конфиг мы теперь можем подредактировать, добавив в первую очередь нужные плагиныв список add_plugins.
и опции их конфигурации ниже.
после каждого изменения конфига не забываейте выполнить sudo -u wiki ikiwiki --setup файлконфигурации
Полагаться на websetup не рекомендую, с конфигом - проще.
Заполнение wiki
Начиная с этого момента можно пытаться работать через web-интерфейс. Но очень рекомендую держать под рукой
рабочую копию выписанную из системы управления версиями. Поскольку, например, для перемещения файлов из одного каталога в другой в web-интерфейсе средств не предусмотрено.
Опять же, web-интерфейс не предлагает, например средств для создания файла robots.txt, в то время как зачекинив его в систему управления версиями мы получаем сразу то, что надо.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-03-05 08:45 am (UTC)Не хватает слов.
no subject
Date: 2012-03-05 09:02 am (UTC)no subject
Date: 2012-03-05 08:47 am (UTC)и можно редактировать текст страниц ручками в локальном редакторе + потом результирующий HTML - выкладывать куда-то, где в принципе веб-сервер не поддерживает динамику?
(да - заплатив за это интерактивностью например)
no subject
Date: 2012-03-05 08:50 am (UTC)Правда, лучше все же иметь в этом случае локальный web-сервер с браузером. Потому что при всем удобстве редактирования в нормальном редакторе режим preview бывает нужен. особенно для того, чтобы отслеживать корректность ссылок на существующие страницы.
no subject
Date: 2012-03-05 08:56 am (UTC)no subject
Date: 2012-03-05 09:03 am (UTC)no subject
Date: 2012-03-05 08:57 am (UTC)no subject
Date: 2012-03-05 08:58 am (UTC)no subject
Date: 2012-03-05 09:01 am (UTC)no subject
Date: 2012-03-05 09:07 am (UTC)no subject
Date: 2012-03-06 01:18 pm (UTC)пример вопроса: TMPL_VAR URL в шаблоне тупо не работает - значение url из конфига - игнорируется
на ikiwiki.info быстро ответ найти не вышло
быстрее - оказалось Render.pm поправить на предмет ввода MYURL с $config{'url'}
+ исправить page.tmpl c использованием новой переменной
это - правильный подход в данной ситуации или все же нет?
с другой стороны...мне нравится. хотябы тем что поправить оказалось просто и код - более менее читаемый(притом что Perl я очень давно последний раз видела). круто.
no subject
Date: 2012-03-06 03:41 pm (UTC)И то что далеко не все переенные из конфига видны из шаблона - это правильный образ действий.
Cкорее всего вы чего-то не того пытались добиться посредством TEMPL_VAR URL.
Но плохо то, что отсутствует документация про то, какие именно переменные доступны в шаблонах, и почему были выбраны именно они. Concept manual нужен.
no subject
Date: 2012-03-05 08:49 am (UTC)no subject
Date: 2012-03-05 08:50 am (UTC)no subject
Date: 2012-03-05 08:55 am (UTC)no subject
Date: 2012-03-05 09:01 am (UTC)про внешний вид
Date: 2012-03-05 12:27 pm (UTC)* Ikiwiki uses many templates for many purposes. By editing its templates, you can fully customise its appearance, and avoid duplicate content - http://ikiwiki.info/templates/
* CSS - http://ikiwiki.info/css/
* Плагин theme - http://ikiwiki.info/plugins/theme/
Re: про внешний вид
Date: 2012-03-05 12:39 pm (UTC)В общем, нужно экспериментировать и писать пошаговое описание того, как привести wiki в жлелаемый вид.
Опять же про виджеты надо по более другим ссылкам смотреть.
Re: про внешний вид
Date: 2012-03-05 04:04 pm (UTC)А пошаговое описание - создаем в своем корне каталог templates/, копируем туда стандартный теплейт из поставки, который собираемся менять, и меняем. Полная документация конечно бы не помешала, но и do it by example вполне прекрасно работает. Каталог templates/ в корне работает похоже на unionfs, налагаясь на стандартный templates/.
Примеры довольно радикального изменения внешнего вида, к которым я сам приложил шаловливые ручки
(просьба не пинать за корявый дизайн): http://www.bsd-dk.dk/ , http://blog.tobez.org/
no subject
Date: 2012-03-05 12:47 pm (UTC)2. Ну, почему, почему оно использует какой-то третюю ни с чем не совместимую wiki нотацию! Если бы оно еще нотацию mediawiki в каком-то минимальном объеме умело, перевел бы на него все имеющиеся. А так...
no subject
Date: 2012-03-05 12:54 pm (UTC)2. Это уже украдено до нас http://ikiwiki.info/plugins/contrib/mediawiki/
no subject
Date: 2012-03-05 01:18 pm (UTC)no subject
Date: 2012-03-05 01:26 pm (UTC)Там, кстати разница с mediawiki почти отсутствующая - ссылки - такие же, списки - такие же. Только заголовки другие. Но заголовки, кстати, в чем-то и логичнее - количество hashmarks по сторонам строчки равное циферке в html-ном тэге, в который оно превратится.
Опять же, то что markdown прозрачен для html тэгов, практически лишает меня мотивации разбираться с альтернативными разметками.
Вот насчет graphviz-овских и tex-овских плагинов, а также встроенного syntax highlighting для всяких языков программирования надо бы покопаться.
В рамках оффтопика.
Date: 2012-03-05 02:49 pm (UTC)- Почему я голосовал за Прохорова
- Почему я выбрал Путина
- Почему я выбрал Прохорова
- Почему я выбрал ikiwiki
Не согласен с выбором (wackowiki - это наше все), но полностью одобряю.
Re: В рамках оффтопика.
Date: 2012-03-05 02:54 pm (UTC)wackowiki к сожэалению , не удовлетворяет главному из них - отсутствует в дистрибутиве.
no subject
Date: 2012-03-06 08:22 am (UTC)имхо
no subject
Date: 2012-03-06 08:25 am (UTC)ikiwiki использует свой собственный suid-ный враппер. Который suid на юзера wiki. Это гораздо безопаснее, чем generic suexec, который теоретически может присвоить права любого юзера.
no subject
Date: 2021-04-08 07:54 pm (UTC)P.S. Вообще, жаль, что забросили, интересная, вроде, штука.
no subject
Date: 2021-04-09 02:45 am (UTC)Никак. Тогда у меня вообще не работали почтовые уведомления.