Midnight Commander 4.8.16 для ARM

Обновил пакеты midnight commander для архитектур ARM (armel, armhf и arm64). Сейчас в моем репозитории следующий расклад:

• Debian Wheezy (armel, armhf)
• Debian Jessie (armel, armhf, arm64)
• Ubuntu Precise (armel, armhf)
• Ubuntu Trusty (armhf, arm64)

Еще есть пакеты для raspbian, но их выложу позже.

Добавил поддержку Ubuntu Xenial в мой репозиторий

Добавил поддержку Ubuntu Xenial в мой репозиторий. Сейчас там только пакеты для midnight commander (4.8.16 и последняя сборка из master ветки).

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

W: http://tataranovich.com/debian/dists/xenial/Release.gpg: Signature by key 4A49274193083320450B7E4D836CC41976FB442E uses weak digest algorithm (SHA1)

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

UPDATE: Проблема была не ключе, а в алгоритме SHA1, который по-умолчанию использует gpg при подписи Release файлов в репозитарии. Добавил --digest-algo SHA512 в опции gpg и теперь предупреждения нет.

Сломался логин в домен после обновления samba в debian wheezy

Не спешите обновлять samba до 2:3.6.6-6+deb7u9 в Debian Wheezy. Эта версия содержит портированное исправление уязвимости badlock, но после обновления перестает работать логин в домен: "The trust relationship between this workstation and the primary domain failed". В интернете можно найти несколько упоминаний этой проблемы (раз, два), но рабочего решения я пока не видел.

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

В лог samba пишутся ошибки вида:

rpc_server/netlogon/srv_netlog_nt.c:976(_netr_ServerAuthenticate3)
  _netr_ServerAuthenticate3: netlogon_creds_server_check failed. Rejecting auth request from client WORKSTATION machine account WORKSTATION$

Меня смущает тот факт, что подобные ошибки были задолго до обновления samba, но логиниться в домен не мешали.

В качестве временного решения откатил samba до 2:3.6.6-6+deb7u7.

Настройка SPF и DKIM для MailChimp

MailChimp - популярный сервис среди маркетологов. Если вам нужно настроить аутентификацию MailChimp для своего домена (пусть для примера домен будет example.com, а адрес от которого идет рассылка - john.doe@example.com), то вам нужно настроить SPF и DKIM у домена, чтобы сервера MailChimp считались авторизованными для отправки почты от имени example.com.

Сначала нужно авторизовать сам ящик john.doe@example.com в MailChimp. Процесс описан тут.

Теперь в настройках DNS для домена example.com нужно:

• добавить в TXT запись (которая описывает SPF) для example.com "include:servers.mcsv.net"
• создать CNAME запись k1._domainkey.example.com. указывающую на dkim.mcsv.net.

В итоге записи будут выглядеть примерно так (будет отличаться в зависимости от текущих настроек SPF):

example.com.  IN  TXT  "v=spf1 a mx include:servers.mcsv.net ~all"
k1._domainkey.example.com.  IN  CNAME  dkim.mcsv.net.

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

Проблемы с Google public DNS

Разобрался с "проблемой" в производительности сайта, мониторинг которого выполняет Zabbix. Проблема выглядела как резкие отклонения response time в графиках проверок.

Включил в Nginx логирование времени обработки запроса. Но никакой связи с пиками на графике в логе Nginx не заметил - время ответа сайта не меняется и находится в районе 150-200 ms. Следовательно проблема вовсе не в сайте.

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

Zabbix и сайт находятся в одной локальной сети, следовательно скорость соединения не может приводить к подобным отклонениям. Что может быть причиной проблемы если это не сайт и не сеть? Остается DNS и zabbix как раз использует google public dns (8.8.8.8, 8.8.4.4).

Для проверки прописываю в /etc/hosts нужные хосты и вуаля - проблема исчезает на глазах.

В процессе нашел ссылку где также указывают на проблемы с Google public DNS. Так что похоже проблема не только у меня.

В общем еще одно подтверждение правилу - если сервис не контролируется тобой, то подвести он может в любой момент.

Протухли ключи на смарт-карте

Довольно долго не пользовался GnuPG и при попытке подписать письмо в Claws-Mail получил ошибку:

Сначала подумал что какая-то проблема со смарт-картой, но gpg2 --card-status правильно определил карту.

Попробовал подписать обычный файл и увидел подробности ошибки.

% gpg2 --output test.txt.asc -ba test.txt
gpg: secret key parts are not available
gpg: no default secret key: Unusable secret key
gpg: signing failed: Unusable secret key

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

Пакеты openfire 4.0.2 для Debian не работают с java 7

Попробовал обновить openfire с 4.0.1 до 4.0.2 в Debian Wheezy. Обновление проходит без проблем, но клиенты не могут подключиться к серверу.

В логе openfire следующее:

2016.04.01 14:35:18 org.jivesoftware.openfire.nio.ConnectionHandler - Closing connection due to exception in session: (0x00000002: nio socket, server, /x.x.x.x:50558 => /y.y.y.y:5222)
java.lang.NoSuchMethodError: java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
at org.jivesoftware.openfire.roster.Roster.broadcastPresence(Roster.java:628)

[пропущен кусок лога]

at java.lang.Thread.run(Thread.java:745)

В багтрекере openfire есть несколько записей на эту тему (OF-965, OF-1115, OF-1116). Причина в том, что openfire 4.0.2 скомпилирован с использованием java 8.x, а в Wheezy доступна только java 7.x. Тут более детально описан источник несовместимости.

Я могу понять позицию разработчиков openfire на счет EOL java 7, но в этом случае нужно изменить зависимости пакета и обновить документацию - тогда никаких вопросов не будет. А пока же заявлена поддержка java 7, но работать будет только с java 8.

UPDATE: Собрал openjdk-8 под Debian Wheezy. Установил на тестовый сервер и попробовал удалить старый openjdk-7 - фиг вам. Оказывается он еще и в зависимостях пакета прибит гвоздями:

$ apt-cache show openfire | grep Depends
Pre-Depends: openjdk-7-jre-headless | openjdk-7-jre | oracle-java7-jre

Перепаковывать лениво - остановил openfire и прописал в /etc/default/openfire нужный JAVA_HOME. После этого все заработало.