Особенность работы DNS резолвера в Windows

Полезная информация об отличиях в работе DNS клиента в различных версиях Windows. В свое время мне прилично попортило кровь поведение DNS клиента в Windows 7 - у некоторых пользователей не помогала опция register-dns и случайным образом отваливался доступ к внутренним корпоративным ресурсам. При этом в Windows XP и Linux все работало замечательно.

Извлечение несколько файлов из бэкапа 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.

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

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

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

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

git config --global core.fscache yes

	Real	User	Sys
Linux	0m5.927s	0m0.304s	0m1.052s
Windows	2m37.809s	0m0.000s	0m0.406s
Windows/core.fscache=yes	0m30.732s	0m0.000s	0m0.031s

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

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: Вот тут есть более подробное сравнение фейка с оригиналом. А вот тут выясняется природа производства этого фейка.

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

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

Транспорт	Real	User	Sys
https	23m45.544s	0m0.000s	0m0.015s
ssh/openssh	12m18.379s	0m0.000s	0m0.030s
ssh/plink	87m21.428s	0m0.000s	0m0.015s

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

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

Транспорт	Real	User	Sys
https	0m49.125s	0m0.000s	0m0.000s
ssh/openssh	0m49.483s	0m0.000s	0m0.015s
ssh/plink	1m51.556s	0m0.000s	0m0.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 секунд...