Рассказ про работу системного администратора в Yandex

Хочу поделиться своей находкой - прекрасным рассказом про работу системного администратора от Дмитрия Куликовского из компании Yandex.

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

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

Я смотрел на скорости 1,5х, вполне реальная скорость для этого видео.

Автор: Шиболов Вячеслав Анатольевич

Саповские секретики - VII

Секретик 1.

Транзакция SM50 отображает список рабочих процессов, которые сконфигурированы в текущей SAP инстанции. Количество рабочих процессов разного назначения настраивается через набор SAP параметров вида rdisp/wp_no_*. Нехватка рабочих процессов, в зависимости от типа, приводит к увеличению заданий в очереди ABAP-диспетчера, "зависанию" во время диалоговой работы, задержкам при запуске фоновых заданий и т.п. При чрезмерном количестве рабочих процессов происходит не оптимальное использование ресурсов сервера. Для мониторинга при настройке оптимального количества рабочих процессов инстанции помогут возможности транзакции SM50. На основном экране транзакции на верхней панели есть кнопка "CPU" (рис. 1).

Рис. 1. Начальный экран транзакции SM50.

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

Рис. 2. Отображение реального времени работы рабочего процесса.

Если данное число после 2-4 недель работы инстанции равно 0, значит ABAP-диспетчер ни разу не давал задания данному рабочему процессу. Если вы обнаружили много таких процессов одного типа, то часть из них можно смело удалить. 

Главное не принимайте такое решение на основании короткого времени работы инстанции. Особенно, если у вас есть редкие кратковременные пиковые дни работы системы, а инстанция не пережила такой день после своего старта.

В последних версиях SAP систем, после обновления транзакции SM50, данные временные значения отображаются постоянно.

Секретик 2.

В транзакции SM04 отображается список пользователей, которые выполнили вход в систему на текущей SAP инстанции. Дополнительно, используя данную транзакцию можно проводить мониторинг версии клиентского программного обеспечения SAP GUI, которое использовал пользователь, а так же IP адрес, с которого был выполнен вход в систему. Для этого на панели на основном экране транзакции необходимо войти в настройки варианта просмотра (рис. 3).

Рис. 3. Настройки варианта просмотра экрана в транзакции SM04.

В диалоговом окне добавить поля "Версия GUI" и "IP-адрес" и нажать кнопку "Скопировать" (рис. 4). 

Рис. 4. Настройка видимых полей транзакции SM04.

После этого в соответствующих полях отобразится информация по пользователям, выполнившим вход в систему (рис. 5).

Рис. 5. Информация по версиям SAP GUI и IP-адресам пользователей.

Секретик 3.

Если SAP система работает на операционной системе UNIX-like, Linux в том числе, то будет полезно знать, что у пользователя операционной системы <sid>adm есть ряд настроенных псевдонимов (aliases) для команд. Например,

• cdexe - переход в директорию с SAP Kernel.
• cdpro - переход в директорию с профилями SAP.
• cdDi - переход в директорию текущей инстанции.

Рис. 6. Пример использования alias для пользователя <sid>adm.

Все активные псевдонимы можно посмотреть выполнив команду alias (рис. 7).

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

grep alias .*

Хотите попробовать администрирование SAP системы в операционной системе Linux?
Посмотрите мои новые обучающие пакеты практических заданий.

Предыдущие выпуски:
- Саповские секретики - I,
- Саповские секретики - II,
- Саповские секретики - III,
- Саповские секретики - IV,
- Саповские секретики - V,
- Саповские секретики - VI.


Автор: Шиболов Вячеслав Анатольевич.

Развитие SAP NetWeaver. Структура директорий

SAP NetWeaver 7.0 - SAP NetWeaver 7.0 EHP3

Начиная с первых версий SAP NetWeaver 7.0 (первоначальное название версии 2004s), компания SAP для систем, работающих на Unix-like операционных системах, внедрила новую структуру директорий и файловых систем (рис. 1).

Рис. 1. Структура директорий для систем на базе SAP NetWeaver 7.0.

Файловых систем, монтирование которых необходимо выполнить при подготовке операционной системы к установке SAP системы, только две:

• /sapmnt
• /usr/sap

Первая файловая система является хранилищем общих файлов для всех инстанций SAP системы:

• общие файлы, например, журналы фоновых процессов (директория global), 
• файлы профилей (директория profile), 
• ядро SAP системы (директория exe).

Вторая файловая система содержит отдельную директорию для транспортной системы (trans), общую логическую директорию (SYS) и директории для каждой инстанции SAP системы:

• DVEBMGS<No> - директория для центральной инстанции (CI),
• D<No> - директория для дополнительной инстанции (DI),
• ASCS<No> - директория для инстанции центральных сервисов,
• ERS<No> - директория для Enqueue Replication Server (ERS) инстанции, используемой в отказоустойчивых инсталляциях.

Здесь <No> - номер инстанции, который используется в нумерации портов для доступа к процессам инстанции.
По умолчанию эти директории не создаются. Директория инстанции будет присутствовать в структуре, только если данная инстанция была установлена. 

Вернёмся к директории /usr/sap/<SAPSID>/SYS. Данная директория является в большей степени логической структурой, так как содержит ссылки на реальные директории файловой системы /sapmnt. То есть директории global, profile, run это символьные ссылки на физические директории в другой файловой системе (фиолетовые пунктирные линии на рисунке). На центральную логическую директорию с ядром SAP (/usr/sap/<SAPSID>/SYS/exe/run) указывает параметр SAP системы с именем DIR_CT_RUN. Данная директория является лишь хранилищем для исполняемых файлов ядра, запуска процессов из неё не происходит. Для каждой инстанции системы есть собственная директория с исполняемыми файлами ядра SAP. Например, для центральной инстанции это директория - /usr/sap/<SAPSID>/DVEBMGS<No>/exe. И на эту директорию указывает уже другой параметр - DIR_EXECUTABLE. Вот эти файлы и создают рабочие процессы текущей инстанции.

Зачем же нужно центральное хранилище SAP ядра? Для упрощения поддержки и обновления. Дело в том, что при старте каждой инстанции SAP системы в первую очередь запускается процесс sapcpe, который актуализирует локальные файлы ядра из центрального хранилища. Таким образом, при обновлении SAP ядра системы достаточно только сменить файлы в центральном хранилище (/sapmnt/<SAPSID>/exe), а остальную работу за вас выполнит программа sapcpe. При работы программы создаётся журнал sapcpe.log, который можно найти в локальных work-директориях инстанций. Процесс актуализации ядра SAP инстанций на рисунке 1 отображён пунктирными стрелками черного цвета.

SAP NetWeaver 7.10 - SAP NetWeaver 7.40

Начиная с версии SAP NetWeaver 7.10, структура директорий изменилась. Основная цель изменений - упрощение поддержки гетерогенных установок, когда в системе используются SAP ядра для различных платформ (рис. 2).

Рис. 2. Структура директория для систем на базе SAP NetWeaver 7.10.

Изменения коснулись лишь директории с SAP ядром. В ней появились следующие поддиректории:

