Изучаем основы *nix \ man \ gzip \ chmod \ pid \ guid \ ps \ kill \ fs \ ls \ cd

Источник:

http://www.xakep.ru/magazine/xs/051/008/1.asp -Alma mater Спецвыпуск: Хакер, номер #051

1	http://www.xakep.ru/magazine/xs/051/008/1.asp -Alma mater Спецвыпуск: Хакер, номер #051

Мир Мануала:

С чего начать? Конечно же, почитать инструкцию к FreeBSD. 
Кроме тонны книжек, которые уже сломали не одну твою полку, есть еще и электронный справочник по командам, с помощью которых ты общаешься с FreeBSD.
Обо всех командах и рассказано в man. 
man man - исполнив которую ты узнаешь, что же такое творит команда man.
man rm – и покажется мануал по утилите rm

Для отображения мануалов по умолчанию используется программа More.
Итак, мануал по какой-либо команде состоит из нескольких частей:
NAME – имя самой команды, ее аналогов и краткое описание команды.
SYNOPSIS – описание синтаксиса данной команды.
DESCRIPTION – этот раздел дает подробное описание того, что делает программа и какие параметры ей можно передавать.
NOTE – здесь описаны некоторые замечания по команде. 
       В частности, по команде rm объясняется, как можно выполнять удаление нетривиальных файлов, например, вида "-filename".
SEE ALSO – очень полезный раздел, так как тут отображаются команды, которые связаны с этой командой.
BUGS – здесь описаны известные ошибки, которые еще не исправлены.
HISTORY – здесь описывается, когда и в какой версии *nix впервые появилась данная команда.
SEE ALSO - можно найти какие-то цифры рядом с командами в скобках. 

Man1 - пользовательские команды (ls, cd, rm).
Man2 – системные вызовы (mkdir(), ioctl()).
Man3 – различные функции (printf(), sin(), abs()).
Man4 – форматы файлов (в частности файлы в /dev).
Man5 – конфигурационные файлы (hosts, syslog.conf).
Man6 – игры.
Также существуют и man7 и man8 и man9

С чего начать? Конечно же, почитать инструкцию к FreeBSD.

Кроме тонны книжек, которые уже сломали не одну твою полку, есть еще и электронный справочник по командам, с помощью которых ты общаешься с FreeBSD.

Обо всех командах и рассказано в man.

man man - исполнив которую ты узнаешь, что же такое творит команда man.

man rm – и покажется мануал по утилите rm

Для отображения мануалов по умолчанию используется программа More.

Итак, мануал по какой-либо команде состоит из нескольких частей:

NAME – имя самой команды, ее аналогов и краткое описание команды.

SYNOPSIS – описание синтаксиса данной команды.

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

NOTE – здесь описаны некоторые замечания по команде.

В частности, по команде rm объясняется, как можно выполнять удаление нетривиальных файлов, например, вида "-filename".

SEE ALSO – очень полезный раздел, так как тут отображаются команды, которые связаны с этой командой.

BUGS – здесь описаны известные ошибки, которые еще не исправлены.

HISTORY – здесь описывается, когда и в какой версии *nix впервые появилась данная команда.

SEE ALSO - можно найти какие-то цифры рядом с командами в скобках.

Man1 - пользовательские команды (ls, cd, rm).

Man2 – системные вызовы (mkdir(), ioctl()).

Man3 – различные функции (printf(), sin(), abs()).

Man4 – форматы файлов (в частности файлы в /dev).

Man5 – конфигурационные файлы (hosts, syslog.conf).

Man6 – игры.

Также существуют и man7 и man8 и man9

Страницы man откуда они?

# strings /usr/bin/man | grep “/” - посмотреть куда обращается бинарник man
Из всех строчек привлекает внимание запись /etc/manpath.config.
После исследования этого файла становится понятно, что здесь описывается и где находятся все мануалы в системе. 
А основные мануалы лежат в /usr/share/man. 
Вот и они! И много как… man1 man2 man3...

# strings /usr/bin/man | grep “/” - посмотреть куда обращается бинарник man

Из всех строчек привлекает внимание запись /etc/manpath.config.

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

А основные мануалы лежат в /usr/share/man.

Вот и они! И много как… man1 man2 man3...

Архивирование мануалов как?

Чаще всего для этого используется gzip. 
# gzip <имя_файла> - архивирование
# gzip leet_syscall.2  - архивирование leet_syscall.2 и получим файл leet_syscall.2.gz
# gzip –d leet_syscall.2.gz - распаковка
# gzip –l leet_syscall2.gz - посмотреть что в архиве

Чаще всего для этого используется gzip.

# gzip <имя_файла> - архивирование

