среда, 29 апреля 2009 г.

Как создать свой пункт в главном меню Ubuntu Linux

В операционной системе Ubuntu Linux все программы удобно разбиты по разделам, которые находятся в главном меню «Приложения», что по умолчанию расположено в верхнем левом углу экрана. Мы привыкли, что после установки той или иной программы, в данном меню появляется новый пункт, привязанный к определенной категории. Так например при установке плеера для воспроизведения аудио файлов, мы можем его найти в подразделе «Аудио и Видео». А что делать, если после установки программы мы не обнаруживаем нового пункта в вышеуказанном меню? Здесь варианта два: либо запускать программу через терминал, что не совсем удобно. Либо создать такой пункт меню вручную. Чем мы с вами сегодня и займемся.

Всю последующую работу мы будем проводить на примере интернет-пейджера Qutim. На нашем сайте уже была статья, посвященная данной программе. Там мы предлагали вашему вниманию дистрибутив, который чудесным образом поддерживает работу со звуком, смайлами и прочими приятными уху и взору вещами. Так вот. Этот дистрибутив после установки забывает поставить пункт в главное меню «Приложения». То есть, после установки неискушенный пользователь растерянно бродит по меню в надежде найти кнопку с запуском Qutim.

Несомненно, можно открыть терминал и просто ввести там английское слово из пяти букв — qutim. Чтобы там не говорили Linux гуру, я не считаю данный способ запуска приложений целесообразным.

Я же предлагаю поступить следующим образом: заходим в меню Параметры и далее выбираем пункт «Главное меню».

Как создать свой пункт в главном меню Ubuntu Linux

Откроется новое окно:

Как создать свой пункт в главном меню Ubuntu Linux

Здесь в левой части мы должны выбрать раздел куда будет добавлен новый пункт меню. Затем в правой части окна мы нажимаем на кнопку «Новый элемент». Появится окошко под названием «Создать кнопку запуска».

В текстовое поле «Имя» мы можем вписать произвольное имя пункта. А вот в поле команда мы обязаны вписать имя программы на латинском языке. В данном случае это Qutim.

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

Обратим внимание на окно «Создать кнопку запуска», в левой части расположена большая кнопка. Я ее обвел красным цветом:

Как создать свой пункт в главном меню Ubuntu Linux

Предлагаю нажать на нее. Откроется новое окно.

Как создать свой пункт в главном меню Ubuntu Linux

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

Чтобы немножко облегчить вам поиски, я выложил на сайте пакет со значками в формате SVG для GNOME. Скачать его можно здесь.

Теперь наша задача решена на все сто процентов. С чем вас и поздравляю.

С уважением, Гоша Компьютерный.

суббота, 25 апреля 2009 г.

ОС как столовые. Юмор.

ДОС. Столовая самообслуживания. Блюда просты и незатейливы. Есть комплексные обеды в стиле "Смешать несколько стандартных в одно". Но если у повара грязные руки — животом маются все посетители поголовно.

Вин-3.1. Столовая-люкс. Есть полноценные комплексные обеды, на раздаче стоят несколько поваров — это позволяет получить "котлету в компоте" и другие странные блюда. На столах — клеенчатые скатерти и жестяные вазочки с пластиковыми цветами. Кухня не изменилась.
Существует расширение, позволяющее посетителям обмениваться блюдами и проблемами друг с другом.

Вин-95. Полный редизайн. Кухня закупила новое оборудование, у каждого повара — свой сектор работы, в обеденном зале — новая мебель и обои. Блюда тоже сплошь новые и красивые — глаз не оторвать. Впрочем, персонал старый, к новым порядкам не привык, и проблемы тут случаются куда чаще, чем раньше.

Вин-98. Персонал прошел переподготовку, а из приправ оставили только соль и перец. Блюда сплошь замороженные — напортачить тяжело, разве что брак пойдет изначально. Впрочем, если попросить, могут приготовить и что-нибудь по рецептам ДОС или Вин-95 — но тут вероятность брака резко возрастает.

Вин-МЕ. Дизайн доведен до совершенства — все блестит и переливается. Впрочем, достигается это тонким слоем смазки на всем, включая продукты. Для "быстроты обслуживания" к столикам приделаны колесики, и если что-то падает, то катастрофа быстро приобретает глобальный характер.

Вин-НТ. Столовая построена с ноля профессионалами, которые раньше строили фабрики-кухни, способные за раз накормить целый город. Поэтому столовая требует прорву электричества, мощное дорогостоящее оборудование "для настоящих профессионалов" и высококачественные продукты. На входе в столовую поставили охранника: если нет пропуска, внутрь вас просто не пустят. Впрочем, еда тут хоть и однообразная, но вполне вкусная и питательная. А если повар напортачил, к примеру, с соком — никаких "таблеток общего действия". Испорченный сок удалят из вас хирургическим путем, а повара расстреляют на заднем дворе.

Вин-2000. Столовая с дизайном от Вин-98. Охранник, впрочем, остался на своем месте. Количество блюд увеличено, а в обеденном зале поставили шикарный телевизор, который частенько вышибает пробки. Доесть свою порцию в темноте обычно не получается.

Вин-ХР. Новый редизайн. Мощность телевизора увеличена: теперь он подпевает целой театральной труппе, озвучивающей любые ваши действия. На входе, помимо охранника, вас встречает консультант, у которого есть премерзкая привычка тягаться за вами по залу и надоедать советами. На кассе появился детектор подлинности банкнот.

Вин-Виста/Вин-7. Очередной редизайн: сейчас, для оригинальности, его выполнило местное похоронное бюро. Охранник, помимо входа, сейчас стоит и на раздаче, и у кассы, и в туалете, и даже у каждого столика. Повсюду телекамеры — они тщательно следят за каждым вашим движением, комментируя их остальным посетителям. Консультант теперь не надоедает советами, у него в лексиконе лишь одна фраза: "Вам это не нужно, я уверен. Оплатите счет за консультацию". Стоимость блюд увеличена вдвое, но они отчего-то стали намного жестче — не всякие зубы справятся. Из-за этого обед частенько затягивается заполночь.

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

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

пятница, 24 апреля 2009 г.

Проблемы при обновлении Ubuntu до версии 9.04


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

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

Менеджер обновлений не видит новый дистрибутив Ubuntu 9.04

Как бы я не старался, какой бы репозиторий (будть то официальный, буть то зеркала) я не подсовывал, менеджер обновлений не видел что вышла Ubuntu 9.04. Все соответствующие "крыжики" в Система -> Параметры -> Источники приложений, стояли.

Оказалось когда я ставил OpenOffice от Инфра Ресурс, он испортил мне Update Manager.
Чтобы исправить, открываем файл /usr/lib/python2.5/site-packages/UpdateManager/Core/MetaRelease.py.
Ищем строки:

Меняем на правильные:
После этого перезапускаем Менеджер обновлений. Если графическая часть до сих пор не видит нового дистрибутива, запустите обновление в консоле:
sudo do-release-upgrade

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

После обновления Ubuntu до 9.04, почтовый клиент Evolution зависает при запуске

Обновился, запускаю Evolution, а он висит.
Если убить процесс evolution-alarm-notify, все чудесным образом начинает работать, evolution дышет.
Если у вас такая же проблема:
1. закрываем evolution
2. закрываем полностью
sudo evolution --force-shutdown
3. лезем в gconf-editor, у кого не установлено:
sudo apt-get install gconf-editor
4. идем в ветку /apps/evolution/calendar/notify меняем значение переменной last_notification_time, на минимальное или вообще на 0.

Запускаем evolution, радуемся.

Источник

среда, 22 апреля 2009 г.

Как обнаружить хакерскую атаку

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

Сборка нового ядра для Ubuntu Linux

Некоторое время назад у меня наконец-то появилась возможность перейти на Linux. Раньше я всегда использовал Slackware, но тут решил поставить Ubuntu из-за удобства менеджера пакетов. И столкнулся с необходимостью сборки нового ядра. Оказалось, что процесс немного отличается от привычного.

четверг, 16 апреля 2009 г.

Настройка маршрутизации в Ubuntu Linux, для начинающих (на заметку)

Оригинал: http://forum.ubuntu.ru/index.php?topic=12454.0

Правила маршрутизации определяют, куда отправлять IP-пакеты. Данные маршрутизации хранятся в одной из таблиц ядра. Вести таблицы маршрутизации можно статически или динамически. Статический маршрут - это маршрут, который задается явно с помощью команды route. Динамическая маршрутизация выполняется процессом-демоном (routed или gated), который ведет и модифицирует таблицу маршрутизации на основе сообщений от других компьютеров сети. Для выполнения динамической маршрутизации разработаны специальные протоколы: RIP, OSPF, IGRP, EGP, BGP и т. д.