• jvm - содержит файлы виртуальной машины JAVA от SAP (используется с 2011 года),
• uc/<platform> - содержит исполняемые файлы для Unicode ядра конкретной платформы (например, linuxx86_64),
• nuc/<platform> - содержит исполняемые файлы для Non-Unicode ядра конкретной платформы.

Количество символических ссылок из директории /usr/sap/<SAPSID>/SYS тоже увеличилось. Концепция при этом осталась прежней: центральное хранилище исполняемых файлов в файловой системе - /sapmnt, а /usr/sap/<SAPSID>/SYS лишь логическая структура с ссылками.

В SAP note # 1104735 - Upgrade to the new instance-specific directory on UNIX описана процедура перевода системы на новую структура директорий при обновлении с ранних версий SAP NetWeaver.

SAP NetWeaver 7.5

Здесь нововведений не так много. Если вы читали пост "Развитие SAP NetWeaver. ASCS инстанция", то помните, что c версии SAP NetWeaver 7.3 произошло переименование инстанций. Это и отразилось в структуре директорий, начиная с версии SAP NetWeaver 7.5 (рис. 3).

Рис. 3. Структура директорий для систем на базе SAP NetWeaver 7.50.

Теперь директории D<No> могут содержать файлы или Primary Application Server (PAS) или Additional Application Server (AAS).

Реальный пример структуры директорий на системе SAP ERP 6.0 EHP8 (основана на SAP NetWeaver 7.50) можно посмотреть на рисунке 4.

Рис. 4. Пример структуры директорий на системе SAP ERP 6.08.

Предыдущие статьи рубрики:
- "Развитие SAP NetWeaver. ASCS инстанция".
- "Развитие SAP NetWeaver. Start profile".
- "Развитие SAP NetWeaver. Мандант 066".


Автор: Шиболов Вячеслав Анатольевич

Принудительное отмонтирование NFS файловых систем на HP-UX

Network File System (NFS), протокол сетевого доступа к файловым системам, является прекрасным изобретением. В мире Unix это стандартное решение задачи подключения файловой системы с одной операционной системы на другую. Раздающая операционная система называется сервером. Принимающая, в данном случае монтирующая, сторона - это клиент. Когда сервер и клиент настроены должным образом, взаимодействие протекает прекрасно. Причем, для клиента файловая система часто ничем не отличается от локальной.
Даже в Windows можно активировать поддержку этого протокола.

Наверное из-за такой прозрачной интеграции часто возникают коллизии и недопонимания при настройке NFS. Помните, я писал про важность синхронизации времени на сервере и клиенте?

В конце прошлого года я столкнулся с ещё одной интересной ситуацией. Эта интересная ситуация лишила меня покоя на 3 дня. :) Сейчас всё расскажу по порядку.

Сервер, работающий на операционной системе HP-UX 11.11. Версия старая, согласен, но работает хорошо. И, как говорится, что есть, с тем и работаем. Так вот, данный сервер, в разрезе NFS является сервером, раздавая часть своих файловых систем для других систем, и одновременно клиентом, монтируя пару файловых систем по протоколу NFS с других серверов.

В один момент времени один из серверов, файловую систему с которого наш герой монтировал, пропал. За сервер отвечает третья сторона, поэтому причины падения я не знаю. Но сервер с HP-UX повёл себя следующим образом. Файловая система просто "зависла". Зависали любые попытки перейти в директорию, которая является точкой монтирования злополучной NFS файловой системы, операции-попытки прочитать таблицу файловых систем (команда bdf), команды просмотра содержимого файловой системы и тому подобное.

Команда umount файловой системы не проходила, отвечая, что файловая система "занята" процессами системы: "nfs umount: nfs_unmount: /path: is busy".

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

Зная, что команды bdf, fuser висят по моей вине, я нашёл их в таблице процессов командой вида:

# ps -ef | grep bdf

Все они стали сиротами, то есть родительский процесс у них заменился процессом init: PPID=1.

Но на моё удивление, попытки послать им команды останова вида:

# kill -9 PID

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

Дальше, стало еще интереснее. Третья сторона, после сообщения им, что их NFS ресурс не отвечает, отработала и ответила, что сервер восстановлен. Но, у меня на стороне NFS клиента ничего не изменилось! Файловая система не отвечает, наглухо зависнув. В таблице процессов список уже из 7-8 сирот, которые пытались попасть на файловую систему с моей подачи.

При этом, команды ping на сервер проходят, команда вида:

# telnet 2049

где 2049 это NFS порт, отрабатывает корректно. Даже команда запроса экспортируемых файловых систем с NFS сервера (showmount -e IP_NFS_server) отрабатывает! А попытка выполнить монтирование этой файловой системы во временную точку монтирования (/tmp/tmp2) не удаётся! (рис. 1).

Рис. 1. Попытки достучаться до NFS-сервера.

Не верить специалистам третьей стороны у меня причин не было. Занимаясь поиском путей решения на специализированных форумах в Интернете, я всё больше и больше убеждался, что проблема в HP-UX, то есть в NFS клиенте.

Выбрав период, когда я смогу устроить небольшой downtime для монтируемых по NFS файловых систем, я решил попробовать рестарт демонов nfs.client. Демон остановился и стартовал корректно, но отмонтировать данную файловую систему не смог. "nfs umount: nfs_unmount: /path: is busy" - ответила система. :) Рестартовать все NFS-процессы (серверные и клиентские) я не мог из-за использования текущего сервера, как NFS-сервера.

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

Так же я узнал, что в данной ситуации команда bdf в силу своей особенности не рекомендуется (зависает), лучше использовать:

# mount -v 

А команде fuser надо в качестве аргумента давать не локальную точку монтирования, а путь до NFS сервера + директорию:

# fuser IP:/path

Такой вариант команды fuser у меня не зависал, отрабатывал, но ни одного процесса не находил. Да, и по предыдущему опыту я знал, что спящие процессы сигналы от команды kill не принимают.

Замкнутый круг. Примерная картина мне была понятна, но решения не было. Я всё больше и больше с тяжёлым сердцем думал о перезагрузке всей операционной системы.

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

Знаете пословицу: одна голова хорошо, а две лучше? Иногда одна лишь попытка описать проблему, систематизировав все симптомы, помогает. Но чаще, другой человек, со своим свежим взглядом на то, над чем ты бьёшься несколько дней, задаёт новые вопросы, предлагает новые пути решения, а иногда и даёт готовое решение. В этой ситуации для меня стал таким человеком мой коллега (Сергей Шевелёв). Готового решения он мне не дал, но нашел для меня документ "Forcible Unmount NFS filesystems", в котором была описана моя проблема и пути решения.

В данном документе инженер HPE, признавал проблему, описывал ситуации когда она может возникнуть и, если кратко, давал следующие советы:

1. Применять команду fuser не на точку монтирования, а на NFS-путь, о чём я писал выше.
2. Иногда бывает достаточно несколько минут подождать, пока процессы остановятся по timeout и отпустят файловую систему.
3. Создать временный суррогатный NFS сервер, чтобы процессы, которые держат файловую систему получили отклик и остановились с ошибкой.

