Отчёт по производственной практике
ГУМАНИТАРНО-ТЕХНОЛОГИЧЕСКАЯ АКАДЕМИЯ»
ОТЧЁТ ПО ПРОИЗВОДСТВЕННОЙ ПРАКТИКЕ
Тип практики: Практика по получению профессиональных умений и опыта профессиональной деятельности
Студента: Сулейманова Хызыра Адильбиевича
Направление подготовки: 09.04.03 Прикладная информатика
Магистерская программа: Прикладная информатика в экономике и управлении
Форма обучения: Очная
Курс: 1
Институт: Прикладной математики и информационных технологии
Кафедра: Информатика и информационные технологии
Место прохождения практики: Кафедра «Информатика и информационные технологии»
Сроки прохождения практики 25.04.2016 – 22.05.2016
Руководитель практики к. ф.-м. н., доцент Эльканова Л. М.
(подпись) (ФИО)
Дата защиты Оценка
Черкесск 2016
Содержание
1. Цели и задачи практики. 3
2. Характеристика структуры базы прохождения практики. 5
3. Этапы прохождения практики. 9
4. Характеристика выполненных работ. 9
Заключение. 12
ПРИЛОЖЕНИЕ 1
ПРИЛОЖЕНИЕ 2
ПРИЛОЖЕНИЕ 3
ПРИЛОЖЕНИЕ 4
ПРИЛОЖЕНИЕ 5
Цели и задачи практики
Я, Сулейманов Хызыр Адильбиевич, магистрант очной формы обучения по магистерской программе «Прикладная информатика в экономике и управлении» проходил практику по получению профессиональных умений и опыта профессиональной деятельности (в том числе технологическую практику) на базе кафедры «Информатика и Информационные технологии» с 30 января по 09 апреля 2017 года. Практика прошла в три этапа: подготовительный, основной и заключительный.
На первом этапе перед началом практики руководителем практики была проведена установочная лекция, на которой магистрантам была сообщена вся необходимая информация для прохождения практики: сроки и место прохождения практики, этапы и задачи практики, требования к подготовке дневника магистранта и подготовке отчета.
На установочной лекции руководителем практики и перед нами были поставлены следующие цели:
· закрепление теоретических знаний, практических умений и навыков, полученных в процессе освоения основной образовательной программы;
· приобретение первоначального практического опыта по основным видам профессиональной деятельности;
· приобретение опыта управленческой, организационной и воспитательной работы в коллективе
Задачи практики в обобщенном виде можно представить следующим образом:
· ознакомление с информационным пространством предприятия;
· формирование общего представления об информационной среде предприятия, методах и средствах ее создания;
· приобретение практических навыков эксплуатации программных и технических средств обработки информации;
· изучение источников информации и системы оценок эффективности ее использования.
· изучение технической и проектной документации;
· ознакомление с должностными инструкциями инженерных категорий работников;
· сбор, обработка и анализ материала для выполнения выпускной квалификационной работы;
· закрепление полученных студентами в процессе обучения знаний, путем самостоятельного выполнения задач, поставленных программой прохождения практики;
выработка умения пользоваться полученными знаниями для решения производственных задач.
Этапы прохождения практики
30.01.2017 Прохождение инструктажа по технике безопасности
31.01.2016 - 15.02.2017 – Обзор литературных источников для решения целей задач учебной практики.
16.02.2017 - 28.02.2017 – Знакомство с программным и аппаратным обеспечением для организации учебного процесса кафедры ИиИТ;
01.03.2017 - 15.03.2016 – Обзор системы Activedirectory
16.03.2017 - 31.03.2017 – Обзор системы размещения контента Drupal
03.04.2017 - 07.04.2017 – Подготовка и защита отчёта по практике
Заключение
Таким образом, в процессе прохождения практики я осуществлял разнообразную деятельность в соответствии с профилем подготовки. Прохождение технологической практики является важным элементом учебного процесса по направлению подготовки.
Во время прохождения технологической практики я научился применять полученные в процессе обучения знания, умения и навыки. Получил практический опыт работы в сфере информатики, углубил навыки работы с нормативно-правовыми и правоприменительными актами в процессе деятельности в организации. Практическая деятельность помогла мне научиться составлять некоторые виды прораммного обеспечения, анализировать их содержание и форму.
Практические проблемы, в которых мне необходимо было применять полученные теоретические знания, позволили мне лучше усвоить теоретический материал, изучить реальный механизм действий в той или иной ситуации, освоить порядок применения различных методов разработки ПО.
ПРИЛОЖЕНИЕ 1
Техника безопасности
ПРИЛОЖЕНИЕ 2
ПРИЛОЖЕНИЕ 3
ПРИЛОЖЕНИЕ 4
Active Directory («Активный каталог», AD) – службы каталогов корпорации Microsoft для операционных систем семейства Windows Server. Первоначально создавалась, как LDAP-совместимая реализация службы каталогов, однако, начиная с Windows Server 2008, включает возможности интеграции с другими службами авторизации, выполняя для них интегрирующую и объединяющую роль. Позволяет администраторам использовать групповые политики для обеспечения единообразия настройки пользовательской рабочей среды, разворачивать программное обеспечение на множестве компьютеров через групповые политики или посредством System Center Configuration Manager (ранее – Microsoft Systems Management Server), устанавливать обновления операционной системы, прикладного и серверного программного обеспечения на всех компьютерах в сети, используя Службу обновления Windows Server. Хранит данные и настройки среды в централизованной базе данных. Сети Active Directory могут быть различного размера: от нескольких десятков до нескольких миллионов объектов.
Представление решения состоялось в 1999 году, впервые продукт был выпущен вместе с Windows 2000 Server, а затем развит в рамках выпуска Windows Server 2003. Впоследствии новые версии продукта вошли в Windows Server 2003 R2, Windows Server 2008 и Windows Server 2008 R2 и переименован в Active Directory Domain Services. Ранее служба каталогов называлась NT Directory Service (NTDS), это название до сих пор можно встретить в некоторых исполняемых файлах.
В отличие от версий Windows до Windows 2000, которые использовали в основном протокол NetBIOS для сетевого взаимодействия, служба Active Directory интегрирована с DNS и работает только поверх TCP/IP. Для аутентификации по умолчанию используется протокол Kerberos. Если клиент или приложение не поддерживает Kerberos-аутентификацию, используется протокол NTLM.
Для разработчиков программного обеспечения предоставляется программный интерфейс доступа к службам Active Directory – ADSI.
Объекты
Active Directory имеет иерархическую структуру, состоящую из объектов. Объекты разделяются на три основные категории: ресурсы (например, принтеры), службы (например, электронная почта) и учётные записи пользователей и компьютеров. Служба предоставляет информацию об объектах, позволяет организовывать объекты, управлять доступом к ним, а также устанавливает правила безопасности.
Объекты могут быть хранилищами для других объектов (группы безопасности и распространения). Объект уникально определяется своим именем и имеет набор атрибутов – характеристик и данных, которые он может содержать; последние, в свою очередь, зависят от типа объекта. Атрибуты являются составляющей базой структуры объекта и определяются в схеме. Схема определяет, какие типы объектов могут существовать.
Сама схема состоит из двух типов объектов: объекты классов схемы и объекты атрибутов схемы. Один объект класса схемы определяет один тип объекта Active Directory (например, объект «Пользователь»), а один объект атрибута схемы определяет атрибут, который объект может иметь.
Каждый объект атрибута может быть использован в нескольких разных объектах классов схемы. Эти объекты называются объектами схемы (или метаданными) и позволяют изменять и дополнять схему, когда это необходимо и возможно. Однако каждый объект схемы является частью определений объектов, поэтому отключение или изменение этих объектов могут иметь серьёзные последствия, так как в результате этих действий будет изменена структура каталогов. Изменение объекта схемы автоматически распространяется в службе каталогов. Будучи однажды созданным, объект схемы не может быть удалён, он может быть только отключён. Обычно все изменения схемы тщательно планируются.
Контейнер аналогичен объекту в том смысле, что он также имеет атрибуты и принадлежит пространству имён, но, в отличие от объекта, контейнер не обозначает ничего конкретного: он может содержать группу объектов или другие контейнеры.
Структура
Верхним уровнем структуры является лес – совокупность всех объектов, атрибутов и правил (синтаксиса атрибутов) в Active Directory. Лес содержит одно или несколько деревьев, связанных транзитивными отношениями доверия. Дерево содержит один или несколько доменов, также связанных в иерархию транзитивными отношениями доверия. Домены идентифицируются своими структурами имён DNS – пространствами имён.
Объекты в домене могут быть сгруппированы в контейнеры – подразделения. Подразделения позволяют создавать иерархию внутри домена, упрощают его администрирование и позволяют моделировать, например, организационную или географическую структуру организации в службе каталогов. Подразделения могут содержать другие подразделения. Microsoft рекомендует использовать как можно меньше доменов в службе каталогов, а для структурирования и политик использовать подразделения. Часто групповые политики применяются именно к подразделениям. Групповые политики сами являются объектами. Подразделение является самым низким уровнем, на котором могут делегироваться административные полномочия.
Другим способом деления являются сайты, которые являются способом физической (а не логической) группировки на основе сегментов сети. Сайты подразделяются на имеющие подключения по низкоскоростным каналам (например, по каналам глобальных сетей, с помощью виртуальных частных сетей) и по высокоскоростным каналам (например, через локальную сеть). Сайт может содержать один или несколько доменов, а домен может содержать один или несколько сайтов. При проектировании службы каталогов важно учитывать сетевой трафик, создающийся при синхронизации данных между сайтами.
Ключевым решением при проектировании службы каталогов является решение о разделении информационной инфраструктуры на иерархические домены и подразделения верхнего уровня. Типичными моделями, используемыми для такого разделения, являются модели разделения по функциональным подразделениям компании, по географическому положению и по ролям в информационной инфраструктуре компании. Часто используются комбинации этих моделей.
Хозяева операций
· Schema master – Хозяин схемы. По сути это компьютер или виртуальная машинка, которая управляет всем, что находится в схеме. Обновление схемы леса невозможно без доступа к этой роли fsmo. Очень важно, что на лес она одна.
· Domain naming master – Хозяин именования доменов. Это контроллер домена служащий для управления, добавлением и удалением доменов в лесу. Так же обеспечивает уникальность имен. В лесу он также один.
· PDC emulator – PDC emulator. Пожалуй, самая нужная роль fsmo, так как без двух верхних вы еще проживете если они сломались, а вот без этого товарища никак, вот почему: является основным обозревателем в сети Windows, если пользователя заблокировала политика неправильно введенных паролей, эта роль вам об этом сообщает, главный NTP сервер в вашем домене, объявляет себя главным контроллером домена для рабочих станций и серверов прошлых версий (XP, 2000), обновление групповых политик. На каждый домен свой PDC эмулятор.
· Infrastructure Master – Хозяин инфраструктуры. В каждом домене он свой. Отвечает за обновление ссылок объектов домена на объекты других доменов, например, SID, GUID. Если бы его не было или был сломан, то вы не смогли бы выполнить команду adprep /domainprep. Средняя значимость из всех fsmo.
· RID Master – Хозяин относительных идентификаторов (RID). Каждый объект active directory имеет свой уникальный sid, по сути эта роль их генерирует. Изначально контроллер домена заказывает у этой роли 500 sid, если они заканчиваются, просит еще.
Физическая структура и репликация
Физически информация хранится на одном или нескольких равнозначных контроллерах доменов, заменивших использовавшиеся в Windows NT основной и резервные контроллеры домена, хотя для выполнения некоторых операций сохраняется и так называемый сервер «операций с одним главным сервером», который может эмулировать главный контроллер домена. Каждый контроллер домена хранит копию данных, предназначенную для чтения и записи. Изменения, сделанные на одном контроллере, синхронизируются на все контроллеры домена при репликации. Серверы, на которых сама служба Active Directory не установлена, но которые при этом входят в домен Active Directory, называются рядовыми серверами.
Репликация каталога выполняется по запросу. Служба KCC (Knowledge Consistency Checker) создаёт топологию репликации, которая использует сайты, определённые в системе, для управления трафиком. Внутрисайтовая репликация выполняется часто и автоматически с помощью средства проверки согласованности (уведомлением партнёров по репликации об изменениях). Репликация между сайтами может быть настроена для каждого канала сайта (в зависимости от качества канала) – различная «оценка» (или «стоимость») может быть назначена каждому каналу (например, DS3, T1, ISDN), и трафик репликации будет ограничен, передаваться по расписанию и маршрутизироваться в соответствии с назначенной оценкой канала. Данные репликации могут транзитом передаваться через несколько сайтов через мосты связи сайтов, если «оценка» низка, хотя AD автоматически назначает более низкую оценку для связей «сайт–сайт», чем для транзитных соединений. Репликация "сайт–сайт" выполняется серверами-плацдармами в каждом сайте, которые затем реплицируют изменения на каждый контроллер домена своего сайта. Внутридоменная репликация проходит по протоколу RPC, междоменная – может использовать также протокол SMTP.
Если структура Active Directory содержит несколько доменов, для решения задачи поиска объектов используется глобальный каталог: контроллер домена, содержащий все объекты леса, но с ограниченным набором атрибутов (неполная реплика). Каталог хранится на указанных серверах глобального каталога и обслуживает междоменные запросы.
Возможность операций с одним главным компьютером позволяет обрабатывать запросы, когда репликация с несколькими главными компьютерами недопустима. Есть пять типов таких операций: эмуляция главного контроллера домена (PDC-эмулятор), главный компьютер относительного идентификатора (мастер относительных идентификаторов или RID-мастер), главный компьютер инфраструктуры (мастер инфраструктуры), главный компьютер схемы (мастер схемы) и главный компьютер именования домена (мастер именования доменов). Первые три роли уникальны в рамках домена, последние две – уникальны в рамках всего леса.
Базу Active Directory можно разделить на три логических хранилища или «раздела». Схема является шаблоном для службы и определяет все типы объектов, их классы и атрибуты, синтаксис атрибутов (все деревья находятся в одном лесу, потому что у них одна схема). Конфигурация является структурой леса и деревьев Active Directory. Домен хранит всю информацию об объектах, созданных в этом домене. Первые два хранилища реплицируются на все контроллеры доменов в лесу, третий раздел полностью реплицируется между репликами контроллеров в рамках каждого домена и частично – на сервера глобального каталога.
База данных (хранилище каталогов) в Windows 2000 использует расширяемую подсистему хранения Microsoft Jet Blue (англ.), которая позволяет для каждого контроллера домена иметь базу размером до 16 терабайт и 1 миллиард объектов (теоретическое ограничение, практические тесты выполнялись только с приблизительно 100 миллионами объектов). Файл базы называется NTDS.DIT и имеет две основные таблицы – таблицу данных и таблицу связей. В Windows Server 2003 добавлена ещё одна таблица для обеспечения уникальности экземпляров дескрипторов безопасности.
Именование
Служба поддерживает следующие форматы именования объектов: универсальные имена типа UNC, URL и LDAP URL. Версия LDAP формата именования X.500 используется внутри службы.
Каждый объект имеет выделенное имя (англ. distinguished name, DN). Например, объект принтера с именем HPLaser3 в подразделении «Маркетинг» и в домене foo.org будет иметь следующее выделенное имя: CN=HPLaser3, OU=Маркетинг,DC=foo,DC=org, где CN – это общее имя, OU – раздел, DC – класс объекта домена. Выделенные имена могут иметь намного больше частей, чем четыре части в этом примере. У объектов также есть канонические имена. Это различающиеся имена, записанные в обратном порядке, без идентификаторов и с использованием косых черт в качестве разделителей: foo.org/Маркетинг/HPLaser3. Чтобы определить объект внутри его контейнера, используется относительное выделенное имя: CN=HPLaser3. У каждого объекта также есть глобально уникальный идентификатор (GUID) – уникальная и неизменная 128-битная строка, которая используется в Active Directory для поиска и репликации. Определённые объекты также имеют имя участника-пользователя (UPN, в соответствии с RFC 822) в формате объект@домен.
Интеграция с UNIX
Различные уровни взаимодействия с Active Directory могут быть реализованы в большинстве UNIX-подобных операционных систем посредством LDAP-клиентов, но такие системы, как правило, не воспринимают большую часть атрибутов, ассоциированных с компонентами Windows, например, групповые политики и поддержку односторонних доверенностей. Однако с выходом Samba 4 появилась возможность использовать групповые политики и инструменты администрирования Windows.
Сторонние поставщики предлагают интеграцию Active Directory на платформах UNIX, Linux, Mac OS X и ряд приложений на Java, среди них – продукты корпорации Centrify DirectControl и Express, UNAB (Computer Associates), TrustBroker (CyberSafe), PowerBroker Identity Services (BeyondTrust), Authentication Services (Quest Software), ADmitMac (Thursby). Сервер Samba – пакета программ PowerBroker Identity Services совместимости с сетевыми службами Microsoft – может выполнять роль контроллера домена.
Добавления в схему, поставляемые с Windows Server 2003 R2, включают атрибуты, которые достаточно тесно связаны с RFC 2307, чтобы использоваться в общем случае. Базовые реализации RFC 2307 – nss_ldap и pam_ldap, предложенные PADL.com, непосредственно поддерживают эти атрибуты. Стандартная схема для членства в группе соответствует RFC 2307bis (предлагаемому). Windows Server 2003 R2 включает Консоль управления Microsoft для создания и редактирования атрибутов.
Альтернативным вариантом является использование другой службы каталогов, например, 389 Directory Server (ранее – Fedora Directory Server, FDS), eB2Bcom ViewDS XML Enabled Directory или Sun Java System Directory Server, выполняющих двухстороннюю синхронизацию с Active Directory, реализуя таким образом «отражённую» интеграцию, когда клиенты UNIX- и Linux-систем аутентифицируются на собственных серверах, а клиенты Windows – в Active Directory. Другим вариантом является использование OpenLDAP с возможностью полупрозрачного перекрытия, расширяющей элементы удалённого сервера LDAP дополнительными атрибутами, хранимыми в локальной базе данных.
Active Directory автоматизируются с помощью Powershell.
ПРИЛОЖЕНИЕ 5
ГУМАНИТАРНО-ТЕХНОЛОГИЧЕСКАЯ АКАДЕМИЯ»
ОТЧЁТ ПО ПРОИЗВОДСТВЕННОЙ ПРАКТИКЕ
Тип практики: Практика по получению профессиональных умений и опыта профессиональной деятельности
Студента: Сулейманова Хызыра Адильбиевича
Направление подготовки: 09.04.03 Прикладная информатика
Магистерская программа: Прикладная информатика в экономике и управлении
Форма обучения: Очная
Курс: 1
Институт: Прикладной математики и информационных технологии
Кафедра: Информатика и информационные технологии
Место прохождения практики: Кафедра «Информатика и информационные технологии»
Сроки прохождения практики 25.04.2016 – 22.05.2016
Руководитель практики к. ф.-м. н., доцент Эльканова Л. М.
(подпись) (ФИО)
Дата защиты Оценка
Черкесск 2016
Содержание
1. Цели и задачи практики. 3
2. Характеристика структуры базы прохождения практики. 5
3. Этапы прохождения практики. 9
4. Характеристика выполненных работ. 9
Заключение. 12
ПРИЛОЖЕНИЕ 1
ПРИЛОЖЕНИЕ 2
ПРИЛОЖЕНИЕ 3
ПРИЛОЖЕНИЕ 4
ПРИЛОЖЕНИЕ 5
Цели и задачи практики
Я, Сулейманов Хызыр Адильбиевич, магистрант очной формы обучения по магистерской программе «Прикладная информатика в экономике и управлении» проходил практику по получению профессиональных умений и опыта профессиональной деятельности (в том числе технологическую практику) на базе кафедры «Информатика и Информационные технологии» с 30 января по 09 апреля 2017 года. Практика прошла в три этапа: подготовительный, основной и заключительный.
На первом этапе перед началом практики руководителем практики была проведена установочная лекция, на которой магистрантам была сообщена вся необходимая информация для прохождения практики: сроки и место прохождения практики, этапы и задачи практики, требования к подготовке дневника магистранта и подготовке отчета.
На установочной лекции руководителем практики и перед нами были поставлены следующие цели:
· закрепление теоретических знаний, практических умений и навыков, полученных в процессе освоения основной образовательной программы;
· приобретение первоначального практического опыта по основным видам профессиональной деятельности;
· приобретение опыта управленческой, организационной и воспитательной работы в коллективе
Задачи практики в обобщенном виде можно представить следующим образом:
· ознакомление с информационным пространством предприятия;
· формирование общего представления об информационной среде предприятия, методах и средствах ее создания;
· приобретение практических навыков эксплуатации программных и технических средств обработки информации;
· изучение источников информации и системы оценок эффективности ее использования.
· изучение технической и проектной документации;
· ознакомление с должностными инструкциями инженерных категорий работников;
· сбор, обработка и анализ материала для выполнения выпускной квалификационной работы;
· закрепление полученных студентами в процессе обучения знаний, путем самостоятельного выполнения задач, поставленных программой прохождения практики;
выработка умения пользоваться полученными знаниями для решения производственных задач.