вторник, 25 августа 2015 г.

Docker Storage Driver on loop device

После очередного обновления докера получил конфигурацию хранилища которая как капуста, сто одежек и все без застежек.

Докер создал файлы в /var/lib/docker, подключил их как loop девайсы, и на них развернул lvm пул, который выдает контейнерам.

Оно даже работает, и собственно без всяких усилий, вот так выглядит lsblk:


Но производительность при этом такая, что мягко говоря, сразу заметишь.

У меня там была задачка по вставке многих позиций в mysql, и я такого медленного ещё никогда не видел.

Чиним:

1. Сносим /var/lib/docker
2. Создаем lvm раздел, у меня это ddata и dmeta
3. Вписываем DOCKER_OPTS="--storage-opt dm.datadev=/dev/mapper/data-ddata --storage-opt dm.metadatadev=/dev/mapper/data-dmeta"

4. Всё перезапускаем

получается так:


Разница по io как минимум вдвое сразу.

пятница, 21 августа 2015 г.

Странное обновления docker

Обновил тут docker до версии 1.6.2 и порадовался что только на тестовых машинах.

Ну ладно, они поменяли там aufs в папках на реализацию через dm.

Но зачем при этом терять все images и контейнеры на хосте, это мне не понять.

Неужели скопировать/преобразовать нельзя было?

Нагуглил вот тут переключатели различные.
Поиграюсь вскоре.

Но в целом эти loop девайсы не порадовали.

Безо всяких тестов видно что как минимум не ускорилось i/o.

Да и вот такая порнография в выводе:
не радует.

А дальше то ещё веселее.
Как вам вот такой скриншот:


поломали push.

Прямо взаимоисключающие параметры. login succeeded && Auth is required.

Как такое возможно, что в версии с индексом .2, в дебиановском репе, никто просто push не попробовал для теста даже сделать?

Просто удивительно.


Ох. истину вам говорю, налетит земля на небесную ось.

понедельник, 20 июля 2015 г.

Пару слов про ansible

Чем больше погружаюсь в ansible, тем меньше и меньше восторгов.

Поначалу, после puppet, казалось прямо красотой нечеловеческой.

Но как то, копится, копится, мелочи всякие, и отпускает радость прямо совсем.

Последнее время меня стало раздражать качество модулей.

Т.е. не безымянных ролей-рецептов с гитхаба, к которым претензий быть не может, а к самым таким настоящим core модулям, типа apt.

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

Пример:

aptitude, карл!

Зачем он вдруг? Я не знаю.

В роли, это вот так:


Core модуль.

Пичаль.


среда, 24 июня 2015 г.

eMachines - скупой платит дважды

Самая неудачная моя покупка вычислительной техники — ноутбук eMachines d525.

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

Ну то что блутуза в нём нет, я знал.

Но что кто-то сэкономит три копейки на микрофоне я не рассчитывал.

Хочешь позвонить? Иди ищи внешний микрофон из-за каких то жадных клоунов сэкономивших копейку.

И так во всём. Ну умершая за полгода батарея, ладно, расходник.

Греется так, что подходит для жарки.

Недружественность Linux - отдельная песня.

Опять я проковырялс полчаса вспоминая acpi_os=Linux для вписывания в grub.

четверг, 7 мая 2015 г.

awesome-dm и xserver заметка для себя.

Периодично, при обновлении пакетов системы, в awesome-dm случается какой то конфликт с xkb или ещё кем то, и хоткеи начинают работать только в английской раскладке.

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

Проблема известная, гуглится легко, решается легко. Но я повторюсь.

Я натыкался на длинный тред, где разработчики awesome-dm и иксов валили проблему друг на друга, году кажется в 2011.

До сих пор не могут договориться.

Блеск и нищета опенсорса.

Обходное решение, в файле
/usr/share/X11/xkb/compat/basic

закомментировать строчки
group 2 = AltGr;


 Не знаю кто в этой ситуации из команд неправ, но мне очевидно что лучше бы awesome-dm прогнулся и сделали workaround у себя.


четверг, 16 апреля 2015 г.

Поймал забавную ошибку при построении docker image

Наткнулся на забавную проблему, захотелось поделиться решением.

