Как получить доступ к базе солярис

Добавил пользователь Алексей Ф.
Обновлено: 05.10.2024

Электронная сервисная книжка Хендай: целый мир возможностей под рукой!

Электронная сервисная книжка Хендай – это полноценный аналог бумажной книги, только хранится он в компьютерной базе данных. Сегодня в России многие автоконцерны перешли на цифровой формат ведения сервисного учета, и Hyundai наряду с Фольксвагеном и Фордом стали одними из первых.

По сути, электронная сервисная книжка Hyundai — это цифровой файл, который пополняется и обновляется при каждом техосмотре и обслуживании. Он хранит всю документацию по выполненным работам, включает гарантийные сведения, действует на протяжении всего срока эксплуатации автомобиля. Таким образом формируется достоверная и полная техническая история службы транспортного средства. Кстати, что немаловажно, данные защищены от воздействия третьих лиц.

Если вас интересует, как посмотреть электронную сервисную книжку автомобиля Хендай Крета, или любой другой модели, для начала нужно зарегистрироваться в программе Мир Хёнде.

Сделать это можно двумя путями: самостоятельно, онлайн или обратившись в дилерский центр автоконцерна.

Самостоятельно

По окончании регистрации, зайдите в блок «Гараж»;

Введите VIN машины, загрузите четкие фотографии СТС или ПТС с двух сторон. Правда,не совсем понятно, что делать тем, у кого ЭПТС;

Далее автомобиль пройдет верификацию, вам придется немного подождать;
После верификации у вас будет полный доступ к цифровой книжке через мобильное приложение или сайт Мир Хёнде.

В дилерском центре

Найдите ближайший дилерский центр автоконцерна;

Обратитесь к менеджеру;
Сотрудник заполнит данные о вас и об автомобиле, создаст профиль в системе;
Вы получите доступ к электронной книжке через платформу Мир Хендай, а также, по желанию, менеджер отправит вам ее PDF-версию на E-mail.

Как выглядит книга?

После регистрации на портале и верификации автомобиля, вы сможете осуществить вход в электронную сервисную книжку Хендай в любое удобное для вас время. Для этого авторизуйтесь на ресурсе и перейдите в блок «Гараж».

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

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

Возможности и преимущества

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

Цифровая книга доступна в любой точке планеты, даже если вы выедете за границу. Это очень удобно, ведь если вам придется за рубежом обратиться в центр обслуживания, специалисты смогут ознакомиться со всей историей предыдущих ремонтов на своем языке. И да, после обслуживания, они обязательно поставят в документе соответствующую электронную отметку;
Бумажную книгу можно потерять или испортить, в конце концов, подделать. С цифровым аналогом – это невозможно, таким образом история эксплуатации тачки становится полностью прозрачной. Последнее немаловажно при покупке подержанного автомобиля с рук;

Обратите внимание, пополнение цифровой книги осуществляется только при обращении к официальным центрам бренда. В случае ухода к «левым» сервисам, просмотр и фиксация истории становится невозможной.

На какие модели доступна?

Электронная сервисная книжка, помимо автомобиля марки Крета, доступна на весь новый автопарк:

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

Цифровая сервисная книга — это максимально защищенная база сведений о техническом состоянии вашего автомобиля. Подобный формат ведения автосервиса на Западе существует уже почти 10 лет. Успешный опыт доказывает актуальность и современность электронного подхода. Совсем скоро бумажные документы полностью канут в лету, а цифровая замена станет привычной и естественной. Кто за?

Создание и администрирование пользователей в ОС Solaris 11

В посте рассматривается создание и администрирование пользователей в операционной системе (ОС) Solaris 11. Рассмотрены следующие вопросы:

Типы пользователей
Основные файлы, хранящие информацию о пользовательских учетных записях
Администрирование (управление) учетными записями
Дополнительные настройки учетных записей

Типы пользователей

Пользователь – индивидуальная учетная запись, представляющая уникальное имя, пользовательский идентификационный номер (UID), домашнюю директорию и командную оболочку.
Группа – множество индивидуальных пользователей, которые разделяют общий набор прав на файлы и другие системные ресурсы.
Роль – специальная учетная запись, привязанная к одному или более пользователям, и предоставляющая набор функций и прав, специфичных для этой роли.

Под ролью невозможно войти в ОС. Например, если требуется использовать роль test, то первоначально необходимо войти в ОС под какой-либо учетной записью, а потом переключиться на роль командой su – test. Команда su (switch user) – предназначена для смены пользователя. Например, выполнение команды su dushanbe, позволяет войти в ОС под пользователем dushanbe. Если же нужно сменить не только пользователя, но и все пользовательское окружение, то выполняется команда su – dushanbe. Например, система под пользователем dushanbe находится в директории /tmp.

Основные файлы, хранящие информацию о пользовательских учетных записях

В Solaris вся информация о пользователях хранится в текстовых файлах ОС. Основные файлы ОС, хранящие информацию о пользовательских учетных записях, следующие:

/etc/passwd – содержит учетные записи и данные о них (доступ на чтение и изменение файла имеет root, остальные пользователи имеют доступ только на чтение).
/etc/shadow – содержит пароли в зашифрованном виде (доступ на чтение файла имеет root, остальные пользователи не имеют никакого доступа).
/etc/default/passwd – содержит информацию для контроля свойств всех пользовательских паролей (доступ на чтение и изменение файла имеет root, остальные пользователи имеют доступ только на чтение).
/etc/group – содержит информацию о группах (доступ на чтение и изменение файла имеет root, остальные пользователи имеют доступ только на чтение).

Далее подробно рассматривается каждый файл и его содержимое.

Файл /etc/passwd

Структура записи файла следующая:

loginID – поле имени пользователя (имя должно быть уникальным и состоять максимум из 8 символов – букв (A-Z, a-z) и/или чисел (0-9). Первым символом должна быть буква и, как минимум, один символ должен быть буквой в нижнем регистре).
x – плейсхолдер зашифрованного пароля, хранящегося в файле /etc/shadow.
UID – номер, использующийся системой для идентификации пользователя (UID обычных пользователей должны иметь диапазон от 100 до 60000. Все UID должны быть уникальными).
GID – номер, использующийся системой для идентификации основной группы пользователя.
comment – комментарий (обычно содержит полное имя пользователя).
home_directory – полный путь к пользовательской домашней директории (в данной директории хранятся конфигурационные файлы пользователя).
login_shell – пользовательская командная оболочка.

По умолчанию, сразу после установки операционной системы файл /etc/passwd выглядит как на скриншоте:

Файл /etc/shadow

Структура записи файла следующая:

loginID – имя пользователя.
password – может содержать: 13-символьный зашифрованный пароль (по умолчанию пароли хэшируются алгоритмом SHA256); символы *LK*, означающие, что учетная запись недоступна; символы NP, означающие, что учетная запись не имеет пароля.
lastchg – количество дней от 01.01.1970 до последнего дня смены пароля.
min – минимальное число дней между сменами пароля.
max – максимальное число дней, в течение которых пароль будет валиден.
warn – количество дней, за которые пользователь будет предупрежден об истечении срока пароля.
inactive – количество дней, в течение которых пользователь может быть неактивен перед блокировкой.
expire – дата окончания срока пользовательской учетной записи.
flag – количество неуспешных попыток входа.

Скриншот файла /etc/shadow:

Файл /etc/default/passwd

Это файл настроек сложности пароля. Примеры с этим файлом приведены ниже.

Файл /etc/group

Структура записи файла следующая:

groupname – имя группы (максимум 8 символов).
group-password – пустое поле или звездочка (означающая, что пароль назначен для группы).
GID – идентификатор группы.
username-list – список пользователей, для которых данная группа является вторичной (Каждый пользователь состоит в одной основной группе, а также может быть в составе других групп. Остальные группы будут для него вторичными).

Администрирование (управление) учетными записями

Добавление пользователей

Добавление новой пользовательской учетной записи выполняется командой useradd под пользователем root. Пример добавления пользователя с именем dushanbe:

Проверка появления соответствующей записи в файле /etc/passwd:

Пароль пользователю dushanbe задается командой passwd:

Появится приглашение ввести новый пароль. Новый пароль должен соответствовать требованиям безопасности ОС Solaris – длина не менее 6 символов, содержать минимум 1 букву и 1 цифру. Пользователь самостоятельно может сменить пароль командой passwd.

Проверка появления соответствующей записи в файле /etc/shadow:

Модификация пользователей

Для модификации пользователей используется команда usermod. Пример изменения имени пользователя dushanbe на test командой usermod и опции –l:

Проверка изменения соответствующей записи в файле /etc/passwd:

Удаление пользователей

Для удаления пользователей используется команда userdel (опция –r также удаляет домашнюю директорию пользователя).

Добавление группы

Для добавления группы используется команда groupadd:

Проверка появления соответствующей записи в файле /etc/group:

Модификация группы

Производится командой groupmod. Пример изменения имени группы grp1 на grp2:

Проверка изменения соответствующей записи в файле /etc/group:

Удаление группы

Для удаления группы из ОС используется команда groupdel. В примере удаляется группа testgrp.

Проверка файла /etc/group на наличие группы testgrp (до удаления группы):

Удаление группы командой:

Проверка файла /etc/group на отсутствие удаленной группы testgrp (после удаления):

Добавление/удаление учетной записи в группу

usermod –G groupname username – добавление учетной записи в группу

usermod –G -groupname username – удаление учетной записи из группы

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

В примере проверяется файл /etc/group на наличие группы sunny и добавляется в эту группу пользователь dushanbe. Проверяется файл еще раз после добавления учетной записи и затем удаляется добавленный пользователь из группы. Заново проверяется файл, чтобы убедиться в правильности выполнения команды:

Дополнительные настройки учетных записей

Файл /etc/default/passwd контролирует пароли всех пользователей системы, в этом файле задаются параметры, которым пароли всех пользователей должны соответствовать. Например, параметр MAXWEEKS определяет в течение какого периода пароль будет валиден/активен (число указывается в неделях). Пустое место, как на скриншоте, означает, что пароль будет валиден постоянно).

Однако три параметра, влияющих на срок истечения пароля – MAXWEEKS, MINWEEKS, WARNWEEKS – могут быть заданы в файле /etc/shadow. В таком случае, эти параметры в файле /etc/default/passwd примут такое же значение, как и для отдельных пользователей, так как значения в файле /etc/shadow более приоритетны.

