… В начале 2010 года одна из сотрудниц Penny Lane отдыхала вместе со своим сыном в Египте. К ее рабочему телефону (тариф «Живи Легко 180″), как выяснили позднее в компании, оказалась «по умолчанию» подключена услуга международного роуминга и мобильного GPRS-интернета, хотя, как отмечает Дзагуров, никто и никогда в Penny Lane не заказывал данных услуг.

Сын сотрудницы, пишет Дзагуров, воспользовался ее телефоном iPhone, поиграв в онлайн-игры. Всего мальчик провел в интернете 4 часа. Гендиректор Penny Lane утверждает, что в случае, если такой же объем трафика был бы израсходован в Москве, то Penny Lane получила бы от «Вымпелкома» счет на 139 рублей. Но из-за роуминга счет составил 522 тысячи рублей… Продолжение

От себя скажу, что господин Дзагуров, видимо, не знает про Премиум-сайты от Билайна! Правда, откуда он узнает, если про это ничего нет ни в договоре, ни на сайте Билайна (экое приятное «упущение» от Билайн). Так что 139 рублей, как он думает, в Москве могли бы быть не 139-тью рублями, а эдак в 50 раз больше (премиум трафик стоит всего то  50 раз больше). Ну и конечно же, не удивлюсь, если вдруг выяснится, что у Билайна есть «Премиум Роуминг» – в 75 раз больше (это не с потолка взято, а простой расчет: 522000 / 139 / 50 = 75) Ну чтож, может быть такие случаи побыстрее доведут Вымпелком до суда и найдется на них управа.

Правленный Live HTTP headers v0.16

Итак, если кратко, то надо сгенерировать закрытый и открытый ключи на стороне, где будем запускать скрипты (назовем такую машину «клиент»), положить открытый ключ туда, куда будем коннектится (назовем его условно «сервер») и настроим, чтобы сессия для такого-то аккаунта Unix запускалась не от Unix пароля, а от ключа (с паролем, но ниже будет показано, как настроить, чтобы вводить его однократно за весь день, например)

