ОМСКАЯ ГРУППА ПОЛЬЗОВАТЕЛЕЙ LINUX » Linux http://omsklug.com Свобода - это ответственность. Вот почему все её так боятся. Бернард Шоу Fri, 10 Nov 2017 17:30:02 +0000 en hourly 1 http://wordpress.org/?v=3.2.1 Трансляция про Docker из Омска http://omsklug.com/2017/11/docker/ http://omsklug.com/2017/11/docker/#comments Fri, 10 Nov 2017 17:24:37 +0000 linuxmasterz http://omsklug.com/?p=2067 Следуй за синим китом!

Docker Logo

2017-11-11 в 16.00 OMST (10.00 UTC) на http://www.omsklug.com/tv (https://www.youtube.com/c/Omsklug/live) будет трансляция, посвящённая контейнерной системе виртуализации Docker. Казалось бы, что ещё можно рассказать, да показать? А вот и послушайте, да посмотрите. Всем синих китов!

]]>
http://omsklug.com/2017/11/docker/feed/ 0
Трансляция “Битва дистрибутивов для импортозамещения” http://omsklug.com/2017/01/distrobattle2017/ http://omsklug.com/2017/01/distrobattle2017/#comments Wed, 25 Jan 2017 19:57:04 +0000 linuxmasterz http://omsklug.com/?p=2042 2017-01-29T17:00+0600 OMST (двадцать девятого января две тысячи семнадцатого года в семнадцать часов по Омскому времени) будет проведена видеотрансляция “Битва лучших дистрибутивов для импортозамещения”. Смотреть видеотрансляцию можно здесь:

http://omsklug.com/tv

или непосредственно на нашем канале тут:

https://youtube.com/OmskLUG

Мы просто установим и сравним несколько известных дистрибутивов GNU/Linux: AstraLinux, BaseAlt, GosLinux, МСВС. Готовьте ваши вопросы, например, в комментариях к этому сообщению. Либо отправляйте электропочтой на адрес post@omsklug.com или делитесь ими в jabber-конференции омских линуксоидов: omsklug@conference.jabber.ru.

Пошумим ПОСРАВНИВАЕМ !!!

]]>
http://omsklug.com/2017/01/distrobattle2017/feed/ 0
День свободы программного обеспечения 2016 http://omsklug.com/2016/09/sfd2016/ http://omsklug.com/2016/09/sfd2016/#comments Mon, 12 Sep 2016 18:54:50 +0000 linuxmasterz http://omsklug.com/?p=2025 Software Freedom Day LogoЧто это такое?

День свободы программного обеспечения (Software Freedom Day, SFD, День СПО) — ежегодное всемирное мероприятие, посвященное свободному программному обеспечению и ПО с открытым исходным кодом. День свободы программного обеспечения — публичная образовательная инициатива, нацеленная на повышение уровня осведомленности о свободном программном обеспечении и его преимуществах, информирование о последних технологиях и тенденциях в свободном программном обеспечении.
Идея Дня свободы программного обеспечения появилась в 2004 году и первый раз такой день был проведен 28 августа того же года. В Омске он проводится с 2007 г. и обычно – группой пользователей Linux.

Что мы будем делать?

Мы просто устроим себе праздник и не будем напрягаться
Мы будем кулуарно свободно общаться на скучные темы про это наше IT, GNU/Linux, свободное программное обеспечение
Мы будем устанавливать и радоваться различным дистрибутивам свободных операционных систем: GNU/Linux-дистрибутивы, ReactOS, KolibriOS, Haiku
Мы будем раздавать случайным лицам методические материалы о свободном программном обеспечении
Мы проведём ещё более безудержную криптовечеринку, чем обычно.

Что мы не будем делать?

Мы не будем делать наши обычные доклады
Мы не будем делать вебтрансляцию мероприятия
Мы не будем никого регистрировать

Кому приходить?

Приходите, кому интересны:
Свободное программное обеспечение
Шифрование (PGP, LUKS, TrueCrypt), анонимность в интернете (Tor, i2p)
Сетевые технологии (виртуализация/контейнеризация через KVM, OpenVZ, LXC, Docker)
Вопросы лицензирования программного обеспечения
Реестр российского программного обеспечения

Что приносить с собой?

Ноутбуки, чтобы поставить туда свободные операционные системы
Носители компьютерной информации (флешки, диски и т.д.), чтобы скопировать свободное программное обеспечение
Аппаратное обеспечение, которое хотите подключить в свободных операционных системах, но не сумели или не успели это сделать

Когда и где?

Собираемся 17.09.2016 в 14.00 в Омске в кафе на 3½ этаже ТЦ «Омский» (над «Сытной площадью»), вот где-то здесь: https://www.openstreetmap.org/?mlat=54.97682&mlon=73.39135#map=19/54.99219/73.37326

 

]]>
http://omsklug.com/2016/09/sfd2016/feed/ 1
Нам нравится Profanity! http://omsklug.com/2016/03/we-like-profanity/ http://omsklug.com/2016/03/we-like-profanity/#comments Wed, 02 Mar 2016 19:20:35 +0000 Shroom http://omsklug.com/?p=1988 .local p {text-align: justify!important; text-justify: inter-word!important;} .local a {color: rgb(16, 8, 96)!important;} .local a:visited {color: Gray!important;} .local a:hover {text-decoration: underline; color: Blue!important;} .local pre {overflow-x:auto;} .local code {font-family: Monospace,Courier!important;} .local code > span.kw { color: #268BD2; font-weight: bold; } .local code > span.dt { color: #268BD2; } .local code > span.dv { color: #D33682; } .local code > span.bn { color: #D33682; } .local code > span.fl { color: #D33682; } .local code > span.ch { color: #4070a0; } .local code > span.st { color: #2AA198; } .local code > span.co { color: #93A1A1; font-style: italic; } .local code > span.ot { color: #A57800; } .local code > span.al { color: #CB4B16; font-weight: bold; } .local code > span.fu { color: #268BD2; } .local code > span.er { color: #D30102; font-weight: bold; }
profanity project logo

Правда. :) Даже несмотря на наличие под катом ненормативной лексики. Так что, если вам нет 18 лет или если инвективная лексика является основной причиной ваших нравственных страданий, добро пожаловать в основной раздел нашего сайта. Если же вам интересны некоторые пикантные подробности наших счастлвых отношений с программкой из сабжа, тогда идёмте дальше…