В документе автор признаёт, во-первых, что такая проблема зависших NFS файловых систем существует в HP-UX. Во-вторых, что в текущих релизах HP-UX (до версии 11.23) официального решения нет. Что в версию HP-UX 11.31 добавят опцию "-f" в команду umount, по которой будет производиться принудительное отмонтирование NFS файловых систем без ожидания освобождения их со стороны процессов системы. Такая опцию, к слову, есть в других операционных системах.

Прочитав этот основательный документ (15 страниц), я попробовал создать суррогатный NFS сервер прямо на текущем сервере. Процедура следующая:

1. Необходимо определить IP адрес NFS сервера, который упал. Для этого смотрим вывод команды mount -v, а потом nslookup NFS_server_hostname.
2. Находим сервер, на котором поднят nfs.server и смотрим доступные сетевые интерфейсы командой netstat -in. В идеале можно использовать сервер, который является NFS клиентом.
3. На интерфейсе, который входит в ту же сеть, что и пропавший NFS сервер, поднять суррогатный сервер, выполнив команду вида: ifconfig lanX:1 IP_NFS_server. Здесь lanX - название необходимого сетевого интерфейса, а "1" - второй IP адрес на этом интерфейсе.
4. Пробуем размонтировать файловую систему, дав если придётся, небольшой timeout процессам, которые удерживают файловую систему.
5. После успешного отмонтирования файловой системы, удаляем суррогатный NFS-сервер, командой вида: ifconfig lanX:1 0.0.0.0.

Как только я поднял на одном из сетевых интерфейсов моего сервера IP адрес NFS сервера, все спящие процессы (bdf, fuser и другие) тут же отвалились (скорее всего с ошибками). После этого корректно отработала команда:

# umount IP:/path

И я смог вздохнуть с облегчением, удалив суррогатный сервер.

Спустя какой-то период времени файловая система настоящего NFS-сервера корректно примонтировалась, то есть операционная система увидела его, выйдя из заколдованного круга.

Получилось очень многословно, поэтому буду заканчивать. В документе от HPE разложено всё по полочкам, объяснены такие моменты как:

• почему команда fuser не выдает в результатах процессы, хотя файловая система занята (виноват buffer cache memory),
• чем плохо использование команды umount с опцией "-f" для принудительного размонтирования,
• почему зависшие процессы не реагируют на команду kill -9 (процессы ждут I/O, а значит уходят на непрерываемый уровень ядра операционной системы),
• какие меры можно принять, чтобы похожая ситуация возникала реже (установка патчей на операционную систему, в особых ситуациях использование метода "soft" при монтировании NFS файловых систем и т.д.).

Допускаю, что в современных Unix-like операционных системах такого безобразия нет, но у кого HP-UX рекомендую скачать и ознакомиться с документом. Предупреждён, значит вооружён. :)

Скачать документ можно по ссылке на официальном сайте HPE.


Автор: Шиболов Вячеслав Анатольевич

Многотомный самораспаковывающийся RAR-архив от SAP

Я настолько стар, что помню времена, когда компания SAP присылала заказчику большую красивую коробку с компакт-дисками (сначала это были CD-ROM, потом DVD), с которых можно было установить все купленные системы. Сейчас, вполне возможно, диски тоже можно заказать. Но, с развитием скоростей сети Интернет и уходом DVD-приводов в прошлое, они мало кому нужны.

Достаточно установить SAP Download Manager, указать в настройках S-user своего договора и можно смело закачивать дистрибутивы, которые входят в договор, сколько угодно раз.

Образы установочных дисков, которые раньше тоже были размером с CD-ROM, теперь ограничены размером 4 Гб. Большинство образов идёт в виде ZIP-архивов. Данный формат я считаю универсальным форматом для распространяемых по сети архивов. К тому же, современные версии Windows (начиная с Windows XP) умеют работать с этим форматом "из коробки".
Но особо большие образы, а сюда относятся файлы экспорта базы данных, исполняемые файлы СУБД Oracle, часто идут в "многотомных самораспаковывающихся RAR архивах". И если в Windows открыть такой архив не проблема - двойной клик левой клавиши мыши на первый файл с расширением exe и можно идти пить кофе. Распаковка выполнится без стороннего ПО и займёт немного времени. :) То в Unix системах не всё так просто.

Меня удивляет еще такой момент. Даже образы дистрибутива СУБД Oracle для Linux идут в таком же "многотомном самораспаковывающемся RAR архиве"! Почему!? Как?! Зачем?! :)

Часть вопросов я опущу и спишу на "так сложилось исторически" или "так им там удобнее", а попробую ответить на один вопрос - "Как?".

В Unix системах для распаковки таких архивов надо установить unrar (freeware). Где-то он обычно уже есть. Например, в Suse Linux его можно установить соответствующей командой (рис. 1).

Рис. 1. Установка пакета unrar в Suse Linux.

После этого для распаковки нашего "многотомного самораспаковывающегося RAR архива" достаточно дать команду вида: unrar x и указать имя первого файла с расширением exe (рис. 2).

Рис. 2. Распаковка много-томного RAR архива в Linux.

После этого можно пойти пить кофе. Ну, а если вам не повезло и у вас очень быстрый и мощный сервер, то распаковав архив, работать дальше. :(

Стоит еще добавить, что файлы распакуются в текущую директорию.

Подробности можно найти в SAP note 886535 - Downloading multispanning archives (RAR archive).


Автор: Шиболов Вячеслав Анатольевич

Пример проблемы при переполнении файловой системы

Хочу описать небольшую ситуацию, которая является примером проблемы администратора и её решения (troubleshooting). Утром одна из систем была обнаружена в недоступном для пользователей состоянии. Анализ показал, что инстанция SAP запущена, а база данных Oracle нет. После старта базы данных система стала доступна для работы, а последующий анализ показал, что не завершился ночной оффлайн бэкап базы данных. Про резервное копирование я писал в посте "Резервное копирование SAP системы". 

Так как при оффлайн резервировании база данных Oracle на время копирования данных останавливается, то утром она была обнаружена как раз в остановленном состоянии.

Анализ журналов копирования показал ошибку при старте базы данных после резервирования: при записи журналов не хватило места на какой-то файловой системе сервера (рис. 1).

Рис. 1. Ошибка в журнале оффлайн резервирования базы данных Oracle.

Тут стоит вспомнить один из моих недавних постов "Анализ места на диске в Unix". Вооружившись советами из статьи и командами bdf и du, можно легко обнаружить, что в домашней директории Oracle закончилось свободное пространство. Много места занимает директория с журналами (log), а именно журнал процесса Listener (рис. 2 и 3).

Рис. 2. Вывод команды bdf.

Рис. 3. Анализ размера директорий в файловой системе.

Тут опять же, стоит вспомнить пост "Старые журналы событий SAP и ORACLE", в котором я упоминал про этот журнал. Данный журнал хранит информацию о соединениях процессов SAP с Oracle. Смело очищаем и высвобождаем место (рис. 4).

Рис. 4. Удаление содержимого журнала listener.log.

После этого проблема решена. 

Стоит отметить, что при настроенном мониторинге (например, через CCMS мониторинг) такой проблемы бы не возникло. 

Первая задача администратора: сделать так, чтобы всё заработало. 

Вторая задача: разобраться в ситуации, выяснить причины ошибки и выполнить шаги, чтобы не допустить повторение ошибки в будущем. 

Автор: Шиболов Вячеслав Анатольевич

Опрос: Windows vs Unix

Предыдущий опрос про опыт администрирования SAP систем завершён. Результаты и обсуждение тут.

Предлагаю новый опрос. Представьте, что необходимо установить продуктивную SAP систему. Согласно PAM возможна установка на операционные системы семейства MS Windows и Unix-подобные (Linux, AIX, HP-UX и т.п.). Никаких особых ограничений ни в одной, ни в другой операционных системах со стороны SAP нет.
Что вы выберете для продуктивной системы? Ваше личное мнение. Анонимно. :)

