How to sync Google Apps account with own LDAP installation

У цій статті я розкажу про установку та налаштування Google Apps Directory Sync. За допомогою GADS можна автоматично синхронізувати акаунти користувачів, груп, на стороні аккаунту Google, з сервером LDAP (наприклад, з Microsoft Active Directory або Lotus Domino, openLDAP та ін). Додаток підключається до каталогу Google Apps і додає або видаляє акаунти користувачів згідно з описаною політикою.

Для роботи GADS звісно необхідно працюючий LDAP-сервер, a про його установку я писав ось тут.

Установка може проходити на будь-якому сервері та операційній системі (окрім OS X), для ОС Linux програмі необхідний Xserver (точніше X11), адже програма не має повнофункціонального CLI-інтерфейсу. Надалі синхонізацію можна виконувати автоматично, наприклад, через cron, за допомогою sync-cmd.

Ілюстрація роботи GADS. Особливо то і нічого додати.

Shc: compile bash-script to binary view

Скоріш за все вам навіть це не спадало на думку, проте так, насправді, є можливість скомпілювати bash-скрипт у бінарний вигляд. Щоправда це не зовсім так, адже програма, мова про яку піде далі, спочатку транслює bash-скрипт в Cі-скрипт, а вже потім його компілює. Як наслідок, ніхто і ніколи не побачить того, що було "накостилячено" в скрипті. Проте таким чином також можна заборонити редагування коду чи приховати паролі, котрі вживаються в скрипті і мають бути недоступні всім іншим. 

Ім'я цієї програми Shc і, на щастя, вона відсутня в репозиторіях. Тому зкомпілюємо її :

# wget http://www.datsi.fi.upm.es/~frosal/sources/shc-3.8.9.tgz

--2013-11-12 01:40:16--  http://www.datsi.fi.upm.es/~frosal/sources/shc-3.8.9.tgz

Resolving www.datsi.fi.upm.es (www.datsi.fi.upm.es)... 138.100.9.22

Connecting to www.datsi.fi.upm.es (www.datsi.fi.upm.es)|138.100.9.22|:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: 20536 (20K) [application/x-gzip]

Saving to: ‘shc-3.8.9.tgz’

100%[====================================================>] 20 536      --.-K/s   in 0,1s    

2013-11-12 01:40:16 (150 KB/s) - ‘shc-3.8.9.tgz’ saved [20536/20536]

# tar xvfz shc-3.8.9.tgz

shc-3.8.9/CHANGES

shc-3.8.9/Copying

shc-3.8.9/match

shc-3.8.9/pru.sh

shc-3.8.9/shc-3.8.9.c

shc-3.8.9/shc.1

shc-3.8.9/shc.README

shc-3.8.9/shc.html

shc-3.8.9/test.bash

shc-3.8.9/test.csh

shc-3.8.9/test.ksh

shc-3.8.9/makefile

# cd shc-3.8.9

Dialog: ncurses-інтерфейс до shell-скрипта

Мабуть багато-хто якось думав, що було б непогано наділити власний скрипт графічним інтерфейсом. Навіщо він потрібен - це вже інше питання: наприклад, для людей, далеких від консольних програм, користування псевдографічним інтерфейсом буде зрозумілішим чи просто таким чином скрипт буде виглядати дещо професійніше або ж ви лише думаєте, що він необхідний - а насправді це просто марнування часу. Для реалізації таких простих інтерфейсів будемо використовувати програму dialog (ncurses-інтерфейс) та shell.

Звісно програму необхідно спочатку встановити:

# aptitude install dialog

Продемонструю його роботу з найпростішим case-скриптом.

#!/bin/bash

dialog --title 'Перезапуск мережі' \
       --yesno "Ви насправді бажаєте перезавантажити сервіс мережі на комп'ютері?" 10 40

case "$?" in
'0')
sudo service networking restart > /dev/null &2>1
echo 'Restarting...'
;;
'1')
exit 0
;;
-1|255)
echo "Сталась помилка, або ви натиснули ESC"
esac