Я последнее время полюбил для публичных образов докера строить их не у себя а в облаке docker hub.

Идея простая, делаешь dockerfile публичным, заливаешь его в github, и настраиваешь автоматизированную сборку, при пуше коммитов в репозиторий оно само пересоберется.

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

Но вчера, один из моих образов отказался собираться напрочь.

Получаю вот такое сообщение:

Таймаут и всё тут. Ну, раз, я подумал что сбой в системе сборки, второй раз. Руками подергал тригер сборочный, не проходит и всё.

Хотел уж баг-репорт отсылать в докер хаб, но решил таки попробовать собрать локально.

И конечно ж:

Пакет mysql захотел получить пароль пользователя с консоли.

И висит так бесконечно, до таймаута.

Решение,запускать так:
RUN DEBIAN_FRONTEND=noninteractive apt-get install

Эту мелочь я всё время забываю.

Новый pkg на freebsd



Прочитал новость:
Разработчики FreeBSD представили релиз пакетного менеджера Pkg 1.5

У меня фрях в эксплуатации много, и в целом я этой новости рад.

Порты и вечные их пересборки меня давно уж утомили.

Ну иногда, разок, для особых опций можно,но постоянно — надоедает.


Особенно, теперь, когда из за какой то загадочной криворукости летом 2014 намеренно сломали make.

Я с большим интересом слежу за развитием pkg по вышеуказанным причинам.

Он уже действительно быстр. Просто освежающе быстр, когда видишь, начинаешь удивляться, эмм, а чем же тогда apt занят?

Но проблем ещё полно.

Я постоянно наталкиваюсь на такой сценарий, когда внезапно в репозитории нужного пакета нет, и ты вынужден поставить его из портов, и вдруг увидеть:




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

Одна только вероятность этого заставляет целиком откатится обратно на установку из портов, что печалит.

Но прогресс заметен, надежда есть.

После pkg останется лишь дождаться человеческого jail в стиле docker.


понедельник, 13 апреля 2015 г.

Улучшаем переключатели pulseaudio в awesome-dm

Регулятор громкостей различных наушников у меня уже есть на панели awesome-dm.

Выглядит аскетично:

Как его сделать, писал вот тут.

Теперь захотелось к нему добавить мгновенное переключение вывода звука.

Не просто set-default, а еще и  всё что уже проигрывается переносить в нужный вывод.

Для этого будем использовать вот такой скрипт:
#!/bin/bash
   
if [ -z "$1" ]; then          
    echo "Usage: $0 <sinkId/sinkName>" >&2
    echo "Valid sinks:" >&2
    pactl list short sinks >&2
    exit 1
fi 
   
newSink="$1"
   
pactl list short sink-inputs|while read stream; do
    streamId=$(echo $stream|cut '-d ' -f1)
    if [ "$streamId" -gt 1 ]
    then
        echo "moving stream $streamId"
        pactl move-sink-input "$streamId" "$newSink"
    fi
done
Забираем всё что проигрывается,
потоки номер 0 и 1 пропускаю потому, что они у меня виртуальные, там находится remapped sink,
и через move-sink-input перенаправляю в нужный источник.

Впишем вызов этого скрипта в pulseaudio.lua
function SwitchTo(i)
    local f = io.popen("pa_switch.sh " .. i )
    local v = f:read()
    f:close()
end

