понедельник, 30 января 2012 г.

Потеря сообщений в jabber при проблемах с сетью

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

Один из вариантов решения - тонкая настройка keep-alive соединений на сервере, чтобы "отстреливание" клиента происходило быстрее. TCP Keepalive HOWTO - настройка tcp keep-alive в Linux. Чтобы не менять настройки всего сервера можно использовать библиотеку libkeepalive.

$ export KEEPIDLE=1 #net.ipv4.tcp_keepalive_time
$ export KEEPINTVL=1 #net.ipv4.tcp_keepalive_intvl
$ export KEEPCNT=5 #net.ipv4.tcp_keepalive_probes
$ LD_PRELOAD=./libkeepalive.so nc jabber.local 5222

При таких настройках интервал между keep-alive запросами будет 1 секунда и при отсутствии ответа будет предпринято 5 попыток после чего соединение будет разорвано на application layer. Чтобы видеть передачу пакетов через соединение, использовался tcpdump

sudo tcpdump -i eth0 -n -p -v host jabber.local and port 5222
...
17:48:34.032178 IP (tos 0x0, ttl 64, id 3461, offset 0, flags [DF], proto TCP (6), length 40)
    client > server: Flags [.], cksum 0x37eb (incorrect -> 0xf46c), ack 1, win 913, length 0
17:48:34.032435 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    server > client: Flags [.], cksum 0xe12c (correct), ack 1, win 5840, length 0
17:48:35.031257 IP (tos 0x0, ttl 64, id 3462, offset 0, flags [DF], proto TCP (6), length 40)
    client > server: Flags [.], cksum 0x37eb (incorrect -> 0xf46c), ack 1, win 913, length 0
17:48:35.031540 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    server > client: Flags [.], cksum 0xe12c (correct), ack 1, win 5840, length 0
...

Для эмуляции разрыва связи я использовал iptables

$ sudo iptables -I INPUT -p tcp -s jabber.local -j DROP

При желании настройки TCP keep-alive можно применить ко всему серверу, а не только определенному приложению. Для этого в файл /etc/sysctl.conf (или /etc/sysctl.d/keep-alive.conf) добавить

net.ipv4.tcp_keepalive_time = 1
net.ipv4.tcp_keepalive_intvl = 1
net.ipv4.tcp_keepalive_probes = 5

И применить настройки

sudo sysctl -p

Недостаток этого варианта в том, что он не гарантирует доставку сообщений, которые отправляются в промежутке между keep-alive запросами сервера. И в дополнение в сети создается служебный траффик, объемом 80B/s на каждое подключение.

Вторым вариантом стало подтверждение доставки сообщений. Для этих целей существует расширение XMPP протокола XEP-0184: Message Delivery Receipts. В случае поддержки этого расширения у обоих собеседников появляется возможность видель статус доставки а также просмотра отправленного сообщения. Если один из собеседников не поддерживает расширение, то оно отключается и у второго собеседника.

Клиенты, поддерживающие XEP-0184: Miranda, Psi+, Tkabber, Gajim и некоторые другие. К сожалению Pidgin в данный момент не поддерживает Message Receipts и похоже в ближайшее время поддерживать не будет.

среда, 25 января 2012 г.

Конвертирование офисных документов для просмотра online

Для одного из проектов понадобилось отображать офисные документы online (на начальном этапе предполагается работа с документами Word/Excel/Powerpoint).

В процессе изучения вопроса появилось возможное решение проблемы (список будет пополняться):
  • Использовать OpenOffice/LibreOffice для конвертации в промежуточный формат (pdf) и затем преобразование pdf в swf через swftools.
  • Использовать unoconv для конвертации в xhtml

OpenOffice/LibreOffice + swftools


Я буду рассматривать вопрос в контексте LibreOffice (далее LO) на Debian Squeeze.

Для работы начала нужно запустить LO в т.н. headless mode.

