пятница, 27 марта 2015 г.

Ошибки при запуске snmpd в Debian

Наткнулся на сообщения об ошибках в логе snmpd:

...
snmpd[3333]: /etc/snmp/snmpd.conf: line 143: Error: unknown monitor OID
snmpd[3333]: payload OID: extNames
snmpd[3333]: /etc/snmp/snmpd.conf: line 143: Error: unknown payload OID
snmpd[3333]: Unknown payload OID: extNames
snmpd[3333]: /etc/snmp/snmpd.conf: line 143: Error: Unknown payload OID
snmpd[3333]: payload OID: extOutput
snmpd[3333]: /etc/snmp/snmpd.conf: line 143: Error: unknown payload OID
snmpd[3333]: Unknown payload OID: extOutput
snmpd[3333]: /etc/snmp/snmpd.conf: line 143: Error: Unknown payload OID
snmpd[3333]: trigger OID: extResult
snmpd[3333]: /etc/snmp/snmpd.conf: line 143: Error: unknown monitor OID
snmpd[3333]: payload OID: dskPath
snmpd[3333]: /etc/snmp/snmpd.conf: line 143: Error: unknown payload OID
snmpd[3333]: Unknown payload OID: dskPath
...

Пакет snmp-mibs-downloader установлен, но оказалось что я забыл закомментировать запрет загрузки mibs. Чтобы это исправить нужно закомментировать строку "mibs:" в файле /etc/snmp/snmp.conf и строку "export MIBS=" в /etc/default/snmpd и перезапустить snmpd.

среда, 25 марта 2015 г.

Ошибка "error: RPC failed; result=22, HTTP code = 411" при git push

Если вы делаете git push в репозитарий, доступный по HTTP или HTTPS, и получаете ошибку вида:

$ git push origin master
Pushing to https://git.example.com/repos/test.git
POST git-receive-pack (chunked)
error: RPC failed; result=22, HTTP code = 411
fatal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly
Everything up-to-date
Completed with errors, see above

то вам поможет увеличение значения параметра http.postBuffer (значение по-умолчанию: 1MB). Чтобы увеличить значение до 50MB выполните

$ git config --global http.postBuffer 52428800

Решение подсмотрено на stackoverflow.com.

Эгоистов и идиотов можно определить на парковке

Массу эмоций получил вчера утром, пытаясь выехать с парковки у дома. Какой-то нехороший человек припарковался в проезде между рядами машин, аккурат перекрыв мне нормальный выезд. Примечательно, что вдоль дороги и через дорогу есть много мест для парковки, но этот паразит поленился пройти лишних 50 метров. И это явление не редкость - часто есть свободные места, но они практически перекрыты вот такими идиотами.

Чтобы было понятно о чем я говорю:


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

вторник, 24 марта 2015 г.

Привязка пользователей хоста к определенному пользователю на сервере NFS

Один из недостатков NFSv3 - отсутствие аутентификации пользователей. Доступна лишь авторизация хоста по IP, которую при желании несложно обойти. Если на вашем сервере стоит разрешение для определенного хоста, то ее локальный администратор может создать другого пользователя с нужным uid/gid и тем самым обойти ограничение прав на сервере. Эта проблема решена в NFSv4, но я пока не реализовал все необходимые изменения в инфраструктуре.

Чтобы на NFSv3 исключить возможность обхода авторизации через создание пользователя с произвольным uid/gid я воспользовался следующей уловкой

# cat /etc/exports
/data/sources  host1(rw,sync,all_squash,anonuid=1000,anongid=500,no_subtree_check)
/data/sources  host2(rw,sync,all_squash,anonuid=1001,anongid=500,no_subtree_check)
/data/sources  host3(rw,sync,all_squash,anonuid=1002,anongid=500,no_subtree_check)

Использование all_squash в комбинации с anonuid/anongid привязывает любого пользователя с хоста к определенному uid/gid (который соответствует uid/gid пользователя в LDAP). Однако нужно понимать, что это решение бесполезно в случае подмены IP адреса хоста. В этом случае может помочь использование 802.1x на коммутаторах, но проще перейти к использованию NFSv4.

понедельник, 23 марта 2015 г.

Незаладился апгрейд: WD Red 4TB

Незаладился апгрейд сервера резервного копирования. Для расширения его дискового массива были заказаны два WD Red (WD40EFRX) на 4TB. Добавил диски в сервер, разметил, собрал в зеркало и стал наблюдать за скоростью синхронизации.

Вначале диски синхронизировались на скорости 150MB/s и обещали завершить процесс за 444 минуты. Но уже через пару минут скорость упала до 100-200 kB/s и время до завершения процесса стало стремиться к бесконечности.

Заглянул в dmesg