И навешаем левый клик по регулятору громкости на вызов этой функции.
     volumewidget0:buttons(awful.util.table.join(
      awful.button({ }, 1, function() pulseaudio.SwitchTo(1); end),
Можно улучшить избавившись от констант номеров звуковых карт, но у меня они почему то не меняются,  и я ленюсь.

Теперь что бы перенести все звуки на конкретные наушники/колонки нужно щелкнуть по нужному регулятору громкости.



четверг, 2 апреля 2015 г.

Прекрасное средство — aptly

Любой системный администратор или, модный ныне, девопс, проходит множество этапов роста мастерства, и по моим личным наблюдениям, один из хороших признаков этого отношение к версиям софта.

Свежий, не битый, полный сил и здоровья админ с удовольствием ставит libfoobar-0.11.beta в продакшен в ту же ночь как она релизится. И с большим упоением следит за changelog выискивая там что-нибудь новенького.


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

В некоторых случаях, если команда девелоперов или менеджеров погоняющая такого админа слаба, софт перестает обновляться «навсегда». Работает — отойди.

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

Но, за последнее время я заметил, один небольшой, но новый нюанс в этом движении.

С современным развитием виртуализации, включая контейнерную, с современным средствами подготовки и управления образов, разнообразными packer, ansible и т.д. на одно из первых мест, для меня, выходит возможность гарантированной возможности получить в точности тот же образ что и на другом железе/облаке/где-либо ещё.

Средств для этого много, но был у меня  один «непокрытый» момент.
Я как-то очень уж смело полагался на содержимое внешних репозиториев debian.

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

Ну, и как водится однажды оно выстрелило.
Ничего особенно страшного не произошло, считаем просто вежливым напоминанием судьбы.

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

Оказалось, что всё уже придумано за нас: http://www.aptly.info/, Автор - Andrey Smirnov.

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

Рекомендую!


воскресенье, 11 января 2015 г.

Очередной привет дебиану от systemd.

Я привык debian на своей рабочей машине обновлять пару раз в месяц через dist-upgrade.

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

Но, прогресс идёт.
Теперь оно при обновлении умеет ломаться так, что ни туда, ни сюда, никуда.

dist-upgrade падает, просит -f  install для исправления, а тот выдаёт вот такую вот портянку:

Чтение списков пакетов… Готово
Построение дерева зависимостей      
Чтение информации о состоянии… Готово
Исправление зависимостей… Готово
Будут установлены следующие дополнительные пакеты:
  libpam-systemd
Пакеты, которые будут обновлены:
  libpam-systemd
обновлено 1, установлено 0 новых пакетов, для удаления отмечено 0 пакетов, и 201 пакетов не обновлено.
не установлено до конца или удалено 11 пакетов.
Необходимо скачать 0 B/120 kB архивов.
После данной операции, объём занятого дискового пространства уменьшится на 4 096 B.
Хотите продолжить? [Д/н]
Чтение журнала изменений... Выполнено                
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: проблемы зависимостей не позволяют выполнить обработку триггеров dbus:
 dbus зависит от libdbus-1-3 (>= 1.7.6), однако:
  Пакет libdbus-1-3:amd64 пока не настроен.

dpkg: ошибка при обработке пакета dbus (--configure):
 проблемы зависимостей — оставляем триггеры не обработанными
dpkg: слишком много ошибок — останавливаемся
При обработке следующих пакетов произошли ошибки:
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
 dbus
Обработка остановлена из-за слишком большого количества ошибок.
E: Sub-process /usr/bin/dpkg returned an error code (1)
systemd уже близок. Уже тут.

Надо менять свои привычки. Какие такие обновления? Работает хоть как-то?
И то хлеб, сплюнь и не трогай.

Конечно ж, это частная и мелкая проблема, но однако
а) оцените портянку? Зачем оно 130 раз одно и тоже апгрейдит? Что вообще можно понять из этого бреда.
б) раньше то однако не случалось. Началось с приходом счастья от systemd.

Очень, очень надеюсь, что или у devuan всё получится, или ещё будут успешные форки.



четверг, 25 декабря 2014 г.

Закончил курс по haskell. Свежие впечатления.

Закончил курс
FP101x Introduction to Functional Programming
на edx.com

Определенно вхожу во вкус функциональщины всё больше и больше.

Но, я внезапно осознал, что  на примитивном уровне все эти фильтры и мапы были у меня и  в perl всегда, и я их всегда использовал.

Другое дело, что конечно, ребята наработали уже просто огромную базу. Начинаешь понимать. что тут дело на в мапах и не в high order functions — этим как раз никого не удивишь. А скорее в общем объеме. Ум за разум заходит как увидишь готовое решение со всеми этими моноидами когда закончишь лабу. А по отдельности, пока пишешь - очень даже ничего. Хороший метод декомпозиции задач.

Но я хотел написать не про собственно функциональщину, а про курс.

Оставил он смешанные чувства.