$ soffice "--accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManager" --nologo --headless --nofirststartwizard --norestore

Для конвертирования документов в pdf использовался PyODConverter. Для работы PyODConverter требуется пакет python-uno. Сам процесс конвертирования выглядит так:

$ python ./DocumentConverter.py ./source.doc ./result.pdf

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

$ pdf2swf --quiet -f --set simpleviewer ./result.pdf --output ./result.swf

Поскольку в Debian нет пакета для swftools, я собрал тестовый пакет, который доступен в моем репозитории.

Unoconv


Версия unoconv, доступная в squeeze, старовата (0.3-6), поэтому я установил версию из unstable (0.4-1). Попробовал конвертировать:

$ unoconv --format xhtml --stdout source.doc > result.html

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

Обновление ядра в CentOS 6.2 (CVE-2012-0056)

Доступно обновленное ядро kernel-2.6.32-220.4.1.el6 для CentOS 6.2, которое закрывает уязвимость CVE-2012-0056. Официального анонса еще не было, но обновление уже можно установить.

CentOS 6.2 - исправление авторизации в SSH по public key

После установки CentOS 6.2 на тестовый сервер, попробовал закинуть свой SSH public key:

$ ssh-copy-id -i .ssh/id_dsa root@newserver
root@newserver 's password:
Now try logging into the machine, with "ssh 'centos62-mysql-master'", and check in:

 .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

После чего споткнулся об запрос пароля, при попытке зайти на сервер под root@newserver.

$ ssh root@newserver
root@newserver's password:

Зашел по паролю и проверил содержимое /root/.ssh/authorized_keys - публичная часть ключа была на месте. Подозрение пало на SELiux, который был в режиме enforcing и не первый раз становился виновником мифических глюков. Перевел SELinux в permissive режим:

# setenforce Permissive

После чего заработал логин по ключу. По запросу "centos 6.2 ssh public key selinux" в гугле нашелся Release Notes для CentOS 6.2, где в разделе Known Issues описывается проблема с SSH public key и SELinux.

Make sure that you setup correctly the selinux context of the public key if you transfer it to a CentOS 6 server with selinux enabled. Otherwise selinux might forbid access to the ~/.ssh/authorized_keys file and by matter of consequence key authentication will not work. In order to setup the correct context you can use:

restorecon -R -v /home/$ACCOUNT/.ssh
ssh-copy-id from CentOS 6 is aware of selinux contexts and the previous workaround is not needed.

После выполнения

# restorecon -R -v /root/.ssh

логин через publickey заработал как положено.

вторник, 24 января 2012 г.

Серьезная уязвимость в ядре Linux >= 2.6.39

Вчера заметил новость про уязвимость в ядрах linux начиная с версии 2.6.39. С такими ядрами у меня только две машинки, на которые доступ имею только я. В принципе для эксплуатации этой уязвимости нужно иметь локальный доступ, а из сетевых сервисов на этих машинках только SSH, поэтому я успокоился.

Утром обнаружил дополнения к новости, где говорилось, что уязвимы ядра 2.6.32-220.el6 в последних RHEL/CentOS. А вот это уже много хуже. У меня как минимум 2 сервера, где стоит последний CentOS и может быть уязвимое ядро. В качестве проверки на уязвимость я взял исходник, который редхатовцы предложили в своей security advisory.

На потенциально уязвимых серверах скомпилировал и выполнил тестовый пример.

# wget 'https://bugzilla.redhat.com/attachment.cgi?id=556461' -O cve-2012-0056.c 
# gcc -o cve-2012-0056 cve-2012-0056.c
# ./cve-2012-0056
vulnerable

Проверка показала, что один из серверов уязвим. Второй сервер не был затронут, т.к. openvz ядро для centos6 собрано на основе ванильного 2.6.32, а не ядра RHEL.

На уязвимом сервере стоял последний CentOS. Первым делом проверил, есть ли апдейт для ядра.

