#!/bin/sh

Есть две вечные темы, о которых пишет почти каждый автор «блога про linux» — туннели в ssh (каюсь, сам грешен) и сброс пароля root путём загрузки в режиме single user. Как правило, второй рецепт провоцирует обширные обсуждения на тему незащищённости Linux от действий злоумышленников при наличии физического доступа к компьютеру.

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

Итак, как же можно минимально обезопасить свой компьютер? read more…

>  uname -rs
FreeBSD 6.1-STABLE
> man panic
PANIC(9)               FreeBSD Kernel Developer's Manual              PANIC(9)

NAME
     panic -- bring down system on fatal error

...

RETURN VALUES
     The panic() function does not return.
> _

По мотивам, там еще много.

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

Еще один способ использовать свои несколько процессоров — просто запустить несколько копий программы. Но когда нужно многократно запускать одну и ту же программу с разными аргументами, приходится следить за тем, чтобы процессы не размножались сверх необходимости, а по завершении отработавшего процесса запускался бы новый. Несмотря на то, что shell имеет достаточно средств для усправления процессами (команды kill, wait и trap вкупе с механизмами отправки процесса в бэкграунд и извлечения его оттуда), отладка собственного скрипта может занять время, значительно превышающее выигрыш от его однократного использования.

К счастью, всё уже придумано до нас.

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

Во-вторых, поскольку в подавляющем большинстве случаев при обработке множества файлов используется связка find + xargs, то почему бы не использовать стандартные возможности этих программ? Команда xargs имеет две опции, которые непосредственно относятся к нашей проблеме ограничения количества одновременно выполняемых процессов:

• xargs -n X ограничивает количество передаваемых вашей программе аргументов. По умолчанию xargs передаёт программе довольно большое число аргументов, поэтому для обработки одного файла за один раз нужно указывать эту опцию
• xargs -P X устанавливает количество одновременно выполняемых процессов. По умолчанию xargs запускает только один процесс, но в нашем случае нужно увеличить это число до количества процессоров.

Например, перекодировать множество wav в mp3 можно примерно следующим образом:

find . -type f -name '*wav' -print0 | xargs -0 -n 1 -P 2 lame -V2

Одновременно будет запущено не более двух процессов lame, а планировщик позаботится о распределении их по разным процессорам.

В-третьих, некоторые программы всё-таки имеют встроенную возможность многопоточного исполнения. Например, у команды make есть опция -j, устанавливающую число одновременно запущенных экземпляров компилятора. Для ускорения сборки можно также посмотреть в сторону использования distcc (параллельная сборка на нескольких машинах) или ccache (кэширование результатов компиляции для многократного использования), но обсуждение этих программ выходит за рамки данного поста. Просто внимательно читайте документацию к используемому ПО, возможно, и ваша программа изначально поддерживает многопоточность.

Окончание перевода Bash Pitfalls. Все остальные части доступны здесь.

22. echo "Hello World!"

Проблема в том, что в интерактивной оболочке Bash эта команда вызовет ошибку:

bash: !": event not found

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

Очевидное решение здесь не работает:

$ echo "hi\!"
hi\!

read more…

Продолжаю перевод Bash Pitfalls. С предыдущими частями можно ознакомиться здесь.

17. cd /foo; bar

Если не проверить результат выполнения cd, в случае ошибки команда bar может выполниться не в том каталоге, где предполагал разработчик. Это может привести к катастрофе, если bar содержит что-то вроде rm *.
read more…

Клиенты прислали свой ноутбук Lenovo Thinkpad X61s для специфической настройки. Перед отправкой они воткнули туда свежеприобретённый Mini PCIe-адаптер Intel PRO Wireless 3945ABG, но проверить его толком не успели за недостатком времени. Когда я включил этот ноутбук, он вообще отказался загружаться с хамской формулировкой:

1802: Unauthorized network card is plugged in - Power off and remove the miniPCI network card.

Расследование этого факта привело на страницу Problem with unauthorized MiniPCI network card, откуда я узнал, что в биосе ноутбуков Thinkpad «зашит» белый список PCI-ID’ов Mini PCIe-устройств, явно разрешённых к использованию, все остальные устройства запрещены. Все разрешённые устройства выпущены под маркой Lenovo и стоят в полтора-два раза дороже, чем их немаркированные аналоги. Как разъясняет справочный центр Lenovo, это вызвано тем, что во избежание порчи эфира сочетание карты и антенны должно быть сертифицировано FCC (североамериканская федеральная комиссия по связи) или аналогичной организацией в других странах, и Lenovo не может гарантировать, что какой попало адаптер будет соответствовать этим требованиям. Поэтому официальный совет по избавлению от этой ошибки: выкиньте свой адаптер и купите правильный втридорога.
read more…