Ключем "-yesno" вказуємо програмі dialog створити вікно з вибором "Так" чи "Ні", "--title" - встановлює назву вікна. Відповідь, що була обрана буде ідентифікуватись зі змінної $? (код завершення останньої команди). Тобто dialog буде повертати "0", якщо було обрано "Yes" та "1" - якщо "No". "10 40" - це позиція вікна, можна указати дефолтні - "0 0".

Також dialog повертає код "-1" у випадку, коли сталась помилка та "255", якщо було натиснено клавішу ESC.

Debug with Strace

Іноді програма не працює як необхідно: незрозуміло які вона читає налаштування чи сегфолтиться в самий непідходящий момент. Саме тому, коли необхідної інформації недостатньо в системних логах, буває корисно скористатись якимось простим деббагером і strace гарно виконує цю роль.

Strace - трасувальник системних викликів і сигналів, інакше кажучи деббагер, котрий здатний виводити результати в системний термінал. Працює в ОС Linux та деяких Unix-системах. Робота програми можлива завдяки системному виклику ptrace ("process trace") в ядрі ОС.

Для початку його необхідно його установити:

# apt-get install strace

Розпочнемо з найбільш простого прикладу: перевіримо, які системні виклики з'являються при запуску команди ls

$ strace ls
 execve("/bin/ls", ["ls"], [/* 49 vars */]) = 0
brk(0)                                  = 0x6ef000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa60c3a3000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=147033, ...}) = 0
mmap(NULL, 147033, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fa60c37f000
close(3)                                = 0
....
write(1, "8154c50c.jpg\t\t   Desktop\t\t\t  fil"..., 618154c50c.jpg  Desktop  films out.log  walls
) = 61
close(1)                                = 0
munmap(0x7fa60c3a2000, 4096)            = 0
close(2)                                = 0
exit_group(0)                           = ?

Network File System (NFS)

Network File System (NFS) — протокол мережевого доступу до файлових систем, що був розроблений компанією Sun Microsystems у 1984 році. Заснований на протоколі виклику віддалених процедур (ONC RPC, Open Network Computing Remote Procedure Call). Дозволяє підключати (монтувати) віддалені файлові системи через мережу.

    NFS надає клієнтам прозорий доступ до файлів і файлової системи сервера. На відміну від FTP, протокол NFS здійснює доступ тільки до тих частин файлу, до яких звернувся процес, і основна перевага його в тому, що він робить цей доступ прозорим. Це означає, що будь-який сервіс/програма клієнта, що може працювати з локальним файлом, із таким же успіхом зможе працювати і файлом, що доступний через NFS, без будь-яких модифікацій самої програми.

NFS-клієнти одержують доступ до файлів на NFS-сервері шляхом відправлення RPC-запитів на сервер.(c) Wikipedia

Процес монтування каталогу віддаленого NFS-серверу можна розбити на такі кроки:

1. На сервері та клієнті на 111 порту udp та tcp запускається RPC-сервер (представлений як rpcbind). Він завантажується разом із запуском NFS-демону.

2. Запускаються служби rpc.statd, rpc.idmapd, rpc.statd і тд., що реєструються на довільних мережевих портах.

3. Команда mount на клієнті створює запит (із вказанням ip/доменнейму, каталогу) на монтування каталогу до ядра ОС. На що ядро формує і відсилає запит на віддалений RPC-сервер, на сервер, де власне локально зберігається необхідний каталог.

4. Ядро NFS-серверу через rpcbind перевіряє наявність процеса rpc.mountd і повертає номер порту, на якому він працює (знову, використовуючи RPC-протокол), ядру клієнта, що надав запит на монтування.

5. Отримавши номер порту, mount відправляє RPC-запит на отриманий порт серверу. Надалі сервер перевіряє дозволи і надає відповідні права на запитану директорію.

6. Демон монтування rpc.mountd на NFS-сервері повертає опис запитаної директорії і на основі цих данних проходить монтування директорії. Надалі в дереві директорій вона буде представлена як звичайна директорія.

Доступ до файлу в директорії, що примонтована як NFS, відбувається через модуль ядра nfsd/nfs, котрий вже потім надсилає запит на віддалений RPC-сервер (зазвичай на порт 2049, що відповідає за роботу з NFS). Тобто для клієнтських програм, що запитують файл на віддаленому розділі не важливо, що це не локальний файл, адже всі додаткові операції виконує ядро ОС та модуль ядра nfsd/nfs.

Щоб дізнатись на яких портах працюють RPC-програми, можна виконати таку команду:

# rpcinfo -p

   program vers proto   port  service

    100000    4   tcp    111  portmapper

    100000    2   tcp    111  portmapper

    100000    4   udp    111  portmapper

    100000    2   udp    111  portmapper

    100024    1   udp  54107  status

    100024    1   tcp  56055  status

    100003    2   tcp   2049  nfs

    100003    4   tcp   2049  nfs

    100227    2   tcp   2049

    100003    2   udp   2049  nfs

    100003    4   udp   2049  nfs

    100227    2   udp   2049

    100021    1   udp  39802  nlockmgr

    100021    4   udp  39802  nlockmgr

    100021    1   tcp  32786  nlockmgr

    100021    4   tcp  32786  nlockmgr

    100005    1   udp  49768  mountd

    100005    2   udp  43705  mountd

    100005    2   tcp  54465  mountd

    100005    3   tcp  35113  mountd

RAID: теорія та практика

Жорсткий диск завжди вважався "вузьким" місцем системи в плані надійності і, зазвичай, швидкості. Саме тому людство придумало таку технологію як RAID, що здатна в певній мірі підвищити ці показники, проте звісно не без втрат. Про це і піде далі мова.

   RAID (англ. redundant array of independent/inexpensive disks) - надлишковий масив дисків, що покликаний підвищити надійність та/або швидкість роботи постійної пам'яті. В залежності від рівня, RAID буває:

1) RAID 0 - масив, як мінімум із 2-х дисків, дані на яких розподіляються частинами (блоками) і записується відповідно на кожен диск. Тобто кожен блок знаходиться лише на одному диску. Таким чином цей масив значно підвищує швидкість запису/читання проте аж ніяк не підвищує надійність.