По OmskLUG прокатилось поветрие сборки и/или установки консольного xmpp-клиента profanity. Может быть, это следствие его специфической суровой консольной кавайности, может быть, омсклуговцы просто устали от навороченного минимализма mcabber’а… А может быть, он на самом деле лучший из всех консольных джаббер-клиентов на сегодняшний день. И сегодня я не буду, как обычно это делал, скучно и долго рассказывать, как протанцевать по граблям сборки, установки и настройки очередного несговорчивого софта. Лучше я, как говорят в этих ваших интернетах, «просто оставлю это здесь»…

Собери Profanity!

(По щелчку на миниатюре загрузится оригинал)

“build profanity” banner in russian

И то же самое по-английски:

“build profanity” banner in english

На сегодня всё.


Спасибо за внимание!


По традиции все материалы, использованные для подготовки данной статьи, в количестве одного упакованного svg-файла можно абсолютно свободно скачать вот по этой ссылке.

]]>
http://omsklug.com/2016/03/we-like-profanity/feed/ 0
Косяки с установкой redmine_git_hosting в Debian 8 Jessie http://omsklug.com/2015/09/smashing-redmine-git-hosting-in-deian-jessie/ http://omsklug.com/2015/09/smashing-redmine-git-hosting-in-deian-jessie/#comments Tue, 29 Sep 2015 18:19:26 +0000 Shroom http://omsklug.com/?p=1954 .local p {text-align: justify!important; text-justify: inter-word!important;} .local a {color: rgb(16, 8, 96)!important;} .local a:visited {color: Gray!important;} .local a:hover {text-decoration: underline; color: Blue!important;} .local pre {overflow-x:auto;} .local code {font-family: Monospace,Courier!important;} .local code > span.kw { color: #268BD2; font-weight: bold; } .local code > span.dt { color: #268BD2; } .local code > span.dv { color: #D33682; } .local code > span.bn { color: #D33682; } .local code > span.fl { color: #D33682; } .local code > span.ch { color: #4070a0; } .local code > span.st { color: #2AA198; } .local code > span.co { color: #93A1A1; font-style: italic; } .local code > span.ot { color: #A57800; } .local code > span.al { color: #CB4B16; font-weight: bold; } .local code > span.fu { color: #268BD2; } .local code > span.er { color: #D30102; font-weight: bold; }
Icon for application-x-ruby MIME type

До меня время от времени доходили слухи, что установка и сопровождение Redmine — это не то, чтобы адЪ, но как минимум геморрой неслабые головняки. Вероятно, я подогнался под эту тему и в первый раз установка заняла у меня дня три. Во второй раз я уложился в пару дней. В последнее время я делаю успехи, поскольку установка плагина redmine_git_hosting прошла не более, чем за сутки. И это не может не радовать. Последовательность шагов по установке очень подробно описана в руководстве от разрабов, которое можно найти здесь: Get started. Собственно, именно такого порядка действий я и буду придерживаться в статье. Вследствие этого изложенный здесь материал может показаться фрагментарным и несколько несвязным. И если вам так и кажется, вы, пожалуй, правы…

Да, кстати. По этому тексту раскидана туева хуча полезных ссылок. Посему настоятельно рекомендую хотя бы мельком заглядывать в каждую из них по мере прочтения, иначе удовольствие будет казаться неполным.

Начало: клонирование и сборка

На всякий пожарный инструкция предупреждает нас о необходимости сбэкапить базу и остановить Redmine. Благоразумно воспользуемся этим советом и приступим…

Как ни странно, в самом начале процесс идёт на удивление гладко. Шаги по установке зависимостей и клонированию реп проходят без проблем. :)

Однако, как только дело доходит до bundle install, он тут же начинает орать. Во-первых, выдаёт предупреждение о дубликате зависимости «gem 'redcarpet', '~> 3.1.2'». Это не страшно, убирается комментированием соответствующей строчки в Gemfile внутри каталога плагина. Во-вторых, ошибка, связанная с несоответствием версий rake. Дескать, установлена 1.5.2, а плагин через зависимость от gitlab-grack требует аж 1.6.0. Это вызвано тем, что в репе jbox-web не указана версия rake; соотвественно, bundler вытягивает и собирает самую последнюю. Собственно, сам автор плагина предлагает бороться с этим косяком, используя гитлабовский форк. В результате получаем такой кусок Gemfile:

## Redmine 3.x
## Ruby/Rack Git Smart-HTTP Server Handler (use our own repository because Redmine uses Rails 4.2 and Rack 1.6)
#gem 'gitlab-grack', git: 'https://github.com/jbox-web/grack.git', require: 'grack', branch: 'fix_rails4'
#gem 'redcarpet', '~> 3.1.2'

# fix for Debian Jessie with rails 4.1
# (https://github.com/jbox-web/redmine_git_hosting/issues/497#issuecomment-133768646)
gem 'gitlab-grack', git: 'https://github.com/gitlabhq/grack.git', require: 'grack', branch: 'master'

После этих манипуляций все гемы собираются, как надо.

Следующй шаг — migrate

Здесь сразу же вылетает ошибка «The git source https: github.com/jbox-web/gitolite-rugged.git is not yet checked out. Please run bundle install before trying to start your application». Естественно, bundle install не помогает. Решение: закомментировать ссылки на git и поставить просто зависимость, как от обычных гемов. В результате получим что-то подобное:

# Gitolite Admin repository management
#gem 'gitolite-rugged', git: 'https://github.com/jbox-web/gitolite-rugged.git', tag: '1.1.1'
gem 'gitolite-rugged'

#gem 'gitlab-grack', git: 'https://github.com/gitlabhq/grack.git', require: 'grack', branch: 'master'
gem 'gitlab-grack', require: 'grack'

Кстати, в Интернете можно найти довольно много вопросов, связанных именно с таким глюком, когда какой-нибудь гем ставится из гита. ИЧСХ, внятных ответов, как бороться с этой напастью, никто не даёт. В основном какие-то шаманские рецепты типа придуманного мной. Это намекает на пару возможных причин: или эта ситуация настолько тривиальна, что отвечать просто нет смысла, или же действительно никто не знает, что там на самом деле происходит в недрах RoR вообще и Redmine в частности.

