find . -name '*.php' | while read i; do iconv -f WINDOWS-1251 -t UTF-8 "$i" >tmp; mv tmp "$i"; done

и все файлы *.php в этой папке перекодируются в UTF-8.
Список доступных кодировок можно вывести командой iconv -l

openssl x509 -in input.crt -out input.der -outform DER

then

openssl x509 -in input.der -inform DER -out output.pem -outform PEM

Менее «фичастый» и более удобный для работы Instant SQL Formatter. Пример работы можно посмотреть здесь. ]]> http://iphp.com.ua/archives/526/feed 0 http://iphp.com.ua/archives/522 http://iphp.com.ua/archives/522#comments Tue, 16 Mar 2010 20:55:40 +0000 admin http://iphp.com.ua/?p=522

Synergy+ (synergy-plus) lets you easily share a single mouse and keyboard between multiple computers with different operating systems, without special hardware. All you need is a LAN connection. It’s intended for users with multiple computers, where each system uses its own display. It’s a little like having a 2nd or a 3rd desktop…

http://code.google.com/p/synergy-plus/

Решение:

Откройте редактор реестра, найдите ключ

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Servic es\SPTD

и измените значение Start на 4.

Теперь перезагрузите компьютер и вернитесь к этому же ключу. Смените права доступа к ключу — нажмите правой кнопкой на ключе, «Разрешения…» и выставьте «Полный доступ» для всех.

Удалите этот ключ, перезагрузите компьютер и установите Daemon Tools еще раз.

Принцип данной реализации следующий. Весь сетевой софт на компе (ну или не весь) форвардится на назначенный порт (вашего локалхоста), на котором висит сервис, соединенный по SSH с сервером (а как мы знаем, соединение по SSH протоколу шифруется) и туннелирующий все запросы; далее, весь ваш трафик (уже не в зашифрованном виде) может форвардится с нашего сервера на прокси (поддерживающий туннерирование) или сокс, который передают весь трафик к необходимым адресам. Наличие прокси или сокса не обязательно, но если нам нужна полнейшая конспирация, то мы можем организовать данный сервис (proxy/socks) на другом сервере (данная схема нужна для создания цепочки адресов), но об этом позже.

