headermask image



Обознался MAC-адресом!

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

В локальной сети взаимное распознавание компьютеров происходит по нескольким признакам. Причиной тому — длительная эволюция сетевых технологий и протоколов. Впрочем, на сегодня TCP/IP, будучи наиболее гибким и универсальным протоколом сетевых коммуникаций, практически вытеснил своих конкурентов (NetBEUI, IPX).

Одним из преимуществ TCP/IP является инкапсуляция: собственно, сам IP-пакет, как матрешка, состоит из нескольких частей, вложенных друг в друга. Это позволяет передавать по сети всевозможные данные, не заботясь о том, чтобы сетевые устройства были знакомы с их форматом. В месте назначения такая матрешка раскрывается — и приложение извлекает оттуда предназначенные для него данные.
Такая архитектура пакета, хотя и является весьма эффективной, таит определенную угрозу безопасности. Чтобы разобраться с этим вопросом подробнее, рассмотрим, как происходит опознавание одного ПК другим.

По имени

В сетях Windows каждый компьютер имеет уникальное имя — “smb name” или “nebios name”, которое вы задаете самостоятельно вместе с именем группы. Доступ к ресурсам сети Windows происходит согласно их именам. А как происходит привязка сетевого имени компьютера к IP-адресу его сетевой карты? При загрузке ОС происходит регистрация компьютера: Microsoft придумала для этого специальный протокол, согласно которому в сетевом сегменте есть компьютер, который хранит таблицу имен ресурсов в сети. Называется такой хост “главным браузером сети”. Каждый компьютер обращается к такому браузеру и говорит: “Я компьютер VASYA. Мой адрес 192.168.0.43″. При случайном совпадении имен или адресов опреационная система автоматически оключит сетевые функции на неправильно сконфигурированном ПК. прочитать полностью »

Ограничение размеров сообщений в Exchange 2007

В прошлой моей статье я показал вам, как можно установить ограничения размера сообщений в Exchange Server 2003. В Exchange Server 2007 все немного по-другому. Я попробую показать вам, где можно ограничивать размер сообщений.

Установить ограничения на размер сообщений в вашей организации, использующей Exchange, на нескольких объектах можно с помощью консоли управления Exchange Management Console или среды Exchange Management Shell. В этой статье будет рассказано, где можно установить эти ограничения, и как они взаимодействуют.

Область действия ограничений

Существует возможность применять фильтры размера сообщений для разных областей в Exchange Server 2007. Ограничения, устанавливаемые на уровне организации, применяются для всех серверов Exchange 2007 в вашей организации, и вам необходимо иметь соответствующие права для их установления. Если вы установили более одного транспортного сервера-концентратора (Hub Transport Server — HTS), тогда все ограничения применяются ко всем транспортным серверам-концентраторам. Если вы используете пограничный транспортный сервер(Edge Transport Server — ETS) Exchange, ограничения размера сообщений применяются к конкретному пограничному серверу Exchange.

Глобальные ограничения используются, когда у вас смешанная среда Exchange Server 2003/2007. Глобальные настройки применяются ко всем серверам Exchange 2003 и 2007, так как эти ограничения размеров сообщений сохраняются в Active Directory. Эти глобальные настройки эквивалентны секции глобальных настроек в Exchange Server 2003 System Manager. Когда настройки на уровне организации конфликтуют с глобальными ограничениями, преимущество имеют младшие настройки.

Можно также определить допустимые размеры сообщений для Exchange Server 2007 Connectors. Exchange Server 2007 использует отправляющие, принимающие и внешние коннекторы для осуществления возможности взаимодействия со «стандартными» или обычными системами отправки сообщений. Ограничения на размер сообщений для коннекторов связаны с серверами Exchange Edge Transport Server или Hub Transport Server.

Другой возможностью применения ограничений на размер сообщений является установка ограничений на серверном уровне. Ограничения, устанавливаемые здесь, применяются к конкретному серверу Exchange Hub Transport Server или Hub Transport Server, так как эти ограничения не сохраняются в Active Directory.

И, наконец, последним местом, где можно установить ограничения на размер сообщений, являются объекты, так как Mailboxes (почтовые ящики), Mail Users(Пользователи почты), Mail contacts (Почтовые контакты), Public folders(Общие папки) и группы распределения. прочитать полностью »

System Mailbox (системный почтовый ящик) Exchange 2003

В Exchange Server 2003 есть три различных типа системных почтовых ящиков, которые используются различными Exchange подсистемами.

Три различных системных почтовых ящика:

  • System Mailbox (системный почтовый ящик) {GUID}
  • System Attendant Mailbox (системный сопутствующий почтовый ящик)
  • SMTP <Servername – {GUID}> Почтовый ящик

SystemMailbox {GUID}

Для каждого индивидуального раздела хранения информации (information store) в Exchange Server 2003 имеется один системный почтовый ящик. Он создается в момент создания индивидуального раздела хранения информации и будет удален вместе с разделом.

