Мануал:
С чего начать? Конечно же, почитать инструкцию к 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...
Архивирование мануалов как?
Чаще всего для этого используется 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). В ней что-то есть такое.
Посмотрю-ка я мануал к команде chmod:
# 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).
Файловая система
Теперь о структуре файловой системы в *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.