# gzip leet_syscall.2 - архивирование leet_syscall.2 и получим файл leet_syscall.2.gz

# gzip –d leet_syscall.2.gz - распаковка

# gzip –l leet_syscall2.gz - посмотреть что в архиве

Посмотрю-ка я мануал к команде access:

# man access
В самом верху надпись ACCESS(2). Значит так: это описание системного вызова. 
Это мне не подходит... Смотрю секцию SEE ALSO и вижу команду chmod(2).
В ней что-то есть такое.

# man access

В самом верху надпись ACCESS(2). Значит так: это описание системного вызова.

Это мне не подходит... Смотрю секцию SEE ALSO и вижу команду chmod(2).

В ней что-то есть такое.

Посмотрю-ка я мануал к команде chmod:

# man 2 chmod
Здесь двойка указывает на то, что мануал берется из секции 2 – опять системный вызов, но делать нечего – кто ищет, тот всегда найдет. 
Тут уже становится интересней. 
Доступ к файлу - это то, что мне нужно: запретить доступ к моему мануалу нежелательным пользователям! 
Но что-то тут совсем уж заумно написано, идем в SEE ALSO и находим команду Chmod, только уже с индексом (1). 
Посмотри мануал к ней и пойми, наконец, что это то, что тебе нужно. 
Оказывается, что доступ к файлу определяется четырехзначным числом x x x x. 
Первый разряд определяет специальные уровни доступа, о которых расскажу позже. 
Второй разряд - уровень доступа хозяина файла. 
Третий разряд - уровень доступа для группы пользователей. 
Четвертый – для всех остальных. 

Итак, теперь ты можешь узнать, как именно определяется доступ для них.
Используется очень простая и в то же время удачная система. 
Есть три возможности для файла (директория – это тот же файл, предназначенный для хранения других файлов) 
– чтение (r)  R = 4
- запись (w)   W = 2
- исполнение (x) X = 1. 
 
Собираем все воедино: 
chmod 0460 <имя файла>.

# man 2 chmod

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

Тут уже становится интересней.

Доступ к файлу - это то, что мне нужно: запретить доступ к моему мануалу нежелательным пользователям!

Но что-то тут совсем уж заумно написано, идем в SEE ALSO и находим команду Chmod, только уже с индексом (1).

Посмотри мануал к ней и пойми, наконец, что это то, что тебе нужно.

Оказывается, что доступ к файлу определяется четырехзначным числом x x x x.

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

Второй разряд - уровень доступа хозяина файла.

Третий разряд - уровень доступа для группы пользователей.

Четвертый – для всех остальных.

Итак, теперь ты можешь узнать, как именно определяется доступ для них.

Используется очень простая и в то же время удачная система.

Есть три возможности для файла (директория – это тот же файл, предназначенный для хранения других файлов)

– чтение (r) R = 4

- запись (w) W = 2

- исполнение (x) X = 1.

Собираем все воедино:

chmod 0460 <имя файла>.

Процессы:

Все бы ничего, но обычно это приводит с "висящим" процессам и незакрытой сессии, которая тоже зависает. 
В этом, конечно, нет ничего страшного, но может зависнуть и процесс ping –s 50000 http://www.ru, 
а это уже неприятно. 
Убей его. 

Допустим, из зависших процессов нужно убить именно ping. 
Находим его среди процессов и определяем его pid (Process IDentifier):
# ps ax|grep "ping"
69560 p1 S+ 0:00.01 ping -s 40000 http://www.ru

Число, находящееся в начале строки, и есть этот самый pid, в этом случае - 69560. 
Это уникальный идентификатор данного процесса. Зная его можно расправиться с самим процессом.
Поскольку нужно убить процесс, то опять идем за помощью к мануалу:
# man kill

Это и есть мануал по kill(1). С помощью этой команды можно послать сигнал процессу. 
Оказывается, что сигналов много и каждый из них имеет свое назначение. Я рассмотрю лишь 
два наиболее часто используемых сигнала – это –HUP и –9. Не странно ли, что один сигнал 
отображается в числовом виде, а другой в символьном? У каждого числового сигнала есть 
символьный аналог для удобства запоминания. 
Например –1 это –HUP, а –9 это –KILL. 
Итак, все-таки процесс убить придется. 
Его pid уже неизвестен, из man видим синтаксис, поэтому:
# kill –9 69560

Я выбрал –9, потому что мне нужно обязательно завершить этот процесс,
а сигнал –KILL не может быть отловлен и проигнорирован.
На самом деле сигнал –HUP должен интересовать тебя больше, чем даже –9. 
Допустим, у нас запущен прокси squid на сервере и что-то изменено в конфигурационном файле, 
но работающая программа об этом ничего не знает. 
Не будет же она постоянно перечитывать конфигурационный файл отслеживая изменения. 
Можно, конечно, убить процесс и запустить squid снова, но это ниже твоего достоинства. 
Лучше подать процессу сигнал о том, что конфигурационный файл изменился и что его нужно прочитать. 
Делается это опять же просто:
# kill –HUP pid