Системный почтовый ящик состоит из двух частей:

  • Почтовый ящик с его информационным наполнением в соответствующем разделе хранения информации
  • Связанная с ним директория в Microsoft Exchange System Objects – иногда называемый MESO

Следующий рисунок иллюстрирует три различных типа системных почтовых ящиков.

Различные типы системных почтовых ящиков

Рисунок 1: Различные типы системных почтовых ящиков прочитать полностью »

Русские буквы в amarok

Была проблема с русскими тегами в amarok. Решена очень быстро, решение ниже :) Спасибо сайту kubuntu.ru

В amarok старше 1.4 разработчики убрали возможность читать теги в кодировке отличной от utf-8, их предложение – перекодировать всю свою музыку в utf-8. Amarok 1.3.9, понимает и koi8-r и cp1251.

Чтобы заставить amarok 1.4 и старше понимать руссикие ID3 теги в кодировке отличной от UTF-8 нужно сделать следующее:

sudo gedit /etc/apt/sources.list

добавляем туда:

deb http://rusxmms.sourceforge.net/ubuntu/rusxmms dapper main

Затем:

sudo wget http://rusxmms.sf.net/ubuntu/rusxmms/key.gpg -O - |
sudo apt-key add -
d -

sudo aptitude update

sudo aptitude install libtag1c2a

После это желательно сделать пересканирование библиотеки.

LPI 101: X Window System. Настройка менеджера экрана. Часть 2

Менеджеры окон

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

Вы можете подумать, что без задания пользовательского интерфейса фантазия разработчиков приведет к множеству различных стилей окон, которые борются за экранное пространство и все имеют разные сочетания клавиш, действия мыши и стили для кнопок, диалоговых окон и т.д. Для привнесения некоторого порядка в этот хаос были созданы высокоуровневые наборы инструментов. Они породили менеджеры окон типа twm, fvwm, и fvwm2 и в конечном итоге привели к графическим оболочкам KDE и GNOME.

Графические оболочки предоставляют целостную схему поведения пользователя, но также потребляют значительные ресурсы центрального процессора и памяти. До того как компьютеры стали достаточно мощными для работы с KDE или GNOME менеджеры окон были популярны и многие пользователи до сих пор любят их за лёгкость и быстродействие.

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

На самом деле команда startx представляет внешнюю оболочку для xinit запускающей процесс X-сервера и некоторые клиенты. Обычно она располагается в каталоге /usr/X11R6/bin также как xinit и многие другие X утилиты. X приложения могут брать настройки из базы данных ресурсов X также как и из командной строки. Таблица 6 резюмирует имена и назначения каждого файла конфигурации, который используется startx либо xinit. Обратите внимание на то, что некоторые или все эти файлы могут отсутствовать в конкретном системном и домашнем каталоге.
прочитать полностью »

LPI 101: X Window System. Настройка менеджера экрана

Менеджеры экрана

Если в предыдущем разделе вы установили и сконфигурировали X на компьютере, на котором ранее X отсутствовал, то вы, вероятно, заметили, что для доступа к любым графическим экранам приходиться регистрироваться в окне виртуального терминала и выполнять команду startx. Это неудобно даже для локального экрана, а для удалённого терминала не работает вообще.

Решение этой проблемы состоит в использовании менеджера экрана для предоставления графического окна регистрации и управления аутентификацией. После того, как пользователь аутентифицирован, менеджер экрана открывает для пользователя сессию на той системе, где он выполняется. Графический вывод производится на том экране, в котором пользователь ввел свои данные регистрации. Это может быть как локальный дисплей, так и X-дисплей, подключенный через сеть. И Xfree86 и X.Org поставляются с менеджером экрана XDM.

Есть ещё два популярных менеджера экрана KDE и GNOME. В этом разделе вы узнаете как устанавливать и настраивать все эти три менеджера экрана.

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

В Red Hat® и SUSE X запускается с уровнем выполнения 5. Debian рассматривает уровни выполнения со 2 по 5 как эквивалентные и по умолчанию использует уровень 2. Определение уровня выполнения производится в файле /etc/inittab как показано в листинге 9.
прочитать полностью »

Артефакты в Totem. Ubuntu 7.04

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

Думать тогда не хотелось, и я поставил другой проигрыватель mplayer. Этот вообще  отказался проигрывать видео, выдавая ошибку видеопотока или чего-то типа этого.

Третий вариант, KMplayer, заработал сразу, я пользовался им, пока сегодня не решил все таки разобраться, в чем же причина.

Итак. Проблема с totem решилась заменой totem-gstreamer на totem-xine..

totem.jpg

А mplayer вылечился выставлением в настройках видео другого кодека. Я поставил X11/Xv. Показывать он начал нормально, с единственным недостатком, изображение перевернуто вниз головой :). Как исправить пока не пойму, хотя впринципе это не важно, проигрывателей и так переизбыток.

WSUS станет опциональной ролью для Windows Server 2008 Server Manager

