Как проверить все бинарные файлы на Debian на предмет идентичности их версиям предоставляемым в пакетном менеджере?

apt-get install -y debsums
debsums -s

GNU parallel - решение Ваших проблем с многопоточностью в Bash

http://www.gnu.org/software/parallel/

Для дебияна есть одноименный пакет, а вот у Центосов с этим плохо :(

Работа с Atlassian Confluence из командной строки CLI

Для начала нужно скачать тулкит: https://bobswift.atlassian.net/wiki/display/CSOAP/Downloads

Нам нужен: atlassian-cli-3.9.0-SNAPSHOT-distribution.zip

Потом в Global  Configuration Confluence ставим флаг "Remote API (XML-RPC & SOAP)".

Потом распаковываем архив  atlassian-cli- и открываем редактором vim atlassian.sh и прописываем в нем user/password для доступа к вики (предварительно вы должны создать пользователя вики с правами доступа по АПИ).

И вот такой командой можно сделать экспорт спейса:

./confluence.sh --server http://corp.wiki.domain.ru:8080 --user USER --password XXXXX --action exportSpace --space space_name --exportType HTML --file export.zip

А вот официальная документация: https://bobswift.atlassian.net/wiki/display/CSOAP/Examples

Обращаю внимание, что напоролся на дикий баг:

#Client error: Bad response code (403) received trying to retrieve data from URL: https://wiki.fv.ee/download/temp/htmlexport-20140425-141751-20/Confluence-space-export-141753-21.html.zip
#org.swift.common.cli.CliClient$ClientException: Bad response code (403) received trying to retrieve data from URL: https://wiki.fv.ee/download/temp/htmlexport-20140425-141751-20/Confluence-space-export-141753-21.html.zip
#    at org.swift.common.cli.CliUtils.copyUrlToFile(CliUtils.java:214)
#    at org.swift.confluence.cli.ConfluenceClient.exportSpace(ConfluenceClient.java:5610)
#    at org.swift.confluence.cli.ConfluenceClient.handleRequest(ConfluenceClient.java:675)
#    at org.swift.common.cli.AbstractRemoteClient.process(AbstractRemoteClient.java:124)
#    at org.swift.common.cli.CliClient.doWork(CliClient.java:393)
#    at org.swift.confluence.cli.ConfluenceClient.main(ConfluenceClient.java:150)

 Но сделал для него work around! Кому нужно - прошу в личку =)

Courgette - супер эффективный алгоритм дельта-сжатия для бинарных исполняемых файлов

http://neugierig.org/software/chromium/notes/2009/05/courgette.html

Да, инженеры Google нереально просто круты!

Как в Nginx логгировать тела POST запросов?

Прописываем в кастом конфиг переменной $request_body при выкрученном буфере client_body_buffer_size 1m результата не дает. В логе прочерки, куда копать?

Где хранит свои сессии ISPManager?

Как можно догадаться, как при работе по API (mgrctl -m ispmgr session.newkey username=root key=$key), так и при работе через веб ISPManager поддерживает свои сессии. В которых лежит секретный код (в случае веба - хранится в куке), который позволяет входить пользователю без пароля пока действительна его сессия.


Путем отладки через starce нашел, что этот файлик вот тут:

 /usr/local/ispmgr/var/.ispmgr.ses

Но вот его формат не понятен, хотя скоро, уверен, я его вскрою и выложу концепт :) Формат у него страшный и бинарный =)
 

Как в HTOP увидеть разделение по номерам контейнеров OpenVZ?

Итак, нужен CentOS 6 + htop.

Запускаем, жмем shift+s, в левом столбце выбираем: Columns, потом на вкладке Available Columns выбираем CTID (он в самом низу), жмем Enter. После этого выходим из конфигурации, выжимая Esc.

Вуаля:

Спасибо за наводку:  http://poiuty.com

librsync и утилита rdiff - все что Вы НЕ знали о резервном копировании

Данный пакет утилит крайне полезен. Чем? В первую очередь, очень высоким в отличие от rsync уровнем контроля за тем, что же делается :)

Вот, например, мы можем взять 8 гигабайтный бинарный файл (созданный из данных за 8е апреля) и сгенерировать для него signature файл вот так:

time rdiff signature 56640_root_hdd.gz_84cab040-bed0-11e3-b5aa-80259087d80c /root/56640.signature

real    0m42.922s
user    0m34.305s
sys     0m2.209s

Займет он при этом 47 мегабайт всего-то. Что такое signature файл? Грубо говоря, это файл с полной информацией о блоках данного файла и их хэш суммах. Для чего это может понадобится? Об этом позже.

Итак, допустим у нас есть актуальная (за 18е апреля) копия данного файла (это НЕ архив, это просто большой файл с бинарными данными).

Итак, мы хотим сделать бинарный патч между версией от 8е апреля и версией за 18е. Нужен ли нам весь 8гб дамп за 8е апреля? Не-а :) Достаточного его signature файла!

Итак, создаем инкрементальный бэкап не имея полного бэкапа на руках (вообще!):

time rdiff delta /root/56640.signature /vz/tmp/56640.hdd /vz/tmp/56640_diff_between_8_and_18_april.rdiff

