Всякие интересные штучки для WEB-разработчика

Допустим, вам необходимо настроить безпарольный вход по ssh (scp и sftp тоже) на удаленный сервер remote.org.ua под пользователем user.
Если ваш имя вашего локального пользователя совпадает с удаленным, то user@ везде можно опустить.

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:~
должно сработать без пароля.

Предположим, у Вас есть сайт, созданный при помощи php-скриптов и базы данных MySQL. В определенное время сервер перестает нормально работать, так как перегружен посетителями — слишком много запросов.
Как быть? Искусственно ограничить запросы — это значит отбросить посетителей. Наращивать мощности сервера накладно. Оптимизировать скрипты нет времени.
Именно в таком случае поможет тотальная конвертация всего сайта в статический HTML код и отдача его при помощи nginx.

Прежде всего необходимо определить дискретность, с которой происходит обновление информации (допустим, раз в час) и выполнять зеркалирование сайта при помощи команды 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 и обращаться к нему.

Если Вы, для работы с сервером, часто используете SSH, то Вам
наверняка понравится идея не вводить каждый раз пароль, а автоматически
попадать на SSH-сервер используя авторизацию по ключам. Ниже приведен
пример настройки такой авторизации.

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-ключей.

Вольный перевод довольно старой статьи с MySQL Performance Blog о том, что лучше сразу же настроить после установки базовой версии mySQL.

Удивительно, сколько народу устанавливает mySQL на свои сервера и оставляют его с настройками по умолчанию.

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

• key_buffer_size — крайне важная настройка при использовании MyISAM-таблиц. Установите её равной около 30-40% от доступной оперативной памяти, если используете только MyISAM. Правильный размер зависит от размеров индексов, данных и нагрузки на сервер — помните, что MyISAM использует кэш операционной системы (ОС), чтобы хранить данные, поэтому нужно оставить достаточно места в ОЗУ под данные, и данные могут занимать значительно больше места, чем индексы. Однако обязательно проверьте, чтобы всё место, отводимое директивой key_buffer_size под кэш, постоянно использовалось — нередко можно видеть ситуации, когда под кэш индексов отведено 4 ГБ, хотя общий размер всех .MYI-файлов не превышает 1 ГБ. Делать так совершенно бесполезно, Вы только потратите ресурсы. Если у Вас практически нет MyISAM-таблиц, то key_buffer_size следует выставить около 16-32 МБ — они будут использоваться для хранения в памяти индексов временных таблиц, создаваемых на диске.
• innodb_buffer_pool_size — не менее важная настройка, но уже для InnoDB, обязательно обратите на неё внимание, если собираетесь использовать в основном InnoDB-таблицы, т.к. они значительно более чувствительны к размеру буфера, чем MyISAM-таблицы. MyISAM-таблицы в принципе могут неплохо работать даже с большим количеством данных и при стандартном значении key_buffer_size, однако mySQL может сильно «тормозить» при неверном значении innodb_buffer_pool_size. InnoDB использует свой буфер для хранения и индексов, и данных, поэтому нет необходимости оставлять память под кэш ОС — устанавливайте innodb_buffer_pool_size в 70-80% доступной оперативной памяти (если, конечно, используются только InnoDB-таблицы). Относительно максимального размера данной опции — аналогично key_buffer_size — не стоит увлекаться, нужно найти оптимальный размер, найдите лучшее применение доступной памяти.
• innodb_additional_mem_pool_size — данная опция практически никак не влияет на производительность mySQL, однако рекомендую оставлять для InnoDB около 20 МБ (или чуть больше) под различные внутренние нужды.
• innodb_log_file_size — крайне важная настройка в условиях баз данных с частыми операциями записи в таблицы, в особенности при больших объёмах. Большие размеры увеличивают быстродействие, однако будьте осторожны — увеличится и время восстановления данных. Я обычно выставляю значение около 64-512 МБ в зависимости от размера сервера.
• innodb_log_buffer_size — стандартное значение данной опции вполне подойдёт для большинства систем со средним количеством операций записи и небольшими транзакциями. Если же в Вашей системе бывают всплески активности, или Вы активно работаете с BLOB-данными, то рекомендую немного увеличить значение innodb_log_buffer_size. Однако не переусердствуйте — слишком большое значение будет пустой тратой памяти: буфер сбрасывается каждую секунду, поэтому Вам не понадобится больше места, чем требуется в течение этой секунды. Рекомендуемое значение — около 8-16 МБ, а для небольших баз — и того меньше.
• innodb_flush_log_at_trx_commit — жалуетесь, что InnoDB работает в 100 раз медленнее MyISAM? Вероятно, Вы забыли про настройку innodb_flush_log_at_trx_commit. Значение по умолчанию «1» означает, что каждая UPDATE-транзакция (или аналогичная команда вне транзакции) должна сбрасывать буфер на диск, что достаточно ресурсоёмко. Большинство приложений, в особенности ранее использовавшие таблицы MyISAM, будут хорошо работать со значением «2» (т.е. «не сбрасывать буфер на диск, только в кэш ОС»). Лог, однако, всё равно будет сбрасываться на диск каждые 1-2 секунды, поэтому в случае аварии Вы потеряете максимум 1-2 секунды обновлений. Значение «0» повысит производительность, но Вы рискуете потерять данные даже при аварийной остановке mySQL-сервера, в то время как при установке значение innodb_flush_log_at_trx_commit в «2» Вы потеряете данные только при аварии всей операционной системы.
• table_cache — открытие таблиц может быть весьма ресурсоёмко. К примеру, MyISAM-таблицы помечают заголовки .MYI файлов как «используемые в текущий момент». Обычно не рекомендуется открывать таблицы слишком часто, поэтому лучше, чтобы кэш был достаточных размеров, чтобы держать все Ваши таблицы открытыми. Для этого используется некоторое количество ресурсов ОС и оперативной памяти, однако это обычно не является существенной проблемой для современных серверов. Если у Вас несколько сотен таблиц, то стартовым значением для опции table_cache может быть«1024» (помните, что каждое соединение требует свой собственный дескриптор). Если у Вас ещё больше таблиц или очень много соединений — увеличьте значение параметра. Я видел mySQL сервера со значением table_cache равной 100 000.
• thread_cache — создание/уничтожение потоков также является ресурсоёмкой операцией, которая происходит при каждой установке соединения и каждом разрыве соединения. Я обычно выставляю эту опцию равную 16. Если у Вашего приложения могут быть скачки количество конкурентных соединений и по переменной Threads_Created виден быстрый рост количества потоков, то стоит увеличить значение thread_cache. Цель — не допускать создания новых потоков в условиях нормального функционирования сервера.
• query_cache_size — если Ваше приложение много и часто читает данные, и при этом у Вас нет кэша на уровне приложения, эта опция может очень помочь. Не ставьте здесь слишком большое значение, так как обслуживание большого кэша запросов будет само по себе затратным. Рекомендуемое значение — от 32 до 512 МБ. Не забудьте проверить, насколько хорошо используется кэш запросов — в некоторых условиях (при небольшом количестве хитов в кэше, т.е. когда практически не выбираются одинаковые данные) использование большого кэша может ухудшить производительность.

