Translate

неділя, 16 грудня 2012 р.

Налаштування 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 на кожному сервері.

понеділок, 9 липня 2012 р.

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

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

ssh username@host -p port

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

cd /path/to/dir

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

python -m SimpleHTTPServer

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


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

понеділок, 30 квітня 2012 р.

Встановлення програм на 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-сервер.

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


неділя, 4 березня 2012 р.

Blackberry Playbook. Чи варто купувати?


Так вже сталося, що ціна в 200 $ вплинула на моє рішення купити планшет. Після моїх роздумів був обраний Blackberry Playbook, не останню роль зіграв при цьому його розмір. Плюс я не зміг спокійно дивитися на його багатозадачність :)
Швиденько пробіжусь по його технічних характеристиках і якості виготовлення.
Отже, наш корпоративний друг ховає в собі:
- 7 " екран з розширенням 1024x600, зрозуміло, що сенсорний.
- Двох ядерний процесор ARM Cortex A9 (1 ГГц)
- Оперативну пам'ять 1 ГБ ( одразу після завантаження, ОС вже споживає половину )
- 16, 32 чи 64 Гб постійної пам’яті
- Роз'єми microUSB, microHDMI. Останній, як виявилось дуже навіть потрібний.
- Дві камери: фронтальна (3Мп) та тилова (5Мп). Автофокусу немає, проте вміє знімати відео високої якості, що навіть не соромно потім комусь його показати.
- Батарею Li-Pol (5300 мАг). Тримає заряд до біса довго. (біля 7 годин відносно активного використання)
Одним словом, потужності йому більше ніж досить. Йдемо далі.
Виглядає девайс так:

четвер, 8 вересня 2011 р.

Налаштування 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

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

неділя, 4 вересня 2011 р.

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


Деякі "розумні" провайдери можуть визначати клієнтів які знаходяться "за 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:


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

понеділок, 2 травня 2011 р.

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-а, щодо того який запит ми зробили.