Ну так вот. После этого нужно ещё раз запустить bundle install, после чего migrate будет ругаться на другие вещи. Или, если redmine изначально был поставлен по-человечески, всё пройдёт гладко. В моём случае пользователю БД не хватало прав на создание и удаление таблиц. Выполнение в mysql

grant all privileges on `redmine_db`.* to 'redmine_user'@'localhost';
flush privileges;

решило проблему радикально.

Установка и настройка Gitolite

Пользователи и ключи

Поскольку Gitolite работает от одного пользователя через ssh, нам нужно сгенерировать некоторое количество ключей. Этот процесс вызвал единственный вопрос относительно места их хранения. В инструкции для создания пары административных ключей для плагина рекомендовано создать каталог ssh_keys в REDMINE_ROOT. Однако, если внимательно посмотреть на init.rb, становится понятно, что в дереве плагина уже есть ssh_keys, и создан он там отнюдь не случайно. Плагин в первую очередь именно там и ищет ключи. Впрочем, когда всё заработает, каталог с ключами можно переопределить в настройках.

Во время установки Gitolite нужно будет указать пользователя, из-под которого он будет работать (и в которого будут логиниться все имеющие доступ к репозиториям). Для общности пусть это будет юзер git. В качестве административного ключа нужно указывать открытый ключ того человека, который будет админом (ну или сразу ключ, сгенерированный для redmine). Дополнительные ключи (для redmine, в частности) кладутся в GITOLITE_HOME/.gitolite/conf/gitolite.conf. После этого нужно сделать gitolite compile от пользователя git. Но на самом деле ничего такого делать не нужно. Gitolite управляется через git-репу. Поэтому после установки с добавлением одного административного ключа можно и даже нужно просто склонировать репозиторий gitolite-admin тому пользователю, которого сделали git-админом. После этого можно настраивать конфиги как угодно, не забывая заливать коммиты обратно. Как и что делать, подробно разжёвано в соответствующем руководстве.

Дополнительно (для версии Gitolite 3) «патчится» пара скриптов, но это описывать не имеет смысла, поскольку процесс тривиален.

Если что-то пошло не так…

Но вот если забыть, как работает ssh, возникнут некоторые сложности с доступом по ключам. Во-первых, домашний каталог Gitolite должен принадлежать руту или тому юзеру, из-под которого работает Gitolite (и мы в самом начале решили, что это git). Следствие: если с репозиториями работает ещё кто-то (например, gitdaemon), этого кого-то нужно добавить в группу git. С другой стороны, что касается gitdaemon‘а, то его-то как раз можно запустить от имени любого нужного пользователя. Во-вторых, нужно выставить адекватные права на .ssh и то, что в нём. В-третьих, Gitolite различает git-юзеров по их ключам, поддерживая соответствующую структуру файла authorized_keys: перед ключом должна идти строчка

command="/usr/share/gitolite3/gitolite-shell <git_user_name>",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty

Если выполнены все эти условия, с доступом проблем не будет. В крайнем случае поможет анализ /var/log/auth.log. Вообще на сайте Gitolite есть специальная страница, где собраны все возможные косяки с ssh и способы их устранения. Опять же, если не лазить в конфиги руками, а делать всё через git, как расписано в документации, всё должно работать адекватно.

Что же там всё-таки с именами?

Кстати, есть ещё один нюанс, связанный с тем, как Gitolite определяет имена пользователей. Всё очень просто: как обзовёшь открытый ключ, так тебя и будут звать дальше. Опять же, всё не настолько фатально, если вспомнить, что вся конфигурация хранится в git-репозитории. Однако же, вот такая штука. Руководство по установке плагина предлагает назвать сгенерированный ключ каким-то нечеловечески длинным именем с суффиксом rsa_id. И это означает, что административный пользователь redmine будет назван этим самым непроизносимым именем. В сущности, и redmine, и плагину, и Gitolite — всем пофиг, формально всё будет работать. Однако, мне лично удобнее, когда подконтрольные мне сущности называются просто и понятно. Поэтому я переобозвал ключи в redmine-admin и redmine-admin.pub. И теперь в конфиге всё прозрачно и тихо.

Запуск Redmine и настройка плагина через веб-морду

Наконец-то, наконец-то! Если вы дошли до этого торжественного момента с минимальными потерями, вас можно поздравить. Остальных, наверное, тоже можно. Просто им уже не до поздравлений.

В общем, выполнение заключительной части инструкции особых сложностей не вызывает. Тем более, что есть целая страница с описанием тех параметров, которые нам предлагают настроить. Более того, там уже практически ничего не поломаешь, и можно, если что, исследовать систему методом научного тыка. С минимальным знанием английского или французского языков (других локализаций в этом плагине я не заметил) вполне реально разобраться даже без документации. Однако, в документации обычно пишут много интересного и полезного. :) Так что хотя бы краем глаза взглянуть всё же сто́ит.

Реальные баги

Так или иначе все ошибки, связанные с софтом, суть ошибки в коде. И если во время установки и настройки это относится к генетическому коду того, кто настраивает, то во время работы самой программы уже ничего не попишешь: мы сталкиваемся с реальными багами.

Вывод ReadMe

Итак, первый косяк в коде, с которым я столкнулся в процессе эксплуатации плагина, находится в файле REDMINE_HOME/plugins/redmine_git_hosting/lib/redmine_git_hosting/hooks/display_repository_readme.rb. Не буду рассказывать, как я его отлавливал и локализовал в конце концов, поскольку дебаггинг — это тема для отдельной статьи. Лучше сразу покажу, что нужно менять:

diff old/display_repository_readme.rb new/display_repository_readme.rb
58c58
<           raw_readme_text = repository.cat(readme_file.path, rev)
---
>           raw_readme_text = Redmine::CodesetUtil.to_utf8_by_setting(repository.cat(readme_file.path, rev))