Как Вы можете видеть, это — глобальные настройки. Эти переменные зависят от «железа» сервера и используемых движков mySQL, в то время как сессионные переменные обычно настраиваются специально под конкретные задачи. Если Вы в основном используете простые запросы, то нет никакой необходимости увеличивать значение sort_buffer_size, даже если у Вас есть лишние 64 ГБ оперативной памяти. Более того, большие значения кэшей могут только ухудшить производительность сервера. Сессионные переменные лучше оставить на потом, для тонкой настройки сервера.

PS: инсталляция mySQL идёт с несколькими предустановленными файлами my.cnf, рассчитанными под разную нагрузку. Если Вам некогда настраивать сервер вручную, то обычно лучше использовать их, чем стандартный конфигурационный файл, выбрав тот, что больше подойдёт под нагрузку Вашего сервера.

Ликбез по движкам MySQL
На сегодняшний день MySQL поддерживает несколько движков. Наиболее популярные это MyISAM, InnoDB, но рассмотрим и другие. Получить список поддерживаемых движков вашего сервера можно командой SHOW ENGINES

mysql> SHOW ENGINES;
+------------+---------+----------------------------------------------------------------+
| Engine     | Support | Comment                                                        |
+------------+---------+----------------------------------------------------------------+
| MyISAM     | YES     | Default engine as of MySQL 3.23 with great performance         |
| MEMORY     | YES     | Hash based, stored in memory, useful for temporary tables      |
| HEAP       | YES     | Alias for MEMORY                                               |
| MERGE      | YES     | Collection of identical MyISAM tables                          |
| MRG_MYISAM | YES     | Alias for MERGE                                                |
| ISAM       | NO      | Obsolete storage engine, now replaced by MyISAM                |
| MRG_ISAM   | NO      | Obsolete storage engine, now replaced by MERGE                 |
| InnoDB     | DEFAULT | Supports transactions, row-level locking, and foreign keys     |
| INNOBASE   | YES     | Alias for INNODB                                               |
| BDB        | YES     | Supports transactions and page-level locking                   |
| BERKELEYDB | YES     | Alias for BDB                                                  |
| NDBCLUSTER | NO      | Clustered, fault-tolerant, memory-based tables                 |
| NDB        | NO      | Alias for NDBCLUSTER                                           |
| EXAMPLE    | NO      | Example storage engine                                         |
| ARCHIVE    | YES     | Archive storage engine                                         |
| CSV        | NO      | CSV storage engine                                             |
| FEDERATED  | YES     | Federated MySQL storage engine                                 |
| BLACKHOLE  | YES     | /dev/null storage engine (anything you write to it disappears) |
+------------+---------+----------------------------------------------------------------+

