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

Проброс X-соединения через SSH

Как я описывал в предыдущих терзаниях по поводу настройки X-соединения с Windows машины к CentOS серверу, Xdmcp не является безопасным, в связи с чем его использование довольно ограничено использованием в открытых сетях, в связи с чем приходится изыскивать другие пути общения со своим удаленным сервером через X-соединение.
Но  X-терминальное соединение, можно инкапсулировать в протокол ssl, путем проброса соединения к клиентской части X-терминала, через протокол сеансового уровня SSH. Для этого ранее использовалась бесплатная программа putty, позволяющая устанавливать ssh соединение с удаленными машинами, а ноне данный клиент включен в поставку Xming сервера. Для чего при установке севера Xming на нашей клиентской Windows машине, в разделе выбора компонентов, выберем пункт Normal Putty Link SSH client. После установки произведем настройку нашего Unix-сервера под управление CentOS:

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

После этого запускаем сервер Xming на стороне виндовой машины и настраиваем подключение, запустив программу XLaunch:
Multiple Window -> Start a program -> в Run Remote выбираем Using PuTTY и прописываем логин информацию к CentOS серверу через SSH  -> Additional parametrs можем оставить пустыми, либо прописать свойства терминала Х и ssh соединения ->  Готово

После нажатия Готово к нам вылетит окно стандартного текстового терминала юниксового сервера xterm, в котором мы можем запускать любые приложения, также как и в окне ssh сессии, с тем условием, что в случае запуска гуевых приложений, предназначенных для работы в X-окружении, в ssh сессии мы бы получили сообщение об ошибке, а в данном случае это приложение будет запущено на нашем виндовом рабочем столе. Для этого набираем любое юниксовое приложение:

# xeyes &
или
# blackjack &

Амперсенд нужен для того чтобы приложение запускалось в фоновом режиме и не вылетало когда мы снова начинаем работать в терминальной сессии.

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

В процессе настройки в какой то момент в логах появилось неприятное сообщение о том, что пакеты дропаются стороной CentOS сервера, что вылечилось добавлением в файл X-сервера Xming виндусовой машины C:\Program Files\Xming\X0.hosts строчки, содержащей IP адрес нашего CentOS сервера. Но это скорее исключение из правил, ибо все работает и без этого.

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

Удаленное 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 | Ваш отзыв »

Устанавливаем 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 | Ваш отзыв »

Автозагрузка в CentOS

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

Собственно в CentOS процесс загрузки работает по принципу System V и расписан в файле  /etc/inittab, точнее расписано то как процесс INIT отрабатывает уровни загрузки. В системе фалы загрузки находятся в каталоге /etc/rc.d и носят названия rc0.d, rc1.d, rc2.d, rc3.d, rc4.d, rc5.d, и rc6.d. Пользователи могут размещать файлы в этих каталогах которые будут контролировать запуск сервисов в системе.В свою очередь эти фалы линкуются на каталог /etc/rc.d/init.d и содержащиеся в них скрипты запуска процессов. В этой связи для запуска сервиса необходимо создать полноценный файл запуска сервиса в /etc/init.d, после чего задать символический линк на него из папки соответствующей тому уровню запуска, на котором необходимо стартовать данный сервис. Файлик запуска сервиса будет выглядеть следующим образом, хотя можно расписать все  пару строк просто строкой запуска сервиса:

#!/bin/bash
#
# chkconfig: 35 90 12
# description: Foo server
#

exit 0

Если нет желания заморачиваться с написанием скрипта, то можно добавить строку инициализации запуска сервиса в файл /etc/rc.local. Это файл будет отработан в самом конце загрузки системы, но перед выдачей меню логина.

Для добавления сервисов находящихся в попдапках rc0.d – rc6.d в автозагрузку в системе есть специальная утилита chkconfig, с помощью которой можно добавлять или исключать сервисы.

# chkconfig -l service_name # просмотреть уровни автозагрузки сервиса
# chkconfig  –level 34 service_name on|off|reset # вкключить или выключить сервис на 3 и 4 уровнях
# chkconfig  –del service_ name # удалить службу
# chkconfig  service_name on|off # включить или выключить службу на всех уровнях
ну и есессно главная команда:
# man chkconfig

Помимо этого можно воспользоваться утилитой ntsysv , для редактирования всех уровней или задач редактирования для определенного уровня:
# ntsysv –level 34

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

Объединяем интерфейсы в CentOS

Разбираясь, накануне, с настройкой IP адреса в CentOS обнаружил интересную фичу по объединению нескольких интерфейсов в один виртуальный, тем самым повышая скорость передачи данных и создавая функционал отказоустойчивости, с помощью модуля ядра bonding.

Для этого необходимо создать bonding интерфейс, путем создания файла /etc/sysconfig/network-scripts/ifcfg-bond<N> , где N номер объединяемого интерфейса. Содержимое файла аналогично содержимому файла описания настроек обычно интерфейса, с той разницей что директива DEVICE= должна содержать поле bond<N>, где N номер интерфейса.

Пример файла выглядит следующим образом:
DEVICE=bond0
BOOTPROTO=none
ONBOOT=yes
NETWORK=10.0.1.0
NETMASK=255.255.255.0
IPADDR=10.0.1.27
USERCTL=no

После того как файлы будут созданы, можно объединять интерфейсы путем добавления директив MASTER= и SLAVE=  , так что за исключением этих полей оба файла должны выглядеть идентично. Например для интерфейсов eth0 и eth1файлы конфигурации будут выглядеть следующим образом:
DEVICE=eth<N>
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

Для того чтобы  слияние интерфейсов работало, необходимо чтобы модуль bonding был загружен в ядро, для чего необходимо проверить, чтобы в файле /etc/modules.conf присутствовала строка:
alias bond<N> bonding
где N номер интерфейса, и для каждого сконфигурированного интерфейса должна присутствовать своя запись.

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

Делегируем управление субдоменом

Возникла необходимость делегировать управление доменной зоной третьего уровня (то есть например newdomain.odminblog.ru) серверам доменных имен хостера. Первое что пришло в голову, это создать зону в named.conf где указать что данный сервер является вторичным и первичным обозначить доменный сервер хостинг провайдера.

Согласуясь с вышесказанным запись в named.conf приобретает следующий вид:

############################################
zone “newdomain.odminblog.ru” {
type slave;
file “slave/newdomain.odminblog.ru”;
masters {
DNS-провайдера;
};
############################################

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

newdomain    IN    NS    ns1.newdomain.odminblog.ru
newdomain    IN    NS    ns2.newdomain.odminblog.ru

После чего, через канонический тип имени CNAME определяем доменные сервера провайдера

ns1.newdomain  CNAME  ns1.DNC-провайдера.
ns2.newdomain  CNAME  ns2.DNC-провайдера.

В таком варианте все должно нормально работать. При тестировании попробовал описать DNS сервера провайдера сразу в описании NS для субдомена, используя их хостнеймы, но после такого финта, по непонятной причине отвалились MX-записи для корневого домена, что было довольно неожиданно, ибо вся остальная зона отдавалась замечательно.

Рубрика: Интернет, Сайты и их проблемы | Ваш отзыв »