где pid – это идентификатор процесса, которому нужно подать сигнал. 
Конечно, идентификаторы - это хорошо, но не каждый человек способен сходу запомнить пятизначное число. 
Нужно посмотреть в таблицу процессов, найти нужный pid, скопировать или вписать его снова на консоль. 
Это долго, да и не всегда удобно. 
Тебя ждут более важные дела, а для свободы твоей гениальности придумана команда killall. 
Все то, что было сотворено с ping, можно было сделать проще:
# killall –9 ping

И даже не нужно было бы смотреть список процессов. 
Эта команда убьет все процессы ping, что не всегда желательно. 
Если вдруг на другой консоли сидит какой-то человек, например, мой знакомый по имени r1c, и кого-то пингует, 
то убийству своего собственного процесса он не порадуется. 
Это мокрое дело произойдет тогда, когда мы с ним будем работать от имени одного пользователя или когда я буду работать под root’ом.
В том случае, если я не root и пытаюсь послать сигнал не моему процессу, мне просто будет отказано в доступе. 
А что сделать, чтобы не разозлить r1c’а? У команды killall есть два замечательных параметра –u и –t. 
Параметр –u ограничивает процессы, которым будет послан сигнал, по пользователю. 
То есть нужно написать:
# killall –u root –9 ping

И теперь будут убиты все процессы ping, которые запущены от имени root’а. 
Второй параметр может понадобиться, если захочешь поиздеваться над каким-либо пользователем. –t ограничивает процессы по терминалу. 
Что это значит и как это нам поможет? 
Используя команду
# w

можно добраться до списка пользователей, которые работают в системе на данный момент. 
Итак, мы видим колонку TTY. 
Это и есть имя терминала, за которым работает пользователь (терминал может быть как виртуальный, так и физический; в этом случае неважно). 
Подмечаем, что товарищ r1c работает за терминалом p2. Выполнив команду
# killall –t p2 –9 bash

сбрасываем r1c’а с консоли (при условии, что default-шелл у r1c’а именно bash).

Все бы ничего, но обычно это приводит с "висящим" процессам и незакрытой сессии, которая тоже зависает.

В этом, конечно, нет ничего страшного, но может зависнуть и процесс ping –s 50000 http://www.ru,

а это уже неприятно.

Убей его.

Допустим, из зависших процессов нужно убить именно ping.

Находим его среди процессов и определяем его pid (Process IDentifier):

# ps ax|grep "ping"

69560 p1 S+ 0:00.01 ping -s 40000 http://www.ru

Число, находящееся в начале строки, и есть этот самый pid, в этом случае - 69560.

Это уникальный идентификатор данного процесса. Зная его можно расправиться с самим процессом.

Поскольку нужно убить процесс, то опять идем за помощью к мануалу:

# man kill

Это и есть мануал по kill(1). С помощью этой команды можно послать сигнал процессу.

Оказывается, что сигналов много и каждый из них имеет свое назначение. Я рассмотрю лишь

два наиболее часто используемых сигнала – это –HUP и –9. Не странно ли, что один сигнал

отображается в числовом виде, а другой в символьном? У каждого числового сигнала есть

символьный аналог для удобства запоминания.

Например –1 это –HUP, а –9 это –KILL.

Итак, все-таки процесс убить придется.

Его pid уже неизвестен, из man видим синтаксис, поэтому:

# kill –9 69560

Я выбрал –9, потому что мне нужно обязательно завершить этот процесс,

а сигнал –KILL не может быть отловлен и проигнорирован.

На самом деле сигнал –HUP должен интересовать тебя больше, чем даже –9.

Допустим, у нас запущен прокси squid на сервере и что-то изменено в конфигурационном файле,

но работающая программа об этом ничего не знает.

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

Можно, конечно, убить процесс и запустить squid снова, но это ниже твоего достоинства.

Лучше подать процессу сигнал о том, что конфигурационный файл изменился и что его нужно прочитать.

Делается это опять же просто:

# kill –HUP pid

где pid – это идентификатор процесса, которому нужно подать сигнал.

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

Нужно посмотреть в таблицу процессов, найти нужный pid, скопировать или вписать его снова на консоль.

Это долго, да и не всегда удобно.

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

Все то, что было сотворено с ping, можно было сделать проще:

# killall –9 ping

И даже не нужно было бы смотреть список процессов.

Эта команда убьет все процессы ping, что не всегда желательно.