В дополнение к функциям и ролям, которые включены в Windows Server 2008 по умолчанию, Server Manager позволит интеграцию дополнительных ролей и функций, доступных на сайтах Microsoft Download Center и Windows Update, как опциональные обновления для Windows Server 2008.

Одна из ролей, которые будут доступны – это Windows Server Update Services 3.0 Service Pack 1 (WSUS 3.0 SP 1). Это обновление к Server Manager позволит полностью интегрировать WSUS 3.0 SP 1 в Server Manager, позволив инсталляцию, настройку и управление WSUS 3.0 SP 1, используя консоль и мастера Server Manager.

Бета тестеры могут загрузить обновление менеджера ролей для Windows Server 2008 RC0, чтобы позволить данную опциональную роль, которой сейчас является только WSUS. Но с тех пор, как Microsoft удалила Windows Sharepoint Services как доступную по умолчанию роль, скорее всего, она также станет опциональной ролью.

Источник: thevista.ru 

LPI 101: X Window System. Установка и настройка X

История X Window System

X Window System называемая также просто X или X11 – оконная среда для графических (растровых) дисплеев. Начало X было положено в Массачусетском технологическом институте (MIT) в 1984 году. X была реализована как часть проекта Афина (Project Atthena), предоставлявшего вычислительную среду, функционирующую на разнотипном оборудовании. В X-среде за вывод информации отвечает сервер экрана (display server), а логику приложения предоставляют клиенты. Взаимодействие между ними является “прозрачным” для сети, поэтому сервер и клиент могут работать на разных машинах. Следует отметить, что термины “клиент” и “сервер” несколько отличаются от обыденного представления. Помимо вывода информации, сервер обрабатывает ввод информации от различных устройств, таких как клавиатуры, мыши, графических планшетов и сенсорных экранов.

X-среда предоставляет набор средств для приложений с графическим интерфейсом, но не определяет конкретный интерфейс пользователя. В Linux обычно можно выбирать между графическими оболочками KDE и GNOME, а также несколькими другими оконными менеджерами. Поскольку X не определяет интерфейс пользователя, то эти среды и оконные менеджеры выглядят по-разному.

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

XFree86 and X.Org

К 1987 году MIT решил передать управление разработкой X отдельной организации. В результате был создан MIT X Consortium – некоммерческая группа по надзору за разработкой X-среды. После ещё нескольких изменений в управлении Open Group в 1999-м сформировал X.Org. С 1992 года большая часть разработки X выполнялась в XFree86, первоначально перенесшей X на платформу Intel® 386, откуда и название. Организация XFree86 присоединилась к X.Org в качестве члена, освобожденного от уплаты взносов.

Хотя первоначально XFree86 был создан для платформы 386, последующие версии поддерживали несколько различных платформ и стали наиболее широко используемым вариантом X-среды в Linux. После ряда споров о новых условиях лицензирования и модели разработки XFree86 была создана X.Org Foundation. Отталкиваясь от последней версии XFree86 с предыдущей лицензией X.Org создала X11R6.7 и X11R6.8. Многие дистрибутивы до сих пор используют XFree86, в то время как многие выбрали X.Org.
прочитать полностью »

LPI 101: Устройства, файловые системы Linux и стандарт FHS. Поиск и расположение системных файлов

Стандарт Filesystem Hierarchycal Standard

Стандарт Filesystem Hierarchycal Standard – это документ, который определяет структуру каталогов в Linux и других UNIX-подобных системах. Он был создан для формирования общей структуры, которая помогает упростить разработку программного обеспечения, независимого от дистрибутивов, путем расположения файлов на всех дистрибутивах Linux в одни и те же общие каталоги. Этот документ также используется в базе стандартов Linux (см. “Ресурсы”).

Две независимые категории стандарта FHS

В основе стандарта Filesystem Hierarchycal Standard лежат две характеристики файлов:

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

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

Такое разделение позволяет хранить файлы с разными характеристиками в различных файловых системах. В таблице 6 приведен пример из документа cтандарта Filesystem Hierarchycal Standard, где показана структура, соответствующая этому стандарту.

Общего использования Локального использования
Статический /usr
/opt
/etc
/boot
Переменный /var/mail
/var/spool/news
/var/run
/var/lock

Корневая файловая система

Целью стандарта Filesystem Hierarchycal Standard является максимально возможное сокращение корневой файловой системы. В ней должны содержаться все файлы, необходимые для загрузки, восстановления или исправления системы, в том числе утилиты, которые могут понадобиться опытным администраторам для выполнения их задач. Следует отметить, что для загрузки системы необходимо, чтобы в корневой файловой системе находились все средства, необходимые для монтирования других файловых систем.

Каталоги корневой файловой системы

В таблице 7 показано назначение каталогов, наличие которых в корневой файловой системе (/) обуславливает стандарт Filesystem Hierarchycal Standard. В ней должны присутствовать перечисленные каталоги или символические ссылки на них, за исключением отмеченных как необязательные, которые необходимы только в случаях, когда имеется соответствующая подсистема. прочитать полностью »