Команда useradd –D

Команда useradd –D создает файл, содержащий значения по умолчанию для новых пользовательских учетных записей. Первоначально проверяется, существует ли подобный файл командой ls /usr/sadm/defadduser и в случае его отсутствия выполняется команда useradd –D. Далее можно изменять значения в этом файле командой useradd –D value (например, useradd –D –s /bin/ksh изменит пользовательскую командную оболочку с дефолтной /usr/bin/bash на /bin/ksh).

Init files

Как получить доступ к базе солярис

Решили сделать так - подцепить диск (SCSI) на другой сервер и там попытаться просто получить доступ к диску. Выбрали для этого HP DL380. А там у него стоит плата RAID контроллера. Короче подцепили диск - но без "активации" его как логического диска в контроллере система этот диск не видит.

. доступ не получили .

. на родном сервере он теперь тоже не запускается - пишет "boot failed" . восстановление fsck ничего не дало .

Я так понимаю что RAID контроллер записал на диск блок своей информации и этим повредил юниксовую разметку диска. В "ДОСе" такое скорее всего вылечилось бы восстановление MBR. А что дулать тут ?

ПРОСЬБА ОСТАЕТСЯ В СИЛЕ !

После того как вы активировали диск скорее всего вы перезаписали VTOC со всеми
вытекающими последствиями. Поэтому восстановление скорее всего станет куда более затруднительным. Для Linux есть такая штука как gpart, которая сканирует весь
диск и ищет известные типы разделов. Попоробуйте ее или что-то подобное.

Короче надо было целять на машинку на базе Sun Sparс c Solaris 8 и выше
и не было бы гемороя. У меня есть одна такая на работе ( SunFire V240 ).
Мог бы даже посодействовать.

А теперь советую все-таки сначала проверить --- сохранился ли VTOC
(подключив к Sun Sparс c Solaris 8 и выше и запустив format)
и если нет --- то придется вручную (изучить структуру VTOC и потом искать
сектор за сектором сигнатуры ФС, потом вручную прописывать в VTOC,
если умеете программировать --- то у вас есть шанс написать аналог gpart,
но уже для Solaris на платформе Sun Sparc)

Такой вопрос - в описании к GPART сказано что он поддерживает только Solaris/x86 disklabels. А если у меня диск разбивался изначально и работал под SPARK-ом - будет он работать или нет ?

Т.е. получается что в зависимости от типа процессора одна и та-же файловая система создается по разному ?

Добавлено:
Только что всё проверили. Оказывается что ситуация поменялась - видны все разделы диска кроме нулевого. Т.е. получается что запорота нулевая партиция !

Проблемы. Образ диска слили dd, на всякий случай.

Как заставить систему снова работать?

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

Oracle Solaris Cluster

SunCluster - это кластерный программный продукт для операционной системы Solaris, первоначально созданный корпорацией Sun Microsystems, которая была приобретена Oracle Corporation в 2010 году.

Sun Cluster даёт возможность удалённым компьютерам и узлам работать вместе; при отказе одного из них другие продолжат предоставлять требуемый сервис. Узлы могут быть расположены в одном датацентре или на разных континентах [Источник 1] .

Содержание

История

Изначально, программный продукт Sun Solaris Cluster был создан компанией Sun Microsystems для их операционной системы Sun Solaris.

Продукт SCGE был был выпущен в августе 2005. Он позволяет управлять двумя системами Solaris Cluster как целым. Обновлённые данные копируются на удалённую систему почти в реальном времени; удалённая система может быстро принять на себя предоставление сервиса, в случае повреждения основной системы.

На момент 2009 года SCGE поддерживал репликацию с Sun StorageTek AVS, EMC SRDF и Hitachi TrueCopy. Реализована поддержка репликации для Oracle Data Guard и MySQL.

Однако в 2010 году, компания Oracle приобрела копанию Sun за 7,4 млн долларов. После поглощения, все продукты, выпускаемые компанией Sun либо были переименованы из ПО Sun в ПО Oracle, либо их поддержка была прекращена.

Таким образом ложно полагать, что Oracle Solaris Cluster, было создано компанией Oracle, на самом деле, изначально, данное ПО разрабатывалось и поддерживалось, а после поглощения продолжала поддерживаться всё теми же людьми из Sun Microsystems, только под теперь под именем Oracle Solaris Cluster.

Функционал

Solaris Cluster предоставляет службы, которые остаются доступными при отказе индивидуальных компонентов. Solaris Cluster предоставляет два типа высокодоступных служб: failover services и scalable services.

Для обеспечения сохранности и доступности данных Solaris Cluster использует сети хранения данных.

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

В июле 2007 Sun Microsystems открыла исходный код Solaris Cluster сообществу OpenSolaris HA Clusters.

Система Sun Cluster представляет собой программную среду, которая обеспечивает поддержку высокой доступности (HA) для служб данных и параллельного доступа к базе данных на кластере серверов (серверы Sun Cluster). Серверы Sun Cluster запускают операционную среду Solaris 2.6, Solaris 7 или Solaris 8, программное обеспечение для инфраструктуры Sun Cluster, программное обеспечение для управления дисковым объемом и сервисы данных HA или приложения параллельной базы данных (OPS или XPS).

