Декоративная штукатурка своими руками Не просто так эту статью я назвал декоративная ш...
МАСТЕР КЛАССЫ ПО КАНЗАШИ - (1)Мастер классы по канзаши. Много Мастер-класс МК "Кру...
РЕЗИНКИ ДЛЯ ВОЛОС - (0)Оригинальные резинки для волос. Котейки в стиле "русское канзаши". МК Ладицы Однажды в &...
ЕЛОЧКА - (0)Елочка канзаши. Мастер-класс Елочка канзаши. Мастер-класс Источник:http://www.tutdizain.ru...
Цветок из узкой ленты - (0)Мастер-класс Екатерины Сотниковой "Канзаши из узкой ленты". Екатерина Сотникова (Москва, Россия...
Использование Kerberos для проверки подлинности SharePoint |
Хотя SharePoint предлагает несколько вариантов проверки подлинности и зон аутентификации, двумя общепринятыми вариантами выбора для корпоративной реализации в сценариях интрасети являются протокол NTLM и Kerberos. Оба эти протокола используются совместно со встроенной проверкой подлинности Windows по классической схеме Запрос/Ответ. Протокол NTLM использует метабазу IIS, генерирующую маркер с вызовом, который она отправляет клиенту, клиент отвечает маркером, а контроллер домена проверяет подлинность данного ответа. В протоколе NTLM необходимо шифрование имен пользователей и паролей перед их передачей, а также повторная проверка подлинности (новый маркер) при получении доступа к новому сетевому ресурсу. Протокол Kerberos, с другой стороны, основывается на системе билетов, когда клиент и сервер получают доступ к доверенному центру авторизации под названием Центр распределения ключей (Key Distribution Center, KDC), который отвечает на запросы клиента и выдает билеты, которые могут использоваться клиентом для подключения к сетевым ресурсам. Для протокола Kerberos не требуется повторная проверка подлинности для получения доступа к нескольким ресурсам.
В большинстве документов советуют использовать протокол NTLM, если только нет необходимости, например, для узлов с соглашениями о высоком уровне безопасности служб. Даже в этом случае, если как следует разобраться, имеется смысл использовать протокол NTLM: его легче внедрять, он требует дополнительных этапов проверки, а также уменьшает проблемы, связанные с технической поддержкой. Например, в базе знаний 832769 сказано: "… или если вы не можете настроить имя участника-службы (SPN), выбрать проверку подлинности с помощью протокола NTLM. Если вы выбираете проверку подлинности с помощью протокола Kerberos и не можете настроить SPN, только администраторы сервера смогут произвести проверку подлинности узла SharePoint". Инструкции являются технически точными, но это не означает, что настройка имен SPN является чрезмерно сложной, или что вы должны избегать использования протокола Kerberos, пока кто-то вас не заставит внедрить его. Но в действительности, если вы понимаете принципы, внедрение протокола Kerberos не является таким уж сложным занятием.
Существует множество веских причин, почему вы должны перейти на Kerberos, или использовать протокол Kerberos с самого начала в новой реализации, но в большинстве случаев все сводится к вопросам производительности или безопасности. При возникновении дополнительных сложностей с нагрузкой пользователей или топологией, протокол NTLM может вызвать проблемы с производительностью, потому что проверка подлинности на основе протокола NTLM, по сути своей, требует несколько циклов передачи данных между метабазой IIS и контроллером домена во многих случаях использования SharePoint, например, при получении доступа веб-приложения к веб-компоненту SharePoint или пользовательской веб-службе. Возможность возникновения проблем с производительностью особенно высока, если доступ к контроллеру домена осуществляется через медленное подключение или связь с большими задержками. С точки зрения безопасности, система на основе билетов (Kerberos) с прямым делегированием сетевых ресурсов является более безопасной, нежели системы, использующие шифрование пользовательских учетных данных. Она также быстрее, потому что использует один билет для получения доступа к нескольким сетевых ресурсов.
Множество установок запускаются с протоколом NTLM вместо протокола Kerberos, потому что использование топологий планирования, распределения размеров серверов, поставщиков поддержки безопасности (SSP) и других деталей уже кажется страшной задачей, а дополнительные сложности вообще покажутся чрезмерными. Данное утверждение имеет смысл. В конце концов, реализации на основе протокола Kerberos имеют свои проблемы. Взгляните на статьи 871179, 962943 и 832769, имеющиеся в базе знаний для получения информации о некоторых проблемах, которые могут быть настолько серьезными, например, как синий экран с ошибкой STOP. Даже существующая документация, например, подробное руководство Microsoft по реализации протокола Kerberos, не содержит информации о метабазе IIS версии 7 и более поздних версий, в которых используется функция проверки подлинности в режиме ядра и изменен способ обработки имен SPN. Но не волнуйтесь, если вы понимаете фундаментальные концепции использования протокола Kerberos приложением SharePoint, то реализация и настройка вам покажется сравнительно несложной. В данной статье рассматриваются важные компоненты архитектуры и содержатся некоторые детали настройки, которые помогут вам начать работу. Корпорация Microsoft уже опубликовала документацию с поэтапными инструкциями, а также статьи 832769 и 953130 в базе знаний KB, которые вы можете использовать в качестве дополнительной информации.
Компоненты и зависимости проверки подлинности
Начнем с обзора зависимостей в архитектуре SharePoint, использующей встроенную проверку подлинности Windows. На самом базовом уровне, с протоколом NTLM или Kerberos, имеется клиент, выполняющий запросы веб-страницы SharePoint.aspx, использующей метабазы .NET и IIS в фоновом режиме. В свою очередь, страница использует данные настроек сервера SQL Server и базы данные содержимого. Способ обработки запросов службами IIS в контексте SharePoint 2007 относительно проверки подлинности показан на рис. 1. Если браузер клиента выполняет веб-запрос, запускается поток в метабазе IIS, а объекты, относящиеся к запросу, например, маркер, содержащийся в объекте IIdentity, который находится в объекте IPrincipal, прикреплены к потоку. Программными средствами доступ к объектам IIdentity и IPrincipal осуществляется через свойство HttpContext.User, а оба объекта и свойство настраиваются модулями проверки подлинности, которые являются частью конвейера .NET, как показано на рис. 1.
Рис. 1. Общие компоненты проверки подлинности и поток данных в SharePoint
Ниже приведено описание потока данных:
Ключевая мысль о механизмах проверки подлинности в SharePoint заключается в том, что здесь играют роль три слоя: браузер клиента, метабаза IIS с конвейером .NET и сервер SQL Server. Для возвращения скомпилированной страницы .aspx, производится проверка подлинности и авторизация между клиентом, метабазой IIS и сервером SQL Server. Иногда процесс упрощается, например, при использовании протокола NTLM в случае, если сервер SQL Server находится на том же физическом сервере, что и метабаза IIS. В этом случае существует только один прыжок из клиента в метабазу IIS. Для получения дополнительных сведений о проверке подлинности в .NET, просмотрите статью Инструкции: проверка подлинности Windows в ASP.NET 2.0.
NTLM и Kerberos
Теперь, после того как мы рассмотрели базовый механизм, используемый Windows Server, IIS и .NET при проверке подлинности и авторизации пользователей, давайте посмотрим, как он подходит в контексте встроенной проверки подлинности Windows с протоколами NTLM и Kerberos. Как уже упоминалось, основное отличие протокола NTLM от Kerberos заключается в том, что протокол NTLM использует механизм Запрос/Ответ, требующий проверки подлинности и авторизации для получения доступа к любому сетевому ресурсу. А протокол Kerberos использует систему билетов, которая выполняет проверку подлинности один раз и затем производит авторизацию с помощью делегирования. Не пугайтесь, если это различие покажется непонятным, далее я все разъясню. На рис. 2 показано, каким образом SharePoint обрабатывает запросы при использовании протокола NTLM.
Рис. 2. Проверка подлинности NTLM в SharePoint
Как видно из рис. 2, использование протокола NTLM требует наличия контроллера домена с возможностью проверки подлинности пользователей. Если домен работает в стандартном режиме, по умолчанию на контроллере домена или другом сервере потребуется наличие глобального каталога. Вот вам и еще одна потенциальная проблема с производительностью в дополнение к проблеме двойного прыжка, потому что после установления связи с контроллером домена, запросы проверки подлинности перенаправляются на сервер глобального каталога, если глобальный каталог не доступен локально. С медленными сетевыми каналами может использоваться много ресурсов и большая часть пропускной способности. Вы можете попытаться выжать дополнительные уровни производительности с помощью проверки подлинности с протоколом NTLM, например, заменив значение записи реестра MaxConcurrentApi, но это не объясняет фундаментальной необходимости в протоколе NTLM для использования схемы Вызов/Ответ, а также не решает соответствующие проблемы с производительностью при работе с большими нагрузками.
Ниже представлены детали проверки подлинности с протоколом NTLM для учетных записей в одном домене:
Если вы когда-нибудь пытались настроить протокол Kerberos на веб-странице центра администрирования для базовой установки, вы должны знать, что после выбора протокола Kerberos вместо NTLM, появится сообщение, в котором будет говориться о том, что вы должны настроить учетную запись пула приложений для разрешения работы протокола Kerberos, если только пул приложений не работает в контексте сетевой службы. Это может быть вызвано способом выполнения проверки подлинности на основе протокола Kerberos с использованием необходимых имен SPN. Как в WSS, так и в MOSS, веб-приложение является веб-узлом IIS, назначенным для пула приложений, который работает в контексте встроенной учетной записи или учетной записи пользователя. Имеется возможность, но не рекомендуется, назначить несколько веб-узлов для одного пула приложений. Если вы не внесете изменения, метабаза IIS использует учетную запись сетевой службы для пулов приложений, а не уникальную учетную запись домена. Однако чтобы протокол Kerberos работал в среде SharePoint, вы должны установить уникальное имя SPN в учетной записи пула приложений.
На практике связь на основе протокола Kerberos основана на использовании клиентов и сервера с поддержкой Kerberos, Центра распределения ключей, который выступает в роли промежуточного звена проверки подлинности, и имен SPN. Технические детали немного сложнее. Например, для протокола Kerberos требуется интеграция DNS с Active Directory или BIND с записями SRV, TCP/IP и служба времени. Скорее всего, если вы используете Windows Server 2003 или 2008 с интегрированной системой DNS, у вас уже имеются необходимые компоненты, и вам просто нужно их настроить. На рис. 3 показаны различные компоненты и поток данных при проверке подлинности на основе протокола Kerberos в среде SharePoint.
Рис. 3. Проверка подлинности на основе протокола Kerberos
Понимание имен SPN
Имена SPN представляют собой один из самых сложных аспектов настройки протокола Kerberos, потому что они зарегистрированы Центром распределения ключей как уникальные идентификаторы для клиентских ресурсов, которые авторизированны для получения доступа к определенным серверным ресурсам. Как клиенты, так и серверы, а также и контроллер домена, при встроенной проверке подлинности Windows доверяют Центру распределения ключей, потому что в большинстве случаев Центру распределения ключей необходим способ для определения того, предоставлять билет на запрос или нет — эти функция возложена на SPN. Как уже было упомянуто, если вы настраиваете учетную запись пользователя домена для пула приложений, вы также должны настроить SPN для него, чтобы любой пользователь мог получить доступ к веб-приложению, относящемуся к пулу приложений.
Имя SPN является строкой уникального идентификатора для службы, которая работает на сервере. Оно хранится в Active Directory в виде атрибута с множественными значениями учетной записи пользователя под названием Service-Principal-Name (имя участника-службы). Множество служб на компьютере или большое количество компьютеров различаются при помощи их уникальных имен SPN. Возможно, я переоцениваю важность имен SPN, но тому есть причина. Некорректно настроенные имена SPN приводят к нарушению проверки подлинности на основе протокола Kerberos. Если вы установите два идентичных имени SPN, или забудете установить имя SPN, или неправильно зададите часть имени SPN, проверка подлинности не заработает.
Рассмотрим пример имен SPN и то, каким образом протокол Kerberos использует их. Имя SPN состоит из трех частей: класс службы, определяющий тип службы, имя компьютера, на котором запущена служба, и порт. Сведя все компоненты вместе, получаем следующий синтаксис service class/host: port. Для среды SharePoint двумя подходящими именами являются HTTP и MSSqlSvc. Имена службы не являются произвольными и определяются как специальные псевдонимы для службы. Имя компьютера — имя FQDN или NetBIOS, дополнительно включающие порт. При регистрации имен SPN, рекомендуется регистрировать SPN как для имен компьютера NetBIOS, так и FQDN, потому что, несмотря на используемый клиентом способ, они могут получить доступ к ресурсам на целевом компьютере.
Ранее я говорил, что пока вы не запустите пул приложений под учетной записью сетевой службы, вам придется регистрировать имена SPN. Это объясняется тем, что когда компьютер входит в домен Active Directory, имена SPN создаются автоматически для учетной записи компьютера в формате HOST/<NetBIOSname> и HOST/<FQDN>. Ввиду того, что учетная запись сетевой службы выступает как компьютер в сети, имена SPN действительны и для нее. Однако не рекомендуется использовать локальную учетную запись сетевой службы из-за вопросов безопасности, и потому, что это может привести к нарушениям в работе некоторых сценариев. Например, если вы восстанавливаете или подключаете базу данных содержимого, настроенную под учетной записью сетевой службы, вы должны добавить учетную запись в локальную группу "Администраторы" сервера SQL Server, а затем удалить ее после подключения базы данных. В большинстве существующей документации рекомендуется использовать учетные записи домена.
Настройка серверной части
Сначала вы должны настроить проверку подлинности на основе протокола Kerberos на сервере SQL Server, переносите ли вы существующую ферму или устанавливаете новую. Сервер SQL Server должен соответствовать выше упомянутым требованиям, например, должен быть подключен к домену, иметь доступ к контроллеру домена, который также является и Центром распределения ключей, и т.д. В большинстве сред эти требования выполнены по умолчанию при использовании Active Directory с интегрированной системой DNS. Вам не нужно детально настраивать протокол Kerberos, если в вашей среде используются только серверы SharePoint переднего плана, а серверы приложений не используются, например, на которых работают службы Excel или службы отчетов SQL. Стандартного имени SPN, созданного при подключении сервера SQL Server к домену, достаточно для основного подключения переднего плана или фонового подключения.
Настройка протокола Kerberos на сервере SQL Server является сравнительно несложной задачей. Сначала вы устанавливаете соответствующие имена SPN, проверяете факт того, что используется протокол Kerberos, а не стандартный протокол NTLM. Вы должны задать имя NetBIOS и FQDN в формате MSSQLSvc/<NetBIOS_Name>:1433 и MSSQLSvc//<FQDN-hostname.domain.local>:1433, предполагая, что ваш экземпляр будет использовать стандартный порт — 1433. Хотя вы можете использовать средство setspn или ADSIEdit для установки SPN, setspn обычно является лучшим вариантом, потому что оно проверяет синтаксис. При использовании ADSIEdit, напротив, вы вписываете имена SPN непосредственно в атрибут servicePrincipalName. Для создания двух имен SPN выполните команду setspn-A MSSQLSvc/<NetBIOS_Name>:1433 <domain>\<username> and setspn-A MSSQLSvc/<FQDNe>:1433 <domain>\<username>, где именем пользователя является учетная запись службы SQL.
Для подтверждения факта того, что трафик сервера SQL Server использует Kerberos, вы можете отследить трафик с помощью анализатора пакетов, например, Wireshark, воспользоваться средством Kerbtray.exe или проверить журналы событий. Если вы подключаетесь к экземпляру SQL с помощью SQL Server Management Studio, в журнале событий безопасности должна появиться запись Event ID 540, в которой будет отмечено, что в процессе входа и проверке подлинности использовался протокол Kerberos. Дополнительные сведения по этой процедуре приведены в статье Настройка проверки подлинности с помощью протокола Kerberos для SQL.
Настройка сервера переднего плана и сервера приложений
Обеспечив то, что протокол Kerberos работает на сервере SQL Server, вы можете переходить к настройке среды SharePoint, установив имена SPN для пулов приложений, активировав протокол Kerberos для поставщиков поддержки безопасности (SSP) и веб-приложений, и приступить к выполнению заключительных шагов. Настройка SPN аналогична тому, что вы делали в учетной записи службы сервера SQL Server, но для настройки представлено гораздо больше имен SPN. Вспомните имена SPN, созданные на основании того, что может ввести пользователь в адресную строку браузера клиента, поэтому мы должны задать имена SPN для каждой записи, которую пользователь может ввести в адресную строку для входа на узел. Сюда входят имена FQDN, NetBIOS и псевдонимы в виде заголовков узла. На рис. 4 отображен пример типов ресурсов и имена SPN, которые необходимо зарегистрировать для каждого ресурса.
Рис. 4. Имена SPN для базовой фермы MOSS
Необходимо помнить о нескольких вещах при настройке имен SPN. Во-первых, имена SPN регистрируются для веб-узла с поддержкой SharePoint аналогичным образом, что и для веб-узла IIS. Важно указать правильное имя компьютера и учетную запись, под которой работает пул приложений для каждого узла. Если вы используете несколько заголовков узла, убедитесь в том, что имена SPN заданы для них всех. Во-вторых, необязательно указывать порты для HTTP и HTTPS, но вы должны указать любой пользовательский порт. И в-третьих, вам придется настроить несколько дополнительных зависимостей, например, изменение реестра для метабазы IIS для обеспечения формирования имен SPN с пользовательскими портами и обновление для поддержки SSP. Дополнительные сведения об этом можно найти в статье Настройка проверки подлинности на основе протокола Kerberos (Office SharePoint Server).
Имеется еще два основных этапа, которые вы должны выполнить для того, чтобы протокол Kerberos заработал в вашей среде. Вы должны настроить учетные записи компьютера и некоторые учетные записи служб для поддержки делегирования, а также вы должны настроить свою ферму для поддержки протокола Kerberos в центре администрирования. Идея делегирования в протоколе Kerberos заключается в том, что если пользователь отправляет запрос на конечный ресурс, а некоторые промежуточные учетные записи должны обработать данный запрос, то эти промежуточные учетные записи должны иметь доверие для делегирования от имени пользователя. Вы можете настроить учетную запись для выполнения делегирования с помощью оснастки "Пользователи и компьютеры Active Directory" под администратором домена. Выберите пункт Trust this user/computer (Доверять этому пользователю/компьютеру) для делегирования любой службы (Kerberos) во вкладке Delegation (Делегирование) учетной записи пользователя или компьютера. Вы должны активировать функцию делегирования для учетных записей компьютеров серверов переднего плана, серверов приложений и SQL Server, для пулов приложений (SSPAdmin, MySite, различных веб-приложений) и для учетной записи служб фермы.
Кроме того, вы должны установить разрешения в Component Services (Службы компонентов). В стандартных настройках установите параметр Impersonation Level = Delegate. В IIS WAMREG Admin Service, перейдите на вкладку Security и назначьте разрешения Local Activation учетным записям пула приложений. Дополнительные сведения приведены в статьях KB 917409 и 920783 базы знаний.
После активации функции делегирования пришло время заключительного этапа — установке Kerberos в качестве предпочтительного протокола для SSP и веб-приложений. Для новой установки вы можете сделать это на узле центра администрирования SharePoint в мастере настройки продуктов и технологий SharePoint. В противном случае, перейдите на вкладку Authentication Providers в пункт Application Management, находящийся в центре администрирования, щелкните Default и установите метод Negotiate (Kerberos). Не забываем выполнить команду iisreset /noforce для того, чтобы изменения вступили в силу в пуле приложений, и протокол Kerberos был активирован для SSP.
Изменения в IIS 7 и Windows Server 2008
До сих пор я ограничивался средой SharePoint 2007 на Windows Server 2003 и IIS 6. Если вы переходите на Windows Server 2008 и IIS 7, то придется выполнить некоторые изменения в настройках. Возможно, наиболее заметное изменение заключается в том, что IIS 7 поддерживает проверки подлинности Kerberos в режиме ядра. Во время проверки подлинности в режиме ядра, учетная запись сетевой службы (на самом деле это вышеупомянутая учетная запись компьютера) дешифрует билеты, если вы только не указали иного. Проверка подлинности в режиме ядра активируется по умолчанию при переходе на IIS 7 или при установке новой фермы. Напомним, что учетная запись сетевой службы является локальной. Если вы запускаете один сервер, начинается дешифрование. На ферме, однако, происходит сбой, потому что вы должны использовать учетные записи домена, которые могут проверяться Центром распределения ключей. Это изменение также означает, что вы можете выполнить переход протокола (клиенты используют проверку подлинности в метабазе не на основе протокола Kerberos и IIS, а IIS использует протокол Kerberos для связи с сервером, используя учетную запись сетевой службы, так как она уже имеет привилегии LocalSystem).
Для настройки протокола Kerberos в вашей ферме SharePoint, на которой работает метабаза IIS 7, вы должны вручную изменить файл %WinDir%\System32\inetsrv\config\ApplicationHost.config (на данный момент графический интерфейс недоступен). Соответствующая запись показана ниже.
<system.webServer>
<security>
<authentication>
<windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true" />
</authentication>
</security>
</system.webServer>
Не забываем выполнить команду iisreset /noforce для того, чтобы изменения вступили в силу, и проверяем наличие последних обновлений решения такой проблемы, как синий экран, подробно описанной в статье 962943 базы знаний.
Также нужно вспомнить еще об одной детали; если в вашей конфигурации используется олицетворение подлинности (<identity impersonate="true" /> в web.config) а также конвейер в интегрированном режиме, вы должны установить значение атрибута validateIntegratedModeConfiguration в "false" или запустить страницы .aspx на конвейере в классическом режиме.
Заключение
Даже если проверка на основе протокола Kerberos предусматривает дополнительные этапы настройки, а также наличие определенных знаний, намечается тенденция использования протокола Kerberos. Корпорация Microsoft включила его по умолчанию в II7, а также данный протокол хорошо поддерживается в целом, являясь открытым стандартом. Использование протокола Kerberos стоит усилий. В настоящий момент имеется большое количество документации по развертыванию, проверке и устранению проблем, что укрепляет позиции протокола Kerberos. Вам не нужно проводить значительные изменения, чтобы воспользоваться преимуществами снижения скачков производительности, возникающих по причине избыточных прыжков при проверке подлинности, и наслаждаться безопасностью, обеспеченной протоколом Kerberos.
Метки: sharepoint 2010 |
101 Причина, Почему Вы не можете Найти Вашего Сисадмина |
Собрано читателями alt.sysadmin.recovery
Перевод: © 2004 Газалов Николай
1. Он прячется под лестницей
2. Он в отпуске, первый раз за 5 лет
3. Он бьет в бубен в подвале, чтобы машины в офисах работали
4. Он в больнице, с передозировкой кофеина
5. Его забрала милиция в момент убийства пользователя, задававшего глупые вопросы
6. А у вас вообще есть системный администратор?
7. Вы прошли мимо стола, под которым он прятался
8. Сисадмин построил лабиринт, и дверь в его офис находится в центре лабиринта
9. Вы сисадмин?
10. Вы проглядели системного администратора, спящего под столом
11. Он прикован к столу в темнице, а ключ от нее только у директора
12. Админ ушел к начальству объяснять, зачем ему нужен помощник
13. Админ так мало спал, что ему лучше вообще не выходить на работу, так как сегодня вы все равно не поймете, о чем он говорит.
14. Вы боитесь, что админ будет использовать Вас как боксерскую грушу, поэтому хоть вы и ищете его, но в тайне надеетесь, что не найдете.
15. Админ прибыл на работу, переодетый почтальоном, чтобы избежать разговоров с пользователями
16. Админ убит током, когда тянул сеть рядом с главным силовым кабелем. Так как его тело стало основным предметом, проводящим электричество, начальство установило ограждение и объявило, что у них все еще есть системный администратор.
17. Админ застрял в шахте лифта, протягивая кабель на другой этаж
18. Админ вытаскивает упаковку пива из тайника под полом
19. Админ прячется на крыше
20. Админ ищет «Оправдание Дня» у BOFH.
21. Админ ушел покупать ящик кофе
22. Админ занят, он устанавливает xfishtank на главном файл-сервере.
23. Админ ушел прикупить стрел для Нерф ™ арбалета.
24. Админ заперся в серверной и играет в Deathmatch.
25. Админ загрузился в ДОС и играет в DOOM по сети.
26. Админ пошел в супермаркет, чтобы пополнить запас кофе, пива и сигарет
27. Админ спрятался в кладовке, в которую никто не заглядывает
28. Админ выкроил пару часов для сна
29. Админ только узнал, что у него двухмесячный ребенок, и заново знакомится с подругой и ребенком.
30. Админ играет в netrek
31. Админ - в больнице, с серьезной травмой, нанесенной упавшей горой бутылок с минеральной водой
32. Админ у босса, и пытается объяснить, почему он загружал фотографию пользователя на seven.rings.of.hell.com
33. Админ - в больнице, накладывает шину на пальцы, после того как 100 раз напечатал «Нет, Вы не можете использовать ваш старый адрес после смена доменного имени. Пожалуйста, прочитайте объявления, которые мы отправляли Вам последние три месяца».
34. Админ прикорнул под половицами, шагайте осторожно!
35. Админ наблюдает, как электрик включает рубильник, который превратит фирму в разноцветные угольки
36. Админ на шоссе ожидает, когда банка пива вывалится из грузовика подпрыгнувшего на камне
37. Админ вышел, чтобы разорвать как грелку лузера, которой лишний раз спросил: "Когда будет делаться резервная копия системы?»
38. Админ с удивлением уставился на «большой горящий шар в небе»
39. Админ упаковывает вещи, чтобы перебраться в фирму, которая использует современное железо
40. Админ играет в гляделки со сворой злобных собак
41. Админ висит на телефоне, пытаясь уговорить жену, не покупать дом без DSL
42. Админ сидит на полу, в истерике после очередного вопроса пользователя
43. Админ - в пивной, потому что «ВСЕ ЭТО ДОСТАЛО»
44. Админ за вашей спиной с топором
45. Админ с отвращением уволился пять минут назад
46. Админ на совещании у босса, обсуждает плохую поддержку пользователей
47. Просто взгляните на потолок. Вспомните «Чужих».
48. Админ нельзя найти по телефону и по электронной почте, потому что он слишком занят в Usenet рассказывая как он занят или придумывая 101 причину почему его нельзя найти.
49. Админ прячется под столом, чтобы не стать тем, кто сидит часами, наблюдая переустановку Ultrix с односкоростного CD-ROM, из-за того, что пользователи, с правами рута, опять уничтожили файловую систему, после неудачной попытки «улучшить» /etc/rc, для переразметки диска во время загрузки «чтобы это сохранилось»
50.У нас есть тайная комната, а на ней долбанный огромный замок. Я прячусь там.
Продолжение следует...
Метки: юмор |
Дополнительные услуги сис-админа: |
Дополнительные услуги сис-админа:
1. Ужин с системным администратором - 200 у.ё.
2. Беседа после ужина на отстранённые от компьютера темы - 10 у.ё. за каждую минуту
3. Продолжение беседы - 20 у.ё. за каждую попытку
4. Ужин при свитчах с любым сотрудником компании - 300 у.ё.
5. Ужин при хабах - 500 у.ё.
6. Экскурсия по серверной - 100 у.ё. за осмотр каждого сервера. Группам по 5 человек скидка 5%
7. Потрогать сервер - 5 у.ё. одно касание
8. Потрогать сисадмина - 20 у.ё. одно прикосновение
9. Потыкать клавиатуру сервера - 2 у.ё. за каждую клавишу
10. Обломать кайф качающим файлы с сервера единичным нажатием reset`а на сервере - 600 у.ё. за пять минут
11. Каждые следующие пять минут - 400 у.ё.
12. Выключить из сети центральный роутер на три минуты - 1500 у.ё.
Метки: юмор |
Танцы с бубном и битой |
|
Дед Мороз и Сисадмин…совпадение? |
Дед Мороз и Сисадмин…совпадение?
Перевод : Газалов Н.
От читателей alt.sysadmin.recovery
Heather Garvey
1. Дед Мороз бородатый, толстый и смешно одевается
2. Когда вы просите что-то у Деда Мороза, шансы получить это стремятся к нулю
3. Дед Мороз редко отвечает на почту
4. Когда вы спрашиваете Деда Мороза, где он берет все то, что у него есть, он отвечает: «Это чудо…»
5. Деда Мороза не волнуют сроки ваших проектов
6. Ваши родители приписывают Деду Морозу сверхъестественные возможности, но делают все сами.
7. Никто не знает, перед кем Дед Мороз отвечает за свои действия
8. Дед Мороз СЛИШКОМ много смеется.
9. Дед Мороз не стесняется врываться в ваш $HOME
10. Только псих плохо отзывается о Деде Морозе в его присутствие
11. Дед Мороз вынужден делать всю работу, когда его пользователи отсутствуют.
12. Он вынужден работать даже в официальные выходные
13. Он утверждает, что он уникален, но вы нередко встречаете таких же… как он
14. У пользователей невероятное число непомерных запросов, но, в конце концов, все что им нужно, это новые игрушки
15. Как-то, где-то непонятным образом… он нашел жену такую же как он.
16. Там где люди в него не верят, обязательно есть тот, кто делает тоже самое, только зовут его иначе
17. Людям недостаточно просто видеть результаты его работы. Они продолжают докучать вопросами, о том, как ему удается это сделать. Их не устраивает ответ, что это волшебство.
18. Даже неверующие молятся, что бы он пришел.
19. Он единственный, кто смеется над собственными шутками
20. Он никогда не найдет другую работу; его резюме слишком специфично.
21. Чтобы делать свою работу, он вынужден карабкаться в узкие и грязные места… даже если он одет в хороший костюм
22. И последнее… даже если его работа в основном нематериальна, мир становится лучше благодаря его присутствию.
Метки: юмор |
Мистика какая то :) |
Метки: юмор |
Молитва админа |
Метки: юмор |
Развертывание SharePoint 2010. Подготовка к обновлению до SharePoint 2010 |
Обновление до SharePoint 2010 будет непохоже на другие обновления, которые вы выполняли. Но еще перед началом планирования необходимо ознакомиться с системными требованиями для SharePoint 2010. В отличие от предыдущих версий SharePoint 2010 выпускается только в 64-разрядной версии. Там образом, необходимо устанавливать SharePoint 2010 на 64-рязрядной версии Windows Server 2008 или Windows Server 2008 R2.
SharePoint требуется база данных SQL Server, но она не обязательно должна находиться на том же сервере, что и SharePoint. SharePoint 2010 по-прежнему требует SQL Server, но корпорация Майкрософт внесла несколько важных изменений. SharePoint 2010 требует, чтобы базы данных работала с 64-разрядной версией SQL Server 2005 или 2008. Это справедливо вне зависимости от того, установлена ли база данных локально на сервере SharePoint.
Необходимо также задуматься об используемом веб-браузере, хотя это и не техническое требование. SharePoint2010 создан для того, чтобы оптимизировать использование веб-стандартов. Это означает, что пользователи смогут работать без перебоев независимо от используемого браузера: Explorer или Firefox (3.x или боле поздняя версия). Единственная тонкость заключается в том, что SharePoint 2010 обеспечивает ограниченную поддержку Internet Explorer 6. Пользователи IE6 не должны испытывать проблем с просмотром содержимого SharePoint, однако для создания содержимого потребуется IE7 или более поздняя версия (или Firefox 3.x или более поздняя версия).
Обновления поверх существующей системы
Как вы уже, наверное, слышали, SharePoint 2010 позволяет выполнять обновления поверх существующей системы Microsoft Office SharePoint Server (MOSS) 2007. Однако, поскольку SharePoint 2010 является 64-разрядной, можно выполнить обновление поверх существующей системы только в том случае, если MOSS 2007 запущен поверх 64-разрядной версии Windows Server 2008. Если ваши серверы SharePoint соответствуют необходимым системным требованиям, можно выполнить обновление поверх существующей системы на каждом сервере фермы SharePoint.
Несмотря на то, что SharePoint полностью поддерживает эти обновления, я бы рекомендовал их выполнять только при наличии простого развертывания SharePoint без каких-либо настроек. В более сложных средах рекомендуется выполнять полные переносы, поскольку это обеспечивает более полный контроль процесса обновления. Кроме того, это рекомендуется также для сред, в которых были выполнены пользовательские настройки, чтобы случайно их не заменить.
Перенос, как правило, подразумевает сборку полностью новой фермы SharePoint, на которой запущен SharePoint 2010. После этого к новой ферме можно прикрепить существующие базы данных SharePoint. Можно также воспользоваться гибридной стратегией переноса, которая сочетает обновления поверх существующей системы и новые серверы SharePoint 2010.
Проверка перед обновлением
Независимо от того, что вы выполняете – обновление поверх существующей системы или перенос, необходимо перед этим все спланировать и подготовиться. Одним из наиболее важных шагов в подготовке к обновлению до SharePoint 2010 является запуск программы предварительного анализа. Перед выпуском MOSS 2007 корпорация Майкрософт представила служебную программу Prescan.exe, которая поможет проверить состояние развертывания SharePoint перед обновлением до MOSS 2007.
Программа Prescan.exe в свое время была отличным средством, однако она не очень хорошо подходит для предварительного анализа SharePoint 2010. Вот почему корпорация Майкрософт выпустила программу предварительного анализа Pre-Upgrade Checker. Она намного совершеннее программы Prescan.exe. Начнем с того, что программа предварительного анализа Pre-Upgrade Checker предназначена только для чтения, поэтому не придется волноваться о внесении каких-либо изменений на серверы SharePoint.
Однако наиболее удобна Pre-Upgrade Checker именно тем, что выполняет куда более тщательную работу по поиску проблем, нежели Prescan.exe. Кроме того, она является расширенной. Она выпускается с набором правил, которые использует при анализе серверов SharePoint. Это правила в формате XML, следовательно, можно создавать свои правила, если это потребуется. Кроме того, использование правил на основе XML упрощает работу корпорации Майкрософт по обновлению программы предварительного анализа, если их рекомендации когда-нибудь изменятся.
Считается, что лучшее в этой программе – это информация, которую она собирает, но это утверждение спорно. Несмотря на том, что корпорация Майкрософт создавала ее как средство для подготовки к обновлению до SharePoint 2010, некоторые организации используют ее для других целей. Одна компания использует ее в рамках своего плана по восстановлению после сбоев. Программа предварительного анализа никоим образом не поможет спасти сервер SharePoint после сбоя, однако собранная ею информация может оказаться бесценной, если вам придется повторно собирать развертывание SharePoint (только обязательно запустите ее перед сбоем).
Другая организация использовала программу предварительного анализа для проверки, все ли серверы SharePoint настроены последовательно. Запуская эту программу на каждом сервере SharePoint, можно сравнить отчеты каждого из них и выполнить поиск отдельных элементов настройки, которые не соответствуют корпоративной политике.
Так где же можно найти эту программу? Есть вероятность, что она у вас уже есть. Корпорация Майкрософт включила ее в MOSS 2007 с пакетом обновления 2 (SP2). Но, возможно, вопреки вашим ожиданиям, программа предварительного анализа не является изолированным средством. Корпорация Майкрософт встроила ее в служебную программу STSADM.EXE. Так уж получилось, что после применения пакета обновления 2 (SP2) мне пришлось перезагружать тестовый сервер несколько раз, пока Windows не позволила мне получить доступ к новым функциям STSADM.EXE.
Учитывая все вышесказанное, я хочу показать, как работает программа предварительного анализа. Как я уже говорил, она работает, анализируя файл правила на основе XML, а затем используя эти правила как основу для анализа развертывания SharePoint. Программа поставляется со встроенным набором правил. Эти правила, основанные на анализаторе соответствия рекомендациям, находятся в файле OssPreUpgradeCheck.xml. На него можно посмотреть на рис. 1.
Рис. 1. Программа предварительного анализа использует файл правил на основе XML.
При запуске этой программы не нужно явно вызывать этот файл правил. Программа вызывает его по умолчанию. Можно использовать свои файлы правил. Полный синтаксис программы предварительного анализа следующий:
STSADM.EXE –O PreUpgradeCheck
[[-RuleFiles “”] [-ListRuleFiles]] [-LocalOnly]
STSADMIN.EXE –O PreUpgradeCheck]
Метки: sharepoint 2010 |
SharePoint 2010: Участвуем в процессе — создаем рабочие процессы для SharePoint |
Метки: sharepoint 2010 |