Плюсы:
  1. Очень интересный, вряд-ли его можно назвать "начальным", но мне как то в уровень попало. И не скучно и не сильно тяжело.
  2. Лекции мне понравились, все за исключением серии про монады. Чего там хотели добиться не понимаю. Явно что то перемудрили.
  3. Лабы - крутые реально, клево так придумали, что дают задание. которое ты выполняешь. что то высчитываешь и заливаешь им на проверку не саму прогу а ответ какой то зашифрованной ими функции. Типа такого:
    Крутая идея и крутая реализация, просто молодцы. И руками такое не посчитаешь - приходится прогу написать, и в тоже время никакой мороки с тестированием.
    И сами задания — интересные. Прямо хочется решить.
  4. Определенно хочется продолжать, было впечатление что окончилось внезапно. Это я считаю плюс.
Минусы: 


  1. Главный основной минус это задания послед лекций  (homework), на мой вкус — просто отвратительно. Что тестирует вот такой тест:

    В лучшем случае моё зрение. Но точно не о программировании он. Но это ягодки. Как вам такой:
    Бредятина на 10 экранов которую надо в уме распарсить и найти правильное решение из 4, а отличаются они парой символов.

    Такая ненависть у меня была к этим заданиям, что я просто даже заставить себя не мог эту гадость читать, в лучшем случае просто тыкал наугад, и кажется ни разу не попал.
    Причем задания эти неоднородные, после некоторых лекций нормальные а после других по 15 пунктов такого дерьмища.

    Это хорошо видно на графике моей успеваемости:
    Те homework где прогресс по 5% это они и есть. Меня это настолько раздражало что только из за этих заданий хотел бросить курс многократно.
  2. Jam sessions ну очень странные, я их записал в простую потерю времени. Ни идеи этого не понял, ничего полезного не вынес. Какая то ерунда.
  3. Мне не показалось что из этого курса можно что то целостное получить. Так, вариации на тему крутых хаскельных штучек, привлечь внимание.

Я так понял это первый запуск этого курса, можно простить некоторые шероховатости с заданиями ( а лучше их совсем выкинуть).