Программное обеспечение Sun Cluster обеспечивает аппаратное и программное обнаружение сбоев, администрирование системы Sun Cluster, отказоустойчивость системы и автоматический перезапуск служб данных в случае сбоя. Программное обеспечение Sun Cluster включает в себя набор служб данных HA и интерфейс прикладного программирования (API), который может использоваться для создания других сервисов данных HA путем их интеграции с инфраструктурой Sun Cluster. Архитектура общего диска, используемая с параллельными базами данных Sun Cluster, обеспечивает повышенную доступность, позволяя пользователям одновременно обращаться к одной базе данных через несколько узлов кластера. Если узел выходит из строя, пользователи могут продолжать получать доступ к данным через другой узел без какой-либо значительной задержки.

Система Sun Cluster использует программное обеспечение Solstice DiskSuite или VERITAS Volume Manager (VxVM) для администрирования многоходовых дисков - дисков, доступных из нескольких серверов Sun Cluster. Программное обеспечение для управления томами обеспечивает зеркальное отображение диска, конкатенацию, чередование и горячее резервирование. VxVM также обеспечивает возможность RAID5.

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

При избыточном оборудовании каждый аппаратный компонент имеет резервную копию, которая может взять на себя ответственность за неисправный компонент. Мониторы сбоев регулярно проверяют структуру Sun Cluster и высокодоступные службы передачи данных и быстро обнаруживают сбои. В случае служб данных HA мониторы сбоев реагируют на сбои либо путем перемещения служб данных, работающих на неустановленном узле, на другой узел, либо, если узел не сработал, путем попытки перезапуска служб данных на том же узле. [Источник 2] .

Программное обеспечение

Структура кластера

Самое внутреннее ядро состоит из Cluster Membership Monitor ( далее CMM - членство в кластере). CMM организует реконфигурирование других компонентов кластера через структуру Sun Cluster.

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

Услуги передачи данных

К этим программным компонентам относятся следующие логические компоненты:

Логические хосты:

Логический хост Sun Cluster представляет собой набор ресурсов, которые могут перемещаться как единое целое между серверами Sun Cluster. В Sun Cluster ресурсы включают коллекцию имен сетевых узлов и связанных с ними IP-адресов, а также одну или несколько групп дисков. В кластерных средах, отличных от HA, таких как OPS-конфигурации, IP-адрес постоянно отображается на конкретную хост-систему. Клиентские приложения получают доступ к своим данным, указав IP-адрес хоста, на котором запущено серверное приложение.

В Sun Cluster IP-адрес назначается логическому хосту и временно связан с любой хост-системой, на которой в настоящий момент запущен сервер приложений. Эти IP-адреса перемещаются, то есть могут перемещаться из одного узла в другой. В среде Sun Cluster клиенты определяют перемещаемые IP-адреса логических хостов для подключения к приложению, а не IP-адрес физической хост-системы.

Группы дисков (VxVM) или диски (Solstice DiskSuite) [Источник 3] .

Особенности Sun Cluster

Интерфейс командной строки:

В новой версии Sun Cluster у вас есть отдельные команды для каждого типа объектов кластера, и все они пытаются по возможности иметь похожие имена для параметров командной строки. Кроме того, поддерживаются как короткие, так и длинные имена для каждого параметра.

Поддержка SMF:

Sun Cluster теперь тесно интегрирован с SMF и легко поддерживает управление службами, управляемыми SMF, в качестве ресурсов Sun Cluster.

Сервер-Quorum:

Для любых сценариев, требующих кворума, вам больше не нужно использовать разделяемое хранилище. Sun Cluster поддерживает использование отдельного сервера Solaris с модулем кворум-сервер. Все атомарные резервирования будут выполняться через TCP / IP. Такой подход позволяет сократить время, необходимое для отказа от одного узла кластера другому.

Расширенная поддержка зон Solaris:

Sun Cluster теперь поддерживает множество сервисов, работающих в неглобальных зонах.

Поддержка ZFS:

Начиная с этой версии Sun Cluster, ZFS полностью поддерживается как локальная высокодоступная файловая система (HA FS).

Обновление в реальном времени:

Теперь вы можете использовать Live Upgrade для обновления ОС с помощью Sun Cluster. Из документации я вижу, что Live Upgrade поддерживает только SVM.

Ведение журнала команд:

Теперь вы можете управлять всеми командами управления кластерами - это полезно как для диагностики, так и для воспроизведения вашей кластерной среды в новой конфигурации. [Источник 4] .

Система доступа

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

Одна общедоступная сеть обозначается как первичная общественная сеть, а другие общедоступные сети называются вторичными общедоступными сетями. Каждая сеть также упоминается как подсеть или подсеть.

Установка ОС Solaris и управление пользователями

Для управления учетными записями можно использовать программу admintool при работе в графическом режиме или программы useradd , usermod , userdel , groupadd , groupmod , groupdel в текстовом режиме или в окне терминала.

admintool

