Управление системными файлами в сети AIX

Опции документа Опции документа, требующие включения JavaScript, не отображаются Обсудить Выскажите мнение об этой странице Помогите нам улучшить содержание

Уровень сложности: простой

Шив Дутта, старший инженер-программист, IBM

01.06.2009

В статье представлены два способа управления системными файлами и их обновления в сети AIX – распространение файлов путем копирования и использование сервиса NIS (Network Information Service). Также объясняется, как сделать выбор между этими двумя методами и как их использовать.

Введение

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

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

Заметим, что NIS (второй из рассматриваемых в этой статье методов) предлагает возможности сделать доступ к системе более безопасным.

В начало

Обзор

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

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

Существуют два общепринятых способа выполнить подобное группирование. Простейшим способом является хранение главной копии каждого конфигурационного файла в одном месте и клонирование этих файлов на другие компьютеры группы, если что-то в них изменится. Этот способ будет называться Распространение файлов путем копирования (Distribution by file copying). Это простой способ, который работает на любой UNIX-системе.

Другим подходом является удаление всех текстовых файлов конфигурации с компьютеров в сети, которые после этого вынуждены брать конфигурационную информацию с центрального сервера. Этот подход используется в NIS и в последующем продукте NIS+. Этот метод более сложный, чем копирование файлов, но и более надежный. Например, клиенты никогда не пропустят обновление, даже если у них нет доступа к сети в момент изменения конфигурационной информации. Однако если подход реализован некорректно, все компьютеры в сети не смогут работать в случае выхода сервера из строя.

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

В начало

Какие конфигурационные файлы надо распределять

Несмотря на множество конфигурационных файлов в UNIX-системах, большинство серверных систем обычно работают со следующим набором файлов (см. таблицу 1).

Таблица 1. Назначение конфигурационных файлов

Доступ к файлам из списка, представленного в таблице 1, обычно осуществляется методами, определенными в библиотеке Standard C. Например, поиск в файле /etc/passwd выполняется методами getpwuid, getpwnam и getpwent. Эти методы выполняют процедуры по открытию, чтению и анализу файла passwd для того, чтобы программам пользовательского уровня не пришлось этим заниматься.

В начало

Распространение файлов путем копирования

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

Распространение файлов путем копирования реализуется двумя моделями – модель "push" ("проталкивание") или модель "pull" ("выталкивать"). При push главный сервер периодически рассылает только что обновленные файлы всем клиентам вне зависимости от того, нужны клиенту эти файлы или нет. Сервер распределяет файлы по заранее заданному расписанию или как только произойдет какое-либо изменение.

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

В pull-системе каждый клиент сам ответственен за обновление своих файлов с центрального сервера. Этот метод менее централизован, но зато более гибок и более безопасен.

Использование команды rdist для модели push

Главный сервер распространяет файлы (модель "push") при выполнении команды rdist. По умолчанию rdist ищет сначала управляющий файл с именем distfile (или Distfile) в текущем каталоге. Если управляющего файла нет в текущем каталоге, можно явно определить путь к нему при помощи опции -f:

rdist -f distfile