Динамическая маршрутизация необходима в том случае, если у вас сложная, постоянно меняющаяся структура сети и одна и та же машина может быть доступна по различным интерфейсам (например, через разные Ethernet или SLIP интерфейсы). Маршруты, заданные статически, обычно не меняются, даже если используется динамическая маршрутизация.
Для персонального компьютера, подключаемого к локальной сети, в большинстве ситуаций бывает достаточно статической маршрутизации командой route. Прежде чем пытаться настраивать маршруты, просмотрите таблицу маршрутизации ядра с помощью команды netstat -n -r. Вы должны увидеть что-то вроде следующего:
rigon@ubuntu-comp:~$ netstat -n -r

Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.254.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.254.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
0.0.0.0 192.168.254.1 0.0.0.0 UG 0 0 0 eth0
0.0.0.0 192.168.254.1 0.0.0.0 UG 0 0 0 eth1

Если таблица пуста, то вы увидите только заголовки столбцов. Тогда надо использовать route. С помощью команды route можно добавить или удалить один (за один раз) статический маршрут. Вот ее формат:
route -f операция -тип адресат шлюз интерфейс

Здесь аргумент операция может принимать одно из двух значений: add (маршрут добавляется) или delete (маршрут удаляется). Аргумент адресат может быть IP-адресом машины, IP-адресом сети или ключевым словом default . Аргумент шлюз - это IP-адрес компьютера, на который следует пересылать пакет (этот компьютер должен иметь прямую связь с вашим компьютером). Команда:
route -f

удаляет из таблицы данные обо всех шлюзах. Необязательный аргумент тип принимает значения net или host . В первом случае в поле адресата указывается адрес сети, а во втором - адрес конкретного компьютера (хоста).
Как правило, бывает необходимо настроить маршрутизацию по упоминавшимся выше трем интерфейсам:
* локальный интерфейс (lo),
* интерфейс для платы Ethetnet (eth0),
* интерфейс для последовательного порта (PPP или SLIP).

Локальный интерфейс поддерживает сеть с IP-номером 127.0.0.1. Поэтому для маршрутизации пакетов с адресом 127.... используется команда:
route add -net 127.0.0.1 lo

Если у вас для связи с локальной сетью используется одна плата Ethernet, и все машины находятся в этой сети (сетевая маска 255.255.255.0), то для настройки маршрутизации достаточно вызвать:
route add -net 192.168.36.0 netmask 255.255.255.0 eth0

Если же вы имеете насколько интерфейсов, то вам надо определиться с сетевой маской и вызвать команду route для каждого интерфейса.
Поскольку очень часто IP-пакеты с вашего компьютера могут отправляться не в одну единственную сеть, а в разные сети (например, при просмотре разных сайтов в Интернете), то в принципе надо было бы задать очень много маршрутов. Очевидно, что сделать это было бы очень сложно, точнее просто невозможно. Поэтому решение проблемы маршрутизации пакетов перекладывают на плечи специальных компьютеров - маршрутизаторов, а на обычных компьютерах задают маршрут по умолчанию, который используется для отправки всех пакетов, не указанных явно в таблице маршрутизации. С помощью маршрута по умолчанию вы говорите ядру "а все остальное отправляй туда". Маршрут по умолчанию настраивается следующей командой:
route add default gw 192.168.1.1 eth0

Опция gw указывает программе route, что следующий аргумент - это IP-адрес или имя маршрутизатора, на который надо отправлять все пакеты, соответствующие этой строке таблицы маршрутизации.
Вот немного теории с сайта linuxcenter.ru

А теперь пример из жизни:
Имеются следующие интерфейсы /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.17.8
hwaddress ether 00:E0:4C:A2:C4:48
netmask 255.255.255.0
broadcast 192.168.17.255
auto eth1
iface eth1 inet static
address 192.168.254.2
netmask 255.255.255.0
gateway 192.168.254.1
broadcast 192.168.254.255

Интерфейс eth0 это связь с локальной сетью состоящей из 20 подсетей 192.168.1.х-192.168.20.х

Интерфейс eth1 это связь с ADSL модемом с выходом в интернет. Так большинство запросов идут в Инет на этом интерфейсе прописываем шлюз (gateway 192.168.254.1) данный параметр указывает в системе шлюз по-умолчанию, обращаю внимание, что шлюз надо прописывать только на одном интерфейсе, иначе в системе появятся 2 маршрута по умолчанию и естествено будет затупление в работе. С интернетом разобрались.

Но требуется еще просматривать ресурсы локальной сети для этого надо выполнить вот эти команды
route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.17.254 eth0
route add -net 192.168.12.0 netmask 255.255.255.0 gw 192.168.17.254 eth0
route add -net 192.168.21.0 netmask 255.255.255.0 gw 192.168.17.254 eth0

На этом примере маршрутизируются 3 подсети. Все эти команды и многие другие можно прописать в файлк /etc/network/interfaces в итоге получится следующее:
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.17.8
hwaddress ether 00:E0:4C:A2:C4:48
netmask 255.255.255.0
broadcast 192.168.17.255
up route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.17.254 eth0
up route add -net 192.168.12.0 netmask 255.255.255.0 gw 192.168.17.254 eth0
up route add -net 192.168.21.0 netmask 255.255.255.0 gw 192.168.17.254 eth0
auto eth1
iface eth1 inet static
address 192.168.254.2
netmask 255.255.255.0
gateway 192.168.254.1
broadcast 192.168.254.255

Ну вот и все по аналогии настраиваются любое кол-во маршрутов и
сетевых интерфейсов

Дополнение 1.

Обратите внимание
hwaddress ether 00:E0:4C:A2:C4:48

так легко можно изменить MAC, не забываем после редактирования файла делать рестарт
sudo /etc/init.d/networking restart

Дополнение 2.

Следует отметить, что:
1) Для того, чтобы просмотреть таблицу маршрутов достаточно запуска
команды route без параметров или route -n, если в сети нет DNS.
2) Маска может быть записана проще, в виде /x, где x - число единичных
битов, например:
route add -net 192.168.36.0/24 eth0

вместо
route add -net 192.168.36.0 netmask 255.255.255.0 eth0

Настройки сети размещаются в файле /etc/network/interfaces. При подключение к Inet через VPN (ppp0...), необходимо заменять маршрут по умолчанию на ppp0.
А проще указать в файле /etc/ppp/options следующее:
defaultroute
replacedefaultroute

тогда маршрут заменяется сам и при отключении восстанавливается.

Дополнение 3.

Есть прога, серверная часть которой стоит во внутренней сети, например Radmin Server, чтобы к нему подключиться клиентская прога (Radmin Viewer) запрашивает соединение по порту 4799 (например). Все работает внутри локальной сети. Есть шлюз (с внешним IP), через который обеспечивает доступ в и-нет всех компов внутренней сети. Теперь вопрос, как настроить шлюз, чтобы при обращении из вне клиентсокой частью к IP шлюза по порту 4799, он пробрасывал этот запрос дальше, например на 192.168.0.2 по томуже порту?

Для этого есть команда iptables:
iptables -t nat -D PREROUTING -i <интерфейс> -s
-p tcp --dport 4899 -j DNAT --to-destination 192.168.0.2:4899

Если ограничивать входящие IP не требуется, то опцию -s можно опустить.
Пример:
iptables -t nat -D PREROUTING -i vlan1 -s 213.87.34.20/24 -p tcp
--dport 4899 -j DNAT --to-destination 192.168.128.24:4899
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 3658 -j DNAT
--to-destination 192.168.0.2:3658

Ошибка

У вас просто:

или

вторник, 14 апреля 2009 г.

Linux: Обзор программ сертификации

Наверняка, многие из вас слышали о такой вещи как сертификация технических специалистов. Особенно широко распространены сертификации MCSA, MCSE, MCDBA и прочие. Но это всё сертификации для операционной системы Windows. Как же обстоят дела с сертификацией в Linux?

Ничуть не хуже. Для Linux тоже есть масса различных сертификаций, которые могут подтвердить Ваш профессиональный уровень. В статье рассмотрены четыре наиболее популярные в мире системы сертификации Linux. Это CompTIA Linux+, Linux Professional Institute Certification (LPIC), SAIR Linux GNU Certification и сертификация фирмы RedHat. Так же указаны ориентировочные цены для сдачи экзаменов в Москве, которые актуальны на момент написания статьи.

1. CompTIA Linux+


Экзамен: XK0-002: CompTIA Linux+ Exam
Продолжительность экзамена: 120 минут
Ориентировочная стоимость: 11 000 рублей

Сертификация CompTIA Linux+ независима от вендора и предназначена для проверки общих знаний и навыков, необходимых при работе с системой Linux. Ориентирована на специалистов, имеющих опыт системного администрирования Linux не менее 6-12 месяцев. В ходе экзамена испытуемый должен показать умение работать с командной строкой, выполнять основные административные задачи и решать возникающие проблемы. В 2009 году, компания CompTIA предложила следующее распределение вопросов в экзаменуемых областях:

  • Установка и конфигурирование – 22%
  • Эксплуатация и поддержка системы – 28%
  • Программы и сервисы – 23%
  • Сеть – 14%
  • Безопасность – 13%

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

2. Linux Professional Institute Certification (LPIC)

Ещё одна система сертификации не привязанная к конкретному вендору. Состоит из трех уровней: LPIC-1, LPIC-2 и LPIC-3. Для прохождения каждого уровня необходимо сдать два экзамена.