Опрос завершён. В опросе приняло участие 44 человека. Всем спасибо за участие.

Итоги получились ожидаемыми: с большим отрывом победили Unix системы (рис. 1).

Рис. 1. Результаты опроса.

Моё личное мнение совпадает с мнением большинства. Я бы тоже выбрал Unix-подобную операционную систему. По объективным и субъективным причинам. Люблю я их. :)

Хотя чаще надо выбирать головой. Например, учитывать при выборе факт наличия навыков и опыта работа с операционной системой у администраторов и политики компании.

В пользу Linux стоить отметить тот факт, что база данных SAP HANA, которую компания разрабатывает уже 5 лет, работает только на Linux. На Windows они её так и не портировали.

Распределение участников опроса по странам, если кому интересно, можно найти на рис. 2.

Рис. 2. Участники опроса по странам.

Автор: Шиболов Вячеслав Анатольевич

Анализ места на диске в Unix

Как вы знаете из поста "35 лет или как я попал в SAP", я начинал свою профессиональную карьеру с администрирования Unix систем. И я обожаю Unix. Во всём многообразии систем, называемых Unix-подобными, мне нравится ядро, концепция, которая лежит в основе их всех, начиная от AIX и заканчивая Linux.

Сегодня хочу остановиться на файловой системе.

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

В Windows, в отличии от Unix, понятие файловой системы не выходит на первый план. Есть набор дисков, которые подключены к компьютеру или серверу. Каждый диск имеет привязку к букве латинского алфавита. Без этой привязки работать с диском операционная система не сможет. А уже внутри диска создается файловая система. В Windows это может быть FAT, HPFS или NTFS. Подробности про них можно посмотреть тут.

Рис. 1. Пример жестких дисков в операционной системе Windows.

В Unix есть единый корень файловой системы: "/" (root). Это начало всего. Не зря суперпользователь в Unix так же носит имя "root". Все остальные файловые системы монтируются, как ветки общего дерева.

Это ещё не всё. Все объекты в Unix это файлы. С точки зрения программиста, программа обращается к файлу с помощью четырех системных вызовов: open(), read(), write() и close(). Таким образом, всё, с чем можно работать через данные вызовы, это файлы. Хотя, например в Linux, файлы в каталоге /proc не существуют физически. Это лишь представление внутренних данных ядра в виде файлов. Но работать с ними можно как с файлами. Это просто, универсально и удобно.

В операционной системе Unix есть следующие типы файлов:

• обычный файл (или жесткая ссылка),
• каталог,
• символическая ссылка,
• блочное и символьное устройства,
• именованный канал и доменный сокет Unix.

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

Каталоги это тоже файлы. Файлы, содержащие список имён файлов с ссылками на inode (рис. 2). 

Рис. 2. Схема хранения файлов в Unix.

Inode хранит атрибуты файла, такие как тип файла, владелец, группа, права доступа, временные метки, и указатели на блоки данных. Про права доступа в Unix я писал в посте "Oracle + Unix: полномочия на директории". Пока на inode файла существует хоть одна жесткая ссылка, файл удален не будет. Стоит еще отметить, что таблица inodes существует в рамках файловой системы и жесткие ссылки могут быть созданы только внутри одной файловой системы.

Для указания на файлы из других файловых систем существуют символьные ссылки. Которые не что иное, как просто указатель на существующий файл в каком-либо каталоге. Пример использования символьных ссылок на файлы устройств для ленточной библиотеки я описывал в посте "Подружить кластер и brbackup/brarchive".

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

Именованные каналы и сокеты используются для организации взаимодействия между разными программами.

Тип файла отображается в результатах команды ls, в виде первого символа перед правами доступа (рис. 3).

Рис. 3. Пример вывода команды ls.

Прочерк - признак обычного файла, d - каталога, l - ссылки и так далее.

Команда find, про которую я рассказывал в посте "HP-UX. Многоликая команда find", может помочь найти те или иные типы файлов. Например, сокеты (рис. 4).

Рис. 4. Пример вывода результатов поиска сокетов Unix.

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

В посте "Файл-пустышка" я уже затрагивал эту тему применительно к одной директории. Я рассказал как создать небольшую заглушку в директории, содержащей оффлайн журналы Oracle. Чтобы в случае заполнения файловой системы до 100% срочно освободить немного места одной командой. В ситуациях отсутствия необходимого пространства в данной директории - это место нужно, как глоток свободного воздуха. Иначе база данных Oracle просто "подвиснет", как и SAP система, которая работает на ней.

Просмотреть место в файловых системах поможет команда df (рис. 5).

Рис. 5. Пример вывода команды df в операционной системе Linux.

Данная команда показывает общее количество блоков (1 Кб), занятых (в Кб и процентах) и свободных блоков по каждой смонтированной файловой системе.

В операционной системе HP-UX более читабельной является команда bdf (рис. 6).

Рис. 6. Пример вывода команды bdf в операционной системе HP-UX.

Если свободное пространство где-то резко уменьшилось, то необходимо выяснить кто и чем его занял. В этом случае поможет команда du. Например,

 # du -ks ./* 

отобразит все каталоги в текущей директории и занимаемое ими пространство в файловой системе в Кб (рис. 7). Опция -k - отображает результаты в Кб, а ключ -s - диктует отображать только суммарное значение занимаемого пространства по каждой директории.

Рис. 7. Пример списка каталогов в директории /var с их размерами.

Еще очень хороший вариант (рис. 8):

 # du -xks / 

Рис. 8. Пример вывода команды, отображающей занимаемое пространство в корневой файловой системе.

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

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

1. С помощью команд df (bdf) проанализировать файловые системы и свободное пространство в них.
2. Перейти в необходимую файловую систему и проанализировать пространство, занимаемое каждой директорией, с помощью команды du с необходимыми опциями.
3. Спуститься по дереву каталогов до конца, собрав информацию по пространству.
4. Принять решение по удалению файлов, если это возможно, или расширению файловой системы.

Так же для поиска старых, самых больших или определённых файлов (например, дампов core) можно воспользоваться командой find, про которую я писал в посте "HP-UX. Многоликая команда find".

