FastNetMon

среда, 16 марта 2016 г.

Возгорание в ДЦ Selectel

Волею судеб у нас на этой площадке находится оборудование: http://www.fontanka.ru/2016/03/16/116/

Да, оно резервировано на другую площадку - поэтому никакой угрозы дорогим клиентам нету :)

Но вот что нас убило, так это то, что было в первую очередь эвакуировано из Дата Центра.

Оставляю фотографию без комментариев:

Да, это Динозавр. 

понедельник, 14 марта 2016 г.

Активация kernel dump's на Ununtu 14.04

Создаем папку для дампов памяти падающих программ:
mkdir -p /var/log/dumps
chmod -R 755 /var/log/dumps
Указываем путь для сохранения дампов явно:
echo 'kernel.core_pattern = /var/log/dumps/core.%e.%p' > /etc/sysctl.d/10-coredump.conf
sysctl --system
Также если существует файл /etc/default/apport в него нужно вписать:
enabled=0

Иначе при ребуте он пропишет свою программу вместо обычного сбора дампов на диск.

Далее нам нужно для конкретного приложения, которое мы собираемся отлаживать задать актвиацию дампов памяти:

Стандартно дампы отключены:
# ulimit -a|grep core
core file size          (blocks, -c) 0

# ulimit -c unlimited
# ulimit -a|grep core
core file size          (blocks, -c) unlimited

Много советов в сети, что активировать дампы "правильно" нужно через /etc/security/limits.conf, но это не так, это будет работать лишь в случае, если сервис использует PAM, а это очень часто НЕ так.

Так что нужно в блоке start init.d скрипта, который запускает интересующую Вас программу добавить строку: 
ulimit -c unlimited
После того, как прописали это для сервиса, перезапускаем его и убвеждаемся, что дампы включены (18829 - здесь PID процесса, дамп памяти которого Вы хотите в результате получить):
cat /proc/18829/limits |grep core
Max core file size        unlimited            unlimited            bytes  

Отладка Upstart

Довольно просто :)

Открываем конфиг:
vim /etc/default/grub
Там правим:
GRUB_CMDLINE_LINUX_DEFAULT="--verbose"
После этого апаем grub:
update-grub2 
И ребутимся :) После этого логи будут писаться прямо в dmesg, где можно проверить корректность и последовательность запуска сервисов.  

В gcc 5.3 сломали бинарную совместимость с clang (и всеми прочими компиляторами) :(

В "фиче" виноваты разработчики gcc: https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.6/+bug/1488254

По мотивам бага есть бага в трекере clang, где его авторы пытаются вернуть поддержку совместимости: http://reviews.llvm.org/D12834

А пока же попытка слинковатся силами clang с библиотекой (с поддержкой С++11), собранной силами gcc 5.3 обречена на провал.

Ошибочки будут вот такие:

/root/fastnetmon/src/fastnetmon.pb.cc:(.text+0x16e6): undefined reference to `google::protobuf::internal::empty_string_'

понедельник, 7 марта 2016 г.

Установка модуля testcookie для Nginx без рекомпиляции Nginx

Мы обсуждаем, что берем Nginx и ставим его на Debian 7 или 8, на котором уже работает nginx из пакетов с сайта nginx.org.

Ставим Nginx из репозитория с офсайта.

Проверяем его версию:
nginx -V 2>&1|grep "nginx version"
nginx version: nginx/1.9.12

Потом там же берем опции компиляции:
nginx -V

Стягиваем модуль:
cd /usr/src
git clone https://github.com/kyprizel/testcookie-nginx-module.git

Ставим зависимости:
apt-get install -y libxml2-dev libxslt-dev libgd2-xpm-dev libgeoip-dev 
Собираем модуль:

cd /usr/src
wget 'http://nginx.org/download/nginx-1.9.12.tar.gz'
tar -xzvf nginx-1.9.12.tar.gz
cd nginx-1.9.12/
# configure параметры берем из выдачи nginx -V выше
./configure --add-dynamic-module=/usr/src/testcookie-nginx-module --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/etc/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic --with-http_geoip_module=dynamic --with-threads --with-stream --with-stream_ssl_module --with-http_slice_module --with-mail --with-mail_ssl_module --with-file-aio --with-http_v2_module --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,--as-needed' --with-ipv6
Собираем:
make

Потом берем бинарик:
mkdir /etc/nginx/modules
cp ./objs/ngx_http_testcookie_access_module.so /etc/nginx/modules

И добавляем в nginx.conf в самом верху:
load_module "modules/ngx_http_testcookie_access_module.so";

Если мы собирали не под ту версию, то в ответ получаем (и идем собирать под нужную):
[....] Restarting nginx: nginxnginx: [emerg] module "/etc/nginx/modules/ngx_http_testcookie_access_module.so" version 1009011 instead of 1009012 in /etc/nginx/nginx.conf:8

Получаем облом, если использованные параметры будут отличаться от тех, с которыми собран наш nginx:
[....] Restarting nginx: nginxnginx: [emerg] module "/etc/nginx/modules/ngx_http_testcookie_access_module.so" is not binary compatible in /etc/nginx/nginx.conf:8


Перезагружаем:
service nginx restart

Убеждаемся, что все загрузилось:
cat  /proc/5731/smaps |grep test
7f18c8441000-7f18c8448000 r-xp 00000000 09:02 6035144                    /usr/lib/nginx/modules/ngx_http_testcookie_access_module.so

суббота, 5 марта 2016 г.

Монтирование папки с удаленного сервера силами SSH на Mac OS X El Capitan

Сначала стягиваем и ставим Fuse For OS X 3ю версию:
https://sourceforge.net/projects/osxfuse/files/osxfuse-3.x/

При установке явно ставим флажок MacFux Compatibility Layer!

Потом стягиваем и ставим актуальную версию файла sshfs-X.pkg отсюда: https://github.com/osxfuse/sshfs/releases 

Монтируем:
mkdir remote
sshfs root@IP: remote
Предыдущий способ был бесконечно медленный, поэтому полез в интернеты за рецептами и нашел, что помогло мне:
sshfs root@IP:/root remote -o auto_cache,reconnect,defer_permissions,noappledouble
Отмонтировать можно как обычный диск через Finder, но у меня этот способ не сработал!

Поэтому для отмонтирования используем:

umount -f remote
Источник: сайт