пятница, 24 июля 2015 г.

Извлечение несколько файлов из бэкапа Clonezilla

Есть полный бэкап диска, выполненный в clonezilla. Нужно вытащить несколько файлов с рабочего стола пользователя.

Сначала смотрим что есть в бэкапе:

$ cd /data/Backups/2015-07-23-14-img
$ ls -1
total 16625923
-rw------- 1 root root        583 Jul 23 17:09 blkdev.list
-rw------- 1 root root        197 Jul 23 17:09 blkid.list
-rw------- 1 root root       6036 Jul 23 17:23 clonezilla-img
-rw------- 1 root root          4 Jul 23 17:17 disk
-rw------- 1 root root      20560 Jul 23 17:17 Info-dmi.txt
-rw------- 1 root root      24254 Jul 23 17:17 Info-lshw.txt
-rw------- 1 root root       2243 Jul 23 17:17 Info-lspci.txt
-rw------- 1 root root        171 Jul 23 17:17 Info-packages.txt
-rw------- 1 root root         90 Jul 23 17:23 Info-saved-by-cmd.txt
-rw------- 1 root root         10 Jul 23 17:17 parts
-rw------- 1 root root         33 Jul 23 17:10 sda1.info
-rw------- 1 root root    9588755 Jul 23 17:09 sda1.ntfs-ptcl-img.gz.aa
-rw------- 1 root root 2097152000 Jul 23 17:10 sda2.ntfs-ptcl-img.gz.aa
-rw------- 1 root root 2097152000 Jul 23 17:11 sda2.ntfs-ptcl-img.gz.ab
-rw------- 1 root root 2097152000 Jul 23 17:12 sda2.ntfs-ptcl-img.gz.ac
-rw------- 1 root root 2097152000 Jul 23 17:13 sda2.ntfs-ptcl-img.gz.ad
-rw------- 1 root root 2097152000 Jul 23 17:15 sda2.ntfs-ptcl-img.gz.ae
-rw------- 1 root root 2097152000 Jul 23 17:15 sda2.ntfs-ptcl-img.gz.af
-rw------- 1 root root 2097152000 Jul 23 17:16 sda2.ntfs-ptcl-img.gz.ag
-rw------- 1 root root 2097152000 Jul 23 17:17 sda2.ntfs-ptcl-img.gz.ah
-rw------- 1 root root  237018999 Jul 23 17:17 sda2.ntfs-ptcl-img.gz.ai
-rw------- 1 root root         37 Jul 23 17:09 sda-chs.sf
-rw------- 1 root root    1048064 Jul 23 17:09 sda-hidden-data-after-mbr
-rw------- 1 root root        512 Jul 23 17:09 sda-mbr
-rw------- 1 root root        319 Jul 23 17:09 sda-pt.parted
-rw------- 1 root root        281 Jul 23 17:09 sda-pt.parted.compact
-rw------- 1 root root        259 Jul 23 17:09 sda-pt.sf

Нужные нам данные хранились на втором разделе (sda2). Для восстановления нам понадобится partclone и pigz (вместо pigz можно использовать gzip, но восстановление займет больше времени)

$ sudo apt-get install partclone pigz

Восстановим сырой образ второго раздела в файл:

# cat sda2.ntfs-ptcl-img.gz.a* | pigz -dc | partclone.restore -C -s - -O /data/Backups/sda2-restore.bin --restore_raw_file
Partclone v0.2.73 http://partclone.org
Starting to restore image (-) to device (/data/Backups/sda2-restore.bin)
Reading Super Block
Calculating bitmap... Please wait... done!
File system:  NTFS
Device size:  119.9 GB = 29278719 Blocks
Space in use:  56.3 GB = 13755539 Blocks
Free Space:    63.6 GB = 15523180 Blocks
Block size:   4096 Byte
Elapsed: 00:17:22, Remaining: 00:00:00, Completed: 100.00%, Rate:   3.24GB/min, 
current block:   16720764, total block:   29278719, Complete: 100.00%           
Total Time: 00:17:22, Ave. Rate:    3.2GB/min, 100.00% completed!
Syncing... OK!
Partclone successfully restored the image (-) to the device (/data/Backups/sda2-restore.bin)
Cloned successfully.

Пробуем смонтировать образ

$ sudo mount -o loop,ro /data/Backups/sda2-restore.bin /mnt
Failed to read last sector (234229758): Invalid argument
HINTS: Either the volume is a RAID/LDM but it wasn't setup yet,
   or it was not setup correctly (e.g. by not using mdadm --build ...),
   or a wrong device is tried to be mounted,
   or the partition table is corrupt (partition is smaller than NTFS),
   or the NTFS boot sector is corrupt (NTFS size is not valid).