Дополнительные ключи и опции команд Unix или Linux всегда можно найти в справке man, набрав команду вида:

 # man <command_name> 

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

Автор: Шиболов Вячеслав Анатольевич

Oracle + Unix: полномочия на директории

Все кто сталкивался с операционными системами семейства Unix знают, что базовые полномочия на файлы/директории разделяются на 3 группы:

• для владельца файла/директории,
• для группы, которой принадлежит файл/директория,
• для всех остальных пользователей системы.

Полномочия можно получить на три типа операции: чтение (read), запись (write) и выполнение (execute) для файлов и переход в директорию для директорий. Кратко они записываются по первым буквам английских понятий: rwx. Последовательность именно такая. Сложив все 3 группы, имеем:

rwx rwx rwx

Например, права на чтение и запись для владельца и группы и запрет всего для остальных пользователей (рис. 1).

Рис. 1. Пример полномочий на файл в Unix.

Существует правило преобразования символьного обозначения в цифровое. Записываем разрешение в виде битов. Например, в приведенном примере это: 

rw- rw- --- = 110 110 000 = 6 6 0 = 660

То есть, выставляем биты-разрешения и получаем 3 числа в двоичном исчислении. Записываем их в десятичном и получаем результат. Кто-то считает по другому r = 4, w = 2, x = 1, а затем просто складывает. Хотя, по-моему по-админски, это считать в двоичном исчислении.

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

 # chmod 660 ./log_g11m2.dbf 

Теперь, к делу. При использовании системы SAP в связке с базой данных Oracle в Unix-подобной операционной системе на ряд директорий и файлов, которые составляют в совокупности экземпляр (инстанцию) базы данных, необходимо установить и поддерживать правильный набор полномочий. Корректные полномочия обеспечивают базовый уровень безопасности системы и бесперебойную работу системы и утилит BR*Tools, про которые я рассказывал в постах: "Утилиты для администрирования ORACLE в SAP. Часть I" и "Утилиты для администрирования ORACLE в SAP. Часть II". Итак, памятка по полномочиям:

Рис. 2. Полномочия на директории Oracle в Unix.

Дополнительная информация:

- страница SAP Help Portal с полномочиями,

- небольшая инструкция о том, как их устанавливать.

Автор: Шиболов Вячеслав Анатольевич

Учебный курс в HPE: H7091S - Enterprise Linux Systems Administration

С 26 по 30 июня в учебном центре Hewlett-Packard Enterprise я прослушал курс по администрированию корпоративных Linux систем. Полное название курса - H7091S - Enterprise Linux Systems Administration (код GL250).

Последний раз на обучении в HP я был в 2004 году. Тогда офис компании располагался рядом с московским офисом SAP - на Космодамианской набережной. Сейчас они уже давно базируются рядом с метро Войковская, в бизнес-центре "Метрополис".

Учебный центр соответствует всем стандартам. :) Чай, кофе, молоко, вода. Удивило большое количество травяных видов чая: чабрец, мята, ромашка, шиповник. Можно было заварить с мёдом, который был там же. Кофе, чего я еще не видел, варят бесплатные автоматы (рис. 1).

Рис. 1. Меню кофейного автомата.

Жалею, что не попробовал, что скрывается за надписью кисель. :) В далекие 2000-е еще были печеньки в неограниченном доступе, но сейчас времена другие. На обеды выдают продуктовую валюту в размере 300 рублей/сутки. Принимают её в нескольких кафе вокруг бизнес-центра (рис. 2).

Рис. 2. Продуктовые карточки в учебном центре HPE.

Курс читал Прилипко Георгий Алексеевич. В 2003 году я у него слушал курс по LVM, MirrorDisk и файловой системе JFS (код H6285S). На сколько я понял, преподавательский состав - это давно сформировавшаяся команда "зубров", стойко читающая курсы уже много лет. Очень приятно было встретить в учебном центре Максима Мошкова. Я считаю его лучшим преподавателем, которого я когда либо видел. Он сейчас читает курсы по VMware. Максим уже не так молод, как был в 2003 году, когда я слушал у него курс по MC/ServiceGuard, да и я уже изменился. :) (рис. 3). Если кто не узнал, то на фото Максим с бородой, а я крайний слева.

Рис. 3. Курс в HP в 2003 году.

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

Очень понравились материалы курса. Курс посвящен администрированию корпоративных Linux систем, а это Red Hat Enterprise Linux и SUSE Linux Enterprise Server. Версии в курсе рассматривались последние: 7-я для RHEL и 12-я для SLES. Материал построен так, что освещает и общие моменты, и нюансы обеих систем. В качестве тренировочной системы была развернута CentOS, которая фактически является бесплатным клоном RHEL. К клону RHEL, кстати, можно отнести и Oracle Linux, который поддерживается для установки систем SAP. Получаем полный охват всех Linux систем, которые нужны администратору SAP систем. Практические задания отличные, широкие возможности делать с системой всё что хочется. :) Дистрибутив, кстати, тоже можно было поменять и спокойно делать лабораторные задания, для SLES они тоже были описаны.

Кроме официальных материалов Георгий Алексеевич раздал всем слушателям копии своих собственных заметок по Unix/RHEL на 24-х страницах.

Некоторые комментарии, мысли и советы от Георгия Алексеевича (через мои заметки).

Если говорить о выборе дистрибутива, то SUSE Linux ближе к классическому Unix, чем Red Hat. Так же он более "дружелюбен" к системному администратору.

Unix, в отличии от Windows, познаваемый. Потому что база одна для разных дистрибутивов и остается от версии к версии.

Была система MULTICS, написали UNICS, которая была не для больших машин. "CS" - Computer Systems. Потом превратилась в UNIX.

Задача системного администратора - минимизировать действия администратора для обеспечения работоспособности системы.

Команды помогающие определить местоположение на машине:
# pwd
# id
# tty
# uname -a
# echo $DISPLAY

Как посмотреть релиз Linux:
# grep -i linux /etc/*-release

Рекомендации:

• при установке чего-либо по инструкции ставить галочки напротив выполненных пунктов.
• использовать sudo -i вместо su - , потому что sudo сохраняет все действия в журналы.
• символьные линки надо делать относительными, а не абсолютными от корня, чтобы они работали при смене корня, например, по NFS.
• создать alias "rm = rm -i" для борьбы от случайного удаления содержимого всей файловой системы.
• логи надо чистить командой # > file, так как эта команда просто перемещает указатель на начало файла, иначе можно не угадать с полномочиями на файл и, память не освободится пока процесс не закончит писать в файл.
• при использовании GRUB2 - ставить пароль на изменения GRUB, иначе можно попасть в систему без пароля root.
• для проверки файлов password+shadow использовать # pwck, group+gshadow - # grpck.
• файл /etc/shells содержит все shell скрипты, которые могут быть присвоены пользователю.
• # type <cmd_name> - показывает cmd_name это alias или команда.
• # find / -perm -4000 -ls -- поиск файлов с битом "s" на полномочиях.
• # find -type l  -- поиск символьных линков.
• # grep -v -e "^$" -e "^#" -- показывает из текстового файла непустые строки и не строки комментариев.
• # tail -f file&  -- можно запустить отображение нескольких журналов по мере поступления сообщений в одном терминале.