# yum check-update

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

В advisory у redhat есть описание, как временно закрыть уязвимость через systemtap. Про systemtap я только слышал, что он приблизительный аналог DTrace (OpenSolaris), а последний очень крут (по слухам). Тут нашелся более детальный гайд, как с помощью systemtap решить проблему. Если кратко, то:

# yum update kernel kernel-firmware
# reboot
# yum install gcc yum-utils systemtap kernel-headers kernel-devel
# wget http://debuginfo.centos.org/6/x86_64/kernel-debuginfo-common-x86_64-`uname -r`.rpm
# wget http://debuginfo.centos.org/6/x86_64/kernel-debuginfo-`uname -r`.rpm
# rpm -Uvh kernel-debuginfo-common-x86_64-`uname -r`.rpm kernel-debuginfo-`uname -r`.rpm
# cat > /root/CVE-2011-0056.stp <<EOF
probe kernel.function("mem_write@fs/proc/base.c").call {
$count = 0
}
EOF

Проверяем, включен ли ASLR (должно выдать 2 или 1)

# cat /proc/sys/kernel/randomize_va_space
2

если нет, то добавляем в /etc/sysctl.conf

kernel.randomize_va_space=2

и применяем изменения

sysctl -p 

Теперь можно запускать systemtap

# stap -g /root/CVE-2011-0056.stp

Если ошибок нет, то жмем Ctrl+C и добавляем в /etc/rc.local

/usr/bin/nohup /usr/bin/stap -g /root/CVE-2011-0056.stp &

не забыв запустить stap в фоне. Остается проверить, осталась ли ошибка

# ./cve-2012-0056
not vulnerable

четверг, 19 января 2012 г.

Maintenance page для сайтов, которые обслуживаются Nginx

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

<html>
<head>
<title>Server Maintenance</title>
</head>
<body>
<center>
<h1>Server maintenance</h1>
Our apologies for the temporary inconvenience. The page is temporarily unavailable as server is down for scheduled maintenance. We will be back soon.
</center>
</body>
</html>
/var/www/maintenance/maintenance.html

<IfModule mod_rewrite.c>
    RewriteEngine on

    RewriteCond %{REQUEST_URI} !^/maintenance.html$
    RewriteRule .* /maintenance.html [R=302,L]
</IfModule>
/var/www/maintenance/.htaccess


Это позволяет отключать сайты вот так:
$ mv /path/to/siteroot /path/to/siteroot~disabled && \
cp -a /path/to/maintenance /path/to/siteroot

Этот способ хорош для apache, который обрабатывает .htaccess. Для Nginx поступил иначе:
  • Поместил директорию maintenance в /var/www
  • Создал конфиг /etc/nginx/maintenance-page
    location / {
        return 503;
    }
    
    error_page 503 /maintenance.html;
    
    location /maintenance.html {
        internal;
        root /var/www/maintenance;
    }
    /etc/nginx/maintenance-page

  • Теперь чтобы отключить сайт /etc/nginx/sites-enabled/example.com (symlink на /etc/nginx/sites-available/example.com), нужно:
    # rm -f /etc/nginx/sites-enabled/example.com
    # cat > /etc/nginx/sites-available/example.com~maintenance <<EOF
    server {
        listen 80;
        server_name example.com;
        include /etc/nginx/maintenance-page;
    }
    EOF
    
    # ln -s /etc/nginx/sites-{available,enabled}/example.com~maintenance
  • Остается перечитать конфиг в Nginx
    nginx -t && nginx -s reload

UPDATE: В комментариях подсказали более простой (и скорее всего более быстрый) способ для maintenance страницы. Поправил код в посте. Директива internal в секции location не даст напрямую обращаться к /maintenance.html.

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

Вышла новая версия freerdp

Сегодня увидел в новостях, что вышла новая версия FreeRDP.