2) RAID 1 - дзеркальний масив. Дані на кожному із дисків ідентичні. Організація масиву в RAID 1 підвищує швидкість  читання та рівень надійності дискової системи (при пошкодженні одного із дисків, система буде працювати з іншим робочим), але все це за рахунок втрати корисної ємності одного із дисків. Тобто використовуючи два диски місця буде доступно вдвічі менше, адже вони оперують тими ж самими даними.

Використання Logical Volume Manager (LVM)

Вирішив написати пару слів про LVM, адже використання цієї технології при налаштуванні серверів досить актуальне та і щоб просто не забути.

LVM (Logical Volume Manager) - менеджер логічних томів, додатковий рівень абстракції між фізичними (/dev/sda1, /dev/sda2 і  т.д.) та логічними томами ( /home, /root, /boot і т.д.), що значно підвищує гнучкість файлової системи. Використовуючи менеджер логічних томів, можна відносно легко змінювати розмір вже існуючих логічних томів (додавши новий HDD, можна просто пододавати місця на уже створені розділи, таким чином вирішивши проблему браку місця) чи робити бекапи без перевантаження/вимкнення/зупинки сервісів. Створення розділів з LVM не обмежене розміром фізичного диска, тобто один розділ може займати розмір декількох вінчестерів чи розділ може знаходитись частково на декількох HDD.

Отже схематично рівні знаходяться так:

PV- Physical volume, фізичний том. Це власне диск чи просто розділ на диску.
VG - Volume group, группа томів. Найвищий рівень абстрактної моделі LVS. До групи томів входять фізичні томи.
LV - Logical volume, логічний том. Власне це еквівалент звичайного розділу в не-LVM системі. В данному випадку Volume group поділяється на окремі розділи на зразок /dev/mapper/diskone, /dev/mapper/disktwo. Наділі кожний логічний том монтується в відповідну директорію /, /usr, /home і т.д.