Менеджер устройств udev имеет правила в /etc/udev/ и /usr/lib/udev/. Поиск начинается с /etc/,

а в /usr/lib/ попадают правила из пакетов. Поэтому редактировать правила надо в /etc/dev/. Чтобы отменить правило, нужно создать пустое правило в /etc/dev/.

Создание копий /etc/ и /dev/:
# cd /
# find etc dev | cpio -pmvdn /s

У каждого файла свой inode, который уникален внутри файловой системы. Директория это файл со списком имен и inodes.

# lsmod - список подключаемых модулей ядра Linux.

NVidia поддерживается лучше, чем ATI/AMD. Тут не уверен, что информация не устарела. :)

Чтобы отправить команду в фон: Ctrl + Z и # BG %1
команда # jobs - список работающих фоновых заданий.

# yum clean all - приводит в порядок базу RPM, чистит временные каталоги в /var/, которые использует RPM/YUM.

Файл /proc/partitions - это то, что видит ядро.

# unidgen -- генератор уникальных номеров.

Если fsck не проходит, то можно попробовать примонтировать только на чтение командой вида # mount -o ro

5% в файловой системе резервируется для процессов root, чтобы он мог писать даже, если avail = 0%.

При монтировании по NFS, по-умолчанию, root становится nfsnobody (Red Hat) или nobody (SLES).

В целом, я получил от курса, что планировал: нюансы администрирования RHEL и SLES, в отличии от HP-UX, который я активно изучал, но который похоже становится историей. К тому же, цена, в отличии от курсов компании SAP, очень демократичная.

Автор: Шиболов Вячеслав Анатольевич

Навыки SAP BASIS администратора - II

В первой части статьи я начал разговор про классификацию навыков, необходимых SAP BASIS специалисту. На первом уровне были выделены 3 крупных подмножества:

• аппаратное обеспечение и операционные системы,
• базы данных,
• SAP NetWeaver.

Сегодня рассмотрим первое подмножество.

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

• аппаратное обеспечение,
• операционные системы.

В аппаратном обеспечении выделим 5 пунктов:

• Серверы - навыки, связанные с архитектурой серверных решений, запуском, остановом и базовыми знаниями по конфигурации и модернизации. Вендоров много, поэтому тут навыки набираются по мере работы с серверами. Например, линейка Blade серверов от HP.
• Системы хранения данных - навыки и знания, связанные с дисковыми массивами и различными решениями по хранению данных: архитектура решений от различных вендоров, какие типы дисков бывают и чем они различаются, типы RAID и так далее. Примером может служить мой пост "Особенности работы HP EVA-5000".
• Sizing - навыки по определению оптимальной конфигурации оборудования для работы SAP системы перед установкой или в процессе эксплуатации для рассмотрения необходимости модернизации оборудования.
• Виртуализация - знания, связанные с виртуализацией аппаратного обеспечения. Сейчас очень популярная тема. Облачные технологии это по факту развитие той же виртуализации.
• Кластерные технологии очень важны при построении отказоустойчивых систем высокого уровня надежности. Например, решения от компании HP, описанные мною в этом посте.

В части операционных систем всё просто. Разделим все операционные системы, на которых могут работать SAP системы, на два больших лагеря:

• Windows (конечно же это семейство MS Windows Server, а не декстопные решения),
• Unix-like - сюда относятся все коммерческие Unix системы, поддерживаемые SAP (HP-UX, AIX, Solaris и т.д) и Linux.

Linux системы на данный момент поддерживаются от 3-х вендоров:

• Suse - SUSE Linux Enterprise Server,
• Red Hat - Red Hat Enterprise Linux,
• Oracle - Oracle Enterprise Linux.

Напоминаю, что все поддерживаемые архитектуры и операционные системы для каждого решения SAP можно найти в PAM (Product Availability Matrix). Пост про это можно прочитать по ссылке.

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

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

Как вы помните, в первой части я приводил описания различных технических специалистов из методологии ASAP. У каждой специализации своя глубина тех или иных навыков. Здесь такая же картина. Глубина знаний может быть разной и, как вы понимаете, глубокая специализация в плане аппаратного обеспечения и операционных систем не так важна для SAP BASIS администратора, как, например, навыки в администрировании SAP NetWeaver. Всё зависит прежде всего от решаемых задач.

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

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

Знания по данному направлению можно получить из обучающих семинаров вендоров "железа" и операционных систем.
По операционным системам информация более открыта: по каждой из версий можно найти книги или Интернет-ресурсы.
По "железу" информация более закрытая. Это следствие того, что вендоров много, решений еще больше, к тому же у каждого вендора идет постоянная смена линеек продуктов и решений. Как следствие, эта информация не так широко востребована, как, например, по операционным системам. Но тут есть и положительная сторона: нет смысла изучать решения, с которыми вы не столкнётесь в ближайшем будущем. Как только компания, в которой вы работаете, решила закупить какое-то аппаратное решение, на котором будет работать SAP система, проситесь на курсы. К тому же, часто они идут "в подарок" к основной закупке "железа".


Автор: Шиболов Вячеслав Анатольевич

Just for Fun. Рассказ нечаянного революционера

Моё первое мимолетное знакомство с операционной системой Linux произошло во времена моей учебы в институте, когда один из преподавателей включил в свой курс информацию по современным на тот момент процессорам и операционным системам.

Как я уже писал в одном из постов, в администрирование SAP систем я ввязался только в 2002 году. А до этого меня привлекали операционные системы, и Unix в частности.

Так вот, когда я учился в институте информацию приходилось добывать по крохам, доступа к сети Интернет у меня тогда не было. Поэтому на Linux в институте я внимания не обратил, да и эта ОС тогда только становилась на ноги. Зато после, когда я устроился на свою первую основную работу, я оценил все его прелести, установив себе на рабочие станции на работе и дома Alt Linux.

В 2004 году, когда я переехал в Москву, я окончательно им заболел, читая запоем книги о нём, устанавливая различные дистрибутивы на личный и рабочий компьютеры. Помню, долго моим любимым дистрибутивом был Slackware. Дистрибутив, к слову, до сих пор живой (Слава Патрику!). О, сколько раз я сносил разделы и ломал разметку своего диска, играясь с загрузчиком и пробуя различные версии дистрибутивов. :)

Одна из первых книг, которую я с удовольствием купил и прочитал, была "Just for Fun" Линуса Торвальдса и Дэвида Даймонда. Книга рассказывает о финском хакере (увлеченном программисте), который в своей каморке создал ядро Linux.

Недавно я перечитал эту книгу. Только перечитывая книги, я вдруг понимаю, как я поменялся за последние 5-7-10 лет. Некоторые вещи воспринимаются совершенно по-другому. Некоторые книги, например, материалы SAP курсов, воспринимаются с новой глубиной. При первом прочтении обычно пытаешься уяснить основную идею, понять общую картину. При повторных прочтениях глаз натыкается на интересные детали, фишечки, нюансы. Появляется глубина.  А иные книги читаешь повторно, как в первый раз. Так было и в этот раз. Основная история мне знакома, а вот нюансы, детали заиграли новыми красками.