Наиболее заметные отличия от rdesktop:
  • корректная работа с раскладками клавиатуры;
  • публикация удаленных приложений (RemoteApplication). Подобный режим был доступен в rdesktop в связке с seamlessrdp;
  • пробрасывание "сырого" мультимедиа потока от сервера для обработки на клиенте.
Возможно есть еще какие-то вещи, о которых я не знаю. Пока у меня не нашлось времени, чтобы собрать пакет и проверить новую версию freerdp в действии.

пятница, 13 января 2012 г.

Тестирование OSS proxy

Тут я упоминал OSS Proxy, который я начал использовать вместо встроенной в ALSA эмуляции OSS.

Для тестирования я выбрал демки Heroes III и Unreal Tournament. Обе игры плохо работают через перехват обращений к /dev/dsp (alsa-oss) или не работают вообще.

В итоге:
  • Heroes III - звук появился сразу и нареканий на качество нет;
  • UnrealTournament - пришлось поправить конфиг ~/.loki/ut/System/UnrealTournament.ini
    AudioDevice=Audio.GenericAudioSubsystem
    После этого звук в UT появился и проблем с качеством не было

В процессе тестирования в фоне играла музыка, в проигрывателе через ALSA. Это позволило оценить одновременную работу ALSA и эмуляции OSS.

OSS proxy

На домашнем компьютере я использую suspend-to-disk вместо выключения системы. Все работает замечательно, кроме звуковой системы. До начала работы с засыпанием на диск в качестве звуковой платы я использовал Aureal Vortex 2 и был весьма ей доволен. Vortex имел много приятных фишек вроде аппаратного эквалайзера и микшера. Последний весьма полезен, когда параллельно используется несколько потоков ALSA и OSS.

Т.к. поддержка управления питанием для Vortex 2 в linux оставляет желать лучшего, то пришлось отказаться от aureal в пользу встроенной в материнскую плату карточки. Микширование потоков в последних версиях ALSA происходит программно, но для этого нужно следить чтобы устройством вывода звука был default, а не hw:0,0. А вот с эмуляцией OSS все гораздо сложнее. Во-первых звук в некоторых играх с искажениями, а во-вторых ошибка "устройство занято", если запущен микшер в трее, выводит из себя.

Чтобы пробежаться в UnrealTournament или Heroes III, приходится закрывать все приложения, использующие alsa и после игры восстанавливать все обратно.

Так продолжалось бы бесконечно долго, если бы в какой-то рассылке не упомянули OSS proxy. Если кратко, то OSS proxy - реализация OSS через CUSE (Character device in USErspace). В changelog даже упомяналась поддержка MMAP для /dev/dsp - фича, которую хотят многие игрушки (к слову сейчас поддержка MMAP отключена из-за проблем с ее реализацией).

Быстренько накидал пакет для debian, который можно забрать у меня в репозитории.

deb http://www.tataranovich.com/debian squeeze main

Для остальных есть вариант с пересборкой пакета под свою систему.

deb-src http://www.tataranovich.com/debian squeeze main

В итоге нормально заработали игры, которые не работают через AOSS. Причем сейчас не нужно выгружать другие проигрыватели или микшеры.

среда, 11 января 2012 г.

TinyCA: Проверка срока действия сертификатов

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

Чтобы узнавать об этом заранее, я решил набросать небольшой скрипт, который проходится по хранилищу сертификатов и проверяет их "годность" (TinyCA хранит сертификаты в каталоге ~/.TinyCA/CAName/certs).

