вот никак не мог правильно подобрать выражение, чтобы правильно описать мою возню с oracle. накатило и я все понял; вот оно:
«чтобы спереди погладить, нужно сзади полизать»
пример:
установка переменной:
alter session set nls_date_format = 'dd/mm/yyyy hh24:mi:ss';
получение значения переменной:
select parameter, value from v$nls_parameters where parameter = 'NLS_DATE_FORMAT';
касательно установки oracle server на mac os x:
вообще, оракл сервер весь из себя прикольный–прикольный. проще даже сказать, ебанутый на всю голову. вот, например, после установки, обнаруживается, что там внутри свой собственный jre и собственный perl 5.8.3 и еще много всего. зато старт–стоп скриптов отродясь не водится. «читайте пару лет документацию и вам откроется тайное знание написания старт–стоп скриптов». до кучи нужно сказать, что оракл сервер смог поставиться, но не смог запуститься.
Tuesday, May 12, 2009
Thursday, April 9, 2009
mac os x limits
немного посмеявшись над ребятами, которые пытались определить, сколько же «приложений» выдержит мак, мне самому пришлось столкнуться с некоторой ограниченностью системных лимитов.
оказывается, что в mac os x 10.5 по умолчанию одним пользователем можно открыть не более 266 приложений. при этом часть из них — системные сервисы, поэтому реально запущеных приложений будет меньше. если такого количества не хватает, то можно увеличить лимит и об этом пойдет речь ниже.
но, к сожалению, эти лимиты тоже не бесконечны и довольно невелики. это значит то, что если вам вдруг понадобится производительный сервер, то mac os x вам этого просто не позволит сделать, несмотря на всю юникс начинку внутри.
как известно, у макоси есть две версии, клиентская и серверная. сейчас я буду говорить за первую, потому как второй в доступности нет.
как показывает команда «sysctl -a | grep maxproc», операционная система ограничила себя до 532 процессов в целом и не более 266 на одного пользователя. не очень–то пожируешь. ну что ж, на то нам дадены руки.
sysctl -w kern.maxproc=4096
sysctl: kern.maxproc: Invalid argument
опа, а это что такое?
это оказалось, что в ядре операционной системы записан жесткий лимит в 2500 соединений. превысить его можно только после пересборки ядра. то есть запустить под mac os x client более 2500 процессов невозможно.
в server 10.4.11 тоже есть подобный лимит, только он чуть ниже — 2068
для увеличения лимита можно добавить информацию в два файла:
/etc/sysctl.conf и /etc/launchd.conf
первый управляет ограничениями в ядре, а второй — в запускаемых приложениях операционной системы.
/etc/sysctl.conf
kern.maxprocperuid=1024
kern.maxproc=2048
/etc/launchd.conf
limit maxproc 512 1024
оказывается, что в mac os x 10.5 по умолчанию одним пользователем можно открыть не более 266 приложений. при этом часть из них — системные сервисы, поэтому реально запущеных приложений будет меньше. если такого количества не хватает, то можно увеличить лимит и об этом пойдет речь ниже.
но, к сожалению, эти лимиты тоже не бесконечны и довольно невелики. это значит то, что если вам вдруг понадобится производительный сервер, то mac os x вам этого просто не позволит сделать, несмотря на всю юникс начинку внутри.
как известно, у макоси есть две версии, клиентская и серверная. сейчас я буду говорить за первую, потому как второй в доступности нет.
как показывает команда «sysctl -a | grep maxproc», операционная система ограничила себя до 532 процессов в целом и не более 266 на одного пользователя. не очень–то пожируешь. ну что ж, на то нам дадены руки.
sysctl -w kern.maxproc=4096
sysctl: kern.maxproc: Invalid argument
опа, а это что такое?
это оказалось, что в ядре операционной системы записан жесткий лимит в 2500 соединений. превысить его можно только после пересборки ядра. то есть запустить под mac os x client более 2500 процессов невозможно.
в server 10.4.11 тоже есть подобный лимит, только он чуть ниже — 2068
для увеличения лимита можно добавить информацию в два файла:
/etc/sysctl.conf и /etc/launchd.conf
первый управляет ограничениями в ядре, а второй — в запускаемых приложениях операционной системы.
/etc/sysctl.conf
kern.maxprocperuid=1024
kern.maxproc=2048
/etc/launchd.conf
limit maxproc 512 1024
Wednesday, March 25, 2009
postfix: no spam without antispam
борьба со спамом без антиспама.
примерно с месяц назад на своей работе я начал переносить почту со старого и неуправляемого CommunigatePro на более стандартный (в рамках почтового сервера под управлением Mac OS X) postfix. и после переноса аккаунтов обнаружил, что /var/log/mail.log растет не по дням, а по часам, причем на пару сотен мегабайт в час. к концу суток у меня был шестигигабайтный лог файл и около гигабайта новых писем. я довольно сильно испугался, что так будет и дальше.
сервер по умолчанию был настроен на прием корреспонденции только для известных адресов, других проверок не делалось.
это вынудило меня начать разбираться со встроенными механизмами фильтрации спама в postfix и возможности применить особенности протокола smtp для отсеивания всей этой корреспонденции. можно было бы попробовать поставить spamassassin или другие решения с открытыми исходниками и натюнинговать их, но гигабайт принятой почты меня совсем не радовал. платные варианты сразу же были исключены, так как спам в основном приходит на русском языке, а kaspersky antispam и спамоборона не имеют сборок под Mac OS X.
немного теории
любая машина, подключенная к интернет, может получить mx dns запись для любого из доменов и отправить туда почту. при этом, можно отправить почту не напрямую, а через специальный relay сервер, который уже сам займется доставкой почты до получателя. обычно relay сервера требуют авторизации отправителя для дальнейшей пересылки почты. те, которые не требуют авторизации, называются open relay. проблема, которая связана с ними — это то, что любая машина сможет послать письмо, которое будет выглядеть, как письмо, полученное от этого relay.
в итоге доставка почты выглядит примерно так:
машина пользователя => relay => … => relay => сервер назначения
отсылка почты напрямую используется сейчас не очень часто и, в основном, всякими сервисами и гиками, которые сподобились настроить local delivery. в том случае, когда пользователь отправляет почту через почтовую программу с указанием mail сервера и данных аутентификации или через web–интерфейс, то почта уходит напрямую с сервера почтового сервиса. при этом отсылка почты напрямую в большинстве случаев сразу же дает знать о себе: скорее всего у такого хоста не будет reverse dns записи или будет что–то выделяющееся, например ppp85-140-10-222.pppoe.mtu-net.ru; в случае серьезного сервиса его владельцы обычно заботятся о reverse dns записи.
reverse dns — это когда по ip адресу можно получить имя связанного с ним домена.
тут есть одна тонкость: спамер может зарегистрировать кучу доменов, купить кучу ip адресов, но ему придется все время покупать новые домены и ip адреса (потому что его будут блокировать — адрес–то известен), что не слишком выгодно. поэтому зачастую спамеры используют зараженные вирусами машины, чтобы ответственность легла на пользователя такой машины. большинство таких зараженных машин находится дома у пользователей, а самый распространненый тип домашнего подключения — это доступ с динамическим ip адресом.
поэтому, отказывая в получении почты с динамических адресов, мы ограничиваем неправильно настроенные интернет–сервисы, гиков с local delivery и сети машин домашних пользователей, зараженные вирусами и рассылающие спам.
для отсеивания спама также иногда применяется технология DNSBL, которая заключается в том, что система с DNSBL получает отчеты об ip адресах машин, которые рассылают спам и делают списки этих адресов доступными всем или подписчикам. сама система по задумке неплохая, но имеет порядочное количество нареканий. например, в некоторых системах DNSBL заблокированы целые подсети адресов и для администратора почтового сервера нет никакой возможности исключить из блокировки свою машину. или кто–то получил пароль для авторизованного аккаунта и начал рассылать с этого аккаунта спам. ip адрес попал в DNSBL и нужно тратить время, чтобы эта ошибка пользователя не отключила полностью отсылку почты с этого сервера. поэтому я не использую эту технологию и другим не рекомендую, так как моя практикапоказывает, что вреда от нее больше, чем пользы.
после отсеивания всех неугодных нам машин, мы беремся за то, как спамеры общаются с нашим почтовым сервером по SMTP протоколу. большинство доковылявших спам–ботов отваливается на простой проверке — в команде HELO должно быть полное доменное имя отправителя. дальше вставляем несколько простых проверок — на наличие указанного адресата, на количество адресатов в минуту, почту для которых мы готовы принять. дальше просто принимаем почту и надеемся, что тупых бот сетей больше, чем разумных.
практика
я сразу же принялся за анализ логов. сразу же стало видно, что есть достаточно большое количество спама исходит от машин, которые тупо перебирают адреса по словарю на домене. postfix не предоставляет встроенных инструментов для отрезания таких деятелей, посему эта проблема была отложена в долгий ящик, но к сведению были приняты некоторые настройки, которые ограничивают количество соединений, писем и получателей в одном письме.
различные «строгие» опции:
лимитирование слишком быстрых:
вторая проблема, которая стала сразу же видна — это соединения с динамических адресов различных интернет провайдеров (через dialup, adsl или подобные соединения) или тех адресов, которые вообще не имеют reverse dns записи. копания в поисках способа определения этих самых динамических пользователей привели меня к статье http://www.yekt.info/postfix_antyspam.html. там я и почерпнул необходимую информацию, но, к сожалению, действия, приводимые там мне не очень понравились, поэтому я расскажу, что сделал я, а те, кому интересно, смогут сравнить и сделать свои собственные выводы.
отклоняем желание клиента прогнать команды «по–быстрому»; разрешаем тех, кто ввел логин/пароль; разрешаем соединения из доверенных сетей; отклоняем тех у кого не совпадают сочетания ip адрес 1=>домен, домен=>ip адрес 2 и ip адрес 1 == ip адрес 2; проверяем клиента на отсутствие в известных dialup и dsl сетях.
ниже добавились:
проверка на известные проблемные helo, отказ от обслуживания клиентам, доменное имя которых вызывает подозрения
две оставшиеся проверки — на наличие домена у отправителя письма и правильное указание получателя.
результат
оказался хорош. например, за 24 марта было 433 158 попыток соединения с почтовым сервером, чтобы отправить почту и почта была доставлена лишь в 1 068 случаях.
как говорят пользователи, им кажется, что вся почта доходит, полезная почта не теряется. вместо гигабайта в день принимается около 4 мегабайт почты.
в следующей заметке я расскажу, как сделать так, чтобы имеющаяся система не проседала со временем.
примерно с месяц назад на своей работе я начал переносить почту со старого и неуправляемого CommunigatePro на более стандартный (в рамках почтового сервера под управлением Mac OS X) postfix. и после переноса аккаунтов обнаружил, что /var/log/mail.log растет не по дням, а по часам, причем на пару сотен мегабайт в час. к концу суток у меня был шестигигабайтный лог файл и около гигабайта новых писем. я довольно сильно испугался, что так будет и дальше.
сервер по умолчанию был настроен на прием корреспонденции только для известных адресов, других проверок не делалось.
это вынудило меня начать разбираться со встроенными механизмами фильтрации спама в postfix и возможности применить особенности протокола smtp для отсеивания всей этой корреспонденции. можно было бы попробовать поставить spamassassin или другие решения с открытыми исходниками и натюнинговать их, но гигабайт принятой почты меня совсем не радовал. платные варианты сразу же были исключены, так как спам в основном приходит на русском языке, а kaspersky antispam и спамоборона не имеют сборок под Mac OS X.
немного теории
любая машина, подключенная к интернет, может получить mx dns запись для любого из доменов и отправить туда почту. при этом, можно отправить почту не напрямую, а через специальный relay сервер, который уже сам займется доставкой почты до получателя. обычно relay сервера требуют авторизации отправителя для дальнейшей пересылки почты. те, которые не требуют авторизации, называются open relay. проблема, которая связана с ними — это то, что любая машина сможет послать письмо, которое будет выглядеть, как письмо, полученное от этого relay.
в итоге доставка почты выглядит примерно так:
машина пользователя => relay => … => relay => сервер назначения
отсылка почты напрямую используется сейчас не очень часто и, в основном, всякими сервисами и гиками, которые сподобились настроить local delivery. в том случае, когда пользователь отправляет почту через почтовую программу с указанием mail сервера и данных аутентификации или через web–интерфейс, то почта уходит напрямую с сервера почтового сервиса. при этом отсылка почты напрямую в большинстве случаев сразу же дает знать о себе: скорее всего у такого хоста не будет reverse dns записи или будет что–то выделяющееся, например ppp85-140-10-222.pppoe.mtu-net.ru; в случае серьезного сервиса его владельцы обычно заботятся о reverse dns записи.
reverse dns — это когда по ip адресу можно получить имя связанного с ним домена.
тут есть одна тонкость: спамер может зарегистрировать кучу доменов, купить кучу ip адресов, но ему придется все время покупать новые домены и ip адреса (потому что его будут блокировать — адрес–то известен), что не слишком выгодно. поэтому зачастую спамеры используют зараженные вирусами машины, чтобы ответственность легла на пользователя такой машины. большинство таких зараженных машин находится дома у пользователей, а самый распространненый тип домашнего подключения — это доступ с динамическим ip адресом.
поэтому, отказывая в получении почты с динамических адресов, мы ограничиваем неправильно настроенные интернет–сервисы, гиков с local delivery и сети машин домашних пользователей, зараженные вирусами и рассылающие спам.
для отсеивания спама также иногда применяется технология DNSBL, которая заключается в том, что система с DNSBL получает отчеты об ip адресах машин, которые рассылают спам и делают списки этих адресов доступными всем или подписчикам. сама система по задумке неплохая, но имеет порядочное количество нареканий. например, в некоторых системах DNSBL заблокированы целые подсети адресов и для администратора почтового сервера нет никакой возможности исключить из блокировки свою машину. или кто–то получил пароль для авторизованного аккаунта и начал рассылать с этого аккаунта спам. ip адрес попал в DNSBL и нужно тратить время, чтобы эта ошибка пользователя не отключила полностью отсылку почты с этого сервера. поэтому я не использую эту технологию и другим не рекомендую, так как моя практикапоказывает, что вреда от нее больше, чем пользы.
после отсеивания всех неугодных нам машин, мы беремся за то, как спамеры общаются с нашим почтовым сервером по SMTP протоколу. большинство доковылявших спам–ботов отваливается на простой проверке — в команде HELO должно быть полное доменное имя отправителя. дальше вставляем несколько простых проверок — на наличие указанного адресата, на количество адресатов в минуту, почту для которых мы готовы принять. дальше просто принимаем почту и надеемся, что тупых бот сетей больше, чем разумных.
практика
я сразу же принялся за анализ логов. сразу же стало видно, что есть достаточно большое количество спама исходит от машин, которые тупо перебирают адреса по словарю на домене. postfix не предоставляет встроенных инструментов для отрезания таких деятелей, посему эта проблема была отложена в долгий ящик, но к сведению были приняты некоторые настройки, которые ограничивают количество соединений, писем и получателей в одном письме.
различные «строгие» опции:
strict_rfc821_envelopes = yes
disable_vrfy_command = yes
smtpd_delay_reject = yes
smtpd_helo_required = yes
лимитирование слишком быстрых:
anvil_rate_time_unit = 60s
smtpd_client_connection_count_limit = 5
smtpd_client_connection_rate_limit = 6
smtpd_client_message_rate_limit = 6
smtpd_client_recipient_rate_limit = 10
вторая проблема, которая стала сразу же видна — это соединения с динамических адресов различных интернет провайдеров (через dialup, adsl или подобные соединения) или тех адресов, которые вообще не имеют reverse dns записи. копания в поисках способа определения этих самых динамических пользователей привели меня к статье http://www.yekt.info/postfix_antyspam.html. там я и почерпнул необходимую информацию, но, к сожалению, действия, приводимые там мне не очень понравились, поэтому я расскажу, что сделал я, а те, кому интересно, смогут сравнить и сделать свои собственные выводы.
отклоняем желание клиента прогнать команды «по–быстрому»; разрешаем тех, кто ввел логин/пароль; разрешаем соединения из доверенных сетей; отклоняем тех у кого не совпадают сочетания ip адрес 1=>домен, домен=>ip адрес 2 и ip адрес 1 == ip адрес 2; проверяем клиента на отсутствие в известных dialup и dsl сетях.
smtpd_client_restrictions =
reject_unauth_pipelining,
permit_sasl_authenticated,
permit_mynetworks,
reject_unknown_client_hostname,
check_client_access regexp:/etc/postfix/dul_checks,
permit
ниже добавились:
проверка на известные проблемные helo, отказ от обслуживания клиентам, доменное имя которых вызывает подозрения
smtpd_helo_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
check_helo_access regexp:/etc/postfix/helo_regexp,
check_helo_access regexp:/etc/postfix/dul_checks,
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,
reject_unknown_helo_hostname,
permit
две оставшиеся проверки — на наличие домена у отправителя письма и правильное указание получателя.
smtpd_sender_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
permit
smtpd_recipient_restrictions =
reject_unauth_pipelining,
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_invalid_hostname,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
permit
результат
оказался хорош. например, за 24 марта было 433 158 попыток соединения с почтовым сервером, чтобы отправить почту и почта была доставлена лишь в 1 068 случаях.
как говорят пользователи, им кажется, что вся почта доходит, полезная почта не теряется. вместо гигабайта в день принимается около 4 мегабайт почты.
в следующей заметке я расскажу, как сделать так, чтобы имеющаяся система не проседала со временем.
Friday, March 20, 2009
Thursday, March 5, 2009
mysql grants dump
меня тут на собеседовании спросили: «а почему вы не любите mysql»?
я вам отвечу.
когда делается «grant privileges on … to 'user'@'hostname' … », то при наличии двух записей, указывающих на один и тот же ip адрес (например 'user'@'host.example.com' и 'user'@'10.0.2.1'), то выбирается всегда запись с ip адресом, а вот сообщение в логе выводится по reverse dns имени хоста. разработчики mysql, вот вам от меня гнилой помидор!
допустим, вы сдампили все базы mysql и хотите теперь восстановить базу к прежнему состоянию в другом месте.
и вуаля — не работают указанные вами гранты. хотите узнать почему? потому что разработчики mysql не умеют без костыликов и вам придется запустить этот костылик самому:
получите–ка, дорогие мои, в лицо собачьей какашкой.
я вам отвечу.
когда делается «grant privileges on … to 'user'@'hostname' … », то при наличии двух записей, указывающих на один и тот же ip адрес (например 'user'@'host.example.com' и 'user'@'10.0.2.1'), то выбирается всегда запись с ip адресом, а вот сообщение в логе выводится по reverse dns имени хоста. разработчики mysql, вот вам от меня гнилой помидор!
допустим, вы сдампили все базы mysql и хотите теперь восстановить базу к прежнему состоянию в другом месте.
mysql -u super -p <mysql_dump
и вуаля — не работают указанные вами гранты. хотите узнать почему? потому что разработчики mysql не умеют без костыликов и вам придется запустить этот костылик самому:
flush privileges
получите–ка, дорогие мои, в лицо собачьей какашкой.
Friday, January 9, 2009
beware perl
как ни странно, скрипт ниже по тексту письма работает без ошибок.
#!/usr/bin/perl
use strict;
print asdfagertghswdfgasdfgsdfgasdf;
# то же самое, когда перл не может определить контекст bareword, он рассматривает его как FILEHANDLE
{
no strict 'refs';
*{a} = sub {return "hello!!!";};
}
print a; # does nothing
print a (); # nothing
print "-=-=-=-=-=-=-=-";
print a(); # ok
print &a; # ok
#beware!
Wednesday, December 31, 2008
the beatles
некоторое время назад, благодаря постоянным «новостям» о том, что битлы наконец проложат свой путь в itunes music store, я решил таки послушать что и как они поют. и это оказалось для меня потрясением — большинство песен с точки зрения звука оказались беспомощным говном. я был в шоке от этого феномена и решил не обращаться к этой теме больше. но недавно услышал как fiona apple поет их песню и понял, в чем дело.
как оказалось, все просто. у битлов хорошая музыка и тексты. но пение и оранжировки портят все. если даже небольшая часть песен спета неплохо, то все остальные спеты и сыграны так, что просто уши вянут.
например — битлы:
и fiona apple:
второй по звуку для меня на порядок приятнее.
как оказалось, все просто. у битлов хорошая музыка и тексты. но пение и оранжировки портят все. если даже небольшая часть песен спета неплохо, то все остальные спеты и сыграны так, что просто уши вянут.
например — битлы:
и fiona apple:
второй по звуку для меня на порядок приятнее.
Subscribe to:
Posts (Atom)