Кусочки из книги:

1. Смысл жизни от Линуса Торвальдса:
   
   "    В жизни  важны всего три вещи.  Они движут и тобой, и любой живой  тварью:  первая - выживание, вторая - общественный уклад,  третья - удовольствие. Все в жизни проходит  через эти три этапа. Причем после удовольствия  уже ничего нет. Отсюда  вывод: смысл  жизни - достичь третьего этапа. Достиг его - и дело  в шляпе. Но сперва - пройди два предыдущих."



2. Описание концепции Unix (потрясающе описано, на мой взгляд):
   
   "    Unix характерна тем, что она утверждает некоторые базовые ценности. Это цельная и красивая операционная система. Она избегает особых случаев. В Unix есть понятие процесса: процесс - это все, что что-нибудь делает. Простой пример. В Unix команда оболочки, которую  вводят, чтобы  войти в систему, не встроена в операционку, как в DOS. Это просто задание. Ничем не отличающееся от остальных. Просто это задание читает с клавиатуры и пишет на монитор. В Unix все, что что-то делает, - процесс. А еще там есть файлы.
       Простота структуры Unix всегда поражала меня, как и  большинство  людей (ну по крайней  мере - нас, хакеров). Почти все, что делается  в Unix, выполняется  с  помощью шести  базовых операций (называемых "системными вызовами", потому что они представляют из себя вызовы системы для выполнения тех или иных действий), А уж из этих шести  базовых  вызовов можно построить почти все на свете.
       Одной из фундаментальных операций Unix является "операция  порождения (fork)".  Выполняя "fork", процесс создает свою точную копию. Таким образом вы получаете две идентичные копии. Порожденная  копия чаще всего выполняет другой  процесс - заменяет себя новой программой. Это вторая базовая операция. Оставшиеся четыре вызова - open (открыть), close (закрыть), read (читать) и write (писать) - предназначены для доступа к файлам. Эти шесть системных вызовов представляют  собой простые операции, из которых и состоит Unix.
       Конечно, есть еще куча других системных вызовов, которые осуществляют детализацию. Но если  вы  поняли шесть базовых - вы поняли Unix. Потому что одна из прелестей Unix в том, что для создания сложных вещей не нужны сложные интерфейсы. Любого уровня сложности можно достичь за счет сочетания простых вещей. Для решения сложной проблемы нужно лишь создать связи ("каналы" в терминологии Unix) между простыми процессами.
       Уродство, когда для любого действия у системы есть специальный интерфейс. В Unix - все наоборот. Она предоставляет строительные блоки, из которых можно создать что угодно. Вот что такое стройная архитектура.
       То же самое с языками. В английском 26  букв, и с их помощью можно написать все. А  в китайском для  каждой мыслимой  вещи -  своя буква. В китайском вы сразу же получаете в свое  распоряжение сложные вещи, которые можно комбинировать ограниченным образом. Это больше напоминает подход VMS: есть множество сложных   вещей с интересным смыслом, которые можно использовать только одним способом. И в Windows то же самое.
       В Unix, напротив, основная идея: "Чем меньше, тем красивее". Здесь есть небольшой набор простых базовых строительных блоков, из которых можно строить бесконечно сложные конструкции.
       Именно так, кстати, обстоит дело и в физике. Эксперименты  позволяют открыть фундаментальные законы, которые, как предполагается, крайне просты. Сложность мира возникает за счет множества удивительных взаимосвязей, которые можно вывести из этих простых законов, а не из внутренней сложности самих законов.
       Простота Unix не возникла сама по себе. Unix со своей концепцией простых строительных  блоков была кропотливо разработана Деннисом Ричи и Кеном Томпсоном в Bell Labs компании AT&T.  Простоту вовсе не следует отождествлять с легкостью. Простота требует проектирования и хорошего вкуса.
       Если вернуться к примеру с языками, то пиктографическое письмо - например, египетские или китайские иероглифы - обычно древнее и кажется "примитивнее", а подход, использующий строительные блоки, требует гораздо более абстрактного мышления. Точно так же и простоту Unix не следует путать с отсутствием изощренности - совсем наоборот."



3. Про статью Билла Джоя (ведущего разработчика BSD Unix):
   
   "    Я беру журнал "Wired" и вижу там его жутко негативную статью о техническом прогрессе под заголовком "Будущее в нас не нуждается". Я был разочарован. Ясно, что будущее в нас не нуждается. Но в этом нет ничего ужасного.
       Не хочу разбирать его статью строчку за строчкой, но я думаю, что самым печальным для  человечества было  бы продолжать жить как живется, избегая дальнейшего   развития. Видимо, Билл считает, что достижения вроде генетической модификации приведут нас к потере человеческого начала. Всем кажется, что всякое  изменение античеловечно, потому что вот сейчас-то мы люди. Но  если мы будем продолжать развиваться, то в любом случае через 10 тысяч лет мы  не будем людьми по сегодняшним стандартам. Человечество просто примет другие формы.
       В статье Билла звучит его страх перед этим фактом. А по-моему, пытаться ограничивать эволюцию - противоестественно и бесполезно. Вместо поисков двух собак, способных произвести  необходимое потомство, мы, безусловно, обратимся к генетике; кажется неизбежным, что то же самое коснется и людей. Мне кажется, лучше изменить человеческую породу с помощью генетики, чем оставить все как есть. Я думаю, что в широком смысле гораздо интереснее способствовать эволюции не самих людей, а общества в целом, в каком бы направлении оно ни шло. Нельзя остановить технический прогресс и нельзя остановить развитие наших знаний о том, как работает наша вселенная и как устроены люди.  Все меняется так быстро, что некоторых людей, как и Билла Джоя, это пугает. Но мне это представляется частью естественной эволюции."



4. Про идеалистов и компромиссы:
   
   "   Кстати говоря, сам я никогда не причислял себя к идеалистам. Конечно, с помощью открытых исходников я стремился  сделать мир лучше. Но  прежде всего они приносили мне удовольствие. Какой уж тут идеализм!
       Идеалисты  всегда  представлялись мне  людьми  интересными, но  немного занудными, а иногда и опасными.
       Чтобы  твердо  придерживаться какого-то мнения,  нужно заведомо отмести все остальные. А это значит, что человек становится неподвластен  убеждению. По мне, именно этим американские политики хуже европейских. По  американской версии игры важно провести разграничительные линии и отстаивать свою позицию до  упора. Европейские же  политики  стремятся выиграть,  демонстрируя  свою способность наладить сотрудничество.
       Лично я  сторонник компромиссов.  Я  боялся коммерциализации  только  в самом начале, когда Linux была  никому не  известна. Если  бы  в тот момент коммерческие организации  захватили  Linux, я бы  ничего не смог сделать. Но теперь все явно переменилось. В  1998  году  в  телеконференции  было много криков о  том, что коммерческие участники не станут соблюдать  правила игры. До некоторой степени я был  вынужден  просто  доверять новым  корпоративным игрокам  так же, как разработчики Linux  доверяли  мне.  И они доказали, что доверять  им  можно.  Они ничего  не  зажимали.  До  сих  пор  опыт  весьма позитивный."



