Одминский блог

VMware ESXi не понимает томов более 2TB

Ставил у клиента сервак. Решили сделать из одного два, ибо шибко крутой прикупили клиенты, так чтобы не было избыточных мощностей, пришли к выводу что будет виртуализовывать и поднимать парочку. Собственно сконфигурил том в рейде, на 2.8 TB, запустил инсталлер VMware ESXi 4.1. Все поставилось быстренько, установил гипервизора, захожу в консоль, немного ковыряюсь с настройками сервера, и начинаю ставить Windows 2008.

Но тут возникает интересный момент- система видит единственный datastore размеров в 800Gb, и все. То есть в девайсах показывает что есть рейд контроллер, есть рейд массив на 2.8TB, но попытка обнаружения новых datastore не увенчивается успехом, так что в системе доступны только 800 гиг. Гуглю, лезу по форумам и обнаруживаю интересный момент, что VMware не может создавать хранилища больше двух террабайт, то есть у системы VMware и имеется ограничение на создание файлов размером более 2TB.

Чертыхаюсь, перегружаюсь- вижу что VMware видит том на аппаратном уровне, так что попытка разбить его на слайсы сразу будет увенчана неудачей. Собственно залезаю снова в рейдовский биос, сношу том и нарезаю его двумя кусками в 900Gb и 1900GB, после чего запускаю снова инсталлер. VMware видит оба куска, и я ставлю её на тот что  размером 900Gb. Все устанавливаю, загружаю систему, подключаюсь гипервизором- все замечательно: в системе два хранилища данных datastore, размерами в 900Gb и 1900Gb.

Резюме: Система виртуализации VMware ESXi не может создавать хранилища данных LUN размером превосходящие 2TB, в данном случае сказывают ограничения по размеру создаваемого файла. При этом если том превышает своими размерами 2TB, то система берет то количество дискового пространства, которое выходит за пределы 2TB и из них создает хранилище, отбрасывая 2TB за ненадобностью. В этой связи единственный способ борьбы- нарезка имеющегося дискового пространства массивами не превышающими 2TB, в этом случае VMware подхватывает их без проблем, и нарезанные массивы подключаются к настроенным системам, средствами VMware путем добавления новых дисков.

(more…)

Рубрика: Дела Одминские, Подсказки, Файловые системы | Ваш отзыв »

После переезда сайта в Drupal открывается только первая страница

Пришлось мне тут переносить один сайт на Drupal который моей конторе достался от одного разработчика- ue-бана. Вкратце, чел со своей конторой доил агентство как мог- выставив не высокие цены за разработку, вламывал в качестве работы над модулями в среднем от 10 до 24 часов за доработку стандартных модулей и прочее, при этом и грел их на хостинге.

(more…)

Рубрика: Сайты и их проблемы | Отзывов: 9 »

Проблема с экспортом конфигурации на R65

Клиенты  попытались перенести шлюз Check Point R65 с одной машины на другую,  и получили не приятные проблемы в виде сообщения при попытке подтянуть конфигурацию с помощью утилиты upgrade_import.  Ошибка которую выводит консоль гласит: Error: Exported and imported machines are not cluster compatible.

Старый сервер однопроцессорный, второй двухпроцессорный.

Стали выяснять, оказалось что помимо R65 Adv Routing клиент устанавливает также HFA70, то есть получается что утилита upgrade_import на старой машине и новой различается версиями.  Собственно не смотря на поучения нашего продакта, который полез в глубины кластеризации шлюзов, посоветовал клиентам попробовать использовать одинаковые версии утилиты upgrade_import.

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

Рубрика: Check Point | Отзывов: 3 »

Управление автоповторами в Exim

На одном из почтарей под управлением exim возникала постоянно ситуация, когда при отправке письма на широковещательный внутренний адрес компании alloffice@odminblog.ru, в случае переполнения ящиков одного или нескольких пользователей, письмо ничинало отсылаться каждые 15 минут, после чего количество забитых ящиков еще больше увеличивалось и почтарь впадал в ступор. Возникало не из-за того что я первоначально криво все настроил, а из-за того что пользователи имея ящики по 200 метров не запаривались на их очистку, в добавок к чему сыпали мейлами по 15-20 мегабайт.

