И еще про вики
Jan. 20th, 2012 02:32 pm![[personal profile]](http://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vitus_wagnerКомментаторы в предыдущем посте таки сподвигли меня продолжить рассмотрение дистрибутива.
B и нарыл я там ikiwiki.. Насколько я понимаю, это примерно тот зверь, которого я хотел создать под названием stilllife, но так и не доделал.
То есть это движок, который по окончании операции редактирования/комментирования генерирует статическую HTML-ку.
И поддерживает еще тут же копирование ее rsync-ом куда надо.
И openid аутентификация выглядит у почти ровно так, как мне бы хотелось.
И поддерживают они еще и блог, помимо wiki. Так что поразбираюсь, может быть реализую наконец давнюю мечту и пошлю далеко-далеко американские блогсайты с ихними жесткими ToS.
Upd На сайте имеет место 22-килобайтная страница Security в которой помимо всего прочего написано "Note that ikiwiki runs with perl taint checks on". И при каждом исправленном security баге указывается не только версия самого ikiwiki где оно пофиксено, но и версии пакета из Debian stable, куда фикс бэкпортирован.
B и нарыл я там ikiwiki.. Насколько я понимаю, это примерно тот зверь, которого я хотел создать под названием stilllife, но так и не доделал.
То есть это движок, который по окончании операции редактирования/комментирования генерирует статическую HTML-ку.
И поддерживает еще тут же копирование ее rsync-ом куда надо.
И openid аутентификация выглядит у почти ровно так, как мне бы хотелось.
И поддерживают они еще и блог, помимо wiki. Так что поразбираюсь, может быть реализую наконец давнюю мечту и пошлю далеко-далеко американские блогсайты с ихними жесткими ToS.
Upd На сайте имеет место 22-килобайтная страница Security в которой помимо всего прочего написано "Note that ikiwiki runs with perl taint checks on". И при каждом исправленном security баге указывается не только версия самого ikiwiki где оно пофиксено, но и версии пакета из Debian stable, куда фикс бэкпортирован.
![[identity profile]](http://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
no subject
Но писать CMS лениво и вообще это изобретение велосипеда, поэтому нашел другой способ, более тупой, но лично меня (и тех кому делал) устраивает. Делается два сайта -- один test.xyz.ru, другой www.xyz.ru. На первом под ssl и под паролем апача в .htaccess кладется банальная CMS на php (я использую CMS Made Easy). Апачу прописывается транслировать запросы урлов вида xxx/yyy.html в запросы страниц у CMS (обычно что-то вроде index.hph?page=yyy). Ну а в каталоге рабочего сайта делается wget с тестового сайта (для запуска cgi-скрипта с wgetом в CMS можно закладку положить). Закончив работать над тестовой версией и удовлетворившесь ей, пользователь жмет ссылочку "опубликовать" и на основном сайте все оказывается в чистом html, и страницы именуются правильно, и можно темплейты с дизайном использовать.
И вряд-ли что-либо влезет в CMS, какие бы жуткие дыры там ни были (нужно иметь логин с паролем владельца сайта), и обслуживания не требует. Одни плюсы, минус только в том, что контент только статический, но любому среднему сайту динамический на самом деле даром не сдался.
no subject
Только я бы держал тот сайт который с CMS в офисе, и wget гонял бы на нем же. А потом уже реплицировал на площадку к провайдеру каким-нибудь rsync-ом.
Для пущей вящести.
no subject
Накручивать же параноидальные уровни безопасности можно до бесконечности, но зачем? Не банковские карточки в конце концов там обрабатываются.
Динамический контент -- увы, только на чем-то высокого уровня. Я вообще для динамики предпочитаю Oracle APEX, позволяющий в считаные часы сварганить большую бизнес-залипуху почти для всех внутренних задач в конторе. К сожалению, аналог APEX никто даже не пытается сделать в опенсорсном мире :(
no subject
Two ideas
Вообще-то "за нас уже все сделано"
в файловой системе
и с простым набором команд
Кидаем эти три маленьких файла (ибо каждая из составляющих - один-единственный executable
файл, причем кроссплатформенный), кидаем в нашу корневую директорию (БЛОГ/бин)
Далее создаем entries в нано-блог-скрипте. Показываем их через нано-веб сервер. И делимся
ими через распределенную систему контроля версий.
Лучшая из существующих для такой цели - Monotone. Один файл примерно 1.5 МБ, в который
встроено ВСЁ, включая и сильную криптографию (умеет генерировать ключи, пользоваться
ssh-agent, распространяет файлы между nodes, узлами, через стандартную ssh.). Можно
скачать готовые binaries для любой из платформ.
Никаких идиотских OpenID - глобально уникальным именем пользователя такой распределенной
сети является хэш его RSA key. Для удобства людей можно комбинировать его с именем
(не обязательно уникальным), вроде "user_34F2BC15_vitus_wagner"
Monotone умеет позволять доступ только на чтение или на чтение-запись владельцам
таких-то ID (ключей), что означает: широкий круг распределенных пользователей
может копировать архивы статей, но узкий - "взаимные друзья" - реплицирует журналы
друг друга.
Верификация и криптопроверка встроены в Monotone. Это - готовое решение покрывающее
90% усилий по разработке распределенной node.
если вам нравится управлять своим узлом через веб-интерфейс, подпишите такой скрипт.
Кроме того нужен второй скрипт, который приклеит копирование с ЖЖ, dreamwidth, ...
через RSS и/или wget'ом с минимальным приведением результатов в стандартный для
вашего узла и вики (единый для всех таких узлов) вид.
Тут остаются некоторые вопросы. Кроме того, такая система пригодна для
малых узлов, чисто личных, на которых не держат свой дом множество пользователей.
Репликации могут вестить с низкой интенсивностью (т.е. не тысячи раз в секунду),
несколько раз в сутки между друзьями и может быть сотни раз в сутки для копирования
прочими узлами read-only.
ВТОРОЕ: можно сделать еще лучше
Я подумал еще на эту тему, и решил, что можно подобный подход развить, удивительно как он по результатам обдумывания упрощается, и сделать _очень_ простую систему, если отказаться от некоторых подсознательных решений, о которые люди никогда даже и не осознают.
Не нужна база данных. Не нужна authentication в виде логина. Не нужны сессии для чтения/комментирования на веб-сайте. Можно сделать простую программу из готовых кусков плюс склеивающих скриптов меньше чем в 2х мегабайтах (где собственных скриптов будет несколько десятков килобайт), и при том она будет масштабироваться от индивидуальных до многопользовательских машин с как минимум сотнями (может быть и тысячами) одновременных запросов в секунду, и масштабироваться и по CPU, и по дискам и т.д - по отдельности, как из кубиков строить.
Отказ от вбитых в мозг и никогда не обсуждаемых положений нужно сделать в 2х главных вещах.
(а) Распределенные блоги учат нас, что сильная криптография решает массу вопросов.
Отказавшись от идеи 'логина на сайт' мы резко упрощаем структуру программ и делаем
ррреволюционный прорыв в веб-архитектуре. ;)))))
(б) современная архитектура работает "синхронно" (я послал запрос - сижу жду ответа, и сильно
нервничаю, если ответ приходит более чем через 10 секунд )
Для блог-сайта _это совершенно не нужно_ для массы функций. Они могут и обязаны стать
_асинхронными_.
В этот комментарий не влезет, но получается очень интересно, и главное, писать склеивающих скриптов надо очень мало (и похоже архитектура масштабируется легко и очень резиново)
Re: Two ideas
Но даже и в них отказатсься от "дурацкого OpenID" не получится. Хотя я готов согласиться с тем, что OpenID - именно дурацкий.
Проблема в том, что люди, комментарии от которых я хочу видеть в этом отдельном блоге/вики являются пользователями ЖЖ или DW, соответственно:
а) OpenID у них есть.
б) аутентифицируясь по этому OpenID они приносят с собой свою репутацию блоггера на LJ/DW.
И видя под комментарием/правкой в Wiki подпись в виде URL на LJ/DW я сразу понимаю с кем имею дело.
Предложение создать свою систему аутентификации позволяет избавиться от кучи технических проблем, но приводит к потере копившегося десятилетиями репутационного капитала.
Тега distributed.blog под этим постом нет. Пригодность ikiwiki к этой задачи я еще не оценивал.
Как, собственно, и к задаче блоггинга. Я только обозначил что попробую протестировать ikiwiki на этот предмет.
А про использование криптографии в распределенном блоггинге я писал в 2007 году
nope, the whole concept is different
Потому что пользователь с новым крипто-ID просто оставляет в своем ЖЖ в верхнем посте
запись "вот мой public key" - и любой, кто верит, что логон мог сделать в этот журнал
только Х (чему вы как видно в целом верите), может с 0выми усилиями считать, что
user_23F4A7B3_vitus_wagner - это тот же самый lj-user vitus_wagner.
Все вокруг знают, что надо сходить в известные места и посмотреть в верхних постах
public keys людей для проверки. Можно даже договориться о стандартном формате такого
поста-оповещения и делать проверку автоматически.
(2) В вашей заметке в 2007 году вы писали:
..модель Web of trust подходит лучше. Но она не поддерживается из коробки браузерами, соответственно возникнут проблемы при работе из интернет-кафе, а у технически не подкованных юзеров, и при работе из дома.
Это неверно. крипто-ID поддерживаются по крайней мере Firefox'ом, причем так просто, что пользоваться ими раздражает намного меньше, чем вбивание Capture's и логонов, которые в ЖЖ у меня срываются раза 4-5 прежде чем пройти (из-за комбинации с capture, немыслимым порядком включения разных cookies, пересылки на промежуточные экраны и т.д.)
(3) Наверно проблема в том, что мы можем сейчас начать разговаривать о разных вещах, называя их одним и тем же термином.
Вся идея крипто-ID заключается всего лишь в подписи каждого поста и каждого комментария
Это настолько просто, чтo...
вы "select all" мышью, и кликаете на кнопку в браузере "подписать"
(clearsign, обязательно _clear_ sign)
любой блог.
Всё, Это и есть ваш "логон" которого не было.
-----------------------------
Вы далее в 2007 писали:
На самом деле, в случае distributed blogging-а, электронная подпись под постом или комментарием, удостоверяет только то, что ..........
чтобы проверить электронную подпись, нужно всего лишь иметь закэшированный сертификат выдавшего её CA,......
Неверно. АБсолютно неверно, и никакие CA (созданные для корпоративного контроля) при электронном подписывании _вообще никак не фиругируют_.
Подпись == факт, что я обладают таким-то private key, не больше и не меньше.
Кто я такой люди знают ТОЧНО ТАК ЖЕ КАК И В ЖЖ, по сумме моих записей и поведения в блогах.
Никакие формальные "web-of-trust", которые пытаются сравнивать с корпоративно-ориентированными
certificate authoriries вообще ни на что не влияют.
Идея web of trust в том, что А, Б и В встречали Х в реальной жизни, и подписываясь нам 'гарантируют", что Х есть костя, размер ботинок 43, телефон нумер ... и так далее.
Для social blogging это всё абсолютно по барабану. Вы жили в ЖЖ многие годы, вспомните как и почему вас знают люди, и какой огромный процент их вообще не связывает "виртуальные" и реальные личности, что не мешает ЖЖистам-виртуалам быть многотысячниками (мой пример).
Далее вы продолжили рассуждать в терминах цепочек CA. НО ОНИ НЕ НУЖНЫ. Нужны лишь крипто-IDs, а не заявления А о личности Б. Сама концепция противоположна идее связи с реальной жизнью.
Я должен лишь знать, что вчерашний А и сегодняшний - то же самое лицо, и что посмотреть архивы его публикаций и коммнетариев мне ДОСТАТОЧНО.
CA и Web-of-trust желают по-милицейски заставить открыть личико - и использование этих механизмов для иных целей оказывается неизбежно громоздким и уродливым
more explanations
разумеется, текст public key подписан своим же private key - чтобы каждый мог проверить.
Т.е. это "чистый" сертификат, в отличие от "политически-мотивированных" сертификатов, принятых в системе с CA (где ключ может считаться лишь сертификацией неких не-ключевых, вне-компьютерных заверений в которых по идее создателей мы должны полагаться на их "авторитет" потому что они "проверят" и "нам скажут" ибо они большие корпорации)
Для глобального social blogging нужны лишь уникальные на все времена и глобально ID. Причем каждое физическое лицо может создавать их сколько угодно и связывать или не связывать с ранее известными своими personalities и/или вневиртуальной жизнью.
Что, разумеется неприемлемо для разработчиков идей CA или OpenID: они хотят прежде всего учета и контроля и связывания разных мелькающих на интернете личин в одну, привязанную к паспорту и адресу.
Re: nope, the whole concept is different
Ни один из тех сотен пользователей ЖЖ и DW, которых бы я хотел увидеть в комментариях в своем блоге НЕ БУДЕТ создавать себе какой-то там крипто-ид.
Ему - и в ЖЖ хорошо. Это тот кто уехал на отдельный хостинг должен предпринимать какие-то усилия, чтобы в ЖЖ его не забыли.
Процесс переполза из ЖЖ в DW очень хорошо иллюстрирует, что даже те минимальные сложности которые доставляют DW-шные external account-ы отсекают 90% комментаторов.
Поэтому одна из причин, которые я имею в виду при рассмотрении ikiwiki как блог-движка, это то, что там ЖЖ-юзерам будет комментировать ПРОЩЕ, чем в DW. И отсекаться будет не 90% комментаторов, а всего 70%.
Соответственно, требование к блогу номер раз:
1. Его можно читать не имея никакого софта кроме браузера
Требовние к блогу номер два
2. Для того чтобы комментировать блог, будучи залогиненным в ЖЖ, DW или что еще в этом роде, должно требоваться не более 2-3 лишних кликов по сравнению с комментированием в самом ЖЖ/DW/whatever, и по возможности не должно требоваться ручного ввода никаких персоанльных данных.
После этого все ваши дилетантские рассуждения про криптографию можно забыть. Но я все же рекомендую вам повнимательнее изучить RFC 5280 и осознать, что удостоверяющие центры (CA) и вообще X.509 это не изобретение злых корпораций, а такая штуковина вроде бластера Сэлвора Хардина - стреляет в любую сторону, в зависимости от того, в чьих руках находится.
Re: nope, the whole concept is different
1. Его можно читать не имея никакого софта кроме браузера
................
Я с годами кажется дошел то той ясности мысли, когда становится невозможно объяснить другим элементарные вещи. Не понимают. Хоть тресни.
Давайте я "не замечу" ваш выпад о 'дилетантских' моих суждения о криптографии, они не таковы (знаю, знаю, вы копались в openSSL а потому позволяете)
Однако похоже даже вас переклинивает. Поясню.
Люди устроены весьма странно. Задайте задачу "в бассейн входит 2 трубы и выходит одна..." - и большинство её решит, или по крайней мере не задумываясь попытается: это "для 5го класса"
Переформулируйте задачу: "на атомной станции для охлаждения реакторов необходим проток воды. В резервуар входят 2 трубы, а выходит одна" - и подавляющее большинство откажется даже пробовать решать "потому что я ничего не понимаю в ядерной физике"
Криптография, public key cryptography, вызывает подобное отношение, которое не имеет ничего общего с реалиями применения уже готовых написанных продуктов.
Ваши возражения звучат примерно как впечатление средневекового европейца о гиппопотамах (см. гравюры того времени). Вы просто не имеете представления о том, что такое интерфейс fireGPG и насколько он элементарен в использовании.
Итак, первое:
требование к блогу номер раз:
1. Его можно читать не имея никакого софта кроме браузера
Абсолютно верно.
(а) Ставим GPG (стандартная установка). Ставим FireGPG (стандартный плагин, один клик и перезапуск браузера)
(б) Кликаем на кнопку "создать ключ". Все дефолты (it'll create a 2048-bit long RSA keypair).
Вам выбирать только имя ("vitus_wagner") да пароль для ключа, неотличимый от пароля для ЖЖ.
(в) открыв a standard web form, пост или комментарий, я пишу текст, затем отметив его мышью, я кликаю на кнопку "подписать" (и вбиваю свой пароль).
FireGPG может его загнать в кэш в памяти, потому мне нужно вбивать его один раз, если я так хочу, за всю сессию.
Плагин САМ заменит мой текст в окошке формы на текст+подпись (сам, понимаете?)
(г) я кликаю на кнопку "отправить" - и всё.
Это ПРОЩЕ ЧЕМ СЕГОДНЯШНЯЯ СИСТЕМА, и в разы проще, чем СЕГОДНЯШНЯЯ СИСТЕМА С УНИКАЛЬНЫМ ЛОГОНОМ НА КАЖДОМ САЙТЕ.
Мой сервер же получив форму, посмотрит:
(а) она от хозяина блога. скопировать в директорию видимую из-под сервера, как новый пост (или комментарий, в зависимости от формы)
(б) Она от кого-то еще. Этот кто-то входит в список с позволением комментировать (просто список key hashes)? Да - копируем в зону видимости.
(в) сами public keys распространяются автоматически или полуавтоматически между nodes, а также Ги GPG и кажется web-UI FireGPG позволяют работать со стандартными (они есть в мире, ничего не надо делать самому) key servers.
Нажал на кнопку, отправил ключ туда один раз - и всё.
(г) Для оповещения: я пришел в свой ЖЖ и повесил простейший пост - просто copy-pasted в него свой public key и нажал на кнопку как в (в) первого перечисления. Это всё.
(я совершенно не понял вашего "возражения" о том, что суетиться должны те, кто из ЖЖ ушел. Ну да, они в старом месте и сделают один такой пост. В журнале, который они покидают. В чем проблема??)
Более того, никто им не запрещает делать в ЖЖ cross-posting с нового места. Пароль-логин остался, в ЖЖ есть нужные APIs - если в новом блоге это прикручено, отметил галочку "cross-post to LJ" и забыл.
Ваши возражения кажутся мне как бы испугом человека, который не представляет о чем говорит. Ковыряясь в потрошках openSSL вы никогда кажется не _пользовались_ готовыми написанными для людей и намного, на многие порядки более простыми для end-user программами вроде GPG. Конкурирующая в чем-то с OpenSSL организация, да, которая однако тоже дает крипто-библиотеки достатчно общего применения и даже встроила X509
Ничего сложного в них нет. Люди используют GPG для почты годы. Но традиция применения public-key-based крипто-logons на Вебе отсутствует. Применение же таких подписей позволяет радикально упростить структуру веб-сервера для подобных блогов не говоря о куче возможностей которых ни ЖЖ, ни dreamwidth, ни индивидуальные непонятно зачем нужные standalone blogs не предоставляют.
Я не просто в IT десятки лет, но детально продумал такую архитектуру и не кричу от наивности.
Я прекрасно понимаю что и как надо конкретно сделать.
Re: nope, the whole concept is different
При чем здесь public key cryptography ВООБШЕ, если речь идет о блогах?
Да, public key cryptography можно и использовать для аутентификации и авторихзции в системе распределенных блогах, но нужно ли?
В составе наиболее распространеной операционной системы gpg не идет. Соответственно, в любых cредах, где установка софта пользователями запрещена, будь то интернет-кафе или корпоративная рабочая станция, GPG нет. Файрфокса скорее всего тоже нет, а есть либо IE, либо Safari. Возможно Chrome.
Все,.пользователь, пользующийся не своей машиной пролетел.
Пользователь, пользующийся мобильным устройством тоже пролетел - у него либо Safari, либо Chrome, либо вообщен какая-нибудь j2me хреновина.
В 2007 году мобильные терминалы можно было игнорировать, сейчас - нельзя.
Рассматривать X.509 имеет хоть какой-то смысл, потому что этот стандарт поддерживается всеми браузерами. Поскольку на него завязано очень много в системе электронной коммерции и ни один производитель браузеров пролетать мимо этого рынка не хочет.
Правда, поставка браузера IE ограничивается поддержкой только HTTPS. Для подписи введенных в форму данных (что возможно из коробки БЕЗ ПЛАГИНОВ в Firefox, Opera и Safari) ннобходимо ставить ActiveX-элемент capicom. Да, бесплатный, да с сайта Microsoft. Но в корпоративной среде это запросто может быть невозможным. А проверки подписей нет наоборрот в браузерах, поддерживающих window.crypto. А в IE есть через тот же ActiveX.
Поэтому нам придется при создании системы блогов обходитьcя без public key cryptography на клиентских терминалах. А не на серверах она куда менее осмыслена.
Re: nope, the whole concept is different
Казалось бы уж на что стандартный плагин Adblock Plus, и то регулярно при обновлении файрфокса совместимость с ним нарушается, и приходится вместе с файрфоксом апгрейдить и плагин.
На мой взгляд, это недопустимо сложно для нормальных людей.
Поэтому я свой вариант криптоблог-клиента рассматривал скорее не как плагин к браузеру, а как приложение-прокси. Благо прокси общается с браузером по стандартному протоколу и взаимодействие с ней не будет сломано при апгрейде браузера.
Re: nope, the whole concept is different
Пришла тут в голову такая идея: такой сайт можно и из домашней директории стартовать и GnuPG локально ставить. Не так давно имел дело с локальным сервисом, который использовался для подписывания данных при работе с удалённым сайтом. Стучались к этому сервису посредством AJAX на 127.0.0.1: на этот адрес стучаться не возбраняется, даже если сама страница загружена с другого адреса. Но это, в любом случае, дополнительные телодвижения.
Re: nope, the whole concept is different
Так что наличие выхода в интернет через прокси совершенно не мешает иметь локальную прокси, выполняющую преобразование контента.
Возбраняется обычно не "стучаться" на какой-то адрес. А "цепляться" в смысле bind(2). Что необходимо для того, чтобы кто-то мог постучаться. Но тут как раз localhost исключение.
Проблема тут скорее не в корпоративных средах, а в распространении кастрированных мобильных ОС, в которых пользователям не дают контроля над системой. Поэтому в наше время от идеи устаноски чего-либо на клиентский терминал придется отказаться.
Re: nope, the whole concept is different
Там кроме нескольких мегабайт собственно GPG ставится еще мегабайт сто графических тулзов для управления сертификатами (а консольной версии в современной версии, кажется, и нет). Ставить сотни метров неведомо чего люди просто не хотят (зная, что писать блоги и править вики можно и без этого), говорю по опыту.
И вешается демон менеджера сертификатов, тоже непонятно зачем, которому нужно разрешить слушать какие-то порты.
(Да, у людей винда, макось и андроид.)
???
no subject
А я развернул ikiwiki в качестве корпоративной вики именно по причине того, что информация хранится в plain text файлах. Ну и бэкап (со всей историей) тривиально делать.
Спасибо за наводку