LPIC-1 (Junior Level Linux Professional)

Экзамен: 117-101: LPI Level 1 Exam 101
Продолжительность экзамена: 90 минут
Ориентировочная стоимость: 7370 рублей

При сдаче данного экзамена необходимо показать хорошие знания в следующих областях:

  • Оборудование («железо»)
  • Установка Linux и управление пакетами
  • GNU и Unix команды
  • Устройства, файловые системы Linux
  • Система X Window


Экзамен: 117-102: LPI Level 1 Exam 102
Продолжительность экзамена: 90 минут
Ориентировочная стоимость: 7370 рублей

Необходимо глубокое понимание нижеследующего:

  • Ядро
  • Загрузка, инициализация, выключение и уровни выполнения
  • Печать
  • Документация
  • Шеллы, скрипты, программирование и компиляция
  • Административные задачи
  • Сеть (основы)
  • Сетевые сервисы
  • Безопасность

LPIC-2 (Advanced Level Linux Professional)

Прохождение уровня LPIC-2 возможно только после успешного прохождения уровня LPIC-1.

Экзамен: 117-201: LPI Level 2 Exam 201
Продолжительность экзамена: 90 минут
Ориентировочная стоимость: 7370 рублей

Проверяются познания в областях:

  • Ядро Linux
  • Запуск системы
  • Файловые системы
  • Железо
  • Обслуживание системы
  • Автоматизация и настройка системы
  • Разрешение проблем


Экзамен: 117-202: LPI Level 2 Exam 202
Продолжительность экзамена: 90 минут
Ориентировочная стоимость: 7370 рублей

  • Сеть
  • Почта и новости
  • DNS
  • Сервисы Web
  • Управление сетевыми клиентами
  • Безопасность системы
  • Разрешение проблем с сетью

LPIC-3 (Senior Level Linux Professional)

Для прохождения уровня LPIC-3, нужно иметь статус Advanced Level Linux Professional (LPIC-2).

Экзамен: 117-301: LPI Level 3 Exam 301
Продолжительность экзамена: 90 минут
Ориентировочная стоимость: 11970 рублей

  • Аутентификация
  • Расчёт производительности
  • LDAP
  • Настраиваемые модули аутентификации
  • Разрешение проблем
  • Интеграция с ключевыми сервисами сети


Экзамен: 117-302: LPI Level 3 Exam 302
Продолжительность экзамена: 90 минут
Ориентировочная стоимость: 7370 рублей

  • Файловые сервисы в сети
  • Сервис сетевой печати
  • Samba
  • Концепции SMB/CIFS
  • Работа со смешанными системами
  • Интеграция с ключевыми сервисами сети

Таким образом, полная стоимость 3-х уровневой сертификации LPIC составляет 48820 рублей.

3. SAIR Linux GNU Certification

Система сертификации SAIR Linux GNU Certification так же является вендоронезависимой и подобно LPIC имеет 3 уровня: Linux Certified Administrator, Linux Certified Engineer, Master Linux Certified Engineer. Правда, в отличие от LPIC, для прохождения каждого уровня придётся сдать уже не 2, а целых 4 экзамена. Ориентировочная стоимость одного экзамена по курсам LCA и LCE составляет 3 780 рублей. Трек MLCE, в настоящий момент, всё ещё в стадии разработки...

Linux Certified Administrator

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

Для получения статуса Linux Certified Administrator потребуется сдать следующие экзамены:

Экзамен: 3X0-101: Linux Installation and Configuration
Продолжительность экзамена: 60 минут

Экзамен: 3X0-102: Linux System Administration
Продолжительность экзамена: 60 минут

Экзамен: 3X0-103: Linux Networking
Продолжительность экзамена: 60 минут

Экзамен: 3X0-104: Linux Security, Privacy & Ethics
Продолжительность экзамена: 60 минут

Linux Certified Engineer

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

Необходимые экзамены:

Экзамен: 3X0-201: Core Concepts and Practices
Продолжительность экзамена: 60 минут

Экзамен: 3X0-202: Apache Webserver
Продолжительность экзамена: 60 минут

Экзамен: 3X0-203: Samba Resource Sharing
Продолжительность экзамена: 60 минут

Экзамен: 3X0-204: Sendmail Mail Systems
Продолжительность экзамена: 60 минут

Master Linux Certified Engineer

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

Необходимые экзамены:

Экзамен: 3X0-301: Linux High Availability

Экзамен: 3X0-302: Postgres, MySql Databases

Экзамен: 3X0-303: В разработке

Экзамен: 3X0-304: В разработке

4. Сертификация RedHat

Пожалуй, наиболее известная система среди Linux-сертификаций. Активно развивается и продвигается фирмой-создателем одноимённого дистрибутива. На сегодняшний день, сертификация RedHat включает в себя 4 ступени: Red Hat Certified Technician (RHCT), Red Hat Certified Engineer (RHCE), Red Hat Certified Specialist, Red Hat Certified Architect (RHCA).

Red Hat Certified Technician (RHCT)

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

Экзамен: RH202: RHCT Exam
Продолжительность экзамена: 4 часа
Ориентировочная стоимость: 6500 рублей

Red Hat Certified Engineer (RHCE)

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

Экзамен: RH302: RHCE Exam
Продолжительность экзамена: 8 часов
Ориентировочная стоимость: 14500 рублей

Red Hat Certified Specialist

На данном уровне можно выбрать любую из двух сертификаций: Red Hat Certified Datacenter Specialist (RHCDS) или Red Hat Certified Security Specialist (RHCSS). Каждая из них требует сдачи трёх экзаменов.

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

Red Hat Certified Datacenter Specialist (RHCDS)

Экзамен: EX401: Корпоративное развертывание и управление системами Red Hat
Продолжительность экзамена: 8 часов

Экзамен: EX423: Корпоративные сервисы каталогов и аутентификации Red Hat
Продолжительность экзамена: 8 часов

Экзамен: EX436: Управление хранением данных на предприятии
Продолжительность экзамена: 8 часов

Red Hat Certified Security Specialist (RHCSS)

Экзамен: EX333: Безопасность на предприятии: Red Hat Enterprise Linux - Сетевые службы
Продолжительность экзамена: 8 часов

Экзамен: EX423: Корпоративные сервисы каталогов и аутентификации Red Hat
Продолжительность экзамена: 8 часов

Экзамен: EX429: Администрирование политик SELinux в Red Hat Enterprise Linux
Продолжительность экзамена: 8 часов

Red Hat Certified Architect (RHCA)

Сертификация ориентирована на архитекторов, людей разрабатывающих и внедряющих инфраструктурные решения на базе RedHat Linux для крупных компаний. Необходимо сдать 5 экзаменов:

Экзамен: EX333: Безопасность на предприятии: Red Hat Enterprise Linux - Сетевые службы
Продолжительность экзамена: 8 часов

Экзамен: EX401: Корпоративное развертывание и управление системами Red Hat
Продолжительность экзамена: 8 часов

Экзамен: EX423: Корпоративные сервисы каталогов и аутентификации Red Hat
Продолжительность экзамена: 8 часов

Экзамен: EX436: Управление хранением данных на предприятии
Продолжительность экзамена: 8 часов

Экзамен: EX442: Мониторинг и настройка производительности промышленных систем Red Hat
Продолжительность экзамена: 8 часов

Главным отличием сертификации RedHat от остальных является то, что вместо тестовых заданий «вопрос-ответ», здесь нужно выполнять лабораторные работы на реальных системах, что несомненно является большим плюсом.

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

источник: www.oslinux.ru

понедельник, 13 апреля 2009 г.

Обнаружение червя Conficker через пассивный анализ трафика

С конца 2008 года червь Conficker, поражающий Windows-клиентов, заразил несколько миллионов машин в сети,
занимая первые позиции в рейтингах антивирусных компаний.

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

