badblocks: Value too large for defined data type invalid end block

Получил новый диск для offsite бэкапов - WDC WD60PURX (6TB). Перед запуском в продакшен обязательный тест в badblocks и последующее изучение S.M.A.R.T. Это продиктовано прошлым опытом покупки двух WDC WD40EFRX (4TB), один из которых "посыпался" в течении недели.

$ sudo smartctl -i /dev/sdc
smartctl 6.4 2014-10-07 r4002 [x86_64-linux-3.16.0-4-amd64] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Purple
Device Model:     WDC WD60PURX-64T0ZY0
Serial Number:    WD-WX11DB514LP0
LU WWN Device Id: 5 0014ee 20d194db1
Firmware Version: 80.00A80
User Capacity:    6,001,175,126,016 bytes [6.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5700 rpm
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2, ACS-3 T13/2161-D revision 3b
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Thu Aug 25 13:06:51 2016 MSK
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Натравливаю на него badblocks и получаю ошибку

$ sudo badblocks -svw /dev/sdc
badblocks: Value too large for defined data type invalid end block (5860522584): must be 32-bit value

Чтобы ее обойти нужно увеличить размер блока, который использует badblocks (по-умолчанию 1024 байт), до 4096 байт

$ sudo badblocks -svw -b 4096 /dev/sdc
Checking for bad blocks in read-write mode
From block 0 to 1465130645
Testing with pattern 0xaa:   0.02% done, 0:06 elapsed. (0/0/0 errors)

Проверка пошла. Осталось дождаться окончания теста и проверить показания S.M.A.R.T. снова.

Включение RDP через консоль Windows

Если вам нужно подключиться через remote desktop к компьютеру (\\test-pc), на котором этот самый remote desktop отключен, но есть доступ для выполнения удаленных команд (например через psexec из pstools), то включить rdesktop можно из консоли.

Для удобства я обернул команды в batch файл и заливаю его на компьютер через монтирование диска по сети (\\test-pc\C$). В моем случае batch файл называется termservice.cmd

@echo off
net stop termservice
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f
sc config termservice start= auto
net start termservice

После этого выполняю batch файл через psexec

psexec -u Administrator \\test-pc C:\termservice.cmd

После выполнения можно подключиться через RDP.

Ошибка "Failed getting Registration Token" в плагине skypeweb после обновления pidgin

После обновления pidgin до 2.11.0 перестал работать плагин pidgin-skypeweb. При попытке включить учетную запись skype выдавало ошибку "Failed getting Registration Token".

На тот момент версия pidgin-skypeweb в системе была 1.1-1, но поскольку в апстриме есть уже 1.2.0, то решил обновить пакет.

Версия pidgin-skypeweb 1.2-1 решила проблему с подключением и уже доступна в моем репозитарии.

Ошибка "E: The method driver /usr/lib/apt/methods/https could not be found" при выполнении apt-get update

При выполнении apt-get update на некоторых серверах стало выдавать ошибку:

$ sudo apt-get update
E: The method driver /usr/lib/apt/methods/https could not be found.
N: Is the package apt-transport-https installed?

.
Для решения проблемы достаточно установить требуемый пакет и обновить списки, но мне стало интересно почему это началось. Ведь все источники в sources.list у меня указаны через http://. На всякий случай проверил это:

$ grep -r https /etc/apt/sources.list*

Ничего не выдало, значит какой-то из репозиториев начал перенаправлять запросы с http:// на https://. Смотрю что у меня есть на одном из проблемных серверов:

$ grep -r http:// /etc/apt/sources.list*
/etc/apt/sources.list:deb http://ftp.us.debian.org/debian jessie main contrib non-free
/etc/apt/sources.list:deb http://security.debian.org/ jessie/updates main contrib non-free
/etc/apt/sources.list.d/zabbix.list:deb http://repo.zabbix.com/zabbix/2.2/debian wheezy main
/etc/apt/sources.list.d/zabbix.list:deb-src http://repo.zabbix.com/zabbix/2.2/debian wheezy main
/etc/apt/sources.list.d/percona.list:deb http://repo.percona.com/apt jessie main

Открыл каждый URL в браузере (добавляя /pool/ в конце) и получил перенаправление на репозитарии percona. Теперь понятно почему проблема есть только на части серверов. Чтобы ее избежать в дальнейшем нужно установить пакеты apt-transport-https и ca-certificates.

$ sudo apt-get install apt-transport-https ca-certificates
$ sudo apt-get update

Также стоит заменить http:// на https:// в репозитарии percona, чтобы избежать ошибки вроде этой:

W: Failed to fetch http://repo.percona.com/apt/dists/wheezy/main/binary-amd64/Packages  301  Moved Permanently

E: Some index files failed to download. They have been ignored, or old ones used instead.

Теперь все работает как полагается.

Поменялся плюс на минус

Первый раз вижу чтобы у разряженной батарейки поменялись полюса:

Батарейка простояла несколько месяцев без использования в батарейном отсеке Lego Technik и сейчас показывает остаточное напряжение ~0.3V, но полярность стала обратная. Это странно, поскольку остальные 5 батареек, которые стояли там же - нормальные (их остаточное напряжение ~1.2V и полярность у согласно маркировке).

Кто нибудь знает как так получилось?

Настройка 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 и каждого домашнего устройства, что довольно неудобно.

Сломался 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