Переходимо до практики. Перш за все встановимо пакет для підтримки LVM:

# apt-get install lvm2

Необхідно створити чи використати існуючі неформатовані розділи. За допомогою fdisk я створив два тестових розділи /dev/sda7 та /dev/sda8 і ініціалізував їх для використання як розділів для LVM:

# pvcreate /dev/sda7
# pvcreate /dev/sda8

Реплікація MongoDB: ReplicaSet

Зовсім нещодавно, я писав про реплікацію MySQL, тож хотілося б продовжити традицію. Цього разу мова піде про реплікацію MongoDB.

MongoDB підтримує два типи реплікацій Master-Slave (на кшталт такої в MySQL) та ReplicaSet. Остання - це прогресивніший варант, так як по-суті одразу забезпечує failover: обирання майстра, у разі відмови попереднього проходить "голосуванням" наявних інстансів (копій).  Це вже не кажучи про те, що ReplicaSet забезпечує читання зі слейвів (або як кажуть secondary-серверів), тим самим підвищуючи швидкість читання. Запити на запис відбуваються лише на головному (primary) сервері. Коротше кажучи, все вищесказане гарно ілюструє цей малюнок:

Приступимо до конфігурації. 3 інстанси демона MongoDB будуть запущені на локалхості, проте на різних портах.
Перед налаштуванням не забуваємо встановити базу данних.
Щоб не захламлювати систему створимо папку mongodb, а вже в ній папки 1, 2, 3 для кожної копії:

mkdir mongodb
cd mongodb
mkdir 1 2 3 

Запускаємо 3 копії демону mongod на портах 2700(1|2|3):

$ mongod --replSet test --dbpath 1 --port 27001 --smallfiles --oplogSize 50 --logpath 1.log --fork
forked process: 18922
all output going to: /media/other/mongodb/replication/1.log
child process started successfully, parent exiting

$ mongod --replSet test --dbpath 2 --port 27002 --smallfiles --oplogSize 50 --logpath 2.log --fork
forked process: 18983
all output going to: /media/other/mongodb/replication/2.log
child process started successfully, parent exiting

$ mongod --replSet test --dbpath 3 --port 27003 --smallfiles --oplogSize 50 --logpath 3.log --fork
forked process: 19029
all output going to: /media/other/mongodb/replication/3.log
child process started successfully, parent exiting

Nginx as reverse proxy for Apache

Усім відомо, що Apache є стандартом де-факто для веб-серверів. Розробники деяких CMS взагалі рекомендують користуватись саме Apache, і для налаштування їх під інший веб-сервер іноді необхідно попотіти. Але також ні для кого не є секретом, що Apache - важкий і ресурсоємкий сервер і на великих проектах від себе показує, м'яко кажучи, не дуже.

Тож одним із самих швидких варіантів оптимізації буде використання веб-серверу Nginx, як фронтенду до Apache. Тобто Nginx буде обробляти всю статику (запити на картинки, джаваскрипти, css і тд), а у випадку якщо відбудеться запит на php-скрипт чи щось таке (динамічний контент) - запит буде відправлено на обробку нашому "жирному" другу Apache-у.

Як показує практика такий варіант значно (!) економить ресурси серверу, адже запущених дочірніх процесів apache буде менше, з левовою часткою запитів буде справлятись Nginx.

Перейдемо до конфігурації.

1) Встановлюємо Apache (чи щось інше що буде у вас бекендом) та nginx з усіма запропонованими залежностями.

2) Конфігуруємо Nginx, щоб він слухав стандартний 80-порт і віддавав всю статику напряму, якщо буде запрошено динамічний контент  - запит буде відсилано Apache-y.

cat /etc/nginx/nginx.conf

# Використовуємо користувача від якого працює сервер Apache