1. Сниффинг сигнатуры червя через утилиту ngrep (http://ngrep.sourceforge.net/):


ngrep -qd eth0 -W single -s 900 -X
0xe8ffffffffc25f8d4f108031c4416681394d5375f538aec69da04f85ea4f84c84f84d84fc44f9ccc497365c4c4c42cedc4
c4c494263c4f38923bd3574702c32cdcc4c4c4f71696964f08a203c5bcea953bb3c096969592963bf33b24699592514f8ff8
4f88cfbcc70ff73249d077c795e44fd6c717cbc404cb7b040504c3f6c68644fec4b131ff01b0c282ffb5dcb61f4f95e0c717
cb73d0b64f85d8c7074fc054c7079a9d07a4664eb2e244680cb1b6a8a9abaac45de7991dacb0b0b4feebeb
'tcp port 445 and dst net 192.168.0.0/16'

конструкцию нужно переписать одной строкой


2. Сканирование компьютеров с использованием готовой маски из комплекта последней версии nmap ( nmap-4.85BETA6):

nmap -PN -T4 -p139,445 -n -v --script=smb-check-vulns --script-args safe=1 192.168.1.0/24

или оптимизировав запрос для сканирования сети большого объема:

nmap -sC -PN -d -p445 -n -T4 --min-hostgroup 256 \
--min-parallelism 64 --script=smb-check-vulns \
--script-args=safe=1 192.168.0.0/16

3. Проверить зараженность отдельной машины можно через специально подготовленный Python скрипт.

wget http://iv.cs.uni-bonn.de/uploads/media/scs.zip
unzip scs.zip
./scs.py 192.168.1.100

четверг, 9 апреля 2009 г.

Системы управления версиями для Linux

Системы управления версиями (VCS) или Системы управления исходным кодом (SMS) - важный аспект разработки современного ПО. Его неиспользование сродни вождению машины слишком быстро: это смешно, и вы можете попасть в пункт назначения быстрее, но катастрофа неизбежна. Эта статья дает обзор систем Управления Конфигурации ПО (SCM) и их преимущества, включая CVS, Subversion, Arch и Git. Наконец, она рассматривает некоторые из новых подходов, которые пригодны и как они отличаются от прежних методов. [Листинг 4 был обновлен в соответствии с улучшениями синтаксиса Git

Что такое управление конфигурацией ПО?

SCM - одно из тех важнейших средств, которое вы, возможно, не изучали в школе. Как следует из названия, управление ПО (или исходным кодом) - это средство и соответствующий процесс, используемый для поддержки исходного кода и его изменения с течением времени. SCM предоставляет следующие возможности:

  • Поддержка файлов в репозитории
  • Поддержка проверки файлов в репозитории
  • Нахождение конфликтов при изменении исходного кода и обеспечение синхронизации при работе в многопользовательской среде разработки
  • Отслеживание авторов изменений
  • Возможность управления конфигурацией файлов (в частности, проверки) для совместимых и повторяющихся сборок.
Область применения SCM
Контроль исходного кода (source control) обычно подразумевает управление исходным кодом и связанными с ним файлами, тогда как управление исходным кодом (source management) может применяться к любым типам ресурсов. Веб-сайт, состоящий из HTML файлов и файлов изображения, обычных текстовых документов, и файлов любого другого типа, является кандидатом на управление версиями с помощью SCM систем.

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

Язык SCM

Прежде чем глубоко нырнуть в детали и типы архитектур для SCM, вам нужно выучить словарь. Первый термин - репозиторий (repository). Репозиторий - это центральное место, где хранятся файлы (иногда его называют деревом [tree]). Извлечение файлов из репозитория в рабочую директорию вашей локальной системы называется выгрузка (check-out). Если вы делаете изменения в файлах локально, для их синхронизации с изменениями файлов в репозитории, вам нужно зафиксировать (commit) изменения. Если ваш измененный файл до этого был изменен кем-то еще, произойдет объединение изменений, то есть два набора изменений будут сведены вместе. Если объединение невозможно из-за конфликтующих изменений в файле, возникнет конфликт (conflict). В такой ситуации, commit отклоняется и разработчику приходится согласовывать изменения вручную. Когда изменения зафиксированы, создается новая версия (revision)файла.

У одного или нескольких разработчиков есть возможность работать вне главного дерева (текущего корня репозитория), а именно, в персональной ветке (branch). Это позволяет разработчикам испытывать какие-то процессы в своих ветках, не влияя на главное дерево. Когда они станут стабильными, их можно соединить с главным деревом.

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


Архитектуры

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

  • Централизованные vs. Рассредоточенные репозитории
  • Метод "изменений" vs. Метод "моментального снимка"

Централизованные vs. Рассредоточенные репозитории

Одно из наиболее важных архитектурных различий в современных SCM, которое вы можете увидеть и ощутить в своей работе - это идея централизованных репозиториев против рассредоточенных (или нецентрализованных). Наиболее распространенной архитектурой в наши дни является архитектура с централизованным репозиторием. Данная "звездная" (star) архитектура изображается как центральный репозиторий ресурсов и множество разработчиков работающих с ним (см. рисунок 1). Разработчик выгружает код из центрального репозитория на локальную машину (check out), и после внесения изменений, фиксирует их и загружает обратно в центральный репозиторий (commit), таким образом, и другие разработчики имеют доступ к его изменениям.


Рисунок 1. При централизованной архитектуре все разработчики работают с центральным репозиторием.
Централизованная архитектура SCM

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

Рассредоточенная архитектура позволяет разработчикам создавать свои собственные локальные репозитории для своих изменений. Локальный репозиторий разработчика такой же, как и исходный репозиторий ресурсов (который был). Ключевым отличием является то, что рассредоточенный подход позволяет разработчикам работать со своими изолированными репозиториями, а не с локальными машинами. Они могут делать изменения, вносить их в свои локальные репозитории и синхронизировать изменения с другими разработчиками, не трогая главную ветку. Затем разработчики могут сделать набор изменений, доступный своим "вышестоящим" коллегам (см. рисунок 2).


Рисунок 2. В нецентрализованной архитектуре разработчики работают, не синхронизуясь друг с другом, в своем собственном репозитории.
Децентрализованная архитектура SCM

Нецентрализованная архитектура интересна тем, что независимые разработчики могут работать асинхронно в одноранговой сети (peer to peer). Когда работа закончена (и достаточно стабильна), они могут сделать набор своих изменений (или исправлений) доступным всем остальным. Такая модель в наши дни широко используется в разработке систем с открытым кодом, включая ядро Linux® kernel.

Модель "моментальных снимков" (snapshot model) против Модели "набора изменений" (changeset model)

Другое интересное архитектурное отличие старых SCM от более современных - способ хранения изменений. Теоретически системы одинаковы и дают один и тот же результат, но различаются тем, как хранятся версии файлов (revision).

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


Рисунок 3. Каждая из моделей ("снимков" и "наборов изменений") имеет свои преимущества.
Модель изменений vs. модель моментальных снимков

Как вы видите из рисунка 3, модели отличаются, но в конечном итоге мы получаем одинаковый результат. В модели "моментальных снимков", вы можете получить версии быстро, но вам потребуется больше места, чтобы хранить их. Модель "набор изменений" потребует меньше места, но займет больше времени, для получения определенной версии, потому что ошибка должна быть учтена в основной версии. Как вы потом увидите, вы можете делать оптимизацию, чтобы минимизировать число ошибок, которые учитываются в модели.

Примеры SCM

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

CVS

Concurrent Versions System (CVS) - одна из наиболее распространенных сегодня SCM. Она имеет централизованную архитектуру с моделью "набора изменений", в которой разработчики работают с центральным репозиторием при совместной разработке программного обеспечения. CVS используется повсеместно и она доступна как стандартная часть любого дистрибутива Linux. Благодаря своему простому и удобному (для многих из нас) синтаксису, она является популярным выбором как при одиночной, так и командной разработке.

Листинг 1 демонстрирует набор простых CVS команд с кратким описанием каждой. Для более подробной информации, обратитесь к секции Ресурсы .


Листинг 1. Примеры команд для CVS
   
# Создать новый репозиторий
cvs -d /home/user/new_repository init

# Подсоединиться к корневому репозиторию
export CVSROOT=:pserver:user@example.com:/cvs_root

# Выгрузить блок для модуля из корневого репозитория
cvs checkout project

# Обновить локальный блок из корневого репозитория
cvs update

# Внести изменения из локального блока в коневой репозиторий
cvs commit

# Добавить новые файлы в локальный блок
cvs add

# Показать изменения, сделанные в локальном блоке
cvs diff

Для любителей интерфейса с использованием координатного указателя ("мышиный" интерфейс) в CVS есть большое количество графических интерфейсов с открытым кодом, которые вы можете использовать, например, WinCVS и TortoiseCVS (которая интегрируется с Microsoft Windows Explorer, если вам это удобно).

Несмотря на повсеместное использование, CVS имеет свои недостатки. CVS не позволяет переименовывать файлы, также она имеет недостатки при работе с определенными файлами, например, с символьными ссылками. Изменения, отслеживаемые самим файлом, могут иногда надоедать. Синхронизация может быть иногда проблематична (CVS внутри использует diff3 для этой цели).

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

Subversion

Subversion (SVN) была разработана как прямая замена CVS, но без свойственных CVS заранее определенных выпусков. Как и CVS, Subversion - централизованное решение и использование модели "моментального снимка". Ее команды, похожие на те же команды CVS, но с новыми дополнениями, хорошо управляются с такими вещами, как удаление файлов, перенаименование файлов или возврат к оригинальному файлу.

Subversion также позволяет удаленный доступ посредством большого количества протоколов, таких как протокол HTTP, протокол безопасности HTTP, или протокол, выполненный по заказу SVN, который также поддерживает туннелирование через Оболочку Безопасности [SSH].

Листинг 2 показывает некоторые из команд, поддерживаемые в Subversion. Мы также включили некоторые из расширений, которые не пригодны для CVS. Посмотрите раздел Ресурсы для более детальной информации о Subversion. Как вы видите, набор команд Subversion действительно похож на набор команд CVS, обеспечивая хорошую альтернативу для CVS-пользователей.


Листинг 2. Примеры команд для Subversion
   
# Создать новый репозиторий
svnadmin create /home/user/new_repository

# Выгрузить блок из корневого репозитория
svn checkout file:///server/svn/existing_repository new_repository

# Обновить локальный блок из корневого репозитория.
svn update

# Внести изменения из локального блока в корневой репозиторий.
svn commit

# Добавить новые файлы в локальный блок
svn add

# Показать изменения, сделанные в локальном блоке
svn diff

#Переименовать файл в локальном блоке
svn rename

# Удалить файлы
svn delete

Следуя традициям CVS, Subversion использует в работе графический внешний интерфейс, такой как ViewCVS and TortoiseSVN. Существуют также средства конвертировать репозиторий CVS в Subversion (такие как cvs2svn.py), но они, как сообщают, управляются не со всем набором ответвлений и сопровождений данных тегами в случаях сложных репозиториев. Учитывая все Open Source проекты, со временем ситуация улучшится. Subversion также использует в работе TortoiseMerge в качестве различия между средствами отображения и исправления.

В Subversion фиксированое число выпусков, испытанных CVS пользователями, такие как организация разработки новых поколений определенных файлов, мелких действий и отладок. Если вам нравится CVS и вам нравится подход центрального репозитория, то Subversion - это SCM для вас.

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

Arch

Arch - это подробное детализированное описание для децентрализированной SCM, которое предлагает множество различных моделей. Они включают в себя ArX, Bazaar, GNU Arch, и Larch. Arch не только оперирует как децентрализованная SCM (как показано на рисунке 2), но также использует модель "набора изменений" (рисунок 3). Arch SCM - популярный метод для разрабоки Open Source, поскольку разработчики смогут создавать в отдельных репозиториях с полным контролем исходного кода. Это происходит потому что рассредоточенные репозитории - действующие репозитории, дополненные контролем проверок (revision). Вы можете создавать patch из изменений в локальной репозитории, используемом вышестоящим разработчиком. Это большое преимущество децентрализованной модели.

Как и Subversion, Arch корректирует число выпусков в CVS. Они включают в себя изменения метаданных, такие как пересматривание разрешений файла, обработка удаления и переименования файлов, и небольшие сравнения (слияние сравнений вместо отдельно действующих сравнений).

Листинг 3 показывает некоторые из команд, которые вы найдете в Arch SCM. Мы продемонстрировали здесь GNU arch, так как он разработан архитектором Arch, Томом Лордом. GNU arch обеспечивает базу, которую вы ждете от SCM, включая новейшие опции, имеющиеся в Subversion.


Листинг 3. Примеры команд для GNU arch (tla)
   
# Регистрация публичного архива
tla register-archive http://www.mtjones.com/arch

# Выгрузка локального репозитория из вышестоящего.
tla get project@mtjones.com--dev/project--stable myproject

# Обновление из локального репозитория.
tla update

# Внесение изменений в локальный репозиторий.
tla commit

# Добавление новых файлов в локальный репозиторий.
tla add

# Показать изменения, сделанные в локальном репозитории.
tla what-changed

# Переименовать файл в локальном репозитории.
tla mv

# Удалить фaйлы (также удалить из репозитория)
tla rm

Arch также позволяет синхронизировать изменения от вышестоящих репозиториев. Чтобы минимизировать число исправлений, которые нужно будет применить к основной проверке (посредством модуля "набора изменений"), команда "cacherev" создаст новый "моментальный снимок" основной проверки в репозитории.

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

Наибольший протест от новых пользователей tla вызвала некоторая запутанность Arch. Другие действия Arch, такие как baz, как говорят эксперты, полегче. Вы можете рассматривать их, если tla не удовлетворит ваши требования.

Теперь рассмотрим окончательную децентрализованную SCM, написанную разработчиком ядра Linux собственноручно, Линусом Торвальдом.

Git

Git SCM был разработан Линусом Торвальдом как прямая замена для Bitkeeper SCM (см. секцию Ресурсы Это очень просто, но это стоит работы децентрализованной SCM, основанной на методе "набора изменений" и используется как SCM для ядра Linux. Он использует модель группировки файлов больше, чем отслеживание отдельными файлами. Изменения сжаты и раздроблены с помощью SHA1, подтверждая их целостность. (см. листинг 4)


Листинг 4. Примеры команд для Git
   
# Получить Git репозиторий (впервые)
git clone \
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git


# Обновить Git репозиторий из определенного вышестоящего Git репозитория
git pull

# Выгрузить из Git репозитория в локально работающий репозиторий.
git checkout

# Добавить изменения в локальный Git репозиторий
git commit

# Внести изменения в вышестоящий (потребует SSH доступ к вышестоящему
git push

# Добавить новые файлы в локальный репозиторийires (commit)
git add

# Показать изменения, сделанные в локально работающей дирктории
git diff

# Удалить файлы
git rm

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

Вы можете спросить, почему не рассматриваем ни одну из существующих SCM, кроме тех, которые описаны здесь? Это хороший вопрос. Git интересен и сохраняет большую пользовательскую базу разработчиков ядра Linux, поэтому это могло быть следующей большой SCM. Линус описывает Git как очень быстрого менеджера содержимого директории, который хоть и не делает много, но делает это эффективно.

Преимущества

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

Используете ли вы централизованный или рассредоточенный репозиторий, модель "снимка" или "изменений", преимущества одинаковы. Так как разработка современного ПО не обходится без SCM, используйте SCM заблаговременно и используйте его часто!

Взгляд в будущее

Эта статья - поверхностный взгляд на SCM в его использовании на сегодняшний момент. Существует много других Open Source SCM, включая Aegis, Bazaar-NG, DARCS, и Monotone, к примеру. Как редакторы и языки, SCM могут быть неясными, поскольку они редко используются в изоляции, и, таким образом, обычно выбираются командами больше, чем в индивидуальном порядке (если у вас не особо властный начальник, который любит принимать решения за вас). Поэтому, играйте с возможностями и развивайтесь в разных направлениях. SCM - необходимый инструмент в разработке ПО и значительная часть вашего технической панели инструментов.

Администрирование Linux на лету

Файловая система /proc - это одна из величайших особенностей Linux и эта статья проведет вас по наиболее полезным ее аспектам. С ней вы сможете администрировать многие детали вашей системы без необходимости перезагрузки машины.

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

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

Внимание: Эта статья написана для ядер серии 2.4-х. Некоторые опции и возможности могут отличаться в ядрах других серий.

Изменение параметров работающего ядра

Linux имеет отличный способ изменять параметры ядра во время работы системы и без необходимости перезагрузки. Это делается при помощи виртуальной файловой системы /proc. Linux Gazette дает один из простейших и легчайших объяснений /proc, которые я когда-либо видел. (см. Источники.) Вкратце, файловая система /proc дает вам возможность заглянуть в работающее ядро, что может быть полезно для мониторинга производительности, проверки системной информации, конфигурирования системы и изменения конфигурации. Эта файловая система называется виртуальной, потому что это в действительности не файловая система. Это карта, создаваемая ядром и присоединяемая к вашей обычной файловой системе, чтобы обеспечить доступ.

Тот факт, что мы можем разными способами внести изменения в ядро во время работы системы дает системному администратору огромную мощь и гибкость при изменении параметров. Но может быть слишком много власти это плохо? Иногда. Если вы собираетесь внести изменения в файловую систему /proc, вы должны быть уверены, что вы знаете, что вы делаете и какой эффект произведут на систему ваши действия. Это очень полезная техника, но одно неверное движение может вызвать неожиданные последствия. Если вы не уверены и новичок в таких делах, попрактикуйтесь на машине с меньшей важностью для ваших дел.


Как вносить изменения

Сначала, подумайте о том, как не вносить изменения в ядро. Есть две отличных причины, почему вам не стоит просто перейти в /proc, открыть файл в текстовом редакторе, сделать несколько изменений и сохранить файл. Вот они:

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

Ответом на это является не использование текстового редактора для внесения изменений. Поэтому для внесения изменения в что-либо в файловой системе /proc, вам следует использовать команду echo и перенаправлять вывод команды в выбранный файл в /proc. Например:

echo "Your-New-Kernel-Value" > /proc/your/file

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

Что изменять

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

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

  • Read-only: Файл не может быть изменен ни каким пользователем; используется для представления системной информации
  • Root-write: Если файл может быть изменен, то изменения может вносить только пользователь root
  • Root-read: Некоторые файлы могут быть не читаемы для обычных пользователей системы, только для root
  • Other: Вы можете найти другие комбинации, чем перечисленные выше, по различным причинам

В основном в /proc вы найдете файлы read-only за исключением /proc/sys, которая содержит большинство параметров ядра и предназначена для изменения во время работы системы. Как результат в этой статье рассматривается в основном эта директория.

Последнее, что вам нужно знать о изменении файлов в /proc - это то, что нужно записывать в эти файлы. Вы заметите, что некоторые из файлов могут быть легко прочитаны человеком, а некоторые являются файлами данных и могут быть прочитаны только при специальных утилит таких как top, lspci,и free. Вы также заметите, что эти легко читаемые файлы имеют два различных формата: некоторые являются бинарными ключами, а другие содержат больше информации. Файлы с бинарными ключами содержат только 0 (выключено) или 1 (включено) для некоторых функций ядра.

Внесение изменений

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

/proc/scsi

/proc/scsi/scsi
Одна из наиболее полезных вещей, которые нужно знать администратору - как добавить дисковое пространство, если у вас есть диски горячей замены без перезагрузки системы. Без использования /proc, вы должны вставить ваш диск, но затем вам придется перезагружать систему для того, чтобы дать ей возможность распознать новый диск. Вы можете позволить системе распознать новый диск с помощью следующей команды:

echo "scsi add-single-device w x y z" > /proc/scsi/scsi

Чтобы эта команда работала правильно, вы должны указать параметры значений w, x, y, и z следующим образом:

  • w - это ID хост адаптера, где первый адаптер имеет ID ноль (0))
  • x - это канал SCSI на хост адаптере, где первый канал ноль (0)
  • y - это SCSI ID устройства
  • z - это номер LUN, где первый LUN ноль (0)

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

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

echo "scsi remove-single-device w x y z" > /proc/scsi/scsi

Перед тем как ввести эту команду и удалить SCSI диск, убедитесь, что вы отмонтировали файловые системы на этом диске.

/proc/sys/fs/

/proc/sys/fs/file-max
Здесь указывается максимальное количество заголовков файлов, которое может быть одновременно открыто. Вам может понадобиться увеличить это число если пользователи получают сообщение об ошибке потому что достигнуто максимальное количество открытых файлов. Можно указать любое числовое значение в этом файле.

Default setting: 4096

/proc/sys/fs/file-nr
Этот файл связан с file-max и содержит три значения:

  • Количество назначенных заголовков файлов
  • Количество используемых заголовков
  • Максимальное число заголовков
Этот файл только для чтения и только для предоставления информации.

/proc/sys/fs/inode-*
Любые файлы, начинающиеся с "inode" будут выполнять те же функции, что и файлы с именем "file" выше, но выполняют эти операции относительно inodes вместо заголовков файлов.

/proc/sys/fs/overflowuid and /proc/sys/fs/overflowgid
Эти файлы содержат User ID (UID) и Group ID (GID) для любой файловой системы, которая поддерживает 16-bit user и group ID. Эти значения могут быть изменены, но если вы действительно считаете это нужным, то более простым будет изменить файл группы и пароля группы вместо этого.

Default Setting: 65534

/proc/sys/fs/super-max
Здесь указывается максимальное количество заголовков суперблоков. Любая файловая система, которую вы монтируете должна использовать суперблоки, так что вам, возможно, придется использовать его если вы монтируете много файловых систем.

Default setting: 256

/proc/sys/fs/super-nr
Здесь указано текущее значение количества суперблоков. Этот файл только для чтения и используется для информации.

/proc/sys/kernel

/proc/sys/kernel/acct
Здесь содержатся три конфигурируемых значения, которые управляют подсчетом процессов, основанном на свободном пространстве (в процентах) файловой системы и ведет лог:

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

Default setting: 2 4 30

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

/proc/sys/kernel/ctrl-alt-del
Этот файл содержит двоичное значение, которое управляет тем, как система реагирует на комбинацию ctrl+alt+delete. Возможны два значения:

  1. Ноль (0) значит, что ctrl+alt+delete принимается и отправляется программе init. Это позволит выполнить системе мягкую остановку и перезагрузку как если бы вы ввели команду shutdown.
  2. Один (1) значит, что ctrl+alt+delete не принимается и никакого чистого отключения не происходит как если бы вы просто выключили питание.

Default setting: 0

/proc/sys/kernel/domainname
Здесь вы можете сконфигурировать ваше сетевое доменное имя. Значения по умолчанию нет и оно может быть, а может и не быть установлено.

/proc/sys/kernel/hostname
Здесь вы можете сконфигурировать ваше сетевое имя хоста. Значения по умолчанию нет и оно может быть, а может и не быть установлено.

/proc/sys/kernel/msgmax
Здесь определяется максимальный размер сообщения, которое может быть отправлено от одного процесса другому. Сообщения между процессами в памяти ядра не копируются на диск, так что если вы увеличите это значение, то вы увеличите количество памяти используемой операционной системой.

Default setting: 8192

/proc/sys/kernel/msgmnb
Здесь указывается максимальное количество байт в одном сообщении.

Default setting: 16384

/proc/sys/kernel/msgmni
Здесь указывается максимальное количество идентификаторов сообщений в очереди.

Default setting: 16

/proc/sys/kernel/panic
Здесь установлено время в секундах, которое ядро будет ждать перед перезагрузкой если произойдет "kernel panic." Установка в ноль (0) секунд отключит возможность перезагрузки при kernel panic.

Default setting: 0

/proc/sys/kernel/printk
Здесь четыре числовых значения, которые определяют куда будут отправлены сообщения логов, в зависимости от их важности. За более подробной информацией о различных уровнях логов отправляейтесь в man syslog(2). Четыре значения это:

  1. Console Log Level: сообщения с высшим приоритетом, чем это будут выведены на консоль
  2. Default Message Log Level: сообщения без приоритета будут напечатаны с этим приоритетом
  3. Minimum Console Log Level: минимальное (высочайший приоритет) значение, в которое может быть установлен Console Log Level
  4. Default Console Log Level: значение по умолчанию для Console Log Level

Default setting: 6 4 1 7

/proc/sys/kernel/shmall
Это общее количество разделяемой памяти (в байтах), которое может быть использовано в системе.

Default setting: 2097152

/proc/sys/kernel/shmax
Здесь указывается наибольший размер сегмента памяти (в байтах) позволяемый ядром.

Default setting: 33554432

/proc/sys/kernel/shmmni
Этот файл связан с максимальным числом сегментов раздляемой памяти всей системы.

Default setting: 4096

/proc/sys/kernel/sysrq
Активирует System Request Key, если не равно нулю.

Default setting: 0

/proc/sys/kernel/threads-max
Максимальное число потоков, которое может быть использовано ядром.

Default setting: 2048

/proc/sys/net

/proc/sys/net/core/message_burst
Это время (в десятых долях секунды) необходимое для записи нового предупреждения; другие предупреждения, полученные в это время будут пропущены. Это используется для предотвращения атаки Denial of Service, которая может быть выполнена при заваливании вашей системы сообщениями.

Default setting: 50 (5 seconds)

/proc/sys/net/core/message_cost
Здесь указывается значимость каждого предупреждения. Чем выше значение, тем больше предупреждений будет проигнорировано.

Default setting: 5

/proc/sys/net/core/netdev_max_backlog
Здесь указывается максимальное количество пакетов в очередь на обработку если интерфейс получает пакеты быстрее, чем ядро может их обработать.

Default setting: 300

/proc/sys/net/core/optmem_max
Здесь указан максимальный размер буфера для одного сокета.

/proc/sys/net/core/rmem_default
Здесь размер буфера для получаемого сокета по умолчанию (в байтах).

/proc/sys/net/core/rmem_max
Это максимальный размер буфера для получаемого сокета (в байтах).

/proc/sys/net/core/wmem_default
Это размер буфера отправляемого сокета по умолчанию (в байтах).

/proc/sys/net/core/wmem_max
Это максимальный размер буфера посылаемого сокета (в байтах).

/proc/sys/net/ipv4
Все параметры IPv4 и IPv6 полностью документированы в документации к ядру. Смотри файл /usr/src/linux/Documentation/networking/ip-sysctl.txt.

/proc/sys/net/ipv6
То же что и IPv4.

/proc/sys/vm

/proc/sys/vm/buffermem
Здесь происходит управление количеством общей системной памяти (в процентах), которая будет использована как буферная память. Файл содержит три значения, которые могут быть указаны в виде списка через пробел:

  1. Минимальный процент памяти, которая будет использована для буфера
  2. Система будет пытаться установить это количество памяти для буфера если количество доступной памяти будет уменьшено
  3. Максимальный процент памяти, которая будет использована для буферов

Default setting: 2 10 60

/proc/sys/vm/freepages
Этот файл управляет как система реагирует на различные уровни свободной памяти. Содержит три значения, которые могут быть установлены в виде списка, разделенного пробелами:

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

Default setting: 512 768 1024

/proc/sys/vm/kswapd
Этот файл управляет как ядро будет свопировать память. Он содержит три значения в виде списка, разделенные пробелами:

  1. Максимальное количество страниц, которое ядро пытается освободить за один раз. Если вы хотите увеличить величину свопирования, вам нужно увеличить это значение.
  2. Минимальное количество раз, которое ядро пытается освободить страницу в время своппинга.
  3. Количество страниц, которое ядро может записать в один своп. Оказывает сильное влияние на производительность системы. Чем больше это значение, тем больше данных будет свопировано и тем меньше времени будет потрачено на поиск на диске. Однако, слишком большое значение окажет обратных эффект на производительность системы из-за увеличения очереди запросов.

Default setting: 512 32 8

/proc/sys/vm/pagecache
Этот файл выполняет ту же работу, что и /proc/sys/vm/buffermem, но он делает ее для карты памяти и общего кэширования файлов.

Выполнение постоянных установок ядра

Полезная утилита для внесения изменений в любые параметры ядра находится в директории /proc/sys. Она позволяет вам вносить изменения в работающее ядро (подобно echo и метод перенаправления, описанный выше), и имеет файл конфигурации, который выполняется при загрузке. Это позволяет чтобы внесенные изменения оставались в ядре после перезагрузки системы. Утилита называется sysctl и она полностью документирована в man sysctl(8).

Файл конфигурации для sysctl - /etc/sysctl.conf, который может быть редактирован, синтаксис файла описан в man sysctl.conf(8). Sysctl использует файлы в /proc/sys как индивидуальные переменные, которые могут быть изменены. Например, файл в /proc/sys, который представляет максимальное количество заголовков файлов в системе, /proc/sys/fs/file-max, представлен как fs.file-max. Этот пример требует некоторых дополнительных пояснений в записи sysctl. Так как sysctl может только изменять переменные в директории /proc/sys, то часть имени переменной обозначающая директорию отбрасывается. Другое изменение касается слэшей, которые заменяются на точки. Вот два простых правила для преобразования файлов в /proc/sys и переменных в sysctl:

  • Отбросьте /proc/sys от начала.
  • Замените слэши на точки в имени файла.

Эти два правила позволят вам преобразовать любой файл в /proc/sys в любое имя переменной в sysctl. Обычное преобразование имени файла в переменную:

/proc/sys/dir/file --> dir.file
dir1.dir2.file --> /proc/sys/dir1/dir2/file

Вы можете увидеть все переменные, доступные для изменения, используя команду sysctl -a. Переменные могут также быть изменены с помощью sysctl, которая выполняет ту же работу что и echo. Эта запись объясняет это:

sysctl -w dir.file="value"

Используя пример с file-max, мы можем изменить это значение на 16384, используя один из двух методов:

sysctl -w fs.file-max="16384"

Или:

echo "16384" > /proc/sys/fs/file-max

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

Внимание: Не все дистрибутивы обеспечивают поддержку sysctl. Если это относится к вашей системе, то вы можете использовать echo и метод перенаправления, как описано выше и добавить эти команды в загрузочный скрипт, чтобы они выполнялись каждый раз при загрузке системы.

Команды для настройки системы

Есть возможность изменять другие параметры (не ядра) во время работы системы и сделать, чтобы эти изменения оказали эффект без перезагрузки системы. В основном это сервисы, демоны и серверы, которые прописаны в директории /etc/init.d. Поскольку в этой директории находится широкий спектр скриптов, то нет возможности рассмотреть их все здесь. Однако, ниже будут приведены несколько примеров того, как можно манипулировать этими скриптами в различных дистрибутивах Linux. Примеры изменения демона и перезагрузки конфигурации без перезагрузки системы могут быть полезны при:

  • Изменении конфигурации Web сервера и перезагрузки Apache
  • Удаления загружаемого в inetd сервиса, которым вы не пользуетесь
  • Манипулирования настройками вашей сети
  • Экспортирования новой файловой системы через NFS
  • Запуска/остановки вашего файервола

Сначала, основной способ манипулирования системными сервисами через скрипты в /etc/init.d. Эти скрипты используют параметры для управления своими сервисами. Вы можете ввести в командной строке имя сервиса без параметров чтобы увидеть допустимые параметры. Общие параметры таковы:

  • start: Запускает остановленный сервис
  • stop: Останавливает запущенный сервис
  • restart: Останавливает и затем запускает сервис; запускает остановленный сервис
  • reload: Перезагружает конфигурацию сервиса без прерывания его соединения
  • status: Выводит информацию запущен сервис или нет

В качестве примера следующая команда перезагрузит конфигурацию вашего xinetd без прерывания любых присоединенных сессий пользователей (полезно, если вы вносите изменения в ваш /etc/xinetd.conf):

/etc/init.d/xinetd reload

Red Hat предоставляет комнанду service, которая будет управлять сервисом для вас. Команда service выполняет те же действия, что и ввод имени скрипта. Синтаксис команды:

service script-name [parameter]

Пример:

service xinetd reload

SuSE также предоставляет команду rc. Она похожа на service, но не имеет пробела между командой и именем скрипта. Синтаксис команды:

rc{script-name} parameter

Пример:

rcapache start

Так же как и при изменении параметров ядра, при перезагрузке системы, все внесенные изменения будут потеряны. Многие дистрибутивы позволяют использовать команду chkconfig, которая управляет сервисами, запускаемыми на различных уровнях (включая загрузку). Во время написания статьи синтаксис команды chkconfig несколько отличался в различных версиях Linux, но если вы введете команду chkconfig без параметров, вы получите список возможных параметров и их использование. Больше информации о chkconfig может быть получено в man chkconfig(8).

Заключение

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

План перехода с Windows на Linux: Часть 9. Установка программного обеспечения

В этом пособии Крис Волден, автор состоящей из 9 частей серии пособий от developerWorks по переходу с Windows на Linux, расскажет, что такое RPM, научит загружать и компилировать пакеты, опишет плюсы и минусы автоматизированного управления пакетами.

Одна из первых вещей, на которые вы обращаете внимание при установке Linux -- это большое количество входящих в дистрибутив пакетов. Большинство дистрибутивов содержат операционную систему Linux, средства для инсталляции и средства администрирования. Кроме того, в них включаются средства для работы в Интернете, средства разработки, офисные пакеты, игры, а также некоторые средства, о которых вы даже не слышали. Дистрибутивы Linux, содержащие тысячи доступных пакетов, не редкость. Если вы не выбрали "установить все", будет установлено некоторое подмножество этих пакетов.

Теперь у вас могут возникнуть вопросы "Как удалить ненужные пакеты? Как установить что-то недостающее? Могу ли я использовать программное обеспечение, не входящее в мой дистрибутив?"

Пакеты RPM

В ходе установки Linux вы, вероятно, обратили внимание на информацию об устанавливаемых пакетах RPM. RPM, сокращение от Redhat Package Manager, созданный в Red Hat, стал стандартным средством управления программным обеспечением для Red Hat и UnitedLinux, а также для многих других дистрибутивов.

RPM -- в сущности пакет, содержащий программное обеспечение для Linux, готовое для установки и запуска на компьютере определенной архитектуры. Например, в "Части 3. Введение в Webmin" мы устанавливали RPM-пакет webmin. Все программное обеспечение, изначально входящее в ваш дистрибутив, устанавливается из RPM.

Структура RPM

RPM -- это набор файлов. В него входит файл .spec, предоставляющий информацию о пакете, его назначении и зависимостях (какие пакеты должны быть установлены, чтобы этот пакет мог работать). Файл .spec также содержит манифест файлов пакета, информацию о том, куда в системе эти файлы должны быть загружены и какие они имеют изначальные права доступа. RPM также содержит преинсталляционный скрипт, написанный разработчиком пакета. Кроме того, RPM содержит скомпилированные бинарные файлы. И наконец, RPM содержит постинсталляционный скрипт.

Структура RPM

.spec преинсталляционный скриптбинарный файлбинарный файл ... бинарный файлпостинсталляционный скрипт

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

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

Что изменяют RPM

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

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

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

База данных RPM

База данных RPM -- элемент, добавляющий пакетам RPM элегантности. Обычно эта база данных хранится в каталоге /var/lib/rpm и содержит информацию о каждом установленном в системе пакете. База данных знает о взаимных зависимостях между пакетами, и от нее поступит предупреждение, если удаление пакета может привести к повреждению других пакетов. База данных знает обо всех файлах, которые изначально установлены при инсталляции пакетов, и знает их изначальное состояние в системе. Ей также известно местоположение документации и конфигурационных файлов для каждого пакета. Может показаться, что информации очень много, и это действительно так. Но она не является раздутой и громоздкой. В системе, содержащей 1,066 пакетов, включающих в себя 203,272 файлов, файлы базы данных занимают всего 45 MB! RPM использует базу данных для проверки зависимостей между пакетами, а также при загрузке и выгрузке пакетов. Кроме того, к базе данных за информацией о пакетах могут обращаться пользователи.

Использование RPM

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

rpm -i (install)

При установке пакета в первый раз используется опция -i (install). Просто укажите команде rpm в качестве аргумента бинарный пакет. Пакет установится в систему. Процесс инсталляции обычно занимает секунды. При установке пакета часто добавляют опцию -v (verbose), которая обеспечивает вывод подробной информации о ходе процесса, а также опцию -h (hash bar), которая по ходу выполнения процесса установки пакета выводит на консоль знаки диез (#). Вот пример инсталляции пакета:


Листинг 1. Инсталляция пакета MyPackage
$ rpm -ivh MyPackage-1.0.0.i386.rpm
Preparing... ########################################### [100%]
1:MyPackage ########################################### [100%]

Вот как! Теперь MyPackage установлен и готов к использованию.

Команду rpm может выполнить только root

Использовать rpm для установки и удаления пакетов может только root, поскольку необходим доступ файловой системе и базе данных rpm.

rpm -e (erase)

Для удаления установленного пакета используется опция -e, 'стирающая' его. rpm обратится к базе данных, чтобы удалить все файлы данного пакета. Если в системе есть пакеты, имеющие зависимости от удаляемого пакета, выполнение команды rpm прервется. Вы можете принудительно удалить пакет, воспользовавшись опцией nodeps. (nodeps может также использоваться для принудительной инсталляции.) При использовании опций принудительной установки или удаления пакета будьте крайне осторожны. Удаление пакетов, от которых зависят другие пакеты, может иметь плачевные последствия. Ниже приведена команда для удаления ранее установленного пакета:

$ rpm -e MyPackage

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

rpm -V (verify)

Опция verify очень полезна. Она сравнивает текущее состояние установленных файлов пакета с их изначальным состоянием. Для отображения различий используются специальные обозначения:

Результаты проверки файлов

SРазличается размер файлов (Size)
MРазличается состояние (Mode) (включая права доступа и тип файла)
5Различается сумма MD5
DНе совпадают major/minor-номера
LНе совпадает путь readLink(2)
UНе совпадает имя пользователя
GНе совпадает группа
TРазличается mTime

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

rpm -U (upgrade)

Если пакет установлен, любая попытка установить пакет с тем же именем выдаст сообщение, что такой пакет уже установлен. Если вы хотите обновить пакет до более поздней версии, используйте опцию -U. При одновременном обновлении нескольких пакетов будет предпринята попытка установить их в таком порядке, чтобы удовлетворялись взаимные зависимости. Другими словами, первыми установятся пакеты, от которых зависят другие. Опция -U может использоваться и в случае, когда пакет не установлен. Многие используют эту опцию не только для обновления, но и и для установки (вместо -i). Ниже приведен пример использования опции upgrade для установки нескольких пакетов:


Листинг 2. Обновление взаимозависимых пакетов
$ rpm -Uvh My*.rpm
Preparing... ########################################### [100%]
1:bMyPackageDep ########################################### [ 50%]
1:aMyPackageNew ########################################### [100%]

В приведенном примере пакет bMyPackageDep был необходим для aMyPackageNew, поэтому rpm сначала установил пакет bMyPackageDep, а затем aMyPackageNew, несмотря на то, что имена файлов были расположены в обратном порядке.

rpm -q (query)

Из базы данных rpm может быть получена полезная информация. Запросы может делать любой пользователь, имеющий права на чтение базы данных rpm. По умолчанию право на чтение имеют все пользователи. Для запроса используется опция -q, затем указывается имя пакета. Ответом будет версия пакета.

$ rpm -q MyPackage
MyPackage-1.0.0

Имя пакета должно быть указано точно. Использование метасимволов не допускается. Однако если вы не помните полное имя пакета, можете воспользоваться командой grep, которая поможет найти нужный пакет. Воспользуйтесь опциями -qa для запроса обо всех установленных в системе пакетах, а затем передайте информацию при помощи pipe команде grep с последующим указанием той части имени пакета, которую помните. Например:

Удобство команды grep

grep -- средство поиска в тексте, имеющее широкие возможности. По умолчанию при поиске в файле grep показывает те строки файла, которые содержат искомый текст. В нашем примере мы будем искать "IBM". grep -- мощный инструмент, используемый при создании скриптов и работе в консоли.

$ rpm -qa | grep IBM
IBMWSAppDev-Product-5.0-0
IBMWSSiteDevExp-Core-5.0-0
IBMWSSiteDev-Core-5.0-0
IBMWSTools-WAS-BASE-V5-5.0-0
IBMJava118-SDK-1.1.8-5.0
IBMWSWB-samples-5.0-0
IBMWSWB-5.0-0
IBMWSAppDev-Core-5.0-0
IBMWSAppDev-5.0-0
IBMWSTools-5.0-0

Помимо номера версии, rpm -q может выдавать и другую полезную информацию о пакете. Ниже приведены несколько примеров:

Получение информации при помощи rpm -q

rpm -q changelogПоказывает историю изменений при разработке пакета
rpm -qcПоказывает конфигурационные файлы для пакета
rpm -qdПоказывает файлы документации для пакета
rpm -qiПоказывает описание пакета
rpm -qlПоказывает список файлов пакета
rpm -qRПоказывает зависимости для пакета

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

rpm -q whatprovides

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

front-end'ы для RPM

Работа с rpm в консоли не сложна, но иногда бывает удобнее использовать графический интерфейс. В Linux обычно присутствуют front-end программы, предоставляющие интерфейс для программы rpm. В каждый дистрибутив включен свой front-end, и они могут различаться. Информацию об используемых в вашем дистрибутиве средствах управления пакетами вы найдете в документации к дистрибутиву.

Программные пакеты Webmin

Webmin также предоставляет несложный основанный на Web-интерфейсе front-end для взаимодействия с пакетами RPM.


Рисунок 1. Интерфейс Webmin
Рисунок 1. Интерфейс Webmin

С помощью этого средства вы можете легко установить, удалить программное обеспечение и получить информацию о нем. Кроме того, программное обеспечение может быть установлено непосредственно с сайта. Если в вашей системе установлены такие инструменты, как apt или Red Hat Network, Webmin соберет их и предоставит интерфейс доступа к ним.

Исходный код

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

При компиляции из исходных кодов на production-системах следует проявлять осторожность, поскольку это может вызвать некоторые проблемы или прекращение поддержки коммерческого программного обеспечения, используемого в вашей системе, например, IBM DB2. Однако умение компилировать из исходных кодов позволит вам прикладывать к программам патчи и работать с пакетами, перенесенными из других окружений. Стоит вам провести успешную компиляцию из исходников, и вы сможете создать даже свой собственный RPM!

Демонстрация компиляции из исходников на примере игры Corewars

Для демонстрации того, насколько прост процесс компиляции из исходных кодов, скомпилируем моделирующую игру под названием Corewars (см. ссылку в разделе Ресурсы). Вот информация о Corewars с соответствующего сайта: "Corewars -- моделирующая игра, в которой на виртуальном компьютере воины пытаются разбить друг друга. Воины могут быть созданы при помощи одного из двух ассемблер-подобных языков, Corewars или Redcode. Corewars -- язык, используемый по умолчанию, он проще для изучения и понимания. Redcode предоставляет более продвинутые и развернутые инструкции, но и требует большего времени для изучения".

Первый этап компилирования из исходных кодов -- загрузка пакета исходников с веб-сайта:

Загрузив пакет, я распаковываю архив.

tar -xvzf corewars-0.9.13.tar.gz

Распаковывание файлов производится в мой текущий каталог. Стандартный подход -- размещать исходные коды в каталоге с названием, соответствующем наименованию продукта. В нашем случае это каталог corewars-0.9.13.

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

Чаще всего следующим этапом идет запуск скрипта configure. configure -- часть пакета Autoconf, входящего в средства разработки вашего дистрибутива Linux. Вот цитата из описания пакета Autoconf: "Autoconf -- средство GNU для конфигурирования исходных кодов и Makefile'ов. При помощи Autoconf программисты могут создавать компактные и настраиваемые пакеты, поскольку автор пакета может предусмотреть различные опции конфигурации".

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

./configure

Несколько тестов, выполняемых в системе, наконец успешно завершились. Теперь создадим программу при помощи

make

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

make install

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

Теперь давайте протестируем наше изделие, запустив программу. Это графическая программа, поэтому для ее запуска нам понадобится графическая сессия. Выполненная нами команда make install должна поместить программу в наш путь поиска исполняемых файлов.

corewars

В награду должен появиться графический экран.


Рисунок 2. Удача!
Рисунок 2. Игра Corewars

Обсуждение правил игры corewars выходит за рамки нашей статьи, но вы можете найти соответствующую документацию на странице man (man corewars).

Сборка corewars производилась по типичному сценарию. Существует множество вариантов использования опций скрипта configure для настройки включаемых в программу возможностей, использования различных команд из Makefile для настройки процесса компиляции и т.д.

Поскольку наша программа была установлена без использования rpm, она не попала в базу данных rpm. На случай, если установленная программа не работает, большинство Makefile'ов имеет параметр для деинсталляции, позволяющий удалить программу:

make uninstall

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

Исходные RPM'ы

При создании RPM используется термин исходные RPM (Source RPM). Это SPEC-файл в сочетании с исходным кодом, предназначенные для сборки на одной или нескольких архитектурах. Из двух возможных вариантов этот является лучшим. Используя исходные коды, вы можете скомпилировать программу на своей системе, но конечный продукт будет пригодным для установки пакетом RPM, а не сырым бинарником. Большая часть пакетов доступна как в виде предварительно скомпилированных RPM, так и в виде SRPM. Это позволяет легко переносить программы между разными платформами в Linux. Если вы успешно пересобрали пакет для другой платформы, подумайте о том, чтобы сделать ваш конечный RPM доступным сообществу Linux.

Пусть исходники будут с вами

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

Для работы с пакетами rpm из консоли вы должны хорошо знать, какие опции для чего используются, но для повседневного использования существуют варианты front-end интерфейсов, которые облегчают процесс управления пакетами rpm. Помимо тех, которые входят в ваш дистрибутив, доступны и другие, например, Webmin.

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