В этой связи возникла задача переписать стандартное правило автоповторов для exim. Для этого открываем конфигурационный файл и идем в самый его конец, в секцию RETRY. Там мы видим следующие строки:

########################################
#                      RETRY CONFIGURATION                           #
########################################
begin retry
# Domain               Error       Retries
*                 refused_A   F,2h,20m;
*                      *           F,2h,15m; G,16h,1h,1.5; F,4d,6h

Это стандартное правило автоповторов для exim, и оно всегда имеет две звездочки, для того чтобы описать общее правило для всех доменов и ошибок, не описанных отдельным полем. Об этом описании мы поговорим позже, а в данной записи получается что в случае любой ошибки для любого домена повтор отправки будет осуществляться каждые 15 минут в течении двух часов, после чего с интервалами от одного часа до 16 часов, с множителем в 1,5, после чего в течении 4 дней попытка будет осуществляться каждые 6 часов. После истечения времени автоповтора exim отбивает адрес доставки и скитывает отправителю отлуп.

Само правило автоповтора создается по следующему шаблону:
<Domain><Error><Retries>
Первым пункт может включать как имя домена, так и, для сужения задачи, адрес получателя.
Второй пункт описывает специфическую ошибку, которые бывают следующих типов:
auth_failed – при неудачной аутентификации в случае отправки на хост из списка  hosts_require_auth
data_4xx   – при ошибке которая получается для команды smtp диалога DATA, или сразу же после команды
mail_4xx   – при ошибке которая получается для команды smtp диалога MAIL.
rcpt_4xx    – которая получается для команды smtp диалога RCPT
Также в этих трех ошибках, ошибка может задаваться полным номером, для сужения правила применения автоповтора.
lost_connection – при неожиданном закрытии SMTP-сессии со стороны сервера
refused_MX – при отказе в соединении к хосту определенному как почтовый сервер по данным из MX записи
refused_A – при отказе в соединении к хосту полученному не из MX записи
refused – при любом отказе в соединении
timeout_connect_MX – при таймауте попытки соединения с хостом определенномв MX-записи
timeout_connect_A – при таймауте попытки соединения с хостом полученным не из MX-записи
timeout_connect – при таймауте любой попытки соединения
timeout_MX – при таймауте во время соединения или в процессе SMTP-сессии с хостом, полученным из MX-записи
timeout_A – при таймауте во время соединения или в процессе SMTP-сессии с хостом, полученным не из MX-записи
timeout – при таймауте во время соединения или в процессе SMTP-сессии
tls_required – в сессии соединения сервер должен был использовать TLS (сервер определен в списке  hosts_require_tls), но либо TLS не был предложен, либо сервер прислал ответ 4xx на команду STARTTLS
quota  – при локальной доставке транспортом “ appendfile ” была превышена квота почтового ящика пользователя
quota_<time> – при локальной доставке транспортом “ appendfile ” была превышена квота почтового ящика, и к почтовому ящику не обращались время равное <time>
Также после этого поля возможно определить отправителя, тем самыв сузив правило автоповтора, например для приоритезации руководства компании:
senders=<address list>
Тогда правило автоповтора будет выглядеть
kremlin.ru  rcpt_452  senders=”mainperson@odminblog.ru”  G,8h,10m,

Третий пункт отпределяет само правило автоповтора:
<letter>,<cutoff time>,<arguments>
Буквой задает алгоритм вычисления правила автоповтора:
F – повторять автоповтор с определенным интервалом. Первое число определяет в течении какого периода осуществлять автоповтор, второе задает интервал.
G -  повторять автоповтор в геометрически увеличивающихся интервалах. Первое число определяет максимальное значение для интервала, второе начальное значение интервала, третье число множитель, используемый для увеличения интервала при каждом повторении.Если первое число не задано, то интервал увеличивается до значения параметра retry_interval_max, который не может быть больше 24h.
H – повторять отправку повтора со случайными интервалами. Используемые аргументы – такие же как для  G. Для каждого повтора, предыдущий интервал умножается на фактор, для получения максимума следующего интервала. Минимальный интервал – первый аргумент параметра, и актуальный интервал выбирается случайным образом из диапазона между ними.
Если в поле правила автоповтора ничего не задано, то сразу после неудачной попытки отправки, генерируется рикошет и уходит в сторону отправителя.