5. Про мораль и моралистов:
   
   "    Издали я восхищаюсь Ричардом Столманом по множеству причин. И вообще мне нравятся люди  с твердыми моральными принципами, как  Ричард. Но почему  они не могут держать эти принципы при себе? Больше всего  я не  люблю, когда мне говорят, что делать и чего не делать. Я полностью отвергаю людей, которые полагают, что имеют право влиять на мои решения. (Кроме, возможно, моей жены.)
       По  ходу  разработки  Linux  некоторые корифеи,  вроде  Эрика Реймонда, утверждали, что успех этой  операционной системы и жизнеспособность модели с открытыми исходниками отчасти объясняются моим прагматичным подходом и  моей способностью не принимать  ничью  сторону во время  споров. Пусть Эрик самый лучший популяризатор идеи  открытых исходников  (хотя я категорически против свободной продажи  огнестрельного оружия, к которой он призывает), я думаю, что он не совсем правильно меня  воспринимает.  Дело не в  том, что я  не становлюсь  ни  на  чью сторону.  Я  просто решительно  против  навязывания окружающим   своей  морали. Вместо  "морали"  можно  поставить   "религии", "компьютерных предпочтений" и вообще что угодно.
       Если навязывать  мораль неправильно,  то вдвойне неправильно утверждать ее законодательно. Я  глубоко верю в свободу личного выбора и поэтому думаю, что в вопросах морали я должен принимать решения сам.
       Я  хочу решать  сам.  Я  решительно  против  ненужных  правил,  которые навязывает общество. Я убежден, что в своем собственном доме человек должен иметь  право делать что угодно - до  тех пор, пока это никому не  вредит. Всякий закон, утверждающий  иное, -  это очень, очень плохой закон. А законов, утверждающих иное, весьма много. Многие правила меня  пугают. Особенно те, что распространяются на школы и детей. Только представьте себе, что   кто-то  решит  установить  правила  обучения эволюции и двинется  в неправильном направлении. Это я считаю опасным. Это общественная мораль сует свою морду туда, где ей совершенно нечего делать.
       В то же время  я  лично считаю,  что есть  кое-что поважнее меня и моих нравственных решений. Я  имею в виду даже  не человеческий  род, а эволюцию. Поэтому в  своих решениях я стараюсь  учитывать  интересы общества.  Но это, возможно, встроенная функция. Думаю, это встроено в человеческую природу  в интересах эволюции - принимать во внимание общественные интересы. Иначе бы нас давно не было.
       Бурный   протест  вызывает у меня еще только одна вещь: любители нравоучений. Никто не должен считать себя вправе выступать с проповедями."



6. Про технологии, эволюцию и будущее:
   
   "   Это называется эволюцией. Тут нет ничего мудреного. Никакая организация не может жить вечно, и это даже к лучшему.
       Но что именно движет этой эволюцией? Лежит ли в основе какая-то фундаментальная внутренняя эволюция технологии, которая однажды приведет к победе компьютеров над людьми, повергнув человечество в прах, как думают некоторые? Или же существует некая странная неизбежность прогресса - по принципу "полный вперед, чего бы это ни стоило", - которая ведет к развитию технологий?
       Я считаю, что нет.
       Технологии идут туда, куда мы их ведем. Ни бизнес, ни технологии не изменяют базовых человеческих потребностей и стремлений. Под влиянием эволюции технологии - как и все остальное - медленно, но неуклонно проделают путь  от  простого  выживания  к обществу,  основанному на коммуникациях, и наконец придут в царство развлечений. (На вас повеяло чем-то знакомым? Да, вы уже читали об этой теории и, если готовы испить эту чашу до дна, прочтете еще раз.)
       Людям суждено быть тусовочными животными, и технологии им в этом помогут.
       Поэтому забудьте все прогнозы о возможностях технологий в ближайшие десять лет. Это просто неважно. Мы смогли послать человека на Луну уже тридцать лет назад, но с тех пор туда не возвращались. Я лично убежден, что Луна просто оказалась скучным местом без всякой ночной жизни - прямо как Сан-Хосе. В итоге люди не хотят туда возвращаться, и все накопленные за это время технологии не играют ни малейшей роли. Луна продолжает пустовать.
       Что действительно влияет на будущее технологий, так это желания людей. Если угадать какую-то потребность, то дальше остается только определить, насколько быстро можно запустить нужную вещь в массовое производство по такой цене, чтобы у людей оставались деньги и на другие покупки. Все остальное не имеет никакого значения."



7. Про открытые исходники и мотивацию:
   
   "   Концепция открытых исходников крайне проста. В случае операционной системы исходники - команды программы, лежащие в основе системы, - свободны. Каждый может их улучшать, менять, использовать. Но все эти улучшения, изменения и реализации должны быть тоже доступны всем свободно. Налицо аналогия с "дзен". Проект не принадлежит никому и одновременно принадлежит всем. Когда проект открыт, происходит его быстрое и непрерывное совершенствование. Параллельная работа нескольких групп приводит к более быстрым и успешным результатам, чем работа за закрытыми дверьми.
       Именно так и было с Linux. Только представьте: взамен небольшой группки,  работающей  в обстановке секретности,  в вашем распоряжении оказываются безграничные возможности. Потенциально в проекте могут принять участие миллионы лучших умов мира, и при этом их работа идет под неусыпным контролем коллектива, которому нет равных.
       Каждому, кто впервые слышит об этом подходе, он кажется абсурдным. Поэтому потребовались годы, чтобы он завоевал признание. Модель открытых исходников утвердилась не за счет идеологии. Она начала привлекать внимание, когда стало очевидно, что это лучший метод разработки и усовершенствования технологии высочайшего качества. Теперь эта модель завоевывает рынок, что еще больше укрепляет ее авторитет. Оказалось, что можно создавать компании для оказания разнообразных дополнительных услуг или использовать открытые исходники для популяризации технологий. Денежный поток - очень убедительный аргумент.
      Самый загадочный вопрос в этом деле - как такая прорва хороших программистов соглашается работать абсолютно бесплатно? Тут нужно поговорить о мотивации. В условиях общества,  где  выживание более  или  менее гарантировано, деньги - не самый лучший стимул. Хорошо известно, что лучше всего работает тот, кто одержим страстью. Кто работает ради удовольствия. Это так же верно в отношении драматургов, скульпторов и предпринимателей, как и в отношении программистов. Модель открытых исходников дает людям возможность удовлетворить свою страсть, получить удовольствие, сотрудничать с лучшими программистами мира, а не только с теми, кто оказался в штате той же компании. При этом разработчики стремятся завоевать авторитет среди своих коллег, и это оказалось превосходным стимулом."

Получилось много. Но лучше, конечно же, прочитать саму книгу. Я не сторонник бумажных книг, но эта у меня стоит на полке. В электронном виде книга лежит свободно (как и сама Linux), например, тут.

Автор: Шиболов Вячеслав Анатольевич