Программа admintool является устаревшей, и в системах Solaris 9 и в более поздних, начиная с мая 2002 года, ее может просто не быть. Вместо нее рекомендуется использовать Solaris Management Console ( SMC ). Однако, в доступных нам версиях Solaris программа admintool вполне способна работать и может оказаться удобной, поэтому здесь мы коротко рассмотрим ее функции. Подробнее программа Solaris Management Console рассматривается в "лекции 16" курса "Администрирование ОС Solaris".

Программа admintool предназначена для управления пользователями , группами , принтерами, последовательными портами ( serial ports ), для назначения имени и IP-адреса компьютера (фактически - редактирования файла /etc/hosts) и управления ПО. Последняя функция в admintool в Solaris 9 x86 не всегда поддерживается, но поддерживалась в версиях до Solaris 8 включительно.

Для управления пакетами ПО следует использовать программу prodreg (запускается в графическом режиме), которая служит полноценным интерфейсом для установки и удаления пакетов программ, управляя Solaris Product Registry - базой данных об установленных продуктах.

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

Тип объектов, которыми вы собираетесь управлять с помощью admintool , следует выбрать в пункте меню Browse (рис. 4.1):

Действия, которые можно совершить с выбранным объектом, доступны через пункт меню Edit. Можно добавить или удалить объект, или изменить его свойства.

Например, можно установить любые свойства учетной записи пользователя , которые перечислены выше, при рассмотрении формата файлов /etc/passwd , /etc/shadow и /etc/group .

Фактически, любая программа управления учетными записями , будь то admintool , Solaris Management Console или любая другая программа, для работы со свойствами пользователя в графическом режиме все равно вызывает простые системные программы с интерфейсом командной строки для выполнения любых операций со свойствами пользователя . В Solaris для создания новой учетной записи пользователя (добавления пользователя в систему) используется программа useradd , для модификации учетной записи пользователя - usermod , для удаления учетной записи - userdel .

useradd

Для добавления нового пользователя следует выполнить команду useradd :

При этом пользователь попадает в группу other , если явно не указано иное. Эта группа имеет идентификатор 1.

При добавлении пользователя в Solaris происходит добавление соответствующей строки в файлы /etc/passwd , /etc/shadow и /etc/user_attr. Первые два файла нам уже знакомы. Последний служит для записи дополнительных атрибутов пользователя . Он используется только в Solaris, в других системах UNIX такого файла нет. К дополнительным атрибутам относятся административные права, данные этому пользователю , перечень ролей, назначенных ему, и указание на то, является ли эта учетная запись пользователя информацией о реальном пользователе или информацией о роли. Более подробно о ролях говорится в "лекции 11" курса "Администрирование ОС Solaris", для получения детальной информации о /etc/user_attr - следует изучить man по user_attr.

По умолчанию useradd добавляет учетную запись пользователя в файлы /etc/passwd и /etc/shadow . Кроме этого, при указании ключа -G запись о пользователе помещается в /etc/group в строку тех групп , которые указываются в качестве дополнительных для него. С помощью ключа -m можно указать, что для пользователя следует создать домашний каталог.

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

Имя пользователя или роли не может быть длиннее 8 символов и должно содержать только латинские символы, цифры, точку, знак подчеркивания и дефис. Точка является допустимым символом не для всех систем UNIX, поэтому ее не рекомендуется использовать в Solaris в целях совместимости, хотя это требование не является жестким. Первый символ имени должен быть буквой, и по крайней мере одна буква в имени должна быть буквой нижнего регистра.

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

-b base_dir - каталог, в котором должен быть создан домашний каталог пользователя ; не требуется указывать, если используется ключ -d ;
-c comment - поле GECOS общей информации о пользователе , как минимум, следует указать полное имя пользователя ;
-d dir - домашний каталог пользователя ; по умолчанию создается в каталоге /home и носит то же имя, что и пользователь (для пользователя lena создается домашний каталог /home/lena);

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

Ряд ключей, служащих для управления ролями, обсуждается в "лекции 11" курса "Администрирование ОС Solaris".

Для удаления пользователя используйте userdel .

Для добавления группы следует использовать groupadd , для удаления - groupdel ; для изменения учетной записи группы - groupmod .

Как получить доступ к данным времени для кражи в Solaris SunOS 5.10

Я думаю, что версия Solaris, которую мы используем, слишком стара, чтобы отображать время кражи в топе. Есть ли способ получить эту информацию о более старой версии Solaris. Вот основная информация о версии:

У меня нет реального опыта работы с этими системами Sun VM, поэтому я могу что-то не понимать, и может быть лучший способ сделать то, что мне нужно в этой ситуации. Применяя свою ментальную модель Intel, я подозреваю, что ЦП перегружен, но как я могу это измерить?

Обновить

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

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

То есть с 10 параллельными рабочими потоками GC, обычно user >> real >> sys и одна из причин нечетного времени - это виртуальная машина, на которой не хватает ЦП. (Мы не меняем местами, и все системы основаны на SSD, поэтому ожидания ввода-вывода не являются проблемой.)

На данный момент мне нужно получить данные, чтобы подтвердить эту теорию, и в моем понимании Linux я бы просто проверил st% вверху. В Google также говорится, что в современной версии Solaris я могу сделать то же самое. Моя проблема в том, что мы не используем эту современную версию Solaris.