Исходя из всего вышеописанного создаем новое правило автоповторов:
####################################################
#                      RETRY CONFIGURATION                           #
####################################################
begin retry
# Domain               Error       Retries
alloffice@odminblog.ru    *
odminblog.ru    quota
*                 refused_A   F,2h,20m;
*                      *           F,2h,15m; G,16h,1h,1.5; F,4d,6h

По этому правилу на все ошибки препятствующие доставки на адрес alloffice@odminblog.ru будет генерироваться рикошет, а при переполнении ящика кого либо из пользователей домена odminblog.ru также будет генерироваться рикошет

Рубрика: Почтовые системы | 1 отзыв »

Удаленное X-подключение к серверу CentOS

Возникла некая необходимость управлять сервером шуршащим под CentOS, из винюка, причем не абы как, а через X-терминал. Поковырявшись, решили делать через Xming- бесплатный продукт, который можно скачать в инете в версии 6.9.0.31, на данный момент. За версию 7.5 дяди хочут бабла в размере 10 евриков, так что нам этот вариант не катит.

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

Схема работы простая: есть юниксовый сервер UNIX-Server под управлением CentOS на котором крутится X-клиент/сервер; есть виндовая машинка Win-XP на которой поднимается X-сервер Xming с помощью которого мы подключаемся к клиентской части UNIX-Server и по идее должны получить картинку с X-терминалом на рабочем столе виндовой машины.

Для начала скачиваем и устанавливаем на нашу Win-XP рабочую станцию X-сервер  Xming, откуда нить с инетовского зеркала, благо их предостаточно разбросано по инету. После установки пробуем настроить работу через Xdmcp.  Это специфический незашифрованный протокол, используемый для аутентификации и подключения Х-сервера к Х-клиенту.  Поскольку он не является закрытым, то его не рекомендуется использовать в открытых сетях, но это ограничение убирается при использовании сторонних средств шифрования. Ибо это наше первое знакомство, то не будем запариваться на безопасность и попробуем хотя бы запустить данный сервис.

Для этого на UNIX-Server открываем файло  /usr/share/config/kdm/kdmrc и в разделе [Xdmcp] проверяем, чтобы активность равенства Enable=true
После этого добавляем в файлы следующие поля:

/etc/gdm/custom.conf
[xdmcp]
Enable=true

/etc/X11/fs/config
# no-listen = tcp

Настроиваем логин: K Menu -> System -> Login Screen
Во вкладке Remote, меню Style выставляем  Same as Local
Во вкладке Security, ставим галку Allow local system administrator login

Перегружаем Х-сервер
# /etc/rc.d/init.d/xfs restart
после чего переходим к настройке виндового сервера. Запускаем приложение XLaunch, в котором выбираем
One Window -> Open session via XDMCP -> в Connect to host прописываем IP адрес UNIX-Server и ставим галку Use indirect connect (народ пишет, что её надо снять но в нашем случае заработало только с ней) -> можем оставить пустыми, либо прописать свойства терминала Х, например в Remote font server наш IP UNIX-Server, а в Additional parametrs for Xming строку инициализации десктопа без кавычек “-screen 0 800×600″ ->  Готово

Если все настроили правильно, то на выходе получаем консоль с приглашением нашего X-терминала.

Рубрика: Linux | Отзывов: 2 »

Устанавливаем Splunk

Собственно о системе Splunk я писал буквально в предыдущем посте, так что добавить ничего не могу, кроме того что это система управления инцидентами и событиями информационной безопасности. Ставить систему будем на FreeBSD 6.4, ибо она вся такая для меня приятная.
Итак поехали, ибо создатели пакета обещают что ставится она на раз-два-три:

# wget ‘http://www.splunk.com/index.php/download_track?file=4.1.4/freebsd/splunk-4.1.4-82143-FreeBSD-i386.tgz&ac=&wget=true&name=wget&typed=releases’
# tar -xzvf splunk-4.1.4-82143-FreeBSD-i386.tgz