1. На стороне клиента генерируем ключ типа DSA:

   mkdir -p ~/.ssh
   chmod 700 ~/.ssh
   cd ~/.ssh
   ssh-keygen -t dsa
   Enter passphrase (empty for no passphrase): …
   Enter same passphrase again: …
   chmod go-rwx ~/.ssh/*

   Я рекодмендую обязательно указать пароль. Рекомендуется указывать пароль, который не используется для аккаунта Unix. Если вы не укажите пароль (сделаете пустым), то любой, кому попадет ваш закрытый ключ-файл, сможет зайти на удаленный сервер под вашим аккаунтом без всяких проблем. Конечно, чтобы файл попал к кому либо, надо, чтобы были нарушены права доступа в Unix. Но файл может «утечь» случайно с утилитами синхронизации, бекапа или т.п.. Далее, я расскажу, как настроить, чтобы вы сами в дальнейшем не вводили часто пароль для закрытого ключа.

2. Копируем ключ на сервер:

   scp -p id_dsa.pub remoteuser@remotehost:
   Password: ********

3. На уделенном сервере делаем:

   ssh -l remoteuser remotehost
   Password: ********
   mkdir -p ~/.ssh # Создать директорию, если ее нет
   chmod 700 ~/.ssh
   cat id_dsa.pub >> ~/.ssh/authorized_keys  # Добавление к файлу, если он уже есть
   chmod 600 ~/.ssh/authorized_keys
   mv id_dsa.pub ~/.ssh # Не обязательно, но можно сохранить открытый ключ на всякий случай
   logout

   Теперь, у вас есть закрытый и открытый ключ на вашей клиентской машине, защищенный (или нет) паролем, и открытый ключ на стороне сервера. Серверу достаточно вашего открытого ключа, чтобы вас идентифицировать (условно говоря, сервер каждый раз будет генерировать некий уникальный текст и давать его вашей клиентской машине при открытии сессии, а ваша машина должна будет его подписать с помощью закрытого ключа, передать обратно цифровую подпись серверу, а тот сверит ее для выданного вам же текста. Поскольку подписать может только тот, кто имеет закрытый ключ + пароль к нему, а проверить подпись может тот, что имеет ваш открытый ключ, то идентификация в этом случае гарантирует серверу, что вы – эти именно вы, и Unix пароль в таком случае вообще не нужен и нигде в сессии не передается).

4. Следующий шаг – настройка ssh-agent. Он может нам понадобится, если мы не хотим постоянно вводить пароль для закрытого ключа. Если же вы на шаге 1 указали пустой пароль, то можете пропустить 4 -6 пункты – вам не потребуется демон ssh-agent для кеширования пароля – его попросту нет – он не будет запрашиваться утилитами, использующими протокол ssh, и все эти утилиты могут работать из скриптов прямо на этом этапе.
   Демон ssh-agent висит в памяти и за операциями подписи и криптования к нему обращаются программы ssh & scp (и другие). Этот демон хранит в своей памяти ваш пароль для закрытого ключа определенное время, заданное вами. Это очень удобно, если вы повседневно используете openssh, например, даже для git pull & git push.

   crontab -e

   Вставляем в редакторе в crontab файл:

   @reboot ssh-agent -s | grep -v echo > $HOME/.ssh-agent

   Эти команды говорят крону, что во время ребута системы запустить ssh-agent, а его вывод – переменные среды окружения с настройками записать в файл $HOME/.ssh-agent. Этот файл необходим нам для того, чтобы программы ssh, scp знали, куда коннектится (в них сохраняются пути до Unix сокетов коммуникации с ssh-agent).
   Чтобы нам не ждать перезагрузки, запускаем демон сразу же:

   nohup ssh-agent -s > ~/.ssh-agent

5. Теперь, в ваши скрипты, которые используют ssh & scp, надо добавить такую строку:

   . ~/.ssh-agent

   Также, рекомендую добавить следующие строки в ~/.bashrc (для bash shell-а):

   . $HOME/.ssh-agent
   alias keyon="ssh-add -t 10h"
   alias keyoff='ssh-add -D'
   alias keylist='ssh-add -l'

   Тем самым, при заходе на клиентскую машину ssh сессией, у вас загрузятся настройки для работы с ssh-agent, а также определятся алиасы команд для повседневной работы. Например, выполнив в bash команду «keyon», от вас ssh-add команда потребует ввести пароль для ключа. После ввода он будет еще работать 10 часов. В это время вы можете запускать команды ssh, scp и любые другие, что используют ssh для коннекта на сервер (rsync, git), и все эти команды будут работать без запроса пароля.

6. Второй вариант настройки ssh-agent (если его выбираете, можете пропустить пункты 4 и 5):
   В файле ~/.bash_profile прописываем:

   SSHAGENT=/usr/bin/ssh-agent
   SSHAGENTARGS="-s"
   if [ -z "$SSH_AUTH_SOCK" -a -x "$SSHAGENT" ]; then
   eval `$SSHAGENT $SSHAGENTARGS`
   trap "kill $SSH_AGENT_PID" 0
   ssh-add
   fi

   Этими командами вы говорим при логине, если если нет таких-то переменных, запустить ssh-agent, выполнить команды вывода ssh-agent в текущем шеле (eval), а по завершении shell-а пристрелить процесс ssh-agent-а (trap). Здесь также при логине у вас единожды запросится пароль для ключа. Затем он будет в памяти ssh-agent

Подробнее и всесторонне об ssh-agent можете прочитать в статье Mark A. Hershberger

Также рекомендуется к чтению:

1. 20 советов по безопасному использованию сервера OpenSSH
2. OpenSSH Public Key Authentication

diff -Nur 1/copy_plain_text-0.3.3-fx+mz+tb/chrome.manifest 2/copy_plain_text-0.3.3-fx+mz+tb/chrome.manifest
--- 1/copy_plain_text-0.3.3-fx+mz+tb/chrome.manifest	1970-01-01 05:00:00.000000000 +0500
+++ 2/copy_plain_text-0.3.3-fx+mz+tb/chrome.manifest	2010-08-03 12:17:02.031250000 +0600
@@ -0,0 +1,6 @@
+overlay chrome://browser/content/browser.xul chrome://copyplaintext/content/overlay.xul
+overlay chrome://navigator/content/navigatorOverlay.xul chrome://copyplaintext/content/overlay_moz.xul
+overlay chrome://navigator/content/navigator.xul chrome://copyplaintext/content/overlay_moz.xul
+overlay chrome://messenger/content/mailWindowOverlay.xul chrome://copyplaintext/content/overlay_thunder.xul
+overlay chrome://messenger/content/messengercompose/messengercompose.xul chrome://copyplaintext/content/overlay_thunder.xul
+content copyplaintext jar:chrome/copyplaintext.jar!/content/
diff -Nur 1/copy_plain_text-0.3.3-fx+mz+tb/install.rdf 2/copy_plain_text-0.3.3-fx+mz+tb/install.rdf
--- 1/copy_plain_text-0.3.3-fx+mz+tb/install.rdf	2006-11-27 21:14:12.000000000 +0500
+++ 2/copy_plain_text-0.3.3-fx+mz+tb/install.rdf	2010-08-03 12:15:14.812500000 +0600
@@ -22,7 +22,7 @@
 			<Description>
 				<em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
 				<em:minVersion>1.0</em:minVersion>
-				<em:maxVersion>2.0</em:maxVersion>
+				<em:maxVersion>3.6.*</em:maxVersion>
 			</Description>
 		</em:targetApplication>

Оказывается, если погуглить на фразу именно в кавычках (чтобы порядок слов искался именно такой), то найдете кучу буржуйских блогов, где все на английском, зато комменты все на русском и многие из них такие Правда там капчей нет почти нигде. А у меня есть. И ведь надо же, спам как то через капчу пролез. Видимо умеют ее распознавать ботами… Правда есть способ распознавать капчи любые автоматом. Простой и эффективный. Только для этого нужен популярный сайт, чтобы он был ваш. Думаю, сообразительные уже догадались, как

Герман Стерилигов обнаружил следы сильной коррозии и ржавчины на тысячах инвестиционных монет «Победоносец» 999.
Чистое золото не вступает в реакции и не окисляется – это известно всем еще из школьного курса химии. Аналогично инвестиционные монеты качества 999 (чистое золото), производимые ЦБ, не портятся и не окисляются. Однако сотрудники Международной Резервной Расчетной Системы обнаружили следы ржавчины (коричневые и красные пятна и полосы на обеих сторонах монеты) сразу на нескольких тысячах монет. Значительная часть монет, по просьбе клиентов, хранилась не в сейфовых ячейках МРРС, а находилась в гораздо более трудноступном месте – была «закопана под дубом». Очевидно, монеты начали окисляться под воздействием влаги…

Далее, подробно уже на первоисточнике: Золотые монеты Центрального Банка ржавеют

Также, будет интересно: Поддельные слитки золота из Форта Нокс! Как США кидают весь мир…

Мое последняя точка зрения – если надо запускать проект, пусть и на одном сервере, надо все таки стремится сразу создавать дистрибутив. Ниже я рассмотрю несколько плюсов и минусов в сравнении с вариантом, когда вы используете простое копирование.

Но пока, давайте, определимся с термином «дистрибутив» для perl. Этим термином я буду называть упакованный пакет файлов (например tar.gz формата), который в своем составе имеет Makefile.PL – стартовый perl скрипт для формирования Makefile файла утилиты make. Также, «правильный» дистрибутив, помимо использования make, должен иметь две раздельные фазы работы. Первая – подготовка файлов, для их дальнейшей установки, внутри своей рабочей директории (исполняется не от ‘root‘, команда ‘make all‘, например). Вторая – установочная: подготовленные файлы копируются в нужные установочные директории (‘make install‘). Эта фаза либо исполняется от ‘root’, либо от какого либо пользователя, в его внутреннюю home директорию. Хочется заметить, что в отличии от компиляционных языков, типа C/C++, perl – язык интерпретатора, поэтому в большинстве случаев в компиляции не нуждается (кроме ‘XS’ модулей), а значит make мало что сможет сделать для нас, с первого взгляда. По этой причине, часто встает вопрос – а нужен ли дистрибутив?

Теперь давайте рассмотрим плюсы и минусы дистрибутива в сравнении с обычным копированием perl файлов.

+)

Дистрибутив – это прежде всего порядок в вашей голове по поводу файлов проектов – какие файлы рабочие, где библиотеки, где директории, созданные в процессе инсталлирования. Создавая дистрибутив, вы вынуждены наводить этот порядок. Но это окупится в дальнейшем.

-)

На перевод готового проекта в дистрибутив требуется больше времени и изучение принципов построения дистрибутива (этот этап однократный). Но если начинать проект сразу с формирования дистрибута, этот минус уже не играет роли.

-)

Любые правки и их испытание на рабочем процессе – это всегда команда make install, заместо обычной правки PM или PL файла в месте, где он установлен руками. Но этот минус незначительный, так как make install обычно работает быстро – она отслеживает только те файлы, что вы изменили и инсталирует только их. Другими словами, после каждой правки исходников, для их тестирования, надо будет немного тратить больше времени.

+)

Если вы используете написание XS модулей (вставок C кода) в проекте – то без дистрибутива вам не обойтись – такие файлы требуют компиляции, и команда make просто необходима.

+)

Самый большой плюс перехода на дистрибутив – это возможность использования программ контроля версий. Я остановился на git (пробовал SVN – не понравился). Дело в том, что многие программы контроля версий не учитывают точные права Unix файлов – например, git хранит в репозитарии только статус файлов: исполняемый (‘x’) или нет – он не помнит user.group, в точности mode самого файла для (user, group, other) и даже не сохраняет дату модификации файла (то есть выставляет ее в «настоящее время»  между переключениями версий проекта, что на самом деле является плюсом, как нистранно – дата модификации служит ориентиром для make, что опять же плюс в использовании дистрибутива). То есть, если вы будете использовать git, вам надо будет иметь специальные свои программы, выставляющие права и/или копирующие файлы в другое месте после каждого переключения между версиями репозитария проекта (то есть без дистрибутива вы фактически создадите свой вариант дистрибутива без make, что будет являться «изобретением велосипеда»). А также надо учитывать то, что все программы контроля версий контролируют одну папку. А рабочие файлы проекта, как правило, живут не в одной папке, а раскиданы по нескольким. Поэтому программы контроля версий будут жить только с дистрибутивами.

+)

Написав грамотный make, можно улучшить порядок вашего проекта – make будет выставлять права, какие необходимы на рабочие директории, создавать их при необходимости и т.п.. Если вам придется запускать проект на другом нулёвом сервере – это будет минимум затрат по времени.

+)

Использование таких команд, как make distcheck, позволяет проверить, какие новые файлы вы добавили/создали, но не поместили их еще в MANIFEST (список файлов для дистрибутива, так сказать, список файлов «на экспорт»), поможет определиться, какие файлы надо убрать из дистрибутива (MANIFEST.SKIP). Все это – опять же порядок, который положительно скажется на вашем проекте (в MANIFEST не обязательно добавлять все файлы, некоторые можно иметь только в своей папке дистрибутива, а при подготовке «установочного» tar.gz архива они будут просто исключаться).

+)

Ваш проект, при создании дистрибутива, даст вам сразу такие преимущества: возможность легкого переноса вашего проекта на другие сервера без особых затрат, без проблем из него можно сделать open source проект и дать ему дальнейший импульс развития вне рамок вашей организации, или же сделать коммерческим проектом с легкой инсталяцией и т.п..

Вот вроде все плюсы и минусы, которые я обнаружил на основе своего опыта. Как видно, плюсов больше, чем минусов. Дополнительное время надо потратить только в самом начале проекта. Дальше – проще. В perl позаботились, чтобы облегчить жизнь разработчику – есть возможность отслеживать, какие новые файлы вы добавили в проект, но не добавили «на экспорт» в будущий дистрибут, или даже есть команды автоматического построения MANIFEST файла. Также, не надо руками создавать Makefile с длинным списком всех своих PL & PM файлов – «perl Makefile.PL» за вас найдет в нужных папках такие файлы и автоматом включит их в Makefile.

В следующей статье я расскажу вам, как легко и быстро создавать perl дистрибутивы. Для начинающих это может показаться сложно, так как надо читать много документации, прежде чем понять это. Я попробую рассказать об этом, опуская все лишнее.

Итак, что же это за такая rsync? Это действительно, утилита рекурсивного копирования (копирует все файлы и поддиректории) с одного хоста на другой, или даже внутри одной машины. На этом все ее отличие от, например, утилиты cp заканчивается. И вот тут самое интересное – она при копировании каждый файл или директории, которые копируем, проходит блоками, и отслеживает только изменения блоков в сравнении с уже скопированными блоками. Грубо говоря, она копирует только «дельты» файлов и директорий! Что это значит? Это значит, что второй, третий и так далее запуски этой программы на определенную цель (куда копировать) будут занимать гораздо меньше времени, операций копирования и передачи данных по сети при повторном копировании уже изменившихся файлов. Вот несколько примеров ее использования:

1) Быстрый перенос баз данных (на примере SQL).

Имеем два сервака – один рабочий A, второй Б – куда будем резервировать свои базы данных (там где нет работающего SQL). Тогда для резервирования можно периодически запускать rsync на сервере A, не прекращая работы SQL сервера (назовем это «рабочим резервом»). Но чтобы нам иметь полностью правильные базы в резервной директории сервера Б, нам надо временами останавливать SQL на серваке А, и пока там нет работаюшего SQL, делать повторное копирование (назовем это «фиксированным резервом»). Вот тут то rsync и пригождается! Во время «рабочего резерва» многие файлы успевают устареть, ведь SQL продолжает работать. Во время «фиксированного резерва» копируются только дельты с последнего запуска «рабочего резерва». Если время между этими запусками мало, то дельты копируются очень быстро – на больших базах это может быть не более минуты, например. Для снижения времени простоя, надо просто выполнить повторный «рабочий резерв» прямо перед остановкой MySQL сервера. Плюсы такого способа – минимальный даун по времени, минимум человеческих ошибок, простота. Я не знаю другого способа на данный момент, чтобы сделать быстрый резерв больших баз данных на другую машину, и при этом свести время простоя к минимуму.

Команды (смотрите не перепутайте! Тут все как в теории относительности )
На стороне сервера Б (можно и на стороне А, но тогда надо поменять пути местами), куда копируем, запускаем команды копирования во время «рабочего резерва»

cd
nohup /bin/nice -n 20 ionice -c3 rsync --rsync-path='/bin/nice -n 20 ionice -c3 rsync' -avz --delete IP.ADDRESS.SERVER.A:'/path/to/source/folder/' /path/to/target/folder/

Краткие пояснения (ВАЖНО):
Некоторые утилиты могут отсутствовать, примеры даны для Linux! Здесь nohup – «оторвать» ввод/вывод от терминала. Это нам потребуется, когда мы захотим оставить запущенный «резерв» в фоновом режиме. Сразу мы не можем этого сделать (то есть не ставлю ‘&’ в конце), так как rsync при копировании использует ssh, и раз мы копируем на другой сервак, он запросит у нас пароль (если авторизация через openssh ключи + ssh-agent, то можно и поставить ‘&’, но об этом в другой раз, в другой статье). После ввода пароля уже можно будет нажать Ctrl+Z в shell и затем "%1 &" для запуска в фоновом режиме первой запущенной задачи (см. man bash). Команда nice – выставить приоритет для процессора, а ionice – приоритет для операций при работе с диском – все приоритеты ставяться на понижение, чтобы продолжалась нормальная работа сервера. Опция --delete для rsync – удалять все файлы в целевой директории (от слово «цель», target), которых нет в исходной (source). То есть, после копирования получим полностью равную директорию по содержанию.
Слеш в конце исходной директории (/path/to/source/folder/)  – важная штука! Если в конце слеш – директория рассматривается rsync-ом как комплект директорий и файлов в ней для копирования, а если слеша нет – как один объект, целая директория со своим именем – в обоих случаях копирование рекурсивное, но если из примера убрать слеш в конце первого пути (сделать /path/to/source/folder), то в /path/to/target/folder/ будет создана папка folder и туда скопируется ее содержимое! Почитайте man-ы, если хотите понять, как присутствие или отсутствие слешей в конце директории влияет на ход событий

2) Перенос сайтов.

Способом, описанным выше, также можно переносить и сайты вместе с их базами. Для баз мы используем способ выше, а для переноса контента делаем все то же самое, но при работающем apache. Как и в первом способе, apache мы останавливаем только на несколько минут или секунд, быстро запускаем rsync для «фиксированного резерва», а после окончания запускаем apache снова. После остается сменить только DNS на новый IP адрес и все! Для повышения скорости переноса не забудьте за неделю до переноса выставить часовой TTL в вашем DNS для SOA записи зоны и для всех ее остальных записей. Тогда при смене IP весь трафик на сайт переместится за один час! Но это, как говориться, уже другая история.

Итак, имеем штрихкод – см. слева. Это – адрес данной статьи. Запускаем некое приложение, которое читает QR-Codes,  наводим камеру на монитор, щелкаем кнопкой и спустя пару секунд – адрес у нас уже в телефоне. Из своего опыта и экспериментов, я хочу предложить вам следующие ссылки для установки приложений, читающих QR-Codes:

1. i-nigma.mobi – самое лучшее приложение, которое мне понравилось из нескольких протестированных мною – приятный интерфейс, оформление, хистори, возможность отправить через СМС отсканированный текст, нормальная работа с русскими буквами, понимает все форматы + может еще читать обычный линейный штрих-код . Просто наберите этот адрес в мобильнике, вам будет предложена ссылка для скачки Java приложения на основании марки телефона, которым вы зайдете на тот сайт.
2. qrcode.kaywa.com – Здесь вы найдете онлайн генератор для формирования штрихкода для вашего URL адреса, текста, SMS. Если вы владелец сайта, и у вас есть мобильный контент, вам это будет очень кстати.
3. www.qrstuff.com -  Другой, более гибкий генератор. Показывает QR код сразу, во время набора. Также делает нормально vCard & meCard («карточки контактов») – для мобильника рекомендую выбрать тип meCard. Также там можно сформировать GPS точку и картой Google Map (сам стандарт QR кода не предусматривает это, но то, чего нет, тот севрис делает через URL сервисы своего сайта). Очень рекомендую этот генератор для продвинутых QR кодов.
4. Статья в русской Wiki, рассказывающая о QR-Codes

Если подумать, применений этому можно найти много. И не обязательно в интернет