Read the rest of this entry »

Кто слышал о BASH? Думаю все, кто, хоть как-то, связан с IT индустрией. О синтаксисе и командах написана не одна тысяча книг. Поэтому здесь, предлагаю, рассмотреть только “редкие” команды, которые трудно найти, но могут быть полезными.
Возвращает количество файлов в том числе и во вложенных папках:

ls -R -l | wc -l

Возвращает объём папки(со вложеностями):

du -sh

Выводит максимальное разрешение текстур (wallpapper, skydom и тд) поддерживаемое системой:

xvinfo | grep max

Высчитывает количество строк в файлах по маске (параметр “*.php”) в текущей и во вложеных директориях:

find . -name "*.php" -type f -print0 | xargs -0 wc -l

Генерирует произвольный пароль в 16 (параметр -c16) символов:

/dev/urandom tr -dc A-Za-z0-9_ | head -c16 ; echo

Разбивает файл bigfile на файлы не превышающие 700 мегабайт (параметр 700m), называя новые файлы BIG_aa, BIG_ab, … (общая маска задаётся последним параметром):

split -b 700m bigfile BIG_

Выводит список популярных на машине команд с количеством вызовов:

history|awk '{a[$2]++ } END{for(i in a){print a[ i ] " " i}}'|sort -rn|head

Простая команда для поиска и удаления в консоле:

 $ rm -rf `find /folder_name/ -name *patern*` 

Пример:

 $ rm -rf `find . -name .svn` 

Удалит все папки .svn из текущей и всех вложенных дерикторий.

Our Developer eBook, Maximizing Your Java Application Development, will help you in understanding these issues and how you can get the most out of your Java code, whether it’s porting from another language, working in the best IDE or optimizing for today’s multi-core computing environments.

Topics explored include:

• A systematic approach for porting an existing Java-based application to a new JDK version,
• Automating the porting of J2ME applications,
• A comparison of the latest versions of the major IDEs in the Java development space, and
• Parallel processing within a J2EE container.

DOWNLOAD

В статье описывается процесс настройки NAT’а (Network Address Translation) на простом примере предоставления доступа к ресурсам внешней сети (или интернету) из внутренней локальной сети.

В данной статье мы будем рассматривать настройку Nat на примере раздачи интернета в локальную сеть.

Итак, у нас есть сервер под управлением FreeBSD, подключенный к сети провайдера («внешняя сеть»).
Также имеется один или несколько компьютеров («внутренняя сеть»), которым нужно дать доступ к ресурсам сети интернет.
Подключить компьютеры внутренней сети напрямую к внешней нельзя, так как у нас есть всего 1 IP-Адрес во внешней сети, который выдан нашему серверу.
Выходом из ситуации будет соединение сетей через сервер (в данной ситуации всётаки «роутер» будет более правильно) при помощи технологии NAT
Предположим что сеть провайдера имеет диапазон 123.123.123.0/24, а IP который выдал нам провайдер 123.123.123.111.
Внутренняя сеть же имеет диапазон 192.168.10.0/24 и IP нашего роутера в ней 192.168.0.1
Диапазон IP адресов во внутренней сети может быть любой, однако необходимо чтобы он не пересекался с диапазонами ни в одной внешней сети.
Read the rest of this entry »

В данной статье мы рассмотрим как правильно настроить сетевой интерфейс для разных Unix систем.
В качестве примера предположим что у нас есть следующие данные:

IP address : 192.168.10.14, 192.168.10.15
Mask : 255.255.255.0
Gateway : 192.168.10.1
DNS : 192.168.10.3
DNS : 192.168.10.2

Итак приступим:
Для операционной системы FreeBSD:
В конфигурационный файл /etc/rc.conf добавляем:

# Основной адрес
ifconfig_rl0="inet 192.168.10.14 netmask 255.255.255.0"
# Основной Шлюз
defaultrouter="192.168.10.1"
# Алиас
ifconfig_rl0_alias0="inet 192.168.10.15 netmask 255.255.255.0"

rl0 — название сетевого интерфейса который настраиваемого мы настраиваем.

После того как Вы сохранили файл нужно перезагрузить сеть выполнив команду

/etc/rc.d/netif restart
 Read the rest of this entry »