Valve выпустило несколько обновлений для Counter-Strike: Global Offensive, которые включают в себя два новых режима Arsenal: Arms Race и Arsenal: Demolition, а так же добавили новую карту под названием de_lake. Так же стало известно, что Valve решила отказаться от кросс-платформенного мультиплеера в Counter-Strike: Global Offensive, объясняя это тем, что кросс-платформенный сетевой режим может стать препятствием для постоянного обновления Global Offensive, стоит заметить, что данная фишка удачно работает в игре Portal 2.

В комментарии на свой пост получил такие слова: "Linux- Это для военных и тех, у кого руки на месте. Это как все качественное подгоняется под каждого персонально. Безопаснее - да как в танке, не даже в бункере..." Пришлось написать пост: http://www.pcweek.ru/ecm/blog/foss/2554.php...(read more)

Написал пост по теме: http://www.pcweek.ru/ecm/blog/foss/2541.php...(read more)

Написал вчера и сегодня. В общем-то, это "толчение воды в ступе", но приходится... http://www.pcweek.ru/ecm/blog/foss/2528.php http://www.pcweek.ru/ecm/blog/foss/2532.php...(read more)

Почему после долгих и продолжительных раздумий я выбрал ikiwiki? Потому что:

1. На мой взгляд ikiwiki обладает главным свойством, требуемым для веб-приложений на домашней машине - не занимает ресурсов, когда не используется.
2. Второй - то что оно устойчиво к кратковременным всплескам посещаемости, связанным с публикацией ссылок на посещаемых ресурсах. Потому что для чтения это - статика.
3. Обладает уже готовой возможностью пускать пользователей по их аккаунтам во всяких прочих системах ЖЖ, Гугль, FB etc. Это очень полезно для маленького, но публичного сайта. Чтобы не заставлять всех желающих регистроваться на yet another сайте.
4. Работает с произвольными системами версионирования.
5. Хорошая поддержка в Debian.
6. Как это ни странно для современного OSS проекта, в команде есть кто-то кто имеет представление об информационной безопасности.

Недостатки у ikiwiki тоже есть.

1. Отсутствие внятной introductory documentation. (восполнить этот недостаток отчасти призван этот пост)
2. Я пока так и не понял как кастомизировать внешний вид сайта. Для сайта вида "личная записная книжка" это и не важно.
3. Внятного руководства "что делать, если что-то не работает" тоже нет.

этим советом.

Конфиг виртуального сайта для 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, в то время как зачекинив его в систему управления версиями мы получаем сразу то, что надо.
http://vitus-wagner.dreamwidth.org/716209.html. Please comment there using OpenID. Now there are comments