А теперь поясню, ради чего, собственно, менять. Этот модуль должен выводить ReadMe под списком файлов и логом коммитов. Практически как на гитхабе. Однако же, без принудительного перевода прочитанного буфера в UTF-8 этот модуль падает на символах с кодами, выходящими за пределы таблицы ASCII. А внешне это выражается в том, что если в репе есть ReadMe с какими-то нестандартными символами (типа диакритики или расширенной пунктуации), то вместо репы мы увидим шиш с маслом Server Error 500. Это некрасиво да и вообще как-то неправильно. Поэтому вот такой нехитрый патч. Сделал pull request с этим «патчем»; будем ждать, когда окажется в апстриме. Upd[2015-10-02]:патч принят в основной репозиторий.

Дополнительно нужно отметить, что для отображения ReadMe в формате ReStructuredText требуется установка python-docutils. Да, именно. Это питоновский пакет, который нужен программе на ruby. Так тоже бывает.

Вывод новостей

В процессе работы был выявлен ещё один косяк, характерный именно для этой версии redmine. В случае, когда у пользователя выставлен признак «Отображать комментарии в обратном хронологическом порядке», при попытке просмотреть отдельную новость (вне зависимости от проекта и наличия комментариев) сервер выдавал Error 500. После анализа логов, мониторинга базы и изучения исходников удалось обнаружить ошибку в REDMINE_HOME/app/controllers/news_controller.rb. Косяк выпрямляется вот таким вот незатейливым способом:

diff old/news_controller.rb new/news_controller.rb
61c61
<     @comments = @news.comments
---
>     @comments = @news.comments.to_a

Кстати, как оказалось впоследствиии, в транке redmine этот баг был пофиксен в ревизии 13595 абсолютно так же.

Автоматическая подгрузка изменений

Собственно, это не то, чтобы баг… Скорее глюк. В общем, я заметил, что репы, переведённые в Redmine на Gitolite, не подхватывали автоматом изменения, сделанные снаружи, хотя соответствующая настройка в конфигурации была включена. В результате оперативно был воплощён в жизнь такой рецепт.

Чтобы redmine могла автоматически отслеживать изменения в репозиториях, в GITOLITE_HOME/.gitolite/hooks/common/post-receive.d нужно добавить скрипт, вызывающий метод fetch_changeset либо через WebAPI, либо напрямую через запуск redmine. Например, такой:

#!/bin/bash

API_KEY=XXXXXXXXXXXXXXXXX

PROJECT_ID=`git config redminegitolite.projectid || echo ''`

[ "${PROJECT_ID}" ] && {
    wget "https://<redmine.server.name>/sys/fetch_changesets?id=${PROJECT_ID}&key=${API_KEY}" >&/dev/null
    echo Redmine repository updated successfully
}

exit 0

Естественно, для доступа через веб должна быть включена соответствующая опция в настройках и получен ключик. Это делается в пару кликов на странице «Administration → Settings» на вкладке «Repositories».

Собственно, на этом всё.


Спасибо за внимание!


И как обычно, текст этой статьи в формате PDF можно совершенно свободно скачать вот по этой ссылке

]]>
http://omsklug.com/2015/09/smashing-redmine-git-hosting-in-deian-jessie/feed/ 0
Криптография с использованием ключей SSH http://omsklug.com/2015/09/ssh-crypto-pgp-for-poors/ http://omsklug.com/2015/09/ssh-crypto-pgp-for-poors/#comments Sun, 20 Sep 2015 16:18:42 +0000 Shroom http://omsklug.com/?p=1932 .local p {text-align: justify!important; text-justify: inter-word!important;} .local a {color: rgb(16, 8, 96)!important;} .local a:visited {color: Gray!important;} .local a:hover {text-decoration: underline; color: Blue!important;} .local code {font-family: Monospace,Courier!important;}

…или «PGP для бедных»

Внезапно за последнюю неделю у меня родилась вторая статья, имеющая отношение к криптографии и защите данных. Это несколько странно для меня, но вот поди ж ты, растащило на скрипты. Но если в прошлый раз речь шла о защите LUKS-разделов, то сейчас я вкратце расскажу, как можно что-нибудь зашифровать для конкретного человека, используя его открытый ключ ssh.

История вопроса

Итак, давным-давно, кажется в прошлую пятницу… Хотя нет. На самом деле в начале мая этого года… Так вот, именно в то время Родригес задался вопросом, можно ли в рамках концепции криптографии с открытым ключом использовать для шифрования ключи ssh. Они же по умолчаню есть практически всегда, чего не скажешь, например, о PGP/GnuPG. И, как оказалось, это возможно! В общем, академический интерес Родригеса был удовлетворён почти сразу же, а вот у меня до практческой реализации идеи руки дошли только сейчас.

Впрочем, для того, чтобы что-то зашифровать и подписать, ssh будет маловато: в любом случае нужно будет поставить дополнительно хотя бы openssl. Не будем спрашивать, почему бы не поставить GnuPG, раз уж в любом случае нужно что-то ставить. Лучше предположим, что шифровать будет какой-нибудь бездомный (в смысле, без ~ и с nologin) робот в автоматическом режиме, и специально для него генерить связку pgp-ключей будет, наверное, слишком жирно. Так что пусть удовлетворяется тем, что есть.

В чём суть

Так чем же удовлетворить себя несчастному одинокому роботу, если GnuPG не стоит, а шифровать хочется? Ответ очевиден: OpenSSL! Более конкретно — модуль rsautl, который позволяет шифровать небольшие клочки данных (в зависимости от типа пэддинга максимум будет составлять 214, 245 или 256 байтов) открытым RSA-ключом. Не нужно быть семи пядей во лбу, чтобы понять, что даже максмальные 256 байтов не пойдут ни в борщ, ни в красную армию. По той простой причине, что их слишком мало. Тем более, что та же openssl enc умеет шифровать симметричными алгоритмами, коих знает туеву хучу, практически ничем не ограниченные тонны информации. Так в чём же фишка?

Фишка, собственно, в асимметричности RSA. То есть, в данном случае не нужно никому передавать по защищённому каналу секрет для расшифровки. В наличии меется открытый ключ, который используется для шифрования и может быть известен неограниченному кругу лиц, а адресат расшифрует файл своим секретным закрытым ключом. Вернее, всё не совсем так. Даже совсем не так. Во-первых, открытым ключом никто сами данные шифровать не будет. Во-вторых, шифровать симметричным алгоритмом всё равно придётся. «Нувыпонели, да?» Это я сейчас пересказываю принцип работы PGP. В общем, те, кто понял, могут переходить прямо к следующему разделу, а всем остальным я предлагаю раскрыть тайну PGP.