Failed to mount '/dev/loop0': Invalid argument
The device '/dev/loop0' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?

но получаем ошибку при попытке прочесть сектор, находящийся за пределами восстановленного файла. Дело в том, что partclone не копирует незанятые области и в данном случае мы получили образ меньшего объема, чем изначальный размер исходного раздела. Чтобы исправить нужно либо увеличить размер образа до заведомо большего объема, либо посмотреть в информации clonezilla правильный размер.

Я опишу второй способ. Смотрим в файле sda-pt.parted информацию о исходном диске:

$ cat sda-pt.parted
Model: ATA Samsung SSD 840 (scsi)
Disk /dev/sda: 234441648s
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start    End         Size        Type     File system  Flags
 1      2048s    206847s     204800s     primary  ntfs         boot
 2      206848s  234436607s  234229760s  primary  ntfs

Размер сектора диска 512 байт, размер второго раздела (sda2) - 234229760 секторов. Значит правильный размер образа файла - 512 * 234229760 = 119925637120 байт. Изменим размер файла образа и попробуем смонтировать образ

$ truncate -s $((512 * 234229760)) /data/Backups/sda2-restore.bin
$ sudo mount -o ro,loop /data/Backups/sda2-restore.bin /mnt

Теперь монтирование прошло без ошибок и можно вытаскивать файлы.

Zimbra ругается "network error" при логине в webmail

Если при попытке залогиниться в Zimbra webmail начало ругаться "network error", то скорее всего кто-то еще с вашего IP адреса (актуально для офисов) несколько раз подряд залогинился неправильно, либо, что менее вероятно, кто-то или что-то сделало 30 запросов на вебсервер zimbra за секунду.

Проверить догадку можно в логе /opt/zimbra/log/mailbox.log:

INFO  [qtp509886383-44962:http://10.117.231.45:80/service/soap/AuthRequest] [name=sales@example.com;ip=10.117.231.45;ua=zclient/8.6.0_GA_1153;] SoapEngine - handler exception
INFO  [qtp509886383-44962:http://10.117.231.45:80/service/soap/AuthRequest] [name=sales@example.com;ip=10.117.231.45;ua=zclient/8.6.0_GA_1153;] soap - AuthRequest elapsed=3
INFO  [qtp509886383-44966:http://127.0.0.1:80/service/soap/AuthRequest] [name=sales@example.com;oip=1.2.3.4;ua=zclient/8.6.0_GA_1153;] SoapEngine - handler exception
INFO  [qtp509886383-44966:http://127.0.0.1:80/service/soap/AuthRequest] [name=sales@example.com;oip=1.2.3.4;ua=zclient/8.6.0_GA_1153;] soap - AuthRequest elapsed=3
WARN  [qtp509886383-44965:https://10.117.231.45:443/?loginOp=relogin&username=sales@example.com] [] webclient - auth credentials have expired
INFO  [qtp509886383-44966:http://127.0.0.1:80/service/soap/AuthRequest] [name=sales@example.com;oip=1.2.3.4;ua=zclient/8.6.0_GA_1153;] SoapEngine - handler exception: authentication failed for [sales@example.com], invalid password
INFO  [qtp509886383-44966:http://127.0.0.1:80/service/soap/AuthRequest] [name=sales@example.com;oip=1.2.3.4;ua=zclient/8.6.0_GA_1153;] soap - AuthRequest elapsed=4
INFO  [qtp509886383-44962:http://127.0.0.1:80/service/soap/AuthRequest] [] misc - Access to IP 1.2.3.4suspended, for repeated failed login.
INFO  [qtp509886383-44965:http://127.0.0.1:80/service/soap/AuthRequest] [] misc - Access to IP 1.2.3.4suspended, for repeated failed login.

Чтобы решить эту проблему достаточно добавить офисный IP (например 1.2.3.4) в whitelist и перезагрузить mailboxd:

# su - zimbra
$ zmprov mcf +zimbraHttpThrottleSafeIPs 1.2.3.4
$ zmmailboxdctl restart

Более подробно описано тут: https://wiki.zimbra.com/wiki/DoSFilter.

понедельник, 20 июля 2015 г.

Скорость работы Git на сетевых дисках

В компании, где я работаю, для разработки используется центральный сервер. На этом сервере в контейнерах настроены различные конфигурации веб-серверов и баз данных. Исходники подключаются к рабочим станциям через сетевые диски (samba), sshfs или NFS. Самый популярный вариант - samba.

Началось все с проблем с большими репозитариями (297MB и ~15k файлов). При работе с подобным репозитарием и на локальном диске все неспешно, а на сетевом - совсем беда. Чтобы понять суть проблемы небольшой тест производительности команды git status на одном и том же репозитарии, но подключенном в Linux и Windows. В Linux используется CIFS, а в Windows - сетевой диск.

В качестве одной из оптимизаций в Windows будет использоваться core.fscache = yes:

git config --global core.fscache yes

RealUserSys
Linux0m5.927s0m0.304s0m1.052s
Windows2m37.809s0m0.000s0m0.406s
Windows/core.fscache=yes0m30.732s0m0.000s0m0.031s

Включение core.fscache дает пятикратный прирост в скорости работы Git в Windows на сетевых дисках. Пока никаких побочных явлений, связанных с включением этого параметра не замечено. Вариант с Linux в комментариях не нуждается - там все ожидаемо быстро и без этой опции.

суббота, 18 июля 2015 г.

Firefox не печатает страницу с длинным названием

Жена пыталась распечатать детям несколько картинок для раскрашивания с этого сайта, но ничего не получилось. Проверили очередь заданий CUPS, но там не было информации о нужных заданиях печати. Зато в файле /var/log/cups/error_log на каждую попытку печати появлялась ошибка:

E [18/Jul/2015:15:45:28 +0300] [Client 16] Returning IPP client-error-attributes-or-values-not-supported for Print-Job (ipp://localhost:631/printers/HP_LaserJet_1018) from localhost

Поиск по "Returning IPP client-error-attributes-or-values-not-supported for Print-Job" вывел на описание похожего бага #917340 в Thunderbird. Его суть в том, что при попытке передать слишком длинный Jobname (в нашем случае использовался title страницы) через протокол IPP приводит к отказу печати.

Чтобы обойти эту проблему можно либо открыть картинку в новом окне, либо через developers tools исправить title страницы на более короткий. Баг проявляется как в версии 31.8.0esr-1~deb8u1 из Debian Jessie, так и в 39.0-1~bpo80+1 из jessie-backports (mozilla.debian.net).

UPDATE: Зарепортил баг в Debian и upstream.

Фейковый Mi Power Bank 16000 mAh

Скоро в отпуск, а запекаться на пляже без гаджетов скучно. В прошлый отпуск меня частично выручал второй аккумулятор для телефона, но в этот раз решил идти в ногу со временем и взять powerbank. В вопросе долго не разбирался - решил взять powerbank Xiaomi на 16000 mAh. Магазин Xiaomi не доставляет в Беларусь, так что отправился на eBay и нашел там нужную модель.

Спустя 20 дней получил powerbank и уже на этапе распаковки начались подозрения, что качество далеко от виденных продуктов Xiaomi. Начал гуглить и нашел инфу, что в интернете продают очень много фейков. Нашелся отличный гайд как не разбирая определить подделку. По всем пунктам мой powerbank - подделка, хотя и неплохого вида. Ну да ладно, лишь бы на электронной начинке не сэкономили, а то ведь неправильная эксплуатация литиевых элементов может быть чревата бедой. При разборке выяснилось, что на оригинальный продукт оно похоже лишь внешне:


Розовые элементы 18650 с маркировкой samsung наврятли произведены самсунгом, а плата электроники совсем не похожа на оригинальную плату:


Элементов на плате меньше, датчика перегрева нет - еще не измерял его характеристики, но подозреваю, что 5V 2A там и не пахнет при такой начинке. В общем не ожидал я, что кто-то будет подделывать китайскую продукцию...

UPDATE: Вот тут есть более подробное сравнение фейка с оригиналом. А вот тут выясняется природа производства этого фейка.

пятница, 17 июля 2015 г.

Скорость работы Git в Windows

Не новость, что Git в Windows работает хуже, чем в Linux. Этому есть несколько причин - от различий в архитектуре кеша файловой системы до различий в скорости работы транспорта ssh. Я решил сделать сравнение скорости клонирования довольно большого репозитария с использованием различных транспортов: http, ssh/plink и ssh/openssh. Результаты тестирования в виде таблицы:

ТранспортRealUserSys
https23m45.544s0m0.000s0m0.015s
ssh/openssh12m18.379s0m0.000s0m0.030s
ssh/plink87m21.428s0m0.000s0m0.015s

В итоге получилось, что самым выигрышным вариантом является ssh/openssh, а используя ssh/plink придется ждать в 7 раза дольше!

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

ТранспортRealUserSys
https0m49.125s0m0.000s0m0.000s
ssh/openssh0m49.483s0m0.000s0m0.015s
ssh/plink1m51.556s0m0.000s0m0.000s

Внутри локальной сети ситуация поменялась - скорость https и ssh/openssh практически не отличается, а ssh/plink сократил отставание до 2-х раз. Таким образом при быстром соединении можно жить и с plink в качестве транспорта, но посколько большинство репозитариев все же находятся далеко, то лучше использовать вариант с openssh.

Hint: Чтобы использовать ssh-agent.exe из openssh в Windows нужно:
  • добавить в пользовательские переменные окружения SSH_AUTH_SOCK=/tmp/.ssh-agent
  • настроить автозапуск C:\Program Files (x86)\Git\bin\ssh-agent.exe -a /tmp/.ssh-agent
  • добавить ключ в ssh-agent (например: ssh-add %USERPROFILE%\.ssh\id_rsa)

Недостаток этого подхода - отсутствие GUI для управления ключами в ssh-agent.

И напоследок: клонирование этого же репозитария в Linux в локальной сети занимает всего 9 секунд...

Слеза админа: итеративность Windows Update

Разворачиваю свежую виртуалку с Windows 7 на борту - нужно обновить информацию о таймзонах. Нужное мне обновление KB3013410, но просто скачать его и установить не выйдет - говорит, что не применимо к моей системе:


Начинаю обновлять через Windows update. Сначала нужно установить обновление самого windows update и перезагрузиться, затем поиск обновлений находит лишь 4 важных и 50 опциональных. Среди опциональных нужного апдейта нету - ставлю все кроме локализации и перезагружаюсь. Далее поиск находит 20 важных и 50 опциональных - и опять там нет нужного апдейта!

Почему нельзя сделать как в Linux - поставить ВСЕ обновления за один раз и перезагрузиться?! Да фиг с однократной перезагрузкой - я хочу скомандовать: ставить апдейты непрерывно не отвлекаясь ни на что, мне фиолетово на нагрузку и тормоза, мне нужна полностью обновленная система и как можно скорее. Выбор варианта автоматической установки обновлений не дает желаемого.

Может есть способ обновить систему "быстро, без регистрации и смс"? Может лучше стало в Win8/Win10?

четверг, 16 июля 2015 г.

Ошибка "NO_PUBKEY 836CC41976FB442E" при выполнении apt-get update

При смене gpg ключа на моем репозитории не обошлось без проблем - сегодня при выполнении apt-get update на одном из хостов получил ошибку:

$ sudo apt-get update

W: A error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://www.tataranovich.com wheezy Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 836CC41976FB442E

W: Failed to fetch http://www.tataranovich.com/debian/dists/wheezy/Release: 
W: Some index files failed to download. They have been ignored, or old ones used instead.

На этом хосте не установлен пакет tataranovich-keyring и ключ не обновился автоматически. Чтобы решить эту проблему достаточно выполнить команду:

$ sudo apt-key adv --keyserver pgp.mit.edu --recv-key 836CC41976FB442E

Затем обновить информацию APT и установить пакет tataranovich-keyring, чтобы избежать подобных проблем в будущем:

$ sudo apt-get update
$ sudo apt-get install tataranovich-keyring

Альтернативным решением будет скачать пакет tataranovich-keyring отсюда и установить его руками:

$ wget http://www.tataranovich.com/debian/pool/sid/main/t/tataranovich-keyring/tataranovich-keyring_2015.07.13_all.deb
$ sudo dpkg -i tataranovich-keyring_2015.07.13_all.deb

среда, 15 июля 2015 г.

Reverting merge in git

Чтобы отменить неудачный мерж в git нужно узнать его sha-хеш в логе и выполнить git revert -m 1 %hash%. Параметр -m требуется чтобы указать git какого из родителей мерж комита нужно оставить.

$ git revert -m 1  975a217272bb91fd 
[master 268298c] Revert "Merge branch 'fix_permissions' into 'master'"
 99 files changed, 3222 insertions(+), 4898 deletions(-)

При этом в истории появится что-то вроде этого:

commit 268298ce95363a2c0c383c2249d4836617484dc5
Author: Andrey Tataranovich <tataranovich@gmail.com>
Date:   Wed Jul 15 16:17:09 2015 +0300

    Revert "Merge branch 'fix_permissions' into 'master'"
    
    This reverts commit 975a217272bb91fd5cd32cc6ea4ea9af189fbcc2, reversing
    changes made to 0c2c54e1a29576afd760bbdaa7f986f14c2c28cd.

commit 975a217272bb91fd5cd32cc6ea4ea9af189fbcc2
Merge: 0c2c54e 4eb3dd6
Author: John Doe <john.doe@example.com>
Date:   Wed Jul 15 14:15:03 2015 +0300

    Merge branch 'fix_permissions' into 'master'
    
    fix permissions
    
    fix permissions
    update order-notes-and-files
    
    See merge request !12

Осталось запушить изменения на сервер. Более подробную инфу по отмене мержа можно найти тут.

понедельник, 13 июля 2015 г.

Flashplugin 11.2.202.481 crashing

Пользуюсь firefox и вчера обновил flashplugin до 11.2.202.481 - в итоге имею пачку segfault при попытке просмотреть запись вебинара:


в dmesg при этом:

[77541.452527] plugin-containe[22314]: segfault at 0 ip ae9c2fbe sp bf900864 error 4 in libflashplayer.so[ae3e7000+1024000]
[79194.784129] plugin-containe[22803]: segfault at 0 ip ae9c2fbe sp bffd8404 error 4 in libflashplayer.so[ae3e7000+1024000]
[79205.180568] plugin-containe[22893]: segfault at 0 ip ae8c2fbe sp bfa7bc04 error 4 in libflashplayer.so[ae2e7000+1024000]
[85649.150525] plugin-containe[25522]: segfault at 0 ip ae8c2fbe sp bfc30814 error 4 in libflashplayer.so[ae2e7000+1024000]

Попробую вечером собрать freshplayer для интеграции pepperflash в firefox.

Новый GPG ключ для моего репозитория

С сегодняшнего дня мой репозиторий подписывается PGP ключем 0x76FB442E (4A49 2741 9308 3320 450B 7E4D 836C C419 76FB 442E). Импортировать ключ в APT можно установив пакет tataranovich-keyring или выполнив команду:

$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 76FB442E

Старый ключ (2EE7EF82, ACBE C1C1 FC07 5E80 359A 7CC2 FE27 2604 2EE7 EF82) будет отозван после проведения июльского KSP в Минске.

пятница, 10 июля 2015 г.

Запрет запуска сервисов в chroot при установке пакетов

Чтобы не засорять ноутбук девелоперскими пакетами (которые часто бывают сильно разных версий squeeze, wheezy, jessie) я использую chroot, а точнее schroot. Для запрета запуска сервисов при установке пакетов по зависимостям внутри chroot нужно создать в chroot файл /usr/sbin/policy-rc.d (подсмотрено тут).

Для моего chroot с jessie это выглядит так:

% schroot -c jessie-dev
(jessie-dev) $ echo 'exit 101' | sudo tee /usr/sbin/policy-rc.d
(jessie-dev) $ sudo chmod +x /usr/sbin/policy-rc.d
(jessie-dev) $ sudo invoke-rc.d dbus start
invoke-rc.d: policy-rc.d denied execution of start.

Теперь при установке сервисов они не запускаются автоматически. Стоит отметить, что данный запрет не действует, если в preinst или postinst используют /sbin/service foo start или /etc/init.d/foo start.

среда, 8 июля 2015 г.

среда, 1 июля 2015 г.

Настройка mod_ssl в apache 2.2.x

Поправил дефолтные настройки mod_ssl для Apache 2.2.x

<IfModule mod_ssl.c>
  SSLRandomSeed startup builtin
  SSLRandomSeed startup file:/dev/urandom 512
  SSLRandomSeed connect builtin
  SSLRandomSeed connect file:/dev/urandom 512
  AddType application/x-x509-ca-cert .crt
  AddType application/x-pkcs7-crl    .crl
  SSLPassPhraseDialog  builtin
  SSLSessionCache        shmcb:${APACHE_RUN_DIR}/ssl_scache(512000)
  SSLSessionCacheTimeout  300
  SSLMutex  file:${APACHE_RUN_DIR}/ssl_mutex
  SSLCipherSuite kEECDH+AESGCM+AES128:kEECDH+AES128:kRSA+AESGCM+AES128:kRSA+AES128:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv2
  SSLHonorCipherOrder on
  SSLProtocol All -SSLv2 -SSLv3
</IfModule>

Если прописать такие настройки в /etc/apache2/mods-available/ssl.conf, то SSL Server Test не выдает дополнительных рекомендаций.

Полезная информация касательно обновления на Windows 10

Нашел полезную статью в блоге Вадима Стеркина касательно обновления до Windows 10 (выйдет 29 июля).

Leap second 2015

Похоже в этом году все прошло без глобальных потрясений:

[319639.240645] Clock: inserting leap second 23:59:60 UTC

В прошлый раз пришлось перезагружать MySQL сервера.