Выходит, что для проверки достаточно пройтись по всем ~/.TinyCA/CAName/certs/*.pem файлам. Нагуглил скрипт на perl, который проверяет срок действия сертификата. Скрипт завершается с кодом 2, если сертификат просрочен, с кодом 1, если истечет в течении двух недель и с нулевым, если с сертификатом все в порядке.

Далее дописал обвязку для крона, который проверяет сертификаты из ~/.TinyCA/CAName/certs

check-certificate-expire - проверка единичного сертификата
#!/bin/sh

openssl_get_CN_from_file() {
  if [ ! -f "$1" ]; then
    echo "Unable to find file: $1"
    return 1
  fi

  X509_CN=`openssl x509 -in "$1" -noout -subject | perl -pi -e 's/^.*\/?CN=([^\/]*).*$/\1/'`
  echo $X509_CN
}

if [ ! -f "$1" ]; then
  echo "Unable to find file: $1"
  exit 1
fi

check-expire -f /usr/local/etc/check-expire.cfg openssl_x509 -in "$1"

case $? in
  1)
    X509_CN=`openssl_get_CN_from_file "$1"`
    if [ ! -z "$X509_CN" ]; then
      echo "$X509_CN: certificate expires soon"
    else
      echo "$1: certificate expires soon"
    fi
    ;;
  2)
  X509_CN=`openssl_get_CN_from_file "$1"`
  if [ ! -z "$X509_CN" ]; then
    echo "$X509_CN: certificate expired!"
  else
    echo "$1: certificate expired!"
  fi
  ;;
esac

check_tinyca_certs - проверка сертификатов из директории
#!/bin/sh

if [ ! -d "$1" ]; then
  echo "Unable to find directory: $1"
  exit 1
fi

for sslcert in "$1"/*.pem
do
  if [ -f "$sslcert" ]; then
    check-certificate-expire "$sslcert"
  else
    echo "File $sslcert not found"
  fi
done

Конфиг для скрипта check-expire
<class default>
        <expired>
                exit_value 2
        </expired>

        <window>
                inside 2w
                exit_value 1
        </window>
</class>

Удобное добавление закачек в transmission

Для работы с torrent у меня используется transmission - простой и удобный сервер, который работает на домашнем сервере в режиме 24x7. Одно лишь неудобство, когда приходится добавлять новую закачку. Приходится либо скачивать torrent файл и добавлять его, либо копировать ссылку (если torrent файл доступен по прямому url) В любом случае не получается просто кликнуть на ссылку и добавить закачку на сервер.

Первым делом попробовал поискать дополнение для Firefox. Нашелся Autotrans, разработка которого похоже давно заброшена. К тому же в последнюю версию firefox дополнение не ставится.

Когда еще не было домашнего сервера, transmission стоял на компьютере и была возможность выбрать его, как обработчик torrent файлов в браузере. Такое поведение вполне устраивало, т.к. для добавления закачки достаточно скачать файл в браузере и открыть его. При открытии запускался transmission, который предлагал добавить новую закачку.

Сейчас так не получается, поскольку transmission стоит на другом компьютере и доступен только через web-интерфейс либо через rpc. Постепенно начала вырисовываться схема:
  • на всех компьютерах регистрируется дефолтный обработчик файлов torrent
  • этот обработчик вызывается каждый раз, когда открывается torrent файл (не важно из файлового менеджера или списка закачек в браузере - механизм открытия файлов примерно одинаков)
  • обработчик посредством RPC вызова добавляет закачку на сервер transmission

Для добавления новых закачек через RPC решил использовать transmission-remote-gui. Он доступен для всех основных платформ. Дополнительным плюсом является доступ к интерфейсу transmission, возможности которого превосходят встроенный web интерфейс.

В репозитарии Debian нет пакета с transmission-remote-gui, поэтому я установил его из архива в ~/bin/transmission-remote-gui. Осталось зарегистрировать его запускаемый файл как обработчик для torrent файлов.

В gnome ассоциации файлов задаются через desktop файлы, пользовательские настройки хранятся в ~/.local/share/applications. Сперва я создал файл ~/.local/share/applications/transmission-remote-gui.desktop, который регистрирует transmission-remote-gui в системе, как обработчик для MIME-type application/x-bittorrent.

~/.local/share/applications/transmission-remote-gui.desktop
[Desktop Entry]
Name=Transmission remote GUI
GenericName=BitTorrent Client
Comment=Download and share files over BitTorrent
Exec=/home/andrey/bin/transmission-remote-gui/transgui %F
Icon=/home/andrey/bin/transmission-remote-gui/transgui.png
Terminal=false
TryExec=/home/andrey/bin/transmission-remote-gui/transgui
Type=Application
MimeType=application/x-bittorrent;
Categories=Network;FileTransfer;P2P;

Затем я добавил в ~/.local/share/applications/mimeapps.list запись, которая делает transmission-remote-gui предпочтительным приложением при обработке файлов application/x-bittorrent.

~/.local/share/applications/mimeapps.list
application/x-bittorrent=transmission-remote-gui.desktop;

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

Hint: Чтобы не замусоривать систему закачанными torrent файлами, нужно выбрать их удаление после добавления закачки.

понедельник, 9 января 2012 г.

Dropbox: переименование директорий и файлов

Появилось время разобраться с заданием крона, которое бэкапит мою домашнюю директорию посредством rdiff-backup. Для работы с pidgin на разных компьютерах я использую синхронизацию истории. Логи pidgin хранятся в ~/.purple/logs, которая является симлинкой на ~/Safe/.purple-logs. Посколько ~/Safe - точка монтирования encfs (allow_other отсутствует), то бэкап обламывается прочитать информацию о ~/Safe и ругается в вывод крона.

Включать allow_other для encfs для меня плохой вариант. Я решил перенести ~/Safe в ~/mnt/dropbox-vault и заодно переименовать ~/Dropbox/Safe в ~/Dropbox/Vault. Вот последнее было большой ошибкой. Вместо того, чтобы обработать переименование каталога, dropbox решил что удалили ~/Dropbox/Safe и добавили ~/Dropbox/Vault. Такое "решение" привело к повторной синхронизации ~37к файлов, чем немало расстроило меня и еще расстроит, когда я включу остальные компы.

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

суббота, 7 января 2012 г.

Новое чтиво

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

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

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

Мой дом - моя крепость

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

Обогрев квартиры работающей плитой я рассматривать не буду - моя паранойя не позволит оставить зажженный огонь на ночь без присмотра. Проблемы могут возникнуть если не работает вентиляция. В этом случае работающая духовка сначала израсходует значительную часть кислорода, затем либо начнет вырабатывать угарный газ (CO) в добавок к углекислому (CO2). Либо просто погаснет. Оба варианта плохи, т.к. первый не исключает наступление второго. В конечном итоге, если не выключить подачу газа плите, в которой отсутствует газ-контоль, начнет образовываться взрывоопасная смесь о появлении которой нужно узнать до ее опасной концентрации.

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

Поскольку природный и угарный газ легче воздуха, то их наличие нужно определять около потолка. Тут есть перечень сенсоров для различных газов. Под мою задачу подходят MQ-4 (природный газ) и MQ-7 (угарный газ). Их сопротивление зависит от концентрации газа в воздухе, поэтому схема контроля не будет сложной.

А если еще использовать беспроводной интерфейс для связи с домашним компьютером, то можно реализовать уведомления через Email/IM/SMS. В таком случае узнать о проблеме можно не находясь дома и действовать соответственно.

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

среда, 4 января 2012 г.

Чистка репозитория

Нашел немного времени, чтобы навести порядок в той части репозитотия, где лежат сборки midnight commander. Удалил все ночные, за исключением последней. Стабильные релизы решил оставить в полном составе.

После нового года хотел разделить buildbot на структурные единицы, но руки так и не дошли. Да и не стоит наверное трогать пока работает.

Сделал некоторые подсчеты, сколько народу скачало последние версии стабильного релиза midnight commander и его ночных билдов. Получилось, что стабильный релиз скачали 568 раз, а последнюю ночную сборку только 72. Не так уж и много любителей "приключений".