А тут на самом деле всё просто. Берём байт 200 какого-нибудь случайного мусора, например, из /dev/random и говорим, что это наш «одноразовый сессионный ключ». Одноразовый, потому что он действительно будет использован только один раз, в данном конкретном случае. При этом его на самом деле никто не знает. То есть, он нигде не светится. Так вот. Берём этот ключ и шифруем на нём всё, что нам нужно. После этого начинается немного магии. Мы берём открытый ключ адресата и на нём шифруем сессионный ключ. Voilá! После этого можно подшить зашифрованный сессионный ключ к зашифрованным данным и отправлять это всё по любым каналам связи: всё равно никто ничего расшфровать не сможет.

На приёмной стороне происходит нечто подобное, но в обратном направлении. Сначала берём закрытый ключ адресата и расшифровываем им сессионный ключ. А после этого естественным образом сессионным ключом расшифровываем данные. Собственно, всё… Вся магия куда-то испарилась, как обычно… Ну а дабы окончательно разогнать остатки мистического огненного тумана, ниже даны команды для осуществления подобного безобразия дома. Для определённости условимся, что данные, подлежащие закрытию, находятся в файле data, сессионный ключ — в файле skey (да, да, я знаю, что так делать нельзя и всё такое, но это просто общая схема, в настоящем скрипте «всё по-другому»), а цифровая подпись — в файле signature. Также будем считать, что открытый ключ записан в файле rsa_key.pub, а закрытый — rsa_key.priv.

# Encryption:
openssl [здесь любимый алгоритм шифрования] -pass file:skey -in data -out data.encrypted
openssl rsautl -encrypt -pubin -inkey rsa_key.pub -in skey -out skey.encrypted
# Decryption
openssl rsautl -decrypt -inkey rsa_key.priv -in skey.encrypted -out skey
openssl [здесь любимый алгоритм шифрования] -d -pass file:skey -in data.encrypted -out data

Если хочется ещё и добавить цифровую подпись, это можно сделать таким образом:

openssl [здесь любмый хзш] -sign [ЗАКРЫТЫЙ ключ ОТПРАВИТЕЛЯ] -out signature -binary data

Проверять, соответственно, так:

openssl [здесь любмый хзш] -verify [ОТКРЫТЫЙ ключ ОТПРАВИТЕЛЯ] -signature signature data

Кстати, обратите внимание на то, что для шифрования используются ключи адресата, а для подписи — отправителя.

Собственно, скрипт

Реализация указанной идеи с помощью костылей shell и openssl повлекла за собой некоторое количество ограничений, о которых необходимо сказать сразу же. Из самого названия модуля rsautl легко можно сделать вывод, что использоваться будут только RSA-ключи. Это не самый удобный вариант, поскольку ssh-keygen умеет генерить не только RSA, но и DSA, а также ключи на основе эллиптических кривых, как, например, ECDSA и ED25519. И этот факт нужно учитывать, если всё-таки захочется шифровать файлы столь извращённым способом. В отношении подписи ограничения не столь суровы: не поддержвается только ED25519.

А собственно скрипт находится в репе на гитхабе. Ничего сверхъестественного, всё достаточно прозрачно и понятно. Если что-то всё-таки непонятно, можно запустить эту штуку с ключом --help, почитать ReadMe или, в конце концов, заглянуть в исходный код. Собственно, ради этого он и находится в свободном доступе.

Всем спасибо, все свободны!


P.S.: В любом случае помните, что использованиие подобных костылей и велосипедов в области криптографии может когда-то серьёзно повредить вашему здоровью. В прямом смысле.

]]>
http://omsklug.com/2015/09/ssh-crypto-pgp-for-poors/feed/ 0
LUKS Header Backup Helper http://omsklug.com/2015/09/luks-header-backup-helper/ http://omsklug.com/2015/09/luks-header-backup-helper/#comments Sun, 13 Sep 2015 18:02:20 +0000 Shroom http://omsklug.com/?p=1908 .local p {text-align: justify!important; text-justify: inter-word!important;} .local a {color: rgb(16, 8, 96)!important;} .local a:visited {color: Gray!important;} .local a:hover {text-decoration: underline; color: Blue!important;} .local code {font-family: Monospace,Courier!important;}
Связка ключей

В свете последнего жестокого дизастера, своей циничной простотой потрясшего весь OmskLUG, я начал задумываться, как можно предотвратить потерю данных, связанную с потенцальным багами в LUKS. Результатом раздумий стала пара скриптов и, как побочный эффект, эта небольшая статья. Если вас не интересует эпистолярный жанр, можете перейти сразу к разделу со ссылкой на репозиторий.

Потеря — это всегда боль…

Потеря данных — не исключение. И неважно на самом деле, были ли эти данные рабочими базами с боевых серверов или же мегатоннами порнухи семейными фотографиями и личной перепиской. Важно то, что данные, которые не были сознательно удалены хозяином, обязаны оставаться доступными. А иногда даже и те, которые были удалены…

Особенно это касается систем хранения данных с шифрованием разделов. Просто потому, что зашифрованные данные особенно уязвимы к ошибкам. Да, безусловно, некоторые алгоритмы позволяют восстановить поток после сбойного блока. Но этот блок в любом случае будет безвозвратно потерян. И особенно это страшно, если речь идёт об ошибках в области заголовков LUKS. Ведь если ошибка появилась в том месте, где размещены слоты для ключей, это в контексте восстановленя данных практически равносильно низкоуровневому форматированию. Да, это очень удобно, когда срочно необходимо избавиться от информации. А когда эта самая информация, зашифрованная криптостойким алгоритмом с 256-битным ключом, позарез нужна для работы крупного предприятия? Что же делать в таких случаях?

Выход есть!

Во-первых, без паники! Если вы используете любое ПО для резервного копирования данных, в худшем случае вы потеряете время на развёртывании копии системы. Не имеет значения, bacula ли это будет, backuppc или голый rsync. Главное, что важные данные, которые требуются ежедневно, будут сохранены в надёжном месте. Безусловно, на другой машине. Желательно в другом здании. Ещё лучше — в другой стране в надёжном дата-центре.