Теперь давайте разберемся с минимальным набором инструментов и сервисов необходимых для организации данного процесса. В первую очередь нам нужна программа для организации туннеля по SSH-протоколу. Для этой задачи мы можем применить VanDyke Entunnel (http://www.vandyke.com/products/entunnel/) или Putty (http://www.web-hack.ru/download/info.php?go=35) (вкладка Connection\SSH\Tunnels). В наших примерах я буду использовать оба клиента. Далее мы можем вручную прописывать в каждой программе работу через прокси или использовать специализированную программу для перенаправления запросов, такую как ProxyCap (http://proxylabs.netwu.com), SocksCap (http://www.socks.nec.com), FreeCap (http://www.freecap.ru) и т.п. В нашем примере будет использоваться ProxyCap, как наиболее удобная софтина (кстати, через ProxyCap мы сможем сделать туннерирование даже WebMoney, которая известна защитой от такого вида софта, для скрытия IP). Так же нам понадобится SSH-аккаунт (на сервере желательно расположенном за пределами вашей страны =), который можно без проблем достать (например, я покупаю VPS-хостинг для этого) и socks`ы.

Первым делом создаем SSH-аккаунт. Далее, я предлагаю вам использовать socks-сервер, а не proxy, т.к. не все прокси поддерживают туннелирование. Также может оказаться, что сегодня прокси анонимный, а завтра уже и не нет (если, конечно, не вы сами отвечаете за него). Кстати, проверить свою анонимность можно здесь (http://ip.xss.ru). Как я уж говорил, мы можем использовать сокс на удаленной машине (для большей безопасности). Для примера я покажу, как установить сокс-демон. Наиболее популярные и продвинутые демоны под никсы это socks5 от Permeo/NEC (http://freeware.sgi.com/source/socks5/), Dante (http://www.inet.no/dante/) и отечественный продукт 3proxy (http://www.security.nnov.ru/soft/3proxy/). Для примера я выбрал классический демон на FreeBSD — socks5.

Для тестирования использовалась FreeBSD 5-ой ветки. Я устанавливал socks5 из портов (/usr/ports/net/socks5/), но и из сорцов под фряхой тоже все хорошо собирается и ставится:

cd /usr/ports/net/socks5/
make install clean
rehash

Для нормальной работы демона необходим конфиг к демону socks5.conf и файл паролей socks5.passwd (если необходима аутификация к сокс-серверу по паролю):

touch /usr/local/etc/socks5.conf
touch /usr/local/etc/socks5.passwd

Далее добавляем в конфиг следующие строчки:

auth - - u
permit u - - - - -
SET SOCKS5_BINDINTFC 1.2.3.4:8080
SET SOCKS5_CONFFILE /usr/local/etc/socks5.conf
SET SOCKS5_PWDFILE /usr/local/etc/socks5.passwd
SET SOCKS5_MAXCHILD 128
SET SOCKS5_NOIDENT
SET SOCKS5_NOREVERSEMAP
SET SOCKS5_NOSERVICENAME
SET SOCKS5_V4SUPPORT
SET SOCKS5_ENCRYPT
SET SOCKS5_FORCE_ENCRYPT
SET SOCKS5_UDPPORTRANGE 1023-5000

Первые две строчки указывают, что необходима аутификация по логин/пароль. SOCKS5_BINDINTFC указывает на какой IP (если у сервера несколько алиасов) и порт повесить демон. SOCKS5_MAXCHILD по умолчанию 64, я советую увеличить до 128, чтобы всем юзерам (если их много) хватило потоков. Далее, идут строчки для ускорения работы демона. SOCKS5_V4SUPPORT — поддержка 4-ой версии протокола. SOCKS5_ENCRYPT и SOCKS5_FORCE_ENCRYPT поддержка шифрования, если клиент это поддерживает. За более подробной информацией по установка обращайтесь к файлам README и INSTALL, а за информацией по настройке к манам socks5(1) и socks5.conf(5).

Далее, заполняем файл паролей. Он имеет обычный текстовый формат и login/password разделяются в нем пробелами:

user password
root toor

Теперь можно запускать демон и приступить к настройке клиентского софта:

/usr/local/bin/socks5

Запускам ProxyCap (http://forum.web-hack.ru/index.php?showtopic=29262), кликаем правой кнопкой мыши на значке в трее, Preferences. На вкладке «Proxies» вписываем 127.0.0.1:8080 и устанавливаем в «Require Authorization» наш login/password на сокс. На вкладке «Rules» добавляем сначала правило для Entunnel, указав в «Rule Type» — Force direct connetion. Далее, создаем правило, для всего остального софта, трафик от которого будет шифроваться и туннелироваться через сокс. В правиле указываем «All Programs», «Tunnel through proxy» и в выпадающем меню наш сокс. Так же можно создать правило не для всего софта, а только выборочный софт пускать через туннель или наоборот, создать правило для всего софта, но для некоторого софта сделать прямой доступ в инет (Force direct connetion). В качестве дополнения могу сказать, что если ваша сетевая программа поддерживает работу через сокс/прокси (и нет необходимости пускать сразу весь сетевой софт через туннель), то в качестве настроек прокси вы можете указать забинденный Entunnel`ем адрес и порт — 127.0.0.1:8080.

Запускаем Entunnel и создаем в нем новое соединение по SSH. Далее, в свойствах соединения (Port Forwarding) добавляем наш сокс. В категории «Local» вписываем 127.0.0.1:8080, а в категории «Remote» вписываем IP и порт нашего сокс-сервера. Настройка закончена! Если что-то не работает, то еще раз перечитайте все пункты настройки.

В случае, если вы хотите использовать SSH-аккаунт, как конечную точку (т.е. не юзать соксы или прокси), то ваши настройки должны быть следующие (на примере для Putty): на вкладке Connection\SSH\Tunnels в строке «Source port» указываем порт, на который Putty забиндится на локалхосте (например, 8080), далее ставим влажок на «Dynamic» и идем на вкладку «Session» прописывать адрес и порт сервера с SSH. Коннектимся…

Какие плюсы данной системы:

1. Для организации данной схемы не нужно устанавливать серверный софт (т.к. SSH-аккаунт и сокс можно без проблем достать в инете);
2. Т.к. при SSH-соединении трафик шифруется и сжимается, то мы получаем небольшой прирост скорости работы в инете (это верно, когда сокс-демон находится на том же сервере);
3. В случае, когда сокс-сервер находится на другом хосте, то мы получаем дополнительную цепочку серверов, которые повышают нам безопасность и анонимность;

1) создаем открытый и закрытый ключ нашей локальной системы
$ ssh-keygen -t rsa
жмем энтер отказываясь от ключевой фразы

2) если в системе есть программа ssh-copy-id, то настраиваем удаленную систему на то, что бы оно авторизировало ssh по открытому ключу
$ ssh-copy-id -i ~/.ssh/id_rsa user@remote.org.ua
переходим к шагу 4)