Ваша настоящая проблема здесь, похоже, заключается в снижении производительности. И время кражи, вероятно, бессмысленно на сервере Solaris 10 T1000 / T2000.

Чтобы узнать, бегаете ли вы в зоне, используйте /usr/bin/zonename команда (расположение может отличаться в разных версиях Solaris - также проверьте /bin , /sbin/ , и /usr/sbin .) Если zonename возвращает что-либо кроме global , вы бежите в зоне.

Если по какой-то причине у вас нет доступа к zonename команда, есть несколько ps команды, которые вы можете использовать, чтобы узнать, находитесь ли вы в зоне. Сначала ищите init :

Если это не поможет найти init процесс с PID 1 , вы в зоне. Вы также можете поискать zsched (IIRC):

Если это возвращает один процесс, который является его собственным родительским (PID и PPID одинаковы и больше, чем 1 ) тогда вы бежите в зоне.

Если вы находитесь в зоне, вы можете столкнуться с ограничениями ресурсов, которые замедляют работу. Однако это вряд ли.

Что еще хоть на сервере работает? В том числе и другие зоны. Я видел действительно неприятные проблемы с производительностью на серверах Sun серии T, похожие на те, что вы описываете, вызванные взаимодействием между ZFS ARC и приложениями, использующими огромные страницы памяти, такими как база данных Oracle.

ZFS ARC использует 4k страниц памяти, поэтому он фрагментирует память - и она будет фрагментирована. ВСЕ память на вашем сервере. Если ваш сервер попадает в это состояние и процессу требуется значительный объем больших страниц памяти, ядру приходится объединять кучу маленьких страниц в большие, что требует перемещения большого количества памяти. И все это делается в однопоточном режиме. И любой отдельный поток на сервере ранней серии T МЕДЛЕННЫЙ поскольку серверы были разработаны для обработки огромного количества потоков с большими задержками - например, веб-сервер или сервер базы данных, который обрабатывает множество подключений по сети.

Таким образом, ядро переходит в длительные периоды, когда практически все, что оно делает, - объединяет маленькие страницы памяти в большие страницы.

Затем ZFS ARC возвращает страницы после того, как с ними завершается процесс использования больших страниц, и они фрагментируются.

Я подозреваю, что у вас может быть такая же проблема.

Чтобы узнать, бегите

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

Чтобы выяснить это, запустите следующий сценарий dTrace, снова от имени пользователя root из глобальной зоны, чтобы определить, на что ядро тратит все свое время:

Скопируйте это в файл, скажем hot.d , установите его исполняемый файл ( chmod 755 hot.d ) и запустите его как root из глобальной зоны:

Запускайте его, когда у вас замедление. Дайте ему поработать 10-20 секунд, если не дольше, после того, как он испустит matched 1 probe , а затем сломать его CTRL-C . Затем он испустит много вывода, большая часть которого вас не волнует. Однако последняя горстка выходных данных трассировки стека будет наиболее часто выбираемой, что скажет вам, на что ядро тратит все свое время.

Это окончательно скажет вам, в чем ваша проблема. Он может быть недостаточно точным, чтобы полностью решить его, и вам может потребоваться дополнительное расследование, но вы будете знать, где искать.

Если вы видите много следов стека с idle или wait в нем у вас проблема с пользовательским пространством. Вы можете определить это, заменив stack() в приведенном выше скрипте dTrace с ustack() чтобы получить стек пользователя.

И если вы видите много следов стека с coalesce в именах функций ядро тратит все свое время на создание больших страниц памяти. Исправление для этого - освободить память, скорее всего, за счет ограничения размера ZFS ARC, возможно, даже сильно. Мне пришлось снизить размер ZFS ARC на нескольких серверах до менее 1 ГБ, чтобы он не убивал производительность.

Role Based Access Control (RBAC) в Solaris 9

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

Рассмотрим, какие средства в этом контексте предоставляет нам ОС Solaris 9.

Role based access control (в дальнейшем RBAC) является чрезвычайно гибким и мощным антиподом упомянутой классической радикальной двухуровневой схеме. RBAC позволяет делегировать определенные возможности суперпользователя группам пользователей. Это позволяет им выполнять конкретные административные задачи. Например, управлять печатью, операциями резервного копирования и т. д.

Основная идея RBAC заключается в предоставлении определенных наборов прав суперпользователя группам пользователей. Такой набор прав и называется ролью. Отдельные пользователи могут быть наделены несколькими ролями. Однако роль не может ссылаться на другую роль.

По отношению к использованию RBAC, стратегии управления системой можно условно разделить на следующие категории:

Без использования RBAC. Это уже упомянутая классическая двухуровневая модель: все операции по администрированию системы выполняются суперпользователем (root).
Использование роли root. Бюджет суперпользователя реализован в виде роли. Пользователи, принадлежащие к этой роли, входят в систему под своими именами, а уже после авторизуют себя в роли, выполняя su root.
Используется одна роль на основе профайла Primary Administrator. Практически аналогична второму пункту.
Используются роли на основе предопределенных в Solaris Operating Environment (далее SOE) типовых профайлах, таких как Primary Administrator, System Administrator, Operator и т. д.
Специальные пользовательские роли создаются для решения отдельных задач, исходя из конкретной стратегии администрирования системы. Эти роли могут основываться на наборах как предопределенных профайлов, так и специально созданных.