И на выходе мы получим дельта-файл между бэкапами за 8е и 18е апреля :)


Но есть одно но, ОН ОЧЕНЬ МЕДЛЕННЫЙ:

real    13m27.094s
user    13m14.457s
sys    0m9.089s

Но при этом бесконечно радует размер файла инкремента:

ls -alh /vz/tmp/56640_diff_between_8_and_18_april.rdiff
-rw-r--r-- 1 root root 447M Апр 18 00:37 /vz/tmp/56640_diff_between_8_and_18_april.rdiff

Теперь попробуем обратный процесс создание полного бэкапа за 18е апреля из дельты + бэкапа за 8е.

Эти тесты я не уверен, что проведу сегодня, так что пока сделаем лишь чексуммы:

sha1sum /vz/tmp/56640.hdd
1580e28b7c23f390e02c30d62f10971a77b9ace8  /vz/tmp/56640.hdd

Также об ускорении. Решил попробовать увеличить блок обработки до 1 мегабайта. Для этого нужно регенерировать signatures файл:

rdiff --statistics  --block-size=1048576 signature 56640_root_hdd.gz_84cab040-bed0-11e3-b5aa-80259087d80c /root/56640.signature

Запускаем создание дельты снова:

 time rdiff --statistics  --block-size=1048576 delta /root/56640.signature /vz/tmp/56640.hdd /vz/tmp/56640_diff_between_8_and_18_april.rdiff

Он сразу сообщит, что используется на порядок меньше блоков (стандартный блок - 2048 байт):

rdiff: loadsig statistics: signature[7938 blocks, 1048576 bytes per block]

Ура! Победа :)

real    2m30.670s
user    2m17.618s
sys    0m10.665s

Но не во всем, сам дельта файл оказался крайне огромный:

ls -alh  /vz/tmp/56640_diff_between_8_and_18_april.rdiff
-rw-r--r-- 1 root root 3,9G Апр 18 01:26 /vz/tmp/56640_diff_between_8_and_18_april.rdiff

Так что с оптимизацией тут нужно быть поосторожнее :(

Как импортировать исходный код OpenVZ в GIT для удобной навигациии по коду и контроля за изменениями в коде?

Я уже положил код актуального ядра в Git для удобства: https://github.com/pavel-odintsov/openvz_rhel6_kernel_mirror

Вот так:

cd /usr/src
wget http://download.openvz.org/kernel/branches/rhel6-2.6.32/042stab108.1/vzkernel-2.6.32-042stab108.1.src.rpm
rpm -ihv vzkernel-2.6.32-042stab108.1.src.rpm
yum install -y rpm-build redhat-rpm-config unifdef # необходимы для патчей
yum install -y patchutils xmlto asciidoc elfutils-libelf-devel zlib-devel  elfutils-devel newt-devel python-devel bison flex hmaccalc binutils-devel audit-libs-devel
cd /root/rpmbuild/SPECS/

После этого нужно внести правки:

vim kernel.spec
выпиливаем там: перл модуль на который ругается rpmbuild: ExtUtils::Embed

 Накладываем патчи:

rpmbuild -bp  kernel.spec

cd /root/rpmbuild/BUILD/kernel-2.6.32-504.16.2.el6/linux-2.6.32-042stab108.1
git init
git add --all

git commit -m "Initial Commit"
git remote add origin ssh:/путь к вашему репо.git
git push origin master

А если делается обновление, то обновить файлы в репо можно так:

/bin/cp -R * /usr/src/openvz_rhel6_kernel_mirror/

P.S. OpenVZ team, я знаю, что Вы меня временами читаете, пожалуйста, сделайте хотя бы по релизным версиям git репо =)

Как измерить уровень занятости QPI шины на PowerEdge 720?

https://software.intel.com/en-us/forums/topic/278653
Даже инженеры Intel молчат =(

Как в терминале Open Indiana убрать A B C D при использовании стрелок?

Проще простого: 

echo "set nocompatible" > /root/.vimrc

Огромная разница в скорости выполнения sha1sum и openssl sha1, откуда и почему?

В процессе отладки нашего бэкап решения обратил внимание, что хэш функции стали потреблять много процессорного времени и совершенно случайно обнаружил следующее:

[root@technode4 ~]# time sha1sum /vz/private/7803/root.hdd/root.hdd
c41be08852baed71294623ea27ec7f64a3ac117f  /vz/private/7803/root.hdd/root.hdd

real    1m1.632s
user    0m59.987s
sys    0m1.663s

[root@technode4 ~]# time openssl sha1 /vz/private/7803/root.hdd/root.hdd
SHA1(/vz/private/7803/root.hdd/root.hdd)= c41be08852baed71294623ea27ec7f64a3ac117f

real    0m17.130s
user    0m16.035s
sys    0m1.093s

То есть, типовая/привычная/понятная sha1sum, используемся везде и вся откровенный тормоз. Почему?

Да, тесты проведены корректно, до запуска хэширования страничный кэш Linux был прогрет и все тесты были проведены по 3-5 раз со сходными результатами.