user www-data;

# Кількість дочірніх процесів, обирають за к-тю ядер CPU

worker_processes 4;

worker_rlimit_nofile 8192;

# Місцезнаходження логу помилок і pid-файлу

error_log /var/log/nginx/error.log;

pid /var/run/nginx.pid;

events {

  worker_connections 1024;

  use epoll;

  accept_mutex off;

}

http {

  server_names_hash_bucket_size 64;

  include /etc/nginx/mime.types;

  default_type application/octet-stream;

  access_log /var/log/nginx/access.log;

  sendfile on;

  tcp_nopush on;

  keepalive_timeout 65;

  # Опції reverse proxy

  proxy_redirect off;

  proxy_set_header Host $host;

  proxy_set_header X-Real-IP $remote_addr;

  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

  # Опції gzip компресії.

  gzip on;

  gzip_http_version 1.0;

  gzip_comp_level 6;

  gzip_min_length 0;

  gzip_buffers 16 8k;

  gzip_proxied any;

  gzip_types text/plain text/css text/xml text/javascript application/xml application/xml+rss application/javascript application/json;

  gzip_disable "MSIE [1-6]\.";

  gzip_vary on;

  # Включення додаткових конфігураційних файлів

  include /etc/nginx/sites-enabled/*.conf;

}

Syslog-ng для централізованого збирання логів

Рано чи пізно постає питання про збирання логів всієї купи серверів, що у вас, у одному місці. І причин, щоб саме так зробити, є декілька: по-перше, так зручно, по-друге, - так безпечніше, адже логи будуть зберігатись в декількох місцях (як мінімум в двох). Коротше кажучи, якщо ви вже читаєте цю статтю - то ви маєте знати навіщо це вам.

Перейдемо до суті. Налаштування проводилось на двох тестових віртуальних машинах:

centos1 - 192.168.1.23
centos2 - 192.168.1.24

Тому на кожну із них встановлюємо syslog-ng. В CentOS це робиться наступним чином:

# yum install syslog-ng

Нехай centos1 буде головним syslog-ng сервером, що буде слухати 514-й порт, приймати всі логи і розкладати куди-треба. Centos2 буде відправником логів на перший сервер.

Конфігураційний файл syslog-ng на centos2, тобто відправника логів:

# Опис джерела всього потоку логів, що власне нас цікавить.

source s_all {

  internal();

  unix-stream("/dev/log");

  file("/proc/kmsg" program_override("kernel: "));

  file("/var/log/dmesg");

};

# Описуємо які саме файли потрібно буде відсилати. Перед відсиланням до 

# кожної рядка логу буде додано назву демона, який його відіслав 

# (за допомогою опції 'program_override').

source mysqld_log { file("/var/log/mysqld.log" program_override("mysqld")); };

source httpd_log { file("/var/log/httpd/error_log" program_override("httpd")); };

# Описуємо місце/сервер куди будуть відправлятись файли

destination remote { udp("192.168.1.23" port(514)); };

#Найголовніша частина: куди саме і які будуть відсилатись логи.

log { source(s_all); destination(remote); };

log { source(mysqld_log); destination(remote);};

log { source(httpd_log); destination(remote);};

Конфігураційний файл syslog-ng на centos1, тобто сервера, що ці логи прийматиме:

# Описуємо джерело логів - сервер мережі.Тобто логи, котрі прийшли на порт syslog-ng.

source s_udp { udp(ip(0.0.0.0)); };

# Описуємо фільтри. Параметр match означає, що обирати з усього потоку повідомлень 

# лише рядки з указаним значенням

filter mysqld { match("mysqld" value("MESSAGE")); };

filter httpd { match("httpd" value("PROGRAM")); };

# Місце куди будуть зберігатись логи.

destination df_remote { file("/var/log/remote/$HOST.other.log"); };

destination mysqld_log { file("/var/log/remote/$YEAR.$MONTH.$DAY/mysqld.log" owner("root") group("root") perm(0640) dir_perm(0750) dir_group("root"));};

destination httpd_log { file("/var/log/remote/$HOST.apache.log"); };

# Власне сам процес логування - це комбінація всіх вищезазначених параметрів.

log { source(s_udp); destination(df_remote); };

log { source(s_udp); filter(mysqld); destination(mysqld_log); };

log { source(s_udp); filter(httpd); destination(httpd_log); };

Тобто, все відбувається наступним чином:

1) Хост centos2 відправляє логи (всі системні логи+mysqld логи+apache логи) на centos1. Перед відправкою логи httpd помічаються значенням, що стоїть у параметрі program_override. Тобто кожен запис логу mysqld.log помітиться словом mysqld, відповідно httpd.log - словом httpd.

2) Логи, відіслані сервером centos2 приходять на centos1 і починають сортуватись. Всі логи загальні підуть в /var/log/remote/$HOST.other.log,а логи httpd та mysqld за допомогою директиви match будуть сортуватись в окремі папки.

Ну власне все, всі питання або зауваження пишіть в коментарі.

Посилання:

https://wiki.archlinux.org/index.php/Syslog-ng

http://www.balabit.com/sites/default/files/documents/syslog-ng-ose-v3.2-guide-admin-en.html/index.html-single.html
http://belgorod.lug.ru/wiki/index.php/%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_syslog-ng

Налаштування MySQL-реплікації типу Master - Master (Slave)

Власне налаштування  реплікації серверів баз даних - дуже важлива складова будь-якого High Load проекту. Надіюсь, що ця невеличка замітка допоможе комусь в освоєні даної теми,  або ж принаймні нагадає мені певні деталі з часом.  :)

Тож до справи!

Для початку опишимо певні деталі. Будемо вважати, що сервера мають такі айпі:

centos1 - 192.168.1.23
centos2 - 192.168.1.24

Редагуємо /etc/my.cnf сервера centos1. Додаємо до вже існуючих параметрів такі:

[mysqld]
# Номер сервера, що реплікується. У кожного має бути унікальний id.

server-id = 1

# Конфігурація сервера, як майстра. Указуємо, де будуть зберігатись бінлоги. 
# Бінлог - це список SQL-запитів (окрім SELECT та SHOW запитів ), що були виконані на сервері задля подальшої їх передачі на слейв.

log-bin = /var/lib/mysql/mysql-bin

# Конфігурація сервера, як слейва. Relay-log - лог дій, котрі були виконані на слейві за ініціативи майстра.
relay-log = /var/lib/mysql/mysql-relay-bin
relay-log-index = /var/lib/mysql/mysql-relay-bin.index
#База, що буде реплікуватись.
replicate-do-db = dbwordpress

Для сервера centos2 необхідно прописати ідентичні параметри, окрім значення 'server-id' (змініть цифру наприклад на 2).
Рестартуємо mysql на кожному сервері.

Веб-сервер за 5 секунд

Для швидкого підняття сервера задля роздачі файлів  найшвидким способом буде використання модуля SimpleHTTPServer для Python.
Все дуже просто:
1) Заходимо на потрібний хост:

ssh username@host -p port

2) Переходимо в директорію яку хочемо розшарити:

cd /path/to/dir

3) Виконуємо:

python -m SimpleHTTPServer

Сервер буде розміщуватись на 8000 порту. Дуже зручно задля швидкого розшарення великих файлів.

Знаю, для подібних цілей можна також використовувати netcat.

Встановлення програм на Playbook, використовуючи BB SDK

      Купивши планшет, одразу ж захотілось на нього щось встановити...Проте платити за програми, якими, можливо, і користуватись надалі не будеш, - не дуже хороша ідея. Ідеальний варіант: оцінив програму - купив, якщо ціна на неї в межах здорового глузду...

      Тож гугління на початку привело до DDPBInstaller-а та PB-Installer-a . Проте вони працюють лише в Windows-середовищі і зрозуміло, це не може виступати в якості нашої історії успіху.
До того ж додам, що вони досить таки помітно туплять при встановленні програм.

     Тож качаємо Blackberry SDK і встановлюємо:

cd ~/bbndk-2.0.1/
./bbndk.sh

*я роблю припущення що дистрибутив програми було завантажено у вашу домашню директорію.
     Додам скріншоти, щоб не здатись зовсім нудним.

Далі ще простіше. Переходимо в директорію:

cd ~/bbndk-2.0.0/host/linux/x86/usr/bin

І радісно виконуємо скрипт blackberry-deploy

./blackberry-deploy -password ваш_пароль -installApp -package /шлях/до/бар/файлу/example.bar -device айпі_планшету

Зрозуміло, що перед цим планшет потрібно перевести в development mode.

Ну ось наприклад як це буде виглядати в житті:

Просто ж підключити девайс можна виконавши команду:

mount -t cifs -o username=vasya.pupkin, password=qwe, rw //ip-playbook/media /media/playbook

Підключається планшет як Samba-сервер.

Додаткова інфа:

https://bdsc.webapps.blackberry.com/native/documentation/com.qnx.doc.native_sdk.devguide/com.qnx.doc.native_sdk.devguide/topic/t_perform_incremental_update_commandline.html

http://geekshuiliving.com/2011/07/23/sideloading-apps-on-the-playbook-and-android-apps-as-well-a-how-to/

http://nex.scrapping.cc/articles/mount-blackberry-playbook-via-usb-on-linux.html

Налаштування Nagios 3 + NRPE

В цій статті хочу коротко описати про налаштування системи моніторингу Nagios. Надалі планую статтю доповнити. Тож приступимо.

1) Встановлюємо необхідні пакети:

# apt-get install nagios3

По залежностях має потягнути за собою купу всього разом з апачем.

apache2-mpm-prefork apache2-utils apache2.2-bin apache2.2-common bsd-mailx libapache2-mod-php5 libapr1 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap

  libgd2-noxpm libnet-snmp-perl libpq5 libradius1 nagios-images nagios-plugins nagios-plugins-basic nagios-plugins-standard nagios3-cgi nagios3-common

  nagios3-core php5-cli php5-common postfix snmp whois

2) Створюємо юзера та пароль:

# cd /etc/nagios3; htpasswd -c htpasswd.users nagiosadmin

Тепер можна залогінитись на нагіос і побачити приблизно таке:

Боротьба з КПІ-Телеком.

Деякі "розумні" провайдери можуть визначати клієнтів які знаходяться "за NAT-ом". Тобто припустимо ситуацію, що ви купили роутер правильно його налаштували, NAT-IP присвоївся, мало б усе працювати, але от біда, не працює. На преший погляд тупикова ситуація, але не все так безнадійно...

Певні провайдери можуть визначати наявність додаткового роутера у мережі, читаючи значення TTL (time to live) в мережевих пакетах, що ви відсилаєте. TTL- це так би мовити час життя пакету, коротше кажучи, його придумано для того, щоб пакети не блукали постійно в мережі і самознищувались. Проходячи через кожен роутер, його значення частіше за все падає на одиницю.

З іншої сторони, наприклад, iptables на роутері (гейтвеї) фільтрує трафік і знищує всі пакети з нестандартним TTL ( а частіше знищує пакети з певним TTL, типу з 128-1=127 (windows) чи 64-1=63 (*nix) ), таким чином визначаючи наявність вашого роутера. Далі представлено такий собі воркераунд . :)

Логічно припустити, що треба зробити так, щоб пакети відправлені з вашої клієнської машини на роутер були вже на один більшими, тобто TTL мав значення 65. (пакет приходить на роутер - значення падає до 64 - пакет відсилається на шлюз провайдера, і так як його значення дефолтне, направляється далі куди треба).

Міняємо значення ТТL на тачці. На Windows це робиться приблизно так http://winitpro.ru/index.php/2010/10/28/menyaem-znachenie-time-to-live-ttl-v-windows-server-2008vista7/ , значення, зрозуміло, має бути наприклад, 129. Якщо результату не досягнуто - спробуйте встановити 65.

На лінуксі все навіть простіше:

# echo 65 > /proc/sys/net/ipv4/ip_default_ttl

Додаємо команду в автозагрузку в /etc/rc.local чи як pre-up в загрузку мережі в /etc/network/interfaces.

Деякі відносно нормальні роутери вміють не змінювати TTL:

Але це, насправді, не дуже нормальна практика.

dig. Копаємо DNS

Приводом до написання статті послужила так би мовити відсутність нормального російсько чи україномовного хавту в інтернеті. Тож спробую нейтралізувати такі пробіли.

Як відомо, dig - програма з CLI-інтерфейсом, що призначена для опитування DNS-серверів на предмет інформації про хост що нас цікавить і тд. Спробую пояснити на конкретних прикладах.

1) Почнемо з найтривіальнішого прикладу, спробуємо дізнатись дані про перший доменнейм, який прийшов нам на думку (одразу в самому виводі прокоментую що значить виведене):

:~$ dig ubuntu.com

#Програма розповідає трішки про себе (версія програми) та про глобальні опції котрі вона використовує. 

; <<>> DiG 9.7.1-P2 <<>> ubuntu.com

;; global options: +cmd

#dig написав про деякі технічні деталі, які він отримав від ДНСа.

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64973

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 0

#Якщо нічого не вказувати в запиті, то по замовчуванню йде запит на наявність A-запису на ДНС-сервері. Власне це нагадування dig-а, щодо того який запит ми зробили.

HOWTO: Фоновий режим, або як правильно запускати програми з консолі

Напевне часто буває шо запустив програму з консолі, програма ще потрібна, а тримати вікриту консоль не хочеться. І як зробити шоб кносоль "відпустив програму"?

І так давайте поексперементуємо...
Виберема якусь програму (бажано гуішну) шоб швидко запускалась і безболісно закриваась) Я візьму gnome-calculator

1) Відкрийте ваш улюблений термінал і запустіть звідти вашу прогу.

gnome-calculator

програма запуститься. Тепер натиснувши Ctrl-C або закривши термінал закриється і ваша програма (ну надіюсь це було ясно і без моїх підказок)

2) а тепер запустимо те саме але з символом '&' в кінці

gnome-calculator &

Калькулятор запустився але в консольці вивелось шось типу
[1] 8631
і термінал не "тримав" вашу програму... Але не спішіть радіти - при закритті терміналу все ж закриється і наш калькулятор.
Давайте подивимось все таки шо це за [1] 8631?

Але спочатку запустіть просто калькулятор без усяких амперсантів

gnome-calculator

тепер в консолі яка його тримає натиснемо Ctrl-Z. Ми призупинили нашу програму. Можете побачити що вона не реагує навіть на натискання миші. Але не треба закривати - вона не зависла)
доречі в терміналі знову бачимо ті ж [1] 8631. І так...

в квадратних дужках номер задачі ("job"). Тепер ми можемо нею управляти.
введемо

jobs

там буде шось типу

[1]+ Stopped gnome-calculator

для переведення програми в фоновий режим введемо

bg 1

(bg - background)
де 1 - номер задачі. Побачимо що прогрмам "відвисла" і відновила роботу.
Щоб перевести курування програмою (консольний ввід) переведемо задачу "на передній план"

fg 1

... і ми знову тримаємо програму нашою консолю

Примітка: команди fg, bg можна було юзати без аругументів - тоді вони виконують управляють задачею яка позначена плюсом (+) в джобсах

А тепер кульмінація

nohup gnome-calculator

тепер по Ctrl-Z , bg переведемо задачу в фоновий режим.
Ну і все. можете закрити консоль а ваш калькулятор залишиться на вашому екрані.
Щоб ще швидше використовуйте

nohup gnome-calculator &

тоді програма автоматом переведеться в фоновий режим і не тримається консолю
Можна сміливо закривати термінал