Продолжаю перевод Bash Pitfalls. С предыдущими частями можно ознакомиться здесь.

11. cat file | sed s/foo/bar/ > file

Нельзя читать из файла и писать в него в одном и том же конвейере. В зависимости от того, как построен конвейер, файл может обнулиться (или оказаться усечённым до размера, равному объёму буфера, выделяемого операционной системой для конвейера), или неограниченно увеличиваться до тех пор, пока он не займёт всё доступное пространство на диске, или не достигнет ограничения на размер файла, заданного операционной системой или квотой, и т.д.
read more…

Немного отвлекусь от обсуждения ошибок в скриптах на bash и порекламирую родственный блог :-)

Моя жена пишет серию интереснейших заметок о происхождении русских имён. Если Вам небезразлична история языка, настоятельно рекомендую ознакомиться.

Продолжаю перевод Bash Pitfalls. С первой частью можно ознакомиться здесь.

5. [ "$foo" = bar && "$bar" = foo ]

Нельзя использовать && внутри «старой» команды test или её эквивалента [. Парсер bash'а видит && снаружи [[ ]] или (( )) и разбивает вашу команду на две, перед и после &&. Лучше используйте один из вариантов:

[ bar = "$foo" -a foo = "$bar" ]       # Правильно!
[ bar = "$foo" ] && [ foo = "$bar" ]   # Тоже правильно!
[[ $foo = bar && $bar = foo ]]         # Тоже правильно!

Обратите внимание, что мы поменяли местами константу и переменную внутри [ — по причинам, рассмотренным в предыдущем пункте.

То же самое относится и к ||. Используйте [[, или -o, или две команды [.
read more…

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

Большинство имеющихся руководств посвящено тому, как надо писать. Я же расскажу о том, как писать НЕ надо :-)

Данный текст является вольным переводом вики-страницы «Bash pitfalls» по состоянию на 13 декабря 2008 года. В силу викиобразности исходника, этот перевод может отличаться от оригинала. Поскольку объем текста слишком велик для публикации целиком, он будет публиковаться частями, по мере перевода.

1. for i in `ls *.mp3`

Одна из наиболее часто встречающихся ошибок в bash-сериптах — это циклы типа такого:

for i in `ls *.mp3`; do     # Неверно!
    some command $i         # Неверно!
done

Это не сработает, если в названии одного из файлов присутствуют пробелы, т.к. результат подстановки команды ls *.mp3 подвергается разбиению на слова. Предположим, что у нас в текущей директории есть файл 01 - Don't Eat the Yellow Snow.mp3. Цикл for пройдётся по каждому слову из названия файла и $i примет значения: "01", "-", "Don't", "Eat", "the", "Yellow", "Snow.mp3".

Заключить всю команду в кавычки тоже не получится:

for i in "`ls *.mp3`"; do   # Неверно!
    ...

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

На самом деле использование ls совершенно излишне: это внешняя команда, которая просто не нужна в данном случае. Как же тогда правильно? А вот так:

for i in *.mp3; do         # Гораздо лучше, но...
    some command "$i"      # ... см. подвох №2
done

Предоставьте bash’у самому подставлять имена файлов. Такая подстановка не будет приводить к разделению строки на слова. Каждое имя файла, удовлетворяющее шаблону *.mp3, будет рассматриваться как одно слово, и цикл пройдёт по каждому имени файла по одному разу.

Дополнительные сведения можно найти в п. 20 Bash FAQ.

Внимательный читатель должен был заметить кавычки во второй строке вышеприведённого примера. Это плавно подводит нас к подвоху №2.
read more…

Знание истории происхождения вещей и их названий, будь это простой карандаш, автомобиль или же команда операционной системы, делает их повседневное использование намного интереснее. В этой заметке я постараюсь осветить некоторые неизвестные широкой публике аспекты наименования нескольких программ, используемых в операционной системе Unix и её родственниках: Solaris, Linux, *BSD и т.д.

По мотивам страницы What does {some strange unix command name} stand for?

awk
Aho, Weinberger, Kerninghan
Первые буквы фамилий разработчиков языка, сотрудников Центра Компьютерных Исследований Bell Labs: Альфред Ахо (руководитель исследований в этом центре с 1963 по 1991 и с 1997 по 2002 годы, сейчас — профессор Колумбийского университета в Нью-Йорке), Питер Вейнбергер (в 1985 году его стилизованный портрет стал своеобразным мемом исследовательского центра Bell Labs) и Брайан Керниган (известен прежде всего как соавтор одной из первых книг про язык C)

grep
Global regular expression print
По одной из версий, название «grep» происходит от команды редактора ed для печати всех строк, соответствующих регулярному выражению (regular expression, re): g/re/p

fgrep
Fixed grep
Команда fgrep ищет заданные фиксированные строки в файлах; список этих строк может быть прочитан из другого файла. «F» означает «fixed». Распространено заблуждение, что «f» означает «fast». Это не так: fgrep может работать медленнее egrep, однако его использование может дать преимущество при поиске бОльшего количества фиксированных подстрок, чем egrep может обработать.

egrep
Extended grep
Команда egrep использует более мощные регулярные выражения, чем grep, а также является самой быстрой из тройки grep, fgrep и egrep.

cat
Catenate
«Catenate», туманное слово, означающее «соединять в последовательности», то есть то, что команда cat делает с одним или несколькими файлами. Никакой связи с аббревиатурой C/A/T (Computer Aided Typesetter, компьютерная система верстки, весьма распространённое на западе сокращение) здесь нет.

nroff
new roff
troff
Typesetter new roff
Система форматирования текстов roff является одной из центральных частей любой Unix системы. Именно благодаря ей происходит подготовка документации man к отображению на экране. Собственно, эволюция Unix неразрывна связана с развитием этой программы. Ее первая версия, под названием RUNOFF, была написана для CTSS (первой операционной системы с разделением машинного времени) в 60-х годах Джеромом Сальтцером, затем была переписана для Multics с ассемблера CTSS на BCPL, чуть позже — на PL/I. В 70-х годах её возможности перестали удовлетворять возросшим потребностям пользователей, поэтому функциональность программы runoff, уже портированной на первый Unix, была значительно расширена Джозефом Осанной, а название сокращено до roff. После этого Брайан Керниган портировал ее с ассемблера PDP-11 на C и в 1976 году выпустил в свет первую версию спецификации Troff User’s Manual. Таким образом roff приобрел классический вид, во многом оставшийся неизменным до сих пор.

Само название «run off» происходит от типографского термина «run off» — «печатать тираж».

tee
Название команды tee происходит от термина «tee» — Т-образное сочленение труб. Сама программа копирует свой стандартный вход в указанный файл и в терминал пользователю, что очень напоминает поведение потока при проходе через такое сочленение.

biff
Программа biff использовалась в BSD-системах для срочного оповещения пользователя, работавшего в консоли, о пришедшей почте. Автором официальной версии происхождения названия является Эрик Купер:

Могу рассказать о происхождении названия biff, если интересно. Бифф был собакой Хейди Стетнер, когда Хейди, я и Билл Джой (один из отцов BSD и сооснователь Sun Microsystems) были студентами в Беркли и ранние версии BSD еще разрабатывались. Бифф был весьма популярен среди обитателей Эванс Холла и прославился тем, что лаял на почтальона, отсюда и название команды

По сведениям из книги «25 лет UNIX» Питера Салюса, выпущенной в 1994 году, пёс Бифф действительно существовал и дал своё имя программе, однако он не лаял на почтальона: Хейди утверждала, что это гнусный поклёп. Бифф был очень дружелюбной собакой и обожал гоняться за мячиками по коридорам общежития. Вместе с Хейди он посещал занятия и однажды даже получил там оценку «B»; его портрет висел на доске объявлений с пояснением, что он работает над dog’торской диссертацией. Бифф умер в 1993 году в возрасте 15 лет.

rc (~/.cshrc или /etc/rc)
runcom
Сочетание «rc» происходит от названия программы RUNCOM из вышеупомянутой системы CTSS. Эта программа запускала программы, перечисленные в файле; и такой файл также назывался runcom, сокращённо «rc».

Впоследствии от RUNCOM произошли многие современные шеллы. В частности, оболочка в Plan 9 так и называлась — rc.

bash
Bourne Again Shell
Игра слов, основанная на схожести звучания «Bourne» (фамилия автора оболочки sh Стивена Борна), и «born» (рождённый). Словосочетание «born again» (рождённый заново, возрождённый), в свою очередь, имеет также и религиозную подоплёку: во многих протестантских конфессиях понятие духовного возрождения является ключевым, да и в православии и католицизме второе, духовное, рождение (более известное как крещение) играет не последнюю роль. Это словосочетание было на слуху благодаря разнообразным американским протестантским движениям и постоянно употреблялось к месту и не к месту. В частности, так называлась книга одного из фигурантов Вотергейтского скандала Чарльза Колсона, выпущенная в 1975 году.

dd
Цитата из отличной статьи DD: команда, которая не похожа на другие:

Команда dd практически ровесник ОС Юникс. Днем рождения последней считается 1 января 1970, и точно известно, что уже в 1970 году утилита dd работала с ленточными накопителями, при помощи которых данные переносили с одной ЭВМ на другую, а также запускали и устанавливали ОС Юникс на популярные тогда мини-ЭВМ PDP/11.

Расшифровка названия команды тоже относится к этим давно ушедшим временам. В языке IBM System/360 JCL был оператор DD ‘Dataset Definition’ (Определение набора данных), имя которого и получила вновь созданная команда.

Расшифровок приходилось встречать много, в частности в рунете популярна расшифровка Disk Dump (не то разгрузка, не то загрузка диска) — версия слабая, так как в описываемые времена ни дисков, ни дампов (что бы под ними не понимали) еще не было. Гораздо ближе к сути команды шутливые расшифровки: «data destroyer» или «delete data», что можно перевести как «Доконай Диск» или «Добей Данные», потому что при неправильном использовании команды раздел или выходной файл мгновенно превращаются в хлам.

vi
Кратчайшее недвусмысленное сокращение для команды перехода в визуальный режим (:visual) в строковом редакторе ex (команда :v выполняет некую команду для строк, не соответствующих заданному шаблону)

vim
Vi IMproved
Улучшенный vi.

apache
Производное от «a patchy server» — на ранних стадиях разработки apache представлял собой набор патчей к NCSA HTTPd 1.3

squid
Squid FAQ:

Жалоба Харриса гласит: «все хорошие уже заняты». Нам нужно было как-то отделить наше детище от программы Harvest. Кодовым именем новой разработки было «squid», так и привязалось.

Традиционный бонус для дочитавших до этого места :)

Слово «карандаш» образовано от тюркского «karadas» — «сланец», «графит» (kara — «черный» и das — «камень»). Первые прототипы карандашей — палочки, изготовленные из смеси свинца с цинком, появились уже в XIV веке. В XVI веке в Англии был обнаружен графит, стержни из которого можно было использовать в качестве пишущего инструмента, обернув их в тряпочку; современный вид (смесь графита с глиной в разных пропорциях внутри деревянного корпуса) карандаш приобрёл в XVIII веке. Первые механические карандаши появились уже в 1869 году. Еще одной важной вехой в развитии карандашной промышленности была мысль о том, что карандаши лучше делать многогранными для избежания их скатывания по наклонной поверхности.

В Debian в bash был добавлен патч, благодаря которому пользователь может написать свою функцию, выполняемую в случае, если введённая пользователем команда отсутствует. В Ubuntu эту фичу использует подсказка command-not-found, заметно тормозящая работу, в то время как можно найти более интересные и полезные возможности применения этого механизма, оставив поиск пакета специализированным программам. Поделюсь своим опытом.

У нашего подразделения есть специальная сеть для тестовых серверов и виртуальных машин: 192.168.20.0/24, и очень часто приходится набирать команды типа ssh user@192.168.20.xx, причем в командах различается только последняя цифра. У ограниченного числа серверов нужно указывать другой username. Реже приходится ходить на сервера в других подсетях (в пределах 192.168.0.0/16); также иногда клиенты открывают нам доступ к своим системам, чтобы мы смогли продиагностировать их проблему и решить ее на месте.

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

ssh ordinary_user@192.168.20.xx
ssh special_user@192.168.xx.yy
ssh third_user@ww.xx.yy.zz

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

alias 123='ssh user@192.168.20.123'

Однако вскоре я понял, что поддерживать список из полусотни alias’ов — не true unix way, и задумался об альтернативах. Вспомнил об опытах вебмастеров эпохи web 1.0 по использованию 404 ошибки для отображения страницы с нужным содержанием, задумался о том, каким образом bash перехватывает вызов неизвестной команды и подменяет её командой поиска нужного пакета… В результате беглого изучения состава пакета command-not-found было выяснено, что используется функция command_not_found_handle. Она принимает в качестве аргумента введённую пользователем команду, выполняет некие действия и возвращает 127, если ничего нельзя сделать (в таком случае bash выводит стандартное сообщение об ошибке), или любое другое число, если что-то получилось.

Остальное оказалось делом техники. В ~/.bashrc была добавлена функция:

command_not_found_handle () {
    if [[ ! "$1" ]] ; then
        return 127
    fi

    n="$1"

    if echo $n| perl -ne 'exit(/^([1-9]|[1-9]\d|1\d{2}|2[0-4]\d|25[0-5])$/ ? 0:1)' ; then
        ip=192.168.20.$n
    elif echo $n| perl -ne 'exit (/^([1-9]|[1-9]\d|1\d{2}|2[0-4]\d|25[0-5])\.([1-9]|[1-9]\d|1\d{2}|2[0-4]\d|25[0-5])$/ ? 0:1)' ; then
        ip=192.168.$n
    elif echo $n| perl -ne 'exit (/^([1-9]|[1-9]\d|1\d{2}|2[0-4]\d|25[0-5])\.([1-9]|[1-9]\d|1\d{2}|2[0-4]\d|25[0-5])\.([1-9]|[1-9]\d|1\d{2}|2[0-4]\d|25[0-5])\.([1-9]|[1-9]\d|1\d{2}|2[0-4]\d|25[0-5])$/ ? 0:1)' ; then
        ip=$n
    else
        return 127
    fi

    ssh $ip
}

Любое введённое число от 1 до 255 преобразуется в команду ssh 192.168.20.число; два числа — в ssh 192.168.число.число; любой введённый IP-адрес превращается в ssh IP-адрес. Во всех остальных случаях просто выводится сообщение "command not found".

Поскольку используется довольно сложное регулярное выражение, то для его обработки пришлось использовать perl. Ещё был вариант с grep -qP, но эксперименальная опция -P (расширенная поддержка perl-овых регулярных выражений) включена в grep не во всех дистрибутивах (например, в Ubuntu 8.04 её нет, а в 8.10 уже есть).

Чтобы для всех хостов в 20 сети подставлялось общее имя пользователя ordinary_user, а для избранных хостов — специальные имена, в ~/.ssh/config я добавил строчки (общие параметры для всех хостов, предваряемые конструкцией Host *, должны находиться в конце списка):

Host 192.168.20.251
User special_user1

Host 192.168.20.252
User special_user2

Host 192.168.20.254
User special_user3

Host *
User ordinary_user

К сожалению, мне не удалось заставить эту функцию обрабатывать также и параметры командной строки: функции command_not_found_handle передаётся только первый позиционный параметр, остальные недоступны. Поэтому для каждого нестандартного хоста придётся либо писать полный вариант команды со всеми параметрами, либо указывать настройки сервера в ~/.ssh/config, подобно указанным выше. Имеются и прочие недостатки в реализации, обсуждаемые, в частности, на сайте smylers hates software.

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

P.S. бонус для дочитавших до этого места: библиотека регулярных выражений perl, где я нашел регэксп для проверки строки на соответствие IP-адресу.

С давних времен многих смущает разнообразие вариантов обеспечения безопасности при выполнении операций с максимальными привилегиями. Например, в официальной документации ubuntu в качестве команды редактирования рекомендуется использовать что-то вроде sudo nano, а в многочисленных любительских мануалах (в стиле «5 фокусов в командной строке, которые удивят вашу бабушку») для получения root’ового шелла предлагается писать «sudo su -». Попробую объяснить, почему такое положение вещей кажется мне неправильным.

Исторически единственным универсальным способом выполнить команду от имени другого пользователя в Unix была программа su. Запущенная без параметров, она запрашивала пароль суперпользователя и в случае успеха просто подменяла текущее имя пользователя на root, оставляя почти все переменные окружения от старого пользователя (кроме PATH, USER и еще пары-тройки, см. man su от своего дистрибутива). Более правильно было запускать ее как su - — в таком случае оболочка получала также и правильный environment. С параметром -c можно было выполнить команду: su -c "vim /etc/fstab".

При этом пользователям приходилось помнить пароль root’а и у всех пользователей, перечисленных в группе «0″ (т.е. в группе, члены которой могли выполнить команды su и стать суперпользователем), был одинаковый неограниченный доступ ко всей системе, что являлось серьёзной проблемой безопасности.

Затем появилась команда sudo, и это был прорыв. Теперь администратор мог указывать список разрешенных команд для каждого пользователя (или группы пользователей), файлы, доступные для редактирования, специальные переменные окружения и многое другое (все это великолепие управляется из /etc/sudoers, см. man sudoers от своего дистрибутива). При запуске sudo спрашивает у пользователя его собственный пароль, а не пароль root. Полноценный шелл можно получить с помощью «sudo -i»

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

sudo vim /etc/fstab

Запускаемый таким образом vim наследовал оболочку с неограниченными правами и через :! пользователь мог запускать любую команду (если, конечно, админ не позаботился об этом заранее) и открыть любой файл.

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

В Debian-based дистрибутивах пользователь root не имеет пароля, вместо этого все административные действия должны производиться через sudo или его графический аналог gksudo. Являясь полной заменой su, sudo должна бы быть единственной командой переключения между пользователями, однако, как было сказано вначале, в настоящий момент это не так и все зачем-то изобретают дикие последовательности из sudo, su, vi и черточек.

Поэтому предлагаю всем раз и навсегда запомнить:

Upd. Тут коллеги в комментариях жалуются на то, что sudo echo 1 >> /etc/apt/sources.list не работает. Это происходит потому, что права повышаются только для команды echo, а результат уже перенаправляется в файл с правами обычного пользователя. Чтобы добавить что-нибудь в privileged_file, нужно выполнить такую команду:

echo 1| sudo tee -a privileged_file >/dev/null

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

Первым делом столкнулся с нехваткой места: установщик обновлений потребовал 1,6 Гб места в корневом разделе, а поскольку при распределении места я пожадничал и выделил под / чуть меньше пяти гигабайт, которые, естественно, сразу же забились, то пришлось основательно почистить систему от старых ядер, ненужных приложений, документации, различных кэшей и т.д. После этого никаких проблем с обновлением не возникло, почти все моё железо продолжило работать в прежнем режиме, включая USB-карточку Netgear WG111T, драйвер которой загружался через ndiswrapper… Кроме графической карты ATI Radeon X1650 Pro, которую и в hardy не удавалось заставить работать на полную мощность ни с проприетарным fglrx, ни с открытым radeon от X.org — обходился vesa. Но и этот баг оказался во благо: достаточно было удалить из /etc/modprobe.d/blacklist драйвер radeon, внесенный туда в процессе предыдущих экспериментов по настройке видеокарты, и внести его в /etc/modules. Затем немного подправил xorg.conf и все отлично заработало.

Через неделю успешного использования Ubuntu Intrepid Ibex дома я решил, что функциональность нового дистрибутива меня устраивает и неплохо бы обновить и рабочий компьютер. Некоторое время назад в нашей компании наконец набралась критическая масса пользователей-линуксоидов, и совместными усилиями удалось уговорить админов открыть неограниченный доступ к вышеупомянутому репозиторию хотя бы в нерабочее время с 18:00 до 9:00 следующего дня (в нашей провинции принято экономить трафик, поэтому каждому корпоративному пользователю еженедельно выделяется 50 мегабайт http-трафика, на которые систему особо не обновишь). Поскольку пакеты устанавливались из этого репозитория без проблем, то я решил, что обновление дистрибутива также пройдёт без особых приключений. Как же я ошибался!

Основная проблема заключалась в том, что в графическом менеджере обновлений никак не появлялась кнопка «доступен новый дистрибутив». Попытка решить проблему методом гугления ничего не дала, кроме еще одного бедолаги, по странному стечению обстоятельств также жаловавшегося на невозможность обновить систему на работе стандартными средствами, тогда как дома все прошло нормально. Автоматический апгрейд из командной строки (do-release-upgrade), едва начавшись, завершался с сообщением: «Checking for a new ubuntu release: no new release found».

Поэтому я полез в исходники (на python я за всю жизнь не написал ни строчки, однако, как оказалось, читать его исходники очень легко) и в /usr/lib/python2.5/site-packages/UpdateManager/Core/MetaRelease.py нашёл, что для определения доступности нового релиза менеджер обновления обращается к файлу по адресу http://changelogs.ubuntu.com/meta-release, который в моем случае был недоступен из-за особенностей нашего корпоративного прокси (сервер обновлений доступен напрямую, тогда как к changelogs.ubuntu.com необходимо обращаться через прокси-сервер с авторизацией).

Как всегда, обнаружилось несколько способов решения проблемы:
— выкачать Alternate CD и обновиться с него: с учетом наличия сети — не тру unix way :) приберегу этот способ для своего eee pc, на котором в любом случае не хватит места для выкачивания новых пакетов;
— поднять свой прокси-сервер, который обращался бы напрямую к yum.fireground.ru и через корпоративный прокси — ко всем остальным ресурсам: неохота ставить монстрообразный сквид для такой простой задачи, а в более мелких и простых прокси разбираться нет времени, хотя задача интеллектуального переключения между несколькими прокси вне зависимости от клиента (proxy.pac не подходит) довольно интересна;
— создать локальную копию changelogs.ubuntu.com и в вышеупомянутом скрипте MetaRelease.py указать свой адрес: также не совсем правильно с точки зрения соблюдения целостности системы, поскольку требует неконтролируемых изменений в программе, а не в конфигурационном файле, и в процессе обновления этот файл будет заменен (необходимо заметить, что в update-manager в intrepid уже можно указывать свои сервера в /etc/update/manager/meta-release).

Я пошел немного другим путем: нашел инструкцию по ручному обновлению 8.04 до 8.10 и воспользовался ей. Краткое содержание (используйте на свой страх и риск):

sudo -s # become superuser

# заменить hardy на intrepid в /etc/apt/sources.list
# лучше воспользоваться текстовым редактором :)
sed -i '/^deb/ s/hardy/intrepid/g' /etc/apt/sources.list

aptitude update
aptitude update # два раза — не опечатка! подробности см. по ссылке выше
aptitude upgrade
aptitude dist-upgrade
aptitude upgrade

Поначалу я вместо «intrepid» в /etc/apt/sources.list «interpid», за что и был обруган :) В процессе обновления опять же не хватило места, пришлось на ходу удалить несколько неиспользуемых ядер, освободив при этом порядка 200 мегабайт), а также слегка чужеродный для гномоориентированного ubuntu amarok, из-за которого не удовлетворялись какие-то зависимости. Пришлось немного поотвечать на вопросы о различиях в конфигурационных файлах; тут приятно удивило то, что задавались вопросы только о настройках, используемых по умолчанию, внесенные пользователем изменения в конфигурации не затрагиваются. По сравнению с mergemaster в FreeBSD это большой шаг вперёд в автоматизации системного обновления :) (правда, FreeBSD последний раз приходилось обновлять с 4.11 до 5.4 и сейчас я не в курсе нынешнего состояния механизма апгрейда, возможно, что-то поменялось в лучшую сторону).