«Но как же,» — спросите вы, — «это связано с LUKS?» Собственно, напрямую. Поскольку cryptsetup умеет делать бэкапы LUKS-заголовков и, соответственно, восстанавливать их. И что самое важное, восстановление заголовка из бэкапа может спасти диск даже в том случае, когда заголовок был просто полностью забит мусором из /dev/random. Да-да! Я лично проверял. Всё работает. Кстати, в связи с этим возникает некая идея «уничтожения» данных с последующим их «волшебным восстановлением»… Ну там если «маски-шоу»… Или если подзаработать захотелось… Гм… Впрочем, ближе к делу. Итак, вот они — две волшебные команды, которые спасут ваши данные/время/деньги/задницупрочие причиндалы.

Сделать бэкап LUKS-заголовка:

cryptsetup luksHeaderBackup <LUKS_DEVICE> --header-backup-file <header_file_name>

Восстановить LUKS-заголовок из бэкапа:

cryptsetup luksHeaderRestore <LUKS_DEVICE> --header-backup-file <header_file_name>

Да, есть ещё одна дополнительная возможность, которая считается весьма опасной. И правильно, в сущности, считается. Потому что это не что иное, как создание мастер-ключа. Удобно, на самом деле: можно на одном мастер-ключе наклепать шифрованных разделов и не бояться забыть пароли. Да вообще пароли можно не знать: нагенерить их автоматически из /dev/random и поскидывать на флэшки, которые вставлять по мере надобности при загрузке. В случае чего мастер-ключ позволит расшифровать раздел, даже без знания обычных ключей. Однако, очевидно, что это палка о двух концах: посеял файлик с мастер-ключом, и все соответствующие разделы можно считать скомпрометированными. Ну либо мёртвыми. И неизвестно ещё, что хуже. Кстати, вот команда для сдампливания мастер-ключа:

cryptsetup luksDump --dump-master-key <LUKS_DEVICE>

Да, вот так просто можно подарить кому-то все свои заботливо зашифрованные данные.

Ну так, собственно, к чему это я всё? К тому, что следующим логичным шагом в деле защиты данных будет

Автоматизация

Собственно, отсюда и начинается та самая реклама, про которую был соответствующий тэг.

Итак… [барабанная дробь] Встречайте! Скрипты для автоматического создания бэкапа заголовков LUKS и мастер-ключа! А на…зачем, собственно, нужны какие-то там непонятные скрипты, если всё делается буквально в полторы-две команды? Отличный вопрос!

  • Во-первых, теперь даже не нужно набирать эти полторы команды, достаточно одной.
  • Во-вторых, для файлов заголовка и мастер-ключа подсчитываются контрольные суммы по нескольким алгоритмам.
  • В-третьих, всё это добро архивируется и шифруется.
  • В-четвёртых, к шифрованному архиву по мере возможностей добавляются тома для восстановления. Чтобы в случае, если флэшку с бэкапом пробьёт шальной протон с высокой энергией, и банк в 128 кБ окажется мёртвым, то была бы возможность откачать этот архиив. А то кому нужен супер-пупер защищённый, вусмерть зашифрованный, но при этом битый бэкап, который невозможно восстановить?

Подробно работу со скриптами описывать не буду, поскольку всё есть в Readme. Однако, на всякий случай отмечу, что кроме coreutils и cryptsetup, скриптам для работы понадобится ещё и xxd. А если хочется ещё и создать тома для восстановления архива, то нужно будет поставить par2. Больше никаких сложностей возникнуть не должно.

Так что, если кто хочет дополнительно обезопасить свои данные и себя, заходите в репу на гитхабе (по ссылке выше).


P.S.: Этот пост посвящается памяти всех данных, безвозвратно утерянных вследствие обстоятельств непреодолимой силы или просто пользовательского/админского раздолбайства (что по сути одно и то же).

]]>
http://omsklug.com/2015/09/luks-header-backup-helper/feed/ 0
День свободы программного обеспечения 2015 http://omsklug.com/2015/08/sfd2015/ http://omsklug.com/2015/08/sfd2015/#comments Sun, 30 Aug 2015 17:21:05 +0000 linuxmasterz http://omsklug.com/?p=1883 Software Freedom Day LogoЧто такое?

День свободы программного обеспечения (Software Freedom Day, SFD, День СПО) — ежегодное всемирное мероприятие, посвященное свободному программному обеспечению и ПО с открытым исходным кодом. День свободы программного обеспечения — публичная образовательная инициатива, нацеленная на повышение уровня осведомленности о свободном программном обеспечении и его преимуществах, информирование о последних технологиях и тенденциях в свободном программном обеспечении.

Идея Дня свободы программного обеспечения пояилась в 2004 году и первый раз такой день был проведен 28 августа того же года. В Омске он проводится с 2007 г. обычно группой пользователей Linux.

Что там будет?

Доклады, в которых мы постараемся осветить использование свободного программного обеспечения в нашей с вами жизни. Вы сможете потестировать некоторые свободные программы, задать интересующие вас вопросы и получить или установить понравившиеся вам. Можно в непринуждённой обстановке проконсультироваться по вопросам ипользования свободного программного обеспечения.

Когда и где?

2015-09-19T15:00+0600 OMST (19 сентября 2015 года в три часа дня после обеда по омскому времени) в #Омском ITLoft (г. Омск, ул. Учебная, 83, второй этаж, каб. 212).

Ссылка на карту в OSM: http://www.openstreetmap.org/?mlat=54.97682&mlon=73.39135#map=19/54.97682/73.39135

Ссылка на карту в 2GIS: http://go.2gis.com/a0j12

Регистрация и что взять с собой?

Вы можете пройти добровольную регистрацию и ответить на небольшой опрос тут:

http://bit.ly/sfd2015omsk

- это позволит нам сделать мероприятие ещё интереснее.

С собой желательно взять тапочки, чтобы не ходить босиком по полу с ковролином. Можно взять свой ноутбук, компьютер, если вы всегда хотели свободное ПО, но стеснялись делать это сами.

Трансляция и контакты:

Если не сможете прийти, будет трансляция в Интернет всего действа вот тут: http://www.omsklug.com/tv. Если вы желаете активно участвовать, рассказать о своей истории успеха в свободном ПО пишите на post@omsklug.com или заходите в jabber-конференцию: omsklug@conference.jabber.ru

