Валидация данных в PHP при помощи filter_var

Основой безопасности любого приложения является простое правило: «пришедшим от пользователя данным доверять нельзя». Для этой цели пишется довольно большое количество кода, хотя типичные задачи можно решить стандартными средствами PHP ничего не изобретая.

Например, таким образом можно проверить адрес e-mail при помощи filter_var:

if (filter_var($user_email, FILTER_VALIDATE_EMAIL)) {
// правильный
}

также можно убрать лишнее, например, из URL:

$sanitized_url = filter_var($url, FILTER_SANITIZE_URL);

Хотя filter_var() есть в стандартном PHP начиная с версии 5.2.0, документация на него, особенно русская, хромает.

Нормальная документация и примеры:
Руководство w3schools.
Input Validation: Using filter_var() Over Regular Expressions.
Data Filtering Using PHP’s Filter Functions

MySQL: utf8_unicode_ci или utf8_general_ci?

Какую таблицу из двух выбрать для своей базы данных в случае использования UTF?

utf8_general_ci
Убирает все акценты и приводит к верхнему регистру: ÀÁÅåāă = A, ü = U.
Не очень точно отрабатывает при сортировках. Иногда полезно при поиске. Быстрее utf8_unicode_ci.

Подходит для Русского. При использовании Белорусского и Украинского сортировка будет не верной.

utf8_unicode_ci
Довольно точно при сортировке и поиске. Например, ß (немецкий эсцет) будет при сортировке располагаться рядом с ss, как ему и положено. Медленнее utf8_general_ci.

Замечательно подходит для Русского, Белорусского и Украинского.

Итог
Если проект исключительно русскоязычный и скорость поиска и сравнения критична — можно остановится на utf8_general_ci. Если же есть планы по поддержке большего количества языков — лучше использовать utf8_unicode_ci.

Полные таблички utf8_unicode_ci и utf8_general_ci (там, кстати, и все остальные есть).

MySQL: How do you set up master-master replication in MySQL?

Setting up master-master replication in MySQL is very similar to how we set up master/slave replication. There is obviously pros and cons about using master/master replication. But this is not a post which discuses advantages and disadvantages for using master/master replication. One of the differences between master/master set up and master/slave is that in master/master set up, you have true redundancy. If one server dies, second server can take all the inserts/selects. In master/slave setup, if master dies, you will have to go through steps to make slave become the master. Master/master set up we are going to set up is essentially master/slave and slave/master. Meaning, if you had two servers, db0 and db1, your setup will be db0(master)/db1(slave) and also db0(slave)/db1(master). Here are some assumptions:

Master1 server ip: 10.0.0.1
Master2 server ip: 10.0.0.2
Slave username: slaveuser
Slave pw: slavepw
Your data directory is: /usr/local/mysql/var/

Read the rest of this entry »

Tip: запускать задачу раз в месяц в субботу

Часто необходимо запускать что-то (например полный бекап бд) раз в месяц, но в выходной, допустим в ночь с субботы на воскресенье.

Это можно сделать в crontab следующим образом

0 23 * * 6 [`date "+%d"` -lt 8] && /path/to/script

Это запустит скрипт в первую субботу месяца в 23:00.

MySQL Performance Tuning Primer Script

MySQL Performance Tuning Primer Script
http://www.day32.com/MySQL/
http://www.day32.com/MySQL/tuning-primer.sh

This script takes information from “SHOW STATUS LIKE…” and “SHOW VARIABLES LIKE…”
to produce sane recomendations for tuning server variables.
It is compatable with all versions of MySQL 3.23 and higher (including 5.1).

Read the rest of this entry »

MySQL performance tuning

This document serves as a starting point for MySQL performance tuning. This document is a combination of research and experience. When I started this document, I utilized a great Google video [1] as a reference for the document structure and many bullet items. I would suggest watching this video. I then filled in a few blanks, and combined a few other articles into this overview.

You may also want to check out this good article from MySQL on performance tuning.. Now onto the show..

Benchmarking

As with all improvement activities, it is better to start with a known problem area that is able to be defined, or an activity where improvement will provide maximum benefit (the 80/20 rule works everywhere). Nobody can really grasp an intangible goal like “we want to achieve excellence” [4].

The following are decent guidelines to start with [1]:
» Target. You must have a target.
» Establish a baseline.
» Change only one thing at a time (if possible).
» Record Everything, you will need it at some point.
» Optionally disable query_cache, by setting query_cache_size = 0 for benchmarking.

Read the rest of this entry »

Файловая система FreeBSD: иерархия и монтирование

Созданием разделов и файловых систем на них дело подготовки дискового пространства к использованию не заканчивается. Все созданные файловые системы нужно еще сделать доступными для FreeBSD. Для чего они должны быть смонтированы — то есть включены в единую иерархию каталогов и файлов, для обозначения которой также используется название файловой системы. Однако если раньше речь шла о физической организации данных, то теперь пора ознакомиться с ее логикой.
Логика файловой системы