Пример управляющего файла distfile будет рассмотрен далее в этой статье. В distfile разделители (символы табуляции, пробела и символы новой строки) равнозначны. Комментарии выделяются знаком "решетки" (#).

Для выражений в distfile используется следующий синтаксис:

label: pathname -> destinations commands

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

rdist label

Параметр pathname – это файл, содержащий имена файлов, которые надо скопировать, а параметр destinations – это файл, содержащий имена систем, куда надо выполнить копирование. Если в списке несколько элементов, то список должен быть взят в круглые скобки, а его элементы должны быть отделены друг от друга пробелами.

По умолчанию rdist копирует файлы и каталоги, указанные в pathname, в те же каталоги на каждом целевом компьютере. Модифицировать это поведение можно при помощи команд из следующего списка, используя их во время создания distfile (стоит отметить, что каждая команда заканчивается точкой с запятой):

install options [destdir];
notify namelist;
except pathlist;
except_pat patternlist;
special [pathlist] string;

Команда install задает опции, которые влияют на то, как rdist копирует файлы. Опции (options) обычно управляют элементами типа символических ссылок.

Аргумент destdir определяет каталог на целевом компьютере, в который будет выполнено копирование.

Команда notify принимает в качестве аргумента список email-адресов. rdist посылает почту на эти адреса, как только файлы будут обновлены. Для адресов, не содержащих символа (@), будет добавлен суффикс в виде имени целевого хоста.

Команды except и except_pat удаляют пути к определенным файлам (pathnames) из списка файлов, которые должны быть скопированы. Параметры команды except интерпретируются буквально, как есть, тогда как параметры команды except_pat интерпретируются как регулярные выражения.

Команда special выполняет команду sh (аргумент string должен быть указан в двойных кавычках) на каждом удаленном хосте. Если задан аргумент pathlist, то rdist выполняет команду, определенную аргументом string после того, как скопирует все файлы, указанные в pathlist. А если pathlist нет, то rdist выполняет команду.

В следующем листинге приведен пример distfile:

	SYS_FILES = (/etc/passwd /etc/group /etc/aliases)
	GET_ALL = (homer bart marge)
	GET_SOME = (krusty moe)

	all: ${SYS_FILES} -> $(GET_ALL)
		notify jim;
		special /etc/aliases "/usr/ucb/newaliases";

	some: ${SYS_FILES} -> ${GET_SOME} 
		except /etc/aliases;
		notify ted@moe;

Данный distfile копирует три системных файла на системы homer, bart и marge и посылает письмо на jim@destination с описанием всех обновлений и ошибок, которые возникли. После того как /etc/aliases будет скопирован, rdist выполняет newaliases на каждом целевом компьютере. Только два из трех указанных файлов будут скопированы на krusty и moe, при этом отчет будет отправлен на ted@moe.

Команда rdist копирует файлы только тогда, когда они устаревают. Можно создать такой distfile, чтобы в нем были указаны все файлы, которые должны быть скопированы, и разрешить rdist решать, какие файлы действительно необходимо скопировать.

Команда rdist сохраняет атрибуты файлов (владелец, группа, режим доступа, и время модификации). Когда rdist обновляет существующий файл, он удаляет старую версию этого файла перед установкой новой.

Команда expect для модели копирования pull

Существует несколько способов реализации системы pull. Первый способ – сделать системные файлы доступными на ftp центрального сервера и использовать команду expect для их получения и инсталляции.

Команда expect является набором расширений для языка Tcl (Tool Command Language), который используется для написания управляющих сценариев к интерактивным программам. Однако expect отличается от обычного языка создания сценариев тем, что он предоставляет возможность инкрементного управления подпроцессами. Информация, полученная в результате работы одной команды, может быть проанализирована чтобы определить, какую информацию посылать на вход следующей команде.

В начало

Сетевая информационная служба

NIS, представленная Sun в 1980-х годах, была первой главной административной базой данных для системных конфигурационных файлов. Первоначально она называлась Yellow Pages, однако из-за юридических проблем ее позднее переименовали в NIS, хотя команды по-прежнему начинаются с сокращения yp.

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

В NIS главный сервер обслуживает официальные копии системных файлов. Сервер реализует доступ к этим файлам (в NIS они называются "карты" – "maps") из сети. Расширяемые процедуры хеширования ndbm выполняют предварительную обработку NIS-карт для увеличения эффективности поиска. Редактировать системные файлы на главном сервере можно при помощи текстового редактора. Затем, когда над этими файлами будет выполнена команда makedbm, NIS конвертирует их в формат ndbm.

Сервер и его клиенты составляют вместе NIS-домен.

Процедуры ndbm позволяют ассоциировать с каждой записью только один уникальный ключевой параметр, поэтому системный файл можно конвертировать в несколько NIS-карт. Например, файл /etc/passwd конвертируется в две карты – passwd.byname и passwd.byuid. Первую карту можно использовать для поиска записей по имени пользователя, вторую карту – для поиска записей по UID. Любая карта может использоваться для перечисления всех записей в файле passwd.

NIS позволяет дублировать карты на группе подчиненных серверов, которых может быть несколько. Внедрение более чем одного сервера в сеть позволяет снизить нагрузку на главный сервер и обеспечить работу клиента даже если несколько серверов вышли из строя. Как только файл был изменен на главном сервере, соответствующие NIS-карты должны быть отправлены на все подчиненные серверы, таким образом будет реализована синхронизация данных. Распространить файлы можно как вручную, так и при помощи cron, как будет объяснено позже. Клиенты не отличают главный сервер от подчиненного сервера.

Каждая физическая сеть должна содержать по крайней мере один NIS-сервер. Клиенты используют IP-ретрансляцию для обнаружения серверов, но ретрансляция пакетов обычно не поддерживается маршрутизаторами и шлюзами. Можно использовать команду ypset, чтобы показать клиенту какой-либо конкретный сервер (как это сделать, показано позже). Первым признаком возникновения проблем является попытка клиента найти новый сервер. Если другой сервер не будет найден в сети клиента, то клиент может "зависнуть".

NIS-данные и локальные данные – объединять или не объединять

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

В традиционной NIS объединение NIS-информации с локальной информацией поддерживается не для всех файлов. Две группы файлов, которые поддерживают объединение и которые его не поддерживают, определены ниже:

• приоритетные локальные файлы – информация в локальных конфигурационных файлах замещает информацию в конфигурационных файлах от NIS;
• приоритетные глобальные файлы – информация в конфигурационных файлах NIS замещает конфигурационные файлы локальной системы.

Обычно файлы /etc/passwd и /etc/group являются приоритетными локальными файлами. Данные NIS должны быть включены в эти файлы путем заключения их в специальные лексемы. Знак плюс (+), поставленный под этими файлами, добавил бы NIS-карту целиком, тогда как запись вида +name добавила бы информацию, нужную только для конкретного пользователя или группы. Третий способ, который рассмотрен ниже, используется сетевыми группами (netgroup).

Например, следующий файл /etc/passwd добавит локальные учетные записи davidw и stevenr к учетным записям, определенным в NIS-карте passwd:

	davidw:!:123:201:David Williams:/home/davidw:/bin/ksh
	stevenr:!:124:201:Steven Roberts:/home/stevenr:/bin/ksh
	+

Локальные копии приоритетных глобальных файлов игнорируются, исключая файл /etc/hosts, который может понадобиться во время загрузки. Файлы /etc/hosts, /etc/networks, /etc/protocols, /etc/services и /etc/netgroup являются глобально-приоритетными.

Что такое сетевая группа?

NIS ввела концепцию сетевой группы (netgroup). Сетевые группы используются для назначения имен группам хостов, пользователей и доменов с целью более удобного обращения к ним в системных файлах. Сетевые группы определены в /etc/netgroup, но также доступны для использования в глобально-приоритетной NIS-карте.

Синтаксис определения сетевой группы следующий:

groupname list-of-members

Участники группы отделяются друг от друга пробелом. Участником может являться либо другая сетевая группа, либо подобный триплет:

(hostname, username, domain name)

Любое пустое поле в триплете является групповым символом; так, выражение (cyclop,,) ссылается на всех пользователей во всех доменах хоста cyclop. Знак (-) в поле означает отрицание, выражение (cyclop,-,) указывает на хост cyclop и не берет в учет всех пользователей этого хоста. Определения групп могут быть вложенными.

Ниже представлен простой пример файла /etc/netgroup:

	jimmy	(cobra,,)	(support,,)
	systems	(chain,,)	(lisa,,)	(apu,,) (cyclop,,)
	clients	(charli,,)	(pushkin,,)	(bush,,)
	daniel	(chain,,)	(bourbon,,)	clients
	hosts	daniel		jimmy		systems

Сетевые группы могут использоваться в различных файлах, которые определяют права доступа. В частности, сетевые группы используются в файле /etc/exports, где они определяют, какие хосты могут монтировать файловые системы. Они могут предоставлять или отменять права на вход в систему для групп пользователей или хостов в файле /etc/hosts.equiv или в пользовательском файле .rhosts.

Сетевые группы используются в файле /etc/passwd, принадлежащем NIS-клиенту, для импорта информации об учетных записях, принадлежащих какой-то определенной сетевой группе. Синтаксис этой операции следующий +@netgroup.

Как настроить NIS

NIS должен быть настроен на главном сервере, на подчиненном сервере и на каждом клиенте. В объяснениях, приведенных ниже, dutta является доменным именем NIS для серверов и клиентов.

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

1. Создать каталог домена с именем /var/yp/dutta:

   cd /var/yp /* каталог NIS */ /usr/bin/domainname dutta /* создание домена dutta */

   
   
   
   
2. Очистить следующие файлы системного администрирования:
   • /etc/passwd
   • /etc/group
   • /etc/hosts
   • /etc/networks
   • /etc/services
   • /etc/protocols
   • /etc/ethers
   • /etc/aliases
   • /etc/rpc
   • /etc/netgroup
   
   
3. Проверить файл /etc/passwd на главном сервере. Если он содержит +, то удалить этот символ.
   
   
4. Запустить /usr/etc/yp/ypinit -m.

   Команда ypinit создаст полный комплект административных NIS-карт и поместит их в каталог /var/yp/dutta. Первая карта – это ypservers. Затем ypinit запрашивает список всех серверов, на которых будет развернут NIS, и добавляет эти серверы к ypservers. Может быть только один главный сервер. Заметим, что ypinit не проверяет главный сервер на предмет его уникальности. Наличие больше чем одного главного NIS-сервера приведет к беспорядку при рассылке NIS-карт и обновлении NIS-файлов с паролями.

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

5. Когда команда ypinit завершит свое выполнение, можно запустить NIS вручную командой /usr/etc/ypserv или путем перезагрузки сервера.

В AIX имя домена NIS вместе с инициированием ypinit для каждого сервера и клиента задается в сценарии /etc/rc.nfs.

Создание подчиненных серверов

Когда главный сервер настроен и запущен, пришло время конфигурировать подчиненные сервера. Для этого надо выполнить следующие шаги на каждом подчиненном сервере:

cd /var/yp				/* каталог NIS */
/usr/bin/domainname dutta		/* этот подчиненный сервер использует домен dutta */
|-------10--------20--------30--------40--------50--------60--------70--------80--------9|
|-------- XML error:  The previous line is longer than the max of 90 characters ---------|
/usr/etc/yp/ypinit -s masterServer     /* masterServer -> – имя главного сервера */
/usr/etc/ypserv>		        /* запуск подчиненного сервера */

Запуск команды ypinit -s передает данные конфигурации системы главного сервера и создает локальные копии карт на подчиненном сервере. Исходные файлы в кодировке ASCII не используются для создания локальных NIS-карт.

Наличие файлов домена указывает ypserv, что нужно обслуживать текущий домен.

Если главный сервер и подчиненный находятся в разных IP-сетях, выполнить эту инициализацию можно настроив подчиненный сервер как NIS-клиент (описано ниже) и использовав команду ypset для явного указания на главный NIS-сервер:

ypset -d dutta -h homer krusty

В этом примере команда ypset присоединяет хост с именем homer к серверу с именем krusty в домене dutta.

Дальнейшее добавление подчиненных серверов

Как упоминалось ранее, список серверов содержится в файле ypservers. Добавить новые серверы к этому списку можно выполнив следующие действия на главном сервере.

1. cd /var/yp/dutta
2. ypcat -k ypservers > /tmp/ypservers
3. Отредактировать файл /tmp/ypservers, добавить в него названия новых серверов и сохранить его.
4. cat /tmp/ypservers | makedbm - /var/yp/`domainname`/ypservers

Далее нужно выполнить следующие операции на новом подчиненном сервере для его инициализации и запуска NIS:

/usr/etc/yp/ypinit -s masterServer
/usr/etc/ypserv

Включение NIS на клиентах

Для запуска NIS на каждом клиенте требуются следующие действия.

1. Проверить, что по крайней мере один сервер выполняет ypserv.
2. Проверить, что конфигурационные файлы на каждом клиенте содержат в конце символ +.
3. Выполнить команду /usr/bin/domainname dutta.
4. Выполнить команду /usr/etc/ypbind.

Эти действия запустят демон-процесс ypbind, который отвечает за обнаружение NIS-серверов и поддержку привязки доменных имен к серверам.

Когда NIS уже запущен, запросы административной информации от клиента обрабатываются двумя различными способами в зависимости от того, находится ли эта информация в файлах с локальным приоритетом (Local Priority) или в файлах с глобальным приоритетом (Global Priority).

1. База данных NIS игнорирует локальные копии следующих файлов и использует свои копии этих файлов с момента запуска на выполнение ypbind:
   • /etc/hosts
   • /etc/networks
   • /etc/services
   • /etc/protocols
   • /etc/ethers
   • /etc/rpc
   • /etc/netgroup
2. NIS добавляет информацию к следующим файлам: /etc/passwd, /etc/bootparams, /etc/group и /etc/aliases. В первую очередь NIS ищет информацию в локальных файлах. В случае, если в локальных файлах нужная информация не найдена, NIS запрашивает соответствующую NIS-карту. Например, когда пользователь входит в систему, NIS сначала ищет имя пользователя в локальном файле passwd; если NIS не находит имя пользователя, то далее поиск имени осуществляется в NIS-карте passwd.

Как минимум, каждый клиент должен иметь собственную версию файлов passwd, group, и hosts. Файлы passwd и group необходимы для того, чтобы пользователь root смог войти в систему в случае, если нет доступного NIS-сервера. Эти файлы должны содержать стандартные системные учетные записи и группы (root, bin, daemon и wheel). Файл hosts должен присутствовать, чтобы отвечать на запросы во время загрузки, которые происходят прежде, чем NIS запустится.

Внутренние механизмы работы NIS

Файлы с данными NIS и большинство команд NIS хранятся в одном каталоге, обычно /var/yp, /usr/etc/yp или /etc/yp, который иногда называется NIS-каталогом. Каждая NIS-карта хранится как пара файлов ndbm, один из них называется map.dir, а другой map.pag, в подкаталоге с именем NIS-домена, который находится в главном NIS-каталоге. Например, в домене dutta файлы ndbm для карт /etc/passwd могут быть следующими:

/usr/etc/yp/dutta/passwd.byname.dir
/usr/etc/yp/dutta/passwd.byname.pag
/usr/etc/yp/dutta/passwd.byuid.dir
/usr/etc/yp/dutta/passwd.byuid.pag


Заметим, что для поиска в файле по каждому из двух полей (name и uid) потребуются две отдельные карты. В файле passwd можно выполнять поиск по имени пользователя (name) и идентификатору пользователя (user ID), поэтому для этого файла необходимы две NIS-карты (которые состоят из четырех файлов).

Скопировать карты с главного сервера на подчиненный сервер можно, если выполнить команду ypxfr на подчиненных серверах (команда ypxfr из модели pull.) На главном сервере выполняется демон-процесс ypxfrd, который отвечает на запросы, поступившие от подчиненных серверов. ypxfr не передаст карту до тех пор, пока она не устарела. Подчиненные серверы обычно часто выполняют команду ypxfr для проверки того, что у них самая свежая версия карт. Можно также сделать так, чтобы ypxfr запускался на выполнение из cron. На каждом подчиненном сервере можно настроить файлы crontab таким образом, чтобы копии всех обновленных карт своевременно приходили на подчиненный сервер с главного. Для этого используется ypxfr map, где map является именем, например, passwd.byuid, для передачи какой-либо определенной карты с главного на подчиненный сервер. Для каждой отдельной карты эту команду нужно выполнять заново. В большинстве случаев достаточно передачи карт с главного на подчиненные серверы один или два раза в день (например, второй раз – поздно ночью). Чтобы получить карты с главного сервера, на подчиненных серверах можно выполнить следующий сценарий оболочки Korn Shell из утилиты cron:

	#!/bin/ksh
	mydomain = '/usr/bin/domainname'
	cd /var/yp/$mydomain
	for map in '/usr/bin/ls'
	do
		/usr/etc/ypxfr  $map
	done

Заметим, что на главном сервере выполняется команда yppush (push-версия команды ypxfr). По сути, эта команда не выполняет никаких действий, она только указывает каждому подчиненному серверу выполнить ypxfr. Команда makefile использует yppush в NIS-каталоге чтобы убедится, что все вновь обновленные карты были распределены между серверами.

После начальной настройки активными компонентами NIS-системы являются только демоны ypserv и ypbind. ypserv работает только на серверах (главном и подчиненных); он принимает запросы от клиентов и отвечает на них, отыскивая информацию в картах ndbm. ypbind работает на каждом компьютере в NIS-домене, включая серверы. Библиотека C взаимодействует с локальным демон-процессом ypbind всякий раз, когда ей требуется выполнить административный запрос. ypbind находит ypserv в соответствующем домене и возвращает его идентификатор библиотеке C, которая потом напрямую связывается с сервером. ypbind, выполняющийся на сервере, не дает указатель на самого себя, поэтому серверы не могут организовать взаимодействие сами с собой.

Необходимые команды NIS

Таблица 2. Команды NIS

В начало

Заключение

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

Ресурсы

• Примите участие в обсуждении материала на форуме.
  
  
• Sharing system files in AIX - a primer: оригинал статьи (EN).
  
  
• Network Information Services (NIS and NIS+) Guide (EN): статья с дополнительной информацией о NIS.
  
  
• Managing NFS and NIS by Hal Stern (O’Reilly & Associates, Inc., ISBN 0-937175-75-7): полезная книга по этой теме.(EN)
  
  
• Another good reference is the Unix System Administration Handbook by Evi Nemeth et al. (Prentice Hall, ISBN 0-13-151051-7): еще одна полезная книга.(EN)
  
  
• Раздел developerWorks AIX and UNIX содержит сотни информативных статей для читателей начальной, средней и высокой квалификации.
  
  
• Блоги developerWorks.(EN)
  
  
• Команда IBM developerWorks проводит по всему миру сотни бесплатных технических консультаций.(EN)
  

Об авторе

		Шив Дутта (Shiv Dutta) - старший инженер-программист в группе IBM System And Technology Group; он оказывает помощь независимым производителям программного обеспечения в адаптации их программ на платформе System p. Шив был одним из соавторов справочника Красная книга (redbook) AIX 5L Differences Guide Version 5.3 Edition (Новое в AIX 5L версии 5.3). Вы можете связаться с ним по электронной почте sdutta@us.ibm.com.

Выскажите мнение об этой странице

Пожалуйста, найдите минутку и заполните форму, чтобы повысить уровень сервиса. Помогла ли данная информация достичь Вашей цели? Да Нет Не знаю   Пожалуйста, напишите комментарий, чтобы мы могли улучшить данную страницу:   Насколько полезна эта информация? (1 = Бесполезна, 5 = Очень полезна) 1 2 3 4 5

Поделиться этой статьей: забобрить сохранить в memori

В начало