3) если ssh-copy-id нет то можно сделать это ручками. вот последовательность действий с объяснениями

3.1) копируем открытый ключ на удаленную систему
$ scp ~/.ssh/id_rsa.pub user@remote.org.ua:~ незабываем ввести пароль. ведь мы еще не настроили беспарольный вход Ж:-)

3.2) логинимся на удаленный сервер
$ ssh user@remoute.org.ua

3.3) заносим открытый ключ нашей локальный системы в авторизированые ключи удаленной системы, устанавливаем правильные права и убираем за собой мусор:
remote$ [ -d ~/.ssh ] || (mkdir ~/.ssh; chmod 711 ~/.ssh) # создадим ~/.ssh директорию если ее нет и дадим нужные права
remote$ cat ~/id_rsa.pub >> ~/.ssh/authorized_keys # добавляем открытый ключ к авторизированым ключам
remote$ chmod 600 ~/.ssh/authorized_keys # и делаем правильные права(иначе ssh откажется брать отсюда ключи)
remote$ rm ~/id_rsa.pub # удаляем ненужное

4) проверяем что все работает. запускаем на локальном хосту
$ ssh user@remoute.org.ua
или например
$ scp .zshrc user@remoute.org.ua:~
должно сработать без пароля.

Прежде всего необходимо определить дискретность, с которой происходит обновление информации (допустим, раз в час) и выполнять зеркалирование сайта при помощи команды wget:

wget -m -q -k http://мой.домен/

После этого полученное зеркало синхронизируем с директорией, откуда файлы обрабатывает nginx (предположим, что это /usr/local/html):

rsync -tgu —delete —force мой.домен /usr/local/html

После чего осталось синхронизировать те файлы, которые wget не отзеркалит, например, *.js — java скрипты:

rsync -a —include ‘*/’ —include ‘*.js’ —exclude ‘*’ /путь/к/файлам/сайта/ /usr/local/html/

Это все. Теперь осталось запускать этот код каждый час (или реже) и всю нагрузку возьмет на себя nginx.
Для того, чтобы сохранить доступ к админке CMS, необходимо повесить какой-то поддомен сайта на реальный IP и обращаться к нему.

1. С помощью PuttyGen генерируем приватный и публичный ssh-ключи — кнопка «Generate». В настройках можно указать тип ключа и его размер.
2. После этого сохраняем приватный ключ в файл с помощью кнопки «Save private key», например private.key. Публичный ключ отображается в верхнем поле «Key» и имеет вид:
   «ssh-rsa AAAAB3NzaC1yc*что-то*uJQ== rsa-key-20020104″.
3. Копируем содержимое поля «Public key for pasting into OpenSSH authorized_keys file» в оперативную память и закрываем PuttyGen.
4. Запускаем ssh-клиент Putty и производим коннект к серверу.
5. Попав на сервер, создаем папку ~/.ssh
6. Создаем файл ~/.ssh/authorized_keys с содержимым поля «Public key for pasting into OpenSSH authorized_keys file» утилиты PuttyGen (то что копировалось в оперативную память).
   ВАЖНО! ключ в файле должен быть записан в одной строке без переносов.
7. Меняем права доступа к файлу командой chmod 600 ~/.ssh/authorized_keys
8. Закрываем Putty
9. Запускаем Putty. В настройках вашего соединения указываем путь к приватному ключу: Connection->SSH->Auth->Private_key_for_Authentification->private.key
10. Сохраняем настройки соединения и производим коннект к серверу. SSH-сервер запросит имя пользователя под которым вы хотите прологиниться — укажите свой логин. Далее авторизация пройдет с использованием приватного и публичного ssh-ключей.

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.