[ 6648.170563] ata5.00: exception Emask 0x0 SAct 0x7fffffff SErr 0x0 action 0x0
[ 6648.170590] ata5.00: irq_stat 0x40000008
[ 6648.170608] ata5.00: failed command: READ FPDMA QUEUED
[ 6648.170630] ata5.00: cmd 60/80:c0:00:bf:15/00:00:02:00:00/40 tag 24 ncq 65536 in
[ 6648.170633]          res 41/40:00:00:bf:15/00:00:02:00:00/40 Emask 0x409 (media error) 
[ 6648.170661] ata5.00: status: { DRDY ERR }
[ 6648.170677] ata5.00: error: { UNC }
[ 6648.171888] ata5.00: configured for UDMA/133
[ 6648.171955] ata5: EH complete
[ 6651.548219] ata5.00: exception Emask 0x0 SAct 0x7fffffff SErr 0x0 action 0x0
[ 6651.548247] ata5.00: irq_stat 0x40000008
[ 6651.548265] ata5.00: failed command: READ FPDMA QUEUED
[ 6651.548287] ata5.00: cmd 60/80:f0:00:bf:15/00:00:02:00:00/40 tag 30 ncq 65536 in
[ 6651.548289]          res 41/40:00:00:bf:15/00:00:02:00:00/40 Emask 0x409 (media error) 
[ 6651.548318] ata5.00: status: { DRDY ERR }
[ 6651.548330] ata5.00: error: { UNC }
[ 6651.549536] ata5.00: configured for UDMA/133
[ 6651.549596] ata5: EH complete

Логи наводнили ошибки с одного из дисков, но второй диск был в порядке. Проверил показания S.M.A.R.T. для обоих новых дисков - у одного все в порядке, а вот второй диск похоже умирает

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: FAILED!
Drive failure expected in less than 24 hours. SAVE ALL DATA.
Failed Attributes:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   001   001   051    Pre-fail  Always   FAILING_NOW 571

Извлек сбойный диск из сервера

echo 1 > /sys/block/sdd/device/delete

а на оставшийся натравил badblocks

# badblocks -svw /dev/sde

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

Checking for bad blocks in read-write mode
From block 0 to 3907018583
Testing with pattern 0xaa: done
Reading and comparing: done
Testing with pattern 0x55: done
Reading and comparing: done
Testing with pattern 0xff: done
Reading and comparing: done
Testing with pattern 0x00: done
Reading and comparing: done
Pass completed, 0 bad blocks found. (0/0/0 errors)

При этом в S.M.A.R.T. обоих дисков ничего криминального нету. Массив снова синхронизируется - надеюсь завтра сюрпризов не будет.

Релиз Midnight Commander 4.8.14

Сегодня анонсировали новую версию Midnight Commander 4.8.14. Список изменений тут. Пакеты для Debian/Ubuntu под архитектуры i386 и amd64 можно взять в моем репозитарии.

суббота, 21 марта 2015 г.

Локаль en_US и начало недели

На своих системах я ставлю локаль en_US.UTF-8 в качестве общесистемной. Это дает меньше проблем с локализацией программ (иногда приходится переключить локаль приложения, чтобы понять о чем идет речь), GUI не "рвется" из-за различной длины слов в других языках и т.д.

А вот вчера я таки рассмотрел слона - понадобилось поизучать даты в календаре и я открыл orage, который висит в трее Xfce. И не сразу понял что не так - неделя начинается с Sunday, а не с Monday - мелкое неудобство, но в Linux подобным мелочам не место.

Поизучал немного содержимое /usr/share/i18n/locales и понял что мою проблему решит опция LC_TIME=en_GB.UTF-8. В локали en_GB началом недели считается понедельник, а не воскресенье. Чтобы применить это изменение ко всей системе целиком в Debian достаточно выполнить команду

sudo update-locale LC_TIME=en_GB.UTF-8

Теперь календарик выглядит более привычно для меня

среда, 11 марта 2015 г.

Описание эксплуатации RowHammer - уязвимости в работе DRAM

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

На этой неделе появилось продолжение этой истории в форме описания работы двух эксплойтов. Проверить систему на наличие проблем можно rowhammer-test.

среда, 4 марта 2015 г.

Свежая малварь в skype

Сегодня уже несколько контактов в skype шлют мне однотипные сообщения вроде

лол!!! Andrey Tataranovich видео: http://skyvideotape.ru/video/?n=Andrey%20Tataranovich
Боже мой!!! Andrey Tataranovich видео: http://24onlineskyvideo.info/video/?n=Andrey%20Tataranovich

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

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

Узнал новый способ ввода символов unicode в X11

Для ввода символов unicode в X11 я пользуюсь либо compose key, либо таблицей символов.

А сегодня наткнулся на еще один способ ввода: "Ctrl+Shift+U+Unicode value". Для этого метода ввода нужно нажать Ctrl+Shift+U, потом отпустить U и ввести значение кода символа.

Например для знака ° это будет 00B0, а для € - 20AC.

Полезный софт: shutter и xpra

Для работы в саппорте нередко приходится делать скриншоты и выкладывать их в онлайн, чтобы прислать клиенту ссылку. Раньше я пользовался самопальной оберткой над gyazo.com, но на февральской линуксовке мне подсказали shutter.

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

Также в рассылке altlinux наткнулся на упоминание xpra - аналог screen для приложений X11. Мне например частенько приходилось запускать linuxdcpp на домашнем сервере и отключаться в процессе скачивания. На самом деле ничего сверхестественного в реализации xpra нет - по сути это обертка над Xvfb, но пользоваться им удобно.

Минимальный набор команд для работы:

$ xpra start :100 --start-child=linuxdcpp
Entering daemon mode; any further errors will be reported to:
  /home/andrey/.xpra/dragoncore-100.log

$ xpra list
Found the following xpra sessions:
 LIVE session at :100

$ xpra attach :100
mmap enabled using /home/andrey/tmp/xpra.rdfJYj.mmap
Attached (press Control-C to detach)

$ xpra attach ssh:andrey@localhost:100     
mmap enabled using /home/andrey/tmp/xpra.khXKZX.mmap
Attached (press Control-C to detach)

$ xpra stop :100
xpra at :100 has exited.