Поскольку, как оказалось, пакет пришел нам в уже собранном виде, то оправляем его по месту постоянного жительства:
# cp -R splunk /usr/local/

Перед запуском системы необходимо внести изменения в конфигурационные файлы:

/boot/loader.conf
kern.maxdsiz=”2147483648″ # 2GB
kern.dfldsiz=”2147483648″ # 2GB
machdep.hlt_cpus=0

/etc/sysctl.conf
vm.max_proc_mmap=2147483647

После этого перегружаем сервер для того чтобы изменения вступили в силу. При желании можем создать ручками пользователя от которого будет работать splunk, а также и его группу, но мне что то сегодня в ломы. Поэтому запускаем сервис: перед первым запуском сервера необходимо согласиться с лицензионным соглашением, для этого стартуем:
# $SPLUNK_HOME/bin/splunk start –accept-license

После некоторого диалога, сервер сообщит, что он теперь запущен на http://our_server_hostname:8000 хотя зайти можно и по адресу http://our_server_IP:8000. В данном случае 8000 это дефолтный порт нашего веб сервера.

Теперь переходим к настройке сервера.
Логин и пароль по умолчанию для входа в web-консоль:
username: admin
password: changeme

В верхнем правом углу белеет на темном фоне кнопочка Manager, нажав на которую мы попадаем в общирное меню, позволяющее нам настроить наш сервер в разделе System configurations, а также добавить необходимые модули Apps, собития, поиски и прочая в разделе Apps and knowledge.

В System settings задается хостнейм и настраиваются веб-морда сервера, а также параметры индексирования. Также настраивается отправка алертов по почте и всевозможные уровни логирования, которых доступно шесть вариантов: DEBUG, INFO, WARN, ERROR, CRIT, FATAL.

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

Рубрика: FreeBSD, IT безопасность, Дела Одминские | Ваш отзыв »

Ошибки при использовании InfoView

Забавная ситуация конечно с просмотром cpinfo файлов, ибо когда я запрашивал эту информацию у тех поддержки check point они мне ответили, что таких утилит у них нет в доступном обозрении, и все это возможно просматривать на их стороне. Однако в usercentre отыскался файлец infoview_360000087_1.exe, доступный для скачивания , который как раз и является смотрелкой и эмулятором для ознакомления с конфигурацией машины и политиками шлюза, полученные путем сбора файла cpinfo. Устанавливаем сию легковесную утилиту и начинаем радостно пользовать для просмотра полученных cpinfo. Единственно несколько напрягает надпись на вкладке о-программе “For internal use only”. Интерфейс прост и незамысловат, в конфиге просмотра можно выбрать какую версию SmartDashboard использовать для открытия собранных политик: если этого не сделать, то для открытия политики будет выбираться наиболее актуальная версия. Также в комплекте поставки идет версия для Provider-1.

И вот при использовании утилиты стали возникать эпизодические проблемы связанные с тем, что политики там или иначе не открывались в InfoView, сопровождая это матерной руганью “Error occured while trying to copy local_plugins_list.C from Gui library” и “The connection has been refused because the database could not been opened”. Собственно удалось побороть это следующим образом: первое сообщение убралось после того, как клиент установил на своем сервере последнюю версию утилиты cpinfo (на данный момент cpinfo_911000096_2) и снова собрал данные по своей системе. Второе сообщение появилось первый раз при открытии, но после того как выпав в Demo-режим, ручками указывалось что следует открывать вариант InfoView, открылась корректно, после чего повторно стала открываться без ошибок.

Так что получается что проблемы лечатся установкой последних версий cpinfo и InfoView, хотя у коллеги на рабочем XP (я пробовал на своем Server 2003 и двух чистых виртуалках XP и 2Yk) выскакивает ошибка, указывающая на то что при открытии возникают какие то проблемы с буффером памяти, что вероятнее всего находится в зависимости от каких то установленных программ или патчей.

Кстати, в процессе копания вскрылся интересный момент что cpinfo собранный на R65 открывается нормально в версии R65.3 SmartDashboard, в то время как в обычной R65, открытие политик приводит к возникновению ошибки The connection has been refused because the database could not been opened.

Рубрика: Check Point | Ваш отзыв »