Логически файловая система FreeBSD (как и любой Unix-системы) организована по древовидному принципу: в основании ее лежит корень (корневой каталог, обозначаемый символом / и именуемый также root-каталогом; последнее не должно путать с каталогом /root, который выполняет роль домашнего для суперпользователя). От корневого каталога, который можно уподобить скорее стволу дерева, отходят ветви — вложенные в него подкаталоги, и побеги — обычные файлы. Последних, правда, немного: в версиях FreeBSD 5-й ветки это пара профильных файлов — /.cshrc и /.profile, на самом деле дублирующие профильные файлы суперпользователя (в каталоге /root), некий энтропийный (/entropy) файл и файл с описанием авторских прав на систему /COPYRIGHT. Read the rest of this entry »

Unix для детей

cat-head-tail-copy

cat file – вывод содержимого файла (целый кот)
head file - вывод первых нескольких строк файла (голова кота)
tail file – вывод последних нескольких строк файла (хвост кота)

Архитектура Skype

Skype – известная система интернет-телефонии, которой пользуется очень много народу по всему миру. Разберемся как оно работает.

Skype для работы использует P2P соединения, а не клиент-серверную модель. Что неудивительно, если вспомнить, что авторы Skype – те же люди, что работали над Kazaa. Однако совсем от клиент-серверной архитектуры им отойти не удалось. У них есть логин-серверы – это единственной централизованный компонент Скайпа (список серверов, к которым надо коннектиться запрятан в исходники Скайповского клиента). И этот единственный централизованный компонент их как-то раз подвел. В 2007 году пользователи Скайпа не могли с ним работать в течение двух дней. Причиной было то, что был выпущен Виндовый патч, который вызвал ребут всех пользовательских машин. Машины ребутнулись и стали дружно логиниться. Сервера Skype были погребены под огромный количеством одновременных логинов.

P2P соединения – это, конечно, хорошо. Однако как быть, если два пользователя, которые хотят сконнектиться, сидят за фаирволлами? Skype борется с симметричными NATами и фаирволлами следующим образом – гонит трафик через тех пользователей, кто не сидит за фаирволлом. Вообще в скайповской сети машины подразделяются на ноды – обычные машины, суперноды – которые разруливают трафик нодов, ну и на их собственные логин-серверы. Так вот, если у вас публичный IP адрес, достаточная мощность CPU, много памяти и пропускная способность сети не подкачала, то вы – супернод! И через вас пойдет чужой трафик. :-)

В качестве базы данных для работы Skype использует PostgreSQL. Но им пришлось PostgreSQL под себя затачивать. Результаты заточки распространяются под BSD лицензией. Лежат тут. Недавно поставили себе амбициозную цель: PostgreSQL должен масштабироваться до одного миллиарда пользователей.

Исходники Скайпа закрыты, протокол тоже закрыт. Есть, правда, Skype API, который позволяет расширять пользовательский интерфейс. Однако пытливые умы ковыряются в скайповском протоколе и находят интересные вещи. Есть очень известный доклад Vanilla Skype, в котором подробно рассказывается об особенностях работы Скайпа и о потенциальных его уязвимостях.

Еще парочка фактов: Для передачи звука они используют Global IP Sound (GIPS). Железо – dual или quad Opteron’ы со SCSI RAID.

Ссылки по теме:
Доклад Vanilla Skype part1[.pdf] и part2[.pdf]. Можно посмотреть видеозапись этого доклада. Осторожно, английский с сильным французским акцентом.
Skype Protocol – статья в Википедии
An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol – довольно старые слайды
Иван Золотухин в своем докладе на РИТ2007 немного говорил о скайповском PostgreSQL.

Быстрая передача файла через псевдо-HTTP

Когда есть необходимость передать файл с одной машины на другую,
а под рукой нет общедоступных ресурсов, можно сделать так:

    nc -l -p 8080 < file

или

    netcat -l 8080 < file

на клиенте достаточно в браузере набрать http://192.168.0.123:8080

Собственно, все. Впрочем, если получатель – блондинка, которая не знает команды File-Save, можно написать так:

   (echo -e "HTTP/1.1 200\nContent-Disposition: attachment;
   filename=gena_na.png\nContent-Type: application/octet-
   stream\nConnection: close\n"; cat vim_mrxvt.png ) | nc -vv -l -p 8080

Но это еще не все. Можно дать доступ к целой директории, написав простой HTTP сервер в одной строке:

   while true; do nc -vv -l -p 8080 -c '( read a b c; file=`echo $b | sed 's/[^a-z0-9.]//g'`;
   if [ a$file = "a" ]; then ( ls | (while read f; do echo "<a href=$f>$f</a><br>"; done) );
   else cat $PWD/$file; fi )'; sleep 1; done

Этот скрипт отдает все файлы, которые есть в текущем каталоге и не позволяет его сменить.
В случае, если запрашивается корневая директория, то управление передается
своеобразному mod_index – т.е. выводится список файлов-ссылок. В конце добавлена задержка в 1 сек для того, чтобы была возможность убить его нажатием Ctrl-C.