Учитывая то, что все вышеописанное я проделывал из дома, используя только ssh, и в процессе лишь один раз перезагружался для загрузки с новым ядром — обновление прошло просто идеально. Правда, новый внешний вид системы на этом компьютере я еще не успел оценить :) но, поскольку там используется простенькая мать со чипсетом 82801FB 2004 года выпуска, то никаких проблем с графикой не ожидается.

Собственно о впечатлениях от новых фич Intrepid Ibex (а их много: и фич, и впечатлений) расскажу как-нибудь в другой раз. Вкратце скажу, что особых тормозов не замечено, система работает стабильно и без ошибок.

P.S. Для нагугливших этот пост по ключевым словам «ubuntu intrepid radeon x1650» привожу краткую инструкцию по настройке.
read more…

1. Мини-программа AllTray, единственное назначение которой — минимизация окон в трей. Работает в Gnome, KDE, XFCE4, FluxBox и WindowMaker. Присутствует в universe-репозитории Ubuntu (sudo apt-get install alltray), имеются готовые пакеты для Fedora, SUSE, Debian, Gentoo.

2. В состав пакета MouseTweaks входит апплет pointer-capture-applet, представляющий из себя область на панельке, куда можно ткнуть мышкой, после чего отключается курсор и некоторые сочетания клавиш типа Alt-Tab или Alt-F1. Чтобы включить всё обратно, нужно еще раз кликнуть мышкой или нажать волшебную комбинацию клавиш (настраивается). Отключение возможности переключаться в другие программы серьёзно улучшает производительность, проверено на себе :-) MouseTweaks входит в комплект поставки Ubuntu и вроде бы ставится по умолчанию вместе с Gnome.