Если вдруг на другой консоли сидит какой-то человек, например, мой знакомый по имени r1c, и кого-то пингует,

то убийству своего собственного процесса он не порадуется.

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

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

А что сделать, чтобы не разозлить r1c’а? У команды killall есть два замечательных параметра –u и –t.

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

То есть нужно написать:

# killall –u root –9 ping

И теперь будут убиты все процессы ping, которые запущены от имени root’а.

Второй параметр может понадобиться, если захочешь поиздеваться над каким-либо пользователем. –t ограничивает процессы по терминалу.

Что это значит и как это нам поможет?

Используя команду

# w

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

Итак, мы видим колонку TTY.

Это и есть имя терминала, за которым работает пользователь (терминал может быть как виртуальный, так и физический; в этом случае неважно).

Подмечаем, что товарищ r1c работает за терминалом p2. Выполнив команду

# killall –t p2 –9 bash

сбрасываем r1c’а с консоли (при условии, что default-шелл у r1c’а именно bash).

Файловая система

Теперь о структуре файловой системы в *nix. 
Можно не знать, как посылать сигналы процессам, как читать мануалы, но вот без знания устройства файловой системы, а точнее устройства каталогов, просто нельзя жить.
В основе файловой системы лежит каталог с именем "/". Его называют "корневым" каталогом: он занимает самый верхний уровень в иерархии файловой системы. 
В нем живут все остальные каталоги системы. 

Итак, сделаем
# ls /
и по порядку посмотрим, для чего нужна каждая папка.

/bin – здесь хранятся фундаментальные, основные пользовательские утилиты.

/boot – здесь хранятся программы и файлы, необходимые для загрузки системы.

/dev – здесь хранятся файлы устройств (например, замечательное псевдоустройство Urandom).

/etc – в этом каталоге можно увидеть конфигурационные файлы и скрипты. По сути, это место скопления конфигурационных файлов. 
       Стоит особо отметить файл rc.conf, в котором определяется начальная настройка системы при загрузке.

/home – место, где обычно хранятся домашние директории пользователей (в FreeBSD 5.x это уже /usr/home), за исключением суперпользователя.

/mnt – эта папка обычно пуста, используется же она обычно как временная точка монтирования разделов.

/proc – полностью виртуальная файловая система.

/root – эта директория является домашней для пользователя root.

/sbin – здесь хранятся системные программы и утилиты администрирования.

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

/usr – основное хранилище для пользовательских утилит и программ. 
       Тут-то и стоит искать вновь установленные программы и конфигурационные файлы к ним.

/var – здесь чаще всего хранятся логи, некоторые временные файлы, каталоги спулинга для электронной почты и принтеров и дополнительные файлы подкачки.

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

То есть чтобы перейти в папку, которая находится выше, пишешь
# cd ..

и попадаешь в директорию выше (или если ты в корневой директории - останешься в ней). 
Таким образом, произошло перемещение из /usr/local/etc в /usr/local.

Теперь о структуре файловой системы в *nix.

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

В основе файловой системы лежит каталог с именем "/". Его называют "корневым" каталогом: он занимает самый верхний уровень в иерархии файловой системы.

В нем живут все остальные каталоги системы.

Итак, сделаем

# ls /

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

/bin – здесь хранятся фундаментальные, основные пользовательские утилиты.

/boot – здесь хранятся программы и файлы, необходимые для загрузки системы.

/dev – здесь хранятся файлы устройств (например, замечательное псевдоустройство Urandom).

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

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

/home – место, где обычно хранятся домашние директории пользователей (в FreeBSD 5.x это уже /usr/home), за исключением суперпользователя.

/mnt – эта папка обычно пуста, используется же она обычно как временная точка монтирования разделов.

/proc – полностью виртуальная файловая система.

/root – эта директория является домашней для пользователя root.

/sbin – здесь хранятся системные программы и утилиты администрирования.

/tmp – директория для хранения временных файлов. Не стоит доверять ей ценную информацию,

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

/usr – основное хранилище для пользовательских утилит и программ.

Тут-то и стоит искать вновь установленные программы и конфигурационные файлы к ним.

/var – здесь чаще всего хранятся логи, некоторые временные файлы, каталоги спулинга для электронной почты и принтеров и дополнительные файлы подкачки.

Это и есть основные каталоги в корневом каталоге. Также стоит отметить, что в каждом каталоге есть ссылка на каталог,

который стоит выше по уровню. Эта ссылка имеет название "..".

То есть чтобы перейти в папку, которая находится выше, пишешь

# cd ..

и попадаешь в директорию выше (или если ты в корневой директории - останешься в ней).

Таким образом, произошло перемещение из /usr/local/etc в /usr/local.

Добавить комментарий