В зависимости от конкретных потребностей организации выбирается та или иная стратегия использования технологии RBAC. Технология RBAC строится на двух базовых понятиях: профайл прав (rights profile) и авторизация (authorization)

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

Как уже было отмечено выше, SOE включает в себя набор предопределенных профайлов прав, которые, по мнению разработчиков Solaris, отвечают конкретным типовым задачам управления системой. Вот лишь некоторые из них: Basic Solaris User, Operator, Media Backup, User Security, FTP Management. Помимо предопределенных профайлов прав, можно создавать собственные профайлы.

Авторизация – определенное право доступа к той или иной компоненте системы, которым может быть пользователь или роль. Существуют целые классы авторизаций. Для наглядности приведу пример:

Если авторизация заканчивается суффиксом grant, то она позволяет делегировать права на все операции префикса.

Авторизации локальной системы всегда начинаются со слова «solaris», авторизации, предоставляемые другими системами, начинаются с реверсивной записи DNS-имени хоста. Вообще говоря, помимо определенных в SOE авторизаций, новые локальные авторизации создавать нельзя.

Реализация RBAC в Solaris 9 базируется на 2 + 4 + 1 = 7 базах данных. Почему 2 + 4 + 1?

Две первые базы – это стандартные для UNIX-систем файлы /etc/passwd и /etc/shadow. Назначение их известно, их структуру мы рассматривать здесь не будем. Я лишь продемонстрирую место этих файлов в технологии RBAC.

Следующие четыре – это RBAC-специфические базы. Собственно, они и есть RBAC. Их-то мы и рассмотрим подробно.

Первый из четырех – файл /etc/user_attr. Этот файл содержит объявления ролей и пользователей с их профайлами прав и авторизациями, а также определяет принадлежность пользователей ролям. Каждая запись (строка) этого файла соответствует одноименной записи в файлах /etc/passwd и /etc/shadow. В определенном смысле user_attr является расширением базы пользовательских бюджетов /etc/passwd.

Структура записей файла такова:

user/role name:нечто1:нечто2:нечто3:список атрибутов

Каждое поле отделяется от другого двоеточием. Первое поле – это имя пользователя или роли, второе, третье и четвертое поля («нечто») в настоящее время пусты, они зарезервированы для возможного последующего использования в будущих версиях Solaris. В последующих описаниях форматов баз я буду эти поля просто оставлять пустыми. Последнее поле содержит атрибуты, разделенные точкой с запятой. Атрибут состоит из названия типа атрибута, знака «=» и соответствующих ему значений, разделенных запятой.

Атрибуты бывают четырех типов:

type – указывает тип записи,
normal – соответствует обычному пользователю,
role – роли,
auths – содержит перечни авторизаций, разделенные запятой.

Авторизации в качестве суффикса могут содержать символ * для обозначения всех операций, определяемых префиксом; profiles содержит перечень профайлов прав, разделенных запятой; roles содержит перечень ролей, к которым относится пользователь. Разумеется, этот атрибут применим только для записей с типом normal, т.е. для записи пользователя, поскольку, как это было сказано выше, нельзя задавать роль на основе других ролей. В качестве примера приведу фрагмент файла /etc/user_attr моей системы:

lp. profiles=Printer Management

adm. profiles=Log Management

master. type=role;profiles=Primary Administrator

team. type=role;profiles=Device Management,Media Backup,Media Restore,Log Management

Запись master определяет основную административную роль на основе профайла Primary Administrator, запись ivanov определяет пользователя и его принадлежность роли master. Обратите внимание на то, что роль team построена на базе сразу четырех профайлов прав. Как следует из названия профайлов, пользователи, принадлежащие к роли team, могут управлять сменными накопителями, производить операции резервного копирования и восстановления данных и управлять системой ведения log-файлов.

Второй из четырех – файл /etc/security/prof_attr. Файл является базой данных профайлов прав. Приведу структуру файла:

Атрибуты записей в этом файле бывают двух типов:

help – задает файл подсказки в формате html,
auths – содержит перечни авторизаций, разделенные запятой.

Device Management. Control Access to Removable Media:auths=solaris.device.*,solaris.admin.serialmgr.*; help=RtDeviceMngmnt.htmlAll. Execute any command as the user or role:help=RtAll.html

Как мы видим, роль team ссылается на профайлы прав, определенные в обсуждаемом файле. Заметим, что эта база данных позволяет также определять профайлы прав на основе ранее описанных профайлов.

Третий из четырех – файл /etc/security/auth_attr. База auth_attr описывает авторизации. Из всех RBAC-баз данных это единственная база, которую нельзя редактировать вручную, т.е. нельзя самостоятельно определять авторизации. Формат файла auth_attr следующий:

auth_name. краткое описание:подробное описание:атрибуты

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

Device Allocation::help=DevAllocHeader.htmlsolaris.device.grant. Delegate

Обратите внимание на первую из приведенных строк: имя авторизации состоит из префикса и заканчивается точкой. Такие записи служат для объявления оглавления группы авторизаций одноименного префикса в программах с графическим интерфейсом.

И наконец, четвертый файл – /etc/security/exec_attr. Эта база определяет соответствие профайлов прав конкретным командам и атрибутам их выполнения. Структура файла такова:

