Ошибки при запуске 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.

Ошибка "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 метров. И это явление не редкость - часто есть свободные места, но они практически перекрыты вот такими идиотами.

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

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

Привязка пользователей хоста к определенному пользователю на сервере 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.

Незаладился апгрейд: 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 можно взять в моем репозитарии.

Локаль 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

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