Плюсов очевидно больше чем минусов — думаю можно советовать курс всем заинтересованным функциональщиной.

    воскресенье, 21 декабря 2014 г.

    Vagrant docker provider — как средство оркестрации.

    Короткий пост про признание ошибок.

    Больше месяца в черновиках у меня висел пост о том, как я пытаюсь использовать
    vagrant --provider=docker
    для управления многими связанными контейнерами docker.

    Что б так сказать запустить в нужном порядке,  связать, настроить и т.д. То, что хочется назвать orchestration.

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

    Как свинью стричь: визга много - шерсти мало.

    У меня в данной задаче, оркестрация такая, ограниченная, всё на одном хосте, контейнеров меньше двух десятков, связаны не то что бы сильно, всё линейно. Но даже тут, или vagrant действительно не подходит, либо я ему.

    Поищу другой инструмент.




    четверг, 18 декабря 2014 г.

    Подсветка ruby в vim

    Пришлось тут немного на ruby писать.

    Ну как минимум, плюс из этого что перестал на  конфиг файлы Vagrant смотреть с отвращением.

    Не то что б полюбил, но свыкся.

    Посмотрите на картинку к посту. Видите что последние два end окрашены по разному? Один в цвета if — потому что к нему относится, второй в цвета def.

    Я и не знал что vim так умеет. да ещё и из коробки.  Очень удивился.

    И в целом, как  к языку к Ruby особых претензий нет, perl - perl-ом,  с претензиями на оригинальность.

    Но вот gem-ы их, и в целом инфраструктура — вечный адъ какой то. Не помню случая что б "просто работало".

    среда, 17 декабря 2014 г.

    ООП в контейнерах docker

    Каждая новая команда изменяющая состояние контейнера в Dockerfile создает новый образ диска- image.

    Посмотреть их можно через docker images. Мне очень нравится ключ --tree к ней, но не понимаю почему они её пометили как depricated.

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

    К примеру два контейнера с такими Dockerfile:
    FROM debian:testing
    RUN DEBIAN_FRONTEND=noninteractive apt-get install -y ssmtp
    RUN DEBIAN_FRONTEND=noninteractive apt-get install -y net-tools
    и второй с другим порядком команд
    FROM debian:testing
    RUN DEBIAN_FRONTEND=noninteractive apt-get install -y net-tools
    RUN DEBIAN_FRONTEND=noninteractive apt-get install -y ssmtp
    Построят 4 разных образа, два промежуточных, два конечных, плюс debian-testing.

    Но функционал то будет одинаков - фактически пустая потеря места, и лишняя сложность.

    Вот так выглядела часть дерева моих образов docker

     Один общий далекий предок debian/testing и затем огромная куча разных промежуточных образов.

    Рефакторим это. Выделим общие настройки и софт в base образ, и унаследуем остальные от него.

    Теперь дерево выглядит так:

    Не идеально, но лучше.

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

    Если вам не нравится большие развесистые деревья можно в dockerfile объединить команды в одну
    RUN command1 && command2
    тогда на две команды будет только один образ.
    К реальному уменьшению потребления дискового пространства это вряд-ли приведет, но дерево будет аккуратнее.
    Я так иногда делаю с теми образами которые уже не меняю.
    Но для часто меняемых и перестраиваемых предпочитаю иметь команды отдельными строками.
    Docker умеет кешировать, и не перестраивать неизменяемые состояния, что очень удобно.

    Автоматизируем написание хороших сообщений к коммитам git

    Все знают как сложно написать хороший commit message.

    К нему предъявляются особые требования:
    -  быть кратким
    -  правильно оформленным
    -  придерживаться определенного стиля

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

    Ну вот пример. Google по фразе good commit message показывает
    Результатов: примерно 12 000 000 (0,35 сек.)

    Не шутки.

    Но я нашел способ решить эту проблему. Эта деятельность легко автоматизируется.

    Возьмем, в помощь mojolicious, ну как же без duct-tape. Если у вас его еще нет, ставьте:

      apt-get install libmojolicious-perl
    Вторым инструментом будет вот этот замечательный сайт  он анализиует ваши изменения и автоматически предлагает отличный текст.

    Осталось лишь прописать в ваш шел, вот такой вот алиас

     git commit -a -m "`perl -Mojo -E "say g('http://whatthecommit.com/')->dom->at('div#content p')->text"`"

    ну например на git-auto, или что вам там нравится


    Всё, одной проблемой в жизни меньше.

    вторник, 16 декабря 2014 г.

    Как docker делает админов ленивыми.

    Понадобилось на днях отдельно взятый парк машин просканировать на уязвимости и попробовать к ним разные rootkit применить.

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

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

    Глобально путей проверить это два:
    - или по базе установленных пакетов проверить базы аудита
    - или самому атаковать снаружи.

    Первый путь мне нравится меньше - машины разнотипные, да и что мне переживать за уязвимость в установленном пакете, если он  например не используется.

    Пошел по второму пути. Ну не руками же такое делать?

    Есть некий framework metasploit, содержащий базу експлоитов, и умеющий их применять.

    Немного гемморойный в установке, ну ничего такого страшного.
    Postgres то сё, сборка ручками.
    Поставил, побаловался - надоело быстро.

    Сразу стало понятно, почему это именно фреймворк а не готовое решение.

    Погуглил, нашел armitage - оболочка поверх этого фреймворка автоматизирующая рутину.

    И тут же, в этом же запросе в google мне попался Dockerfile для него.

    Ну,  даже интересно стало, неужели счастье близко.
    И правда, docker run - и всё, сразу работает, само расправилось и с постгрей и с metasploit , поставило и настроило всё,  и выдало поверх этого мне vnc — заходи и сразу работай.

    Удобно? Да, прямо очень. Особенно для моей разовой задачи, поставил - просканировал - снёс - забыл.

    Но, ммм, если подумать. Не пришли ли мы в c:\program files\ схему?
    Точнее в комбинацию этого и каких то fat jar?

    Ну для разовой задачи, вопросов нет - удобно и может в чём то лучше даже, не насилуем пакетный менеджер, не оставляем следов в host системе.

    Но ведь если инструментом можно пользоваться неправильно - им будут.
    И тут docker предоставляет целую кучу возможностей.
    Думаю, скоро набегут на него разные проприетарщики, 1с-еры и прочие, кому так будет проще.

    Большая тема для раздумий.