До встречи на SFD2015!

]]>
http://omsklug.com/2015/08/sfd2015/feed/ 1
Как собрать chatbot’а для Tox http://omsklug.com/2015/01/how-to-build-toxbot/ http://omsklug.com/2015/01/how-to-build-toxbot/#comments Sat, 24 Jan 2015 22:00:22 +0000 Shroom http://omsklug.com/?p=1777 .local p {text-align: justify!important; text-justify: inter-word!important;} .local a {color: rgb(16, 8, 96)!important;} .local a:visited {color: Gray!important;} .local a:hover {text-decoration: underline; color: Blue!important;} .local code {font-family: Monospace,Courier!important;}

В этой статье собраны некоторые подводные камни, обнаруженные лично автором при сборке чатбота для tox на Debian GNU/Linux 7 (Wheezy) для архитектуры amd64. Приведены способы обхода обнаруженных ошибок.

Подготовка

Для начала нам нужно установить некоторое количество пакетов с библиотеками и заголовочными файлами и вообще со средствами разработки (если таковых в системе ещё нет). Начнём с инструментария разработчика:

apt-get install build-essential libtool autotools-dev \
automake checkinstall check git yasm

Для удовлетворения сборочных зависимостей и для разных дополнительных плюшек типа аудио/видео, возможности запуска bootstrap-демона и хостинга ноды, ncurses-интерфейса поставим ещё несколько пакетов:

apt-get install libopus-dev libvpx-dev pkg-config \
libconfig-dev ncurses-dev

В принципе, эти рекомендации указаны на странице, посвящённой сборке toxcore. А дальше пойдут некоторые особенности… Кстати, я не рекомендую проходить данный квест, одновременно читая этот текст, поскольку стиль изложения материала довольно свободный и допускает возврат на несколько шагов назад и повтор действий с возможным улучшением стратегии. В общем, информация дана в чисто ознакомительных целях и ни в коей мере не является полноценным HowTo и, тем более, пошаговой инструкцией.

Итак, начнём, так сказать, с базовых вещей. Для шифрования нужна библиотека NaCl (старая и плохо портируемая, но быстрая) или sodium (новая, хорошо переносимая, с совместимым API, но несоколько медленнее). При этом существуют косяки как с первой, так и со второй библиотекой. Косяк с первой: нет объектников randombytes.o и cpucycles.o, которые требуются для сборки toxcore, но которые не являются частью NaCl [см. обсуждение подобной проблемы]. Косяк со второй — её тупо нет в репах для Wheezy (появилась только в Jessie), поэтому нужно сливать сырцы для Jessie и собирать (Естественно, для этого нужно добавить соответствующий репозиторий в /etc/apt/sources.list, настроить pinning, чтобы ненароком не обновить систему и т.п. Хотя можно, конечно, скачать нужный пакет прямо с сайта Debian). Соответственно, на старых системах (или если хочется «скорости»):

apt-get install libnacl-dev

А вообще NaCl лучше собирать из исходников, чтобы было откуда выцарапать randombytes.[c|o].

На новых системах (а также на Ubuntu, Mint, Arch, Gentoo и прочих, где всё новьё можно найти в стандартных репах/ppa/портах и пр.):

apt-get install libsodium-dev libsodium13

На старых же системах, где libsodium придётся брать в виде исходиков для Jessie, нужно дополнительно поставить pkg-config и dh-autoreconf, которые указаны в зависимостях для сборки. Впрочем, первый из них мыуже поставили в самом начале, поэтому остаётся только второй (Я лично ограничился сборкой с использованием NaCl, поэтому не могу сказать, какие глюки можно словить с sodium. Однако, смею предположить, что как минимум отсутствие randombytes.o породит похожие эффекты).

Сборка NaCl

Предположим, мы собрались использовать NaCl.

apt-get source nacl-tools

Из этого получатся пакеты для «-tools» и для «-dev». Здесь в зависимостях для сборки присутствует docbook-to-man, поэтому ставим и его тоже.

Сборка пакета: ничего страшного. Как обычно,

dpkg-buildpackage -b -us -uc

Но перед этим нужно в файлике debian/rules закомментировать строчку вида

rm -f $(CURDIR)/build/$(SHORTHOSTNAME)/lib/*.o

чтобы иметь возможность упаковать вместе с основной библиотекой и нужные нам объектники (ну или просто чтобы найти их после сборки). На самом деле по зрелом размышлении можно понять, что сборка пакета по сути не нужна. Можно ограничиться готовым пакетом из репы. Однако, при этом в любом случае нужно в верхнем каталоге дерева исходников libnacl выполнить магический скрипт ./do, который, собственно, и занимается сборкой либы. И уже после этого можно выдернуть и куда-нибудь сложить cpucycles.o и randombytes.o. Этот вариант будет даже более правильным с точки зрения поддержания чистоты пакетов.

Сборка ToxCore

Со стандартными либами покончено. можно сливать с гитхаба исподники toxcore:

git clone git://github.com/irungentoo/toxcore.git

После этого нужно перейти в каталог toxcore и фигачить далее по тексту руководства. Почти. Потому что, как обычно, появятся небольшие нюансы. Начнётся всё просто замечательно:

autoreconf -i

отработает без ошибок, поскольку здесь ломаться в принципе нечему. Зато следующий шаг

./configure --enable-nacl --enable-log --enable-ntox \
--enable-daemon --disable-testing

(в данном случае вся фишка в --enable-nacl; всё остальное — по желанию) закончится ошибкой. Нам скажут, что либа NaCl якобы не найдена, и предложат явно указать путь к ней. Хорошо, сделаем то, что просят, и даже больше, предполагая, что те самые cpucycles.o и randombytes.o лежат в одном из каталогов, известных линкеру (например, в /usr/lib рядом с libnacl.a):

./configure --enable-nacl --enable-log --enable-ntox \
--enable-daemon --disable-testing --with-nacl-libs=/usr/lib \
--with-nacl-headers=/usr/include/nacl

После того, как конфигуратор удовлетворится этой подсказкой, можно делать

make

Однако, сборка тоже не пройдёт с первого раза. Это, вероятно, связано как раз с ошибочным мнением разрабов toxcore о том, что randombytes.o принадлежит libnacl. Но это метафизика, а нам нужно что-нибудь уже собрать. Короче, процесс останавливается на линковке tox-bootstrapd с воплями о том, что в нескольких модулях найдены «undefined reference to ‘randombytes’». Хорошо, предоставим костыль в виде

make LIBS=''/usr/lib/randombytes.o''

после чего чудесным образом (Ну то есть сразу после ошибки запускаем «костыль» — и всё. Не нужно ничего нигде чистить, менять, копаться в файлах и др.пр.) дособерётся демон tox-bootstrapd (Естественно, если нет необходимости в этом функционале (а её в подавляющем большинстве случаев нет) и не был указан параметр --enable-daemon при вызове ./configure, то всё соберётся без проблем). После этого параноики могут проверить качество сборки, запустив

make check

(кстати, все тесты должны завершиться успешно), а все остальные могут сразу же приступить к сборке deb-пакета (ну или любого другого пакета на выбор) и его установке. Например, так:

sudo checkinstall -D make install

По умолчанию либы и бинарники будут установлены в /usr/local, поскольку мы не меняли эти пути в параметрах конфигуратора. Собственно, никто не мешает при вызове ./configure добавить параметр --prefix=/usr. Однако, это не является критичным для сборки бота.

Сборка ToxBot

Теперь, собственно, то, ради чего затевался весь этот сыр-бор. Сборка чат-бота.

Перед тем, как что-то собирать, это что-то нужно стянуть с гитхаба:

git clone git://github.com/JFreegman/ToxBot.git

Далее всё тривиально. Почти, опять же… Если взглянуть на руководство по установке, может возникнуть ложное чувство уверенности в своих силах и полного контроля над происходящим. В самом-то деле, что уж, так сложно единственную команду make запустить что ли?! Однако, в реальности всё не так, как на самом деле… Наверняка сборка загнётся опять же на этапе линковки, и линкер будет орать, что нашёл «undefined reference to `clock_gettime’» где-то в недрах toxcore. В принципе, он прав, потому что эта функция находится в библиотеке librt, а про неё линкеру никто ничего не рассказал. Поэтому придётся лезть в Makefile и менять строчку

LDFLAGS = $(shell pkg-config --libs $(LIBS))

на почти такую же, только с упоминанием нужной библиотеки:

LDFLAGS = -lrt $(shell pkg-config --libs $(LIBS))

После этого всё должно пройти без ошибок. Результат сборки — свежий бинарник toxbot, который не требует настройки и заводится с полпинка. Дальнейшие вопросы вроде «что делать, чтобы он признал хозяина?» и «как пробиться через заботливо закрытый файрвол?» автор статьи оставляет в качестве упражнения для читателя. Поверьте, это абсолютно несложно и даже описано в документации.


Спасибо за внимание!

Как обычно, полный текст этой статьи можно совершенно бесплатно, без регистрации, без смс свободно скачать отсюда в формате PDF.

]]>
http://omsklug.com/2015/01/how-to-build-toxbot/feed/ 0
Software Freedom Day 2014 в Омске анонс http://omsklug.com/2014/09/sfd2014announce/ http://omsklug.com/2014/09/sfd2014announce/#comments Mon, 15 Sep 2014 14:50:42 +0000 linuxmasterz http://omsklug.com/?p=1749 Software Freedom Day Logo2014-10-04T14:00+0700 OMST (четвёртого октября 2014 года в 2 часа дня после обеда по омскому времени) в 301 аудитории первого корпуса Омского государственного университета им. Ф.М. Достоевского (г. Омск, пр. Мира, д. 55А) пройдёт международный День свободы программного обеспечения (Software Freedom Day). Да, да, мы знаем, что он пройдёт 2014-09-20 по всему миру, но… В общем, мы слоупоки, извините. Если не сможете прийти, будет трансляция в Интернет всего действа вот тут: http://www.omsklug.com/tv. Вот карта для тех, кто ещё умеет понимать такие вещи:

карта подходов к первому корпусу ОмГУ © Участники OpenStreetMap

РЕГИСТРАЦИЯ

Просьба, в случае участия, зарегистрироваться вот здесь:

http://bit.ly/sfd2014omsk

Мы просто хотим знать, сколько вас будет, да и охрана ОмГУ будет рада.

ДОКЛАДЫ

Планируются доклады на следующие темы:

  • Итоги свободного программного обеспечения в 2014 (Алексей Тараканов)
  • История успеха: Puppet (Александр Рак)
  • BASH tips & tricks (Александр Матюхин)
  • Астериск: фреймворк для построения телефонии (Станислав Емец)

Честно говоря, это ещё и обычный Linux Install Fest, когда можно установить и получить безвозмездно понравившийся дистрибутив свободного программного обеспечения с помощью активистов OmskLUG (омских линуксоидов) — не только GNU/Linux, но и иное свободное ПО. Можно непринуждённо проконсультироваться по тому или иному вопросу о свободном программном обеспечении. Не забываем, что, как обычно, планируется отвязная криптовечеринка (KSP), поэтому готовьте свои PGP-ключи с сильной криптографией.

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

ПОМОЩЬ

Помогите хотя бы в распространении информации о мероприятии, отправьте ссылку сюда на сайт своим знакомым через ваши любимые социальные сети, микроблоги и прочие вебдваноли. Распечатайте это объявление: http://bit.ly/sfd2014omskannounce, поместите на достаточно видное место у себя в курилке на работе, в подъезде любимой девушки, на заднике вашего мотоцикла или яхты. Мы были бы рады вашему рвению к продвижению свободного программного обеспечения, ведь эти ваши маленькие шажки неотвратимо делают свободное программное обеспечение лучше.

ССЫЛКИ

http://bit.ly/sfd2014omskannounce – ссылка на объявление о мероприятии

http://bit.ly/sfd2014omskannouncev – ссылка на объявление о мероприятии (вертикальное)

http://bit.ly/sfd2014omsk – ссылка на форму регистрации на мероприятие

Хештег для Twitter и для других мест, где принимают хештеги: #sfd2014omsk

До встречи на SFD 2014!

]]>
http://omsklug.com/2014/09/sfd2014announce/feed/ 1