В текущей реализации RBAC поле policy может принимать единственное значение – suser (суперпользователь), а тип может быть только cmd (команда). Под командой подразумевается полный путь к исполняемому файлу или shell-скрипту; если в поле команды стоит символ *, то это означает любую команду. Атрибуты, как и раньше, разделяются точкой с запятой и могут быть четырех типов:

uid – идентификатор пользователя,
euid – эффективный идентификатор пользователя,
gid – идентификатор группы,
egid – эффективный идентификатор группы.

Последний из рассматриваемых файлов (помните, +1) /etc/security/policy.conf. Он задает авторизации и профайлы прав, предоставляемые пользователю по умолчанию. Как видно из примера, файл содержит две записи:

PROFS_GRANTED=Basic Solaris User

Разумеется, значения этих двух полей должны быть определены в файлах auth_attr и prof_attr.

Взаимодействие компонентов RBAC

Рисунок 1. Компоненты RBAC и взаимодействие между ними

Поясню связи компонентов RBAC комментариями.

Прежде всего напомню, что каждой записи в user_attr соответствуют одноименные записи в файлах /etc/passwd и /etc/shadow.

Стоит обратить внимание на то, что в строках ролей файла /etc/passwd в поле командного интерпретатора стоит не обычный пользовательский shell (bash, csh, sh), а так называемый «профайловый» shell (profile shell) с префиксом pf:

. team:x:102:1:Operators" Team:/export/home/team:/bin/pfshivanov:x:103:1:V. Ivanov:/export/home/ivanov:/usr/bin/bash.

Когда пользователь авторизуется в роли, то запускается соответствующий profile shell, и в дальнейшем все команды выполняются при помощи pfexec с текущими полномочиями, которые определены в роли.

Записи в /etc/user_attr, обозначающие пользователей, могут ссылаться на описанные в нем же роли.

Атрибуты auths и profiles ссылаются соответственно на авторизации (файл /etc/security/auth_attr) и профайлы прав (файл /etc/security/prof_attr).

Записи профайлов прав в файле /etc/security/prof_attr ссылаются на:

другие профайлы, определенные в этом же файле;
авторизации, описанные в файле auth_attr;
одну или несколько строк в файле /etc/security/exec_attr, которая и начинается с имени данного профайла.

Операционное окружение Solaris (SOE) предусматривает три способа управления ролевыми бюджетами. Самым «цивилизованным» способом является управление при помощи утилиты с графическим интерфейсом Solaris Management Console (smc).

На рис. 2 показано окно Solaris Management Console. Я не думаю, что стоит подробно рассказывать об управлении ролями и пользовательскими бюджетами при помощи этой утилиты: человек, знакомый с графическими оболочками и понимающий концепции и структуру RBAC, без труда разберется. Замечу лишь, что для управления ролями и пользовательскими бюджетами, разумеется, необходимы соответствующие права. Альтернативой использования утилиты smc является набор консольных утилит. Перечислим их и приведем их назначение.

Рисунок 2. Solaris Management Console

auths – выводит перечень авторизаций, которыми обладает пользователь(и). Выполнение этой команды без параметров выводит список авторизаций текущего пользователя.
profiles – выводит перечень профайлов, которыми обладает пользователь(и).
roles – выводит имена ролей, к которым принадлежит пользователь(и).

Команды useradd, userdel, usermod и roleadd, roledel, rolemod позволяют добавлять, удалять и изменять пользователей и роли соответственно.

Утилита smrole управляет ролями и позволяет добавлять и удалять пользователя в роль. smprofile и smexec управляют содержимым баз prof_attr и exec_attr.

Утилиты, название которых начинается с sm, требуют запущенной Solaris Management Console. Подробная информация об этих командах и их опциях содержится в man-страницах (1M), мы же ограничимся несколькими простыми примерами использования. Вернемся к рассмотренному нами фрагменту файла user_attr:

. master. type=role;profiles=Primary Administratorivanov. type=normal;roles=masterteam.

ype=role;profiles=Device Management,Media Backup,Media Restore,Log Managementpetrov. type=normal;roles=team.

Приведу здесь команды, при помощи которых созданы роли master и team, пользователи ivanov и petrov, принадлежающие к соответствующей роли. Создаем роль master:

В опции -d указывается домашний каталог роли, ключ -m разрешает автоматическое создание каталога, если таковой не существует. Опция -c задает комментарий, а -P – перечень профайлов прав, на которых должна базироваться роль.

Создаем роль team:

Обратите внимание на то, что при перечислении профайлов прав между запятой и именем следующего профайла пробелов быть не должно. Разумеется, задавать можно только существующие профайлы, определенные в файле /etc/security/prof_attr. Добавляем пользователя ivanov и определяем его принадлежность роли master:

Добавляем пользователя petrov и определяем его принадлежность роли team:

Полагаю, что две последние команды не нуждаются в комментариях.

Помимо двух рассмотренных подходов в управлении ролями есть и третий: прямое редактирование баз данных RBAC (как уже сказано, кроме файла /etc/security/auth_attr), но этот подход не рекомендован разработчиками из Sun Microsystems по причине «возможных синтаксических ошибок».

Читайте также: