вторник, 17 мая 2016 г.

Настройка SSH jump host

Наткнулся на замечательный пример универсальной настройки ssh jump host в wiki gentoo:

Host *+*
  ProxyCommand ssh $(echo %h | sed 's/+[^+]*$//;s/\([^+%%]*\)%%\([^+]*\)$/\2 -l \1/;s/:/ -p /') exec nc -w 120 $(echo %h | sed 's/^.*+//;/:/!s/$/ %p/;s/:/ /')

Теперь чтобы зайти на домашний ноутбук достаточно скомандовать:

$ ssh andrey@public_host+home_gateway+laptop_host

До этого у меня была статичная конфигурация для public_host, home_gateway и каждого домашнего устройства, что довольно неудобно.

вторник, 3 мая 2016 г.

Сломался owncloud 9.0.1 после обновления php до 7.0.6

После обновления PHP с 7.0.5 до 7.0.6 сломался owncloud 9.0.1. При попытке залогиниться предлагает логиниться еще раз и так по кругу. Никаких ошибок или предупреждений при этом не выдает.

В логе data/owncloud.log ничего нет. Чтобы выяснить что происходит при логине включил отладку в config/config.php

<?php
$CONFIG = array (
...
  'debug' => true,
  'loglevel' => 0,
);

Но ничего интересного в лог не записалось. Все заработало после отката версии PHP до 7.0.5.

На форуме owncloud нашлось обсуждение аналогичной проблемы и ссылка на пул реквест, который решает проблему. Патч для owncloud который установлен официальных пакетов выглядит так:

--- lib/private/appframework/http/request.php.orig      2016-05-03 13:19:36.893158727 +0300
+++ lib/private/appframework/http/request.php   2016-05-03 13:20:13.750028337 +0300
@@ -264,6 +264,9 @@
         * @return bool
         */
        public function __isset($name) {
+               if (in_array($name, $this->allowedKeys, true)) {
+                       return true;
+               }
                return isset($this->items['parameters'][$name]);
        }

Применить патч можно так:

$ cd /var/www/owncloud/
$ sudo patch -p0 < /tmp/owncloud-9.0.1-php-7.0.6-login.patch

воскресенье, 24 апреля 2016 г.

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, но их выложу позже.

суббота, 23 апреля 2016 г.

Добавил поддержку 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 и теперь предупреждения нет.

пятница, 15 апреля 2016 г.

Сломался логин в домен после обновления 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.

понедельник, 11 апреля 2016 г.

Настройка 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.

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

четверг, 7 апреля 2016 г.

Проблемы с 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. Так что похоже проблема не только у меня.

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