А полностью всё прочитай, не вырывая цитаты из контекста. А так же потом пройдись по страницам безопасности указанных компаний(а не дистрибутивов) и посмотри, в каких пакетах ошибки. RedHat сразу пишет - xen. OpenSuSe так же говорит - xen. Citrix - понятное дело, они как раз на виртуализации зарабатывают и т.д. Все подтверждённые в системах Linux баги связаны с использованием гипервизора xen.
Я понимаю, что ты на ЛОРе новость прочитал и побежал обновляться. А мне эта новость прилетела в рассылку до ЛОРа. К слову и на ЛОРе она появилась с большим опозданием(17-го, когда ты её перепостил), потому как на том же опеннете эта ошибка была уже 13-го числа. А сам уязвимость была опубликована 12-го.
А мне эта новость прилетела в рассылку как раз 12-го. И так как у меня используются на серверах процы интел я побежал читать, что за дыра, и что делать. Среди прочего первым делом вышел на редхат, где прочитал вот такое:

И в конце концов ещё через несколько шагов пришёл к заключению, что ошибка довольно специфична. О чём дополнительно прочитал на слешдоте: "According to the article, exposed OSes include "Windows 7, Windows Server 2008 R2, 64-bit versions of FreeBSD and NetBSD, as well as systems that include the Xen hypervisor."
Дополнительно для очистки совести пробежался ещё по майлилстам разработчиков ядра linux и окончательно убедился, что паника поднята преждевременно.

Я как раз по ссылкам ходил, а на ЛОРе комменты не читал, тамошние аналитики не впечатляют.

Очевидно же. Ты в новости своей ни слова не сказал про то, что на самом деле уязвимо(добавив какой-то бред про макось), а люди, не проверив, побежали обновляться. :)

Да, извиняюсь, у меня в примере ошибка была. Почему-то значение автоматом подставилось.
Но при вызове bash'а эмулятор терминала может установить свои переменные, некоторые программы могут добавлять свои опции в .bashrc или profile, где export уже отлично работает и всё, что там указано замечательно применяется нашими скриптами, так как они являются как раз дочерними процессами для запущенной версии bash.
И как ни крути всегда есть вероятность, что в нужной нам переменной может находиться неожиданное значение. Я об этом пытаюсь объяснить.

Вообще-то дыра проявляется только на Xen, специфичных виндовых системах привелегий и ядре фряхи, а все побежали свои локалхосты обновлять. :)

Жестоко (с) Nathan Explosion

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

┌┤~/wtmp/welinux├─────────────────────────────────────────────────┤cppmm@damned├─ └─> cat > welinux.sh << EOFILE > #!/bin/bash > KOOM="koom" > export KOOM > EOFILE ┌┤~/wtmp/welinux├─────────────────────────────────────────────────┤cppmm@damned├─ └─> cat > welinux1.sh << EOFILE > #!/bin/bash > echo $KOOM > EOFILE ┌┤~/wtmp/welinux├─────────────────────────────────────────────────┤cppmm@damned├─ └─> bash welinux.sh ┌┤~/wtmp/welinux├─────────────────────────────────────────────────┤cppmm@damned├─ └─> bash welinux1.sh koom

Ага. Присоединяюсь к mironov_orig. Нужны подробности.

А мой опыт таков: если с системой "переодически приходится воевать" и "нравится ковырятся в системе" тратя на это "время, терпение и усидчивость" и при этом система (любая) не является полем профессиональной деятельности или на худой конец хобби, то что-то в жизни индивида пошло не так

//fixed

И именно поэтому я когда-то снёс винду, а сейчас работаю админом и если меня просят посмотреть на винду или предлагают сервак с ней, сразу же отказываюсь, потому как не хочу геммороя. :)

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

> Антоша, давай я тебе ещё раз прозрачно намекну, что пора бы перестать хамить незнакомым cтаршим?
Ой, извините, дяденька, телепатии не обучен, а по сообщениям на школьника похож сильно. :)

Наконец-то по делу разговор пошёл. И стоило столько кривляться прежде чем сразу ясно и понятно выразить свои мысли?

Пример от ananas не надуман. В системе огромное количество программ и многие из них используют в своей работе переменные окружения. Для bash-скрипта любая переменная практически равносильна переменной окружения. Стоит одному криворукому программисту в своей программе вызвать export TYPE со своим значением и наш скрипт без явного обнуления этой переменной будет по умолчанию использовать то, что там записано. И уже не важно, что там будет(rm или там просто случайный набор символов), скрипт отработает не верно.
Мой же пример является просто ответом на то, что даже в таком простом языке как bash есть разница между инициализированными переменными и неинициализированными. Именно в данном конкретном скрипте это незначительно. Но в другой раз может оказаться проверка на существование переменной и тут с твоим подходом мы рискуем наступить на грабли.
Подобные вещи должны сидеть в программистах на уровне рефлексов. Сначала объявляешь переменную, потом её используешь. Это как грамотное форматирование кода. Оно не всегда обязательно, но если его нет, программист хорошим быть не может, потому как это потенциальные ошибки и путаница.

Ну и я не совсем понял, какой именно конкретный пример нужен? Пример, где применяется такой подход? Да любой нормальный скрипт. Вот, выдержка из скрипта /etc/init.d/bind9 (debian squeezy):

1 2 3 4 5 6

# for a chrooted server: "-u bind -t /var/lib/named" # Don't modify this line, change or create /etc/default/bind9. OPTIONS="" RESOLVCONF=no test -f /etc/default/bind9 && . /etc/default/bind9

Если бы в данном примере не было объявления OPTIONS и этот параметр не был бы указан в /etc/default/bind9, то туда вполне возможно могло бы попасть оставшееся в этой переменной значение из другого скрипта. bind бы, разумеется, не понял, что там за параметры и упал бы при старте. Так понятно?

Что касается современных компиляторов, то они продвинулись довольно далеко со времён PDP-7 и иже с ними. Но всё-равно они не всемогущи. И если есть возможность перестраховаться и защитить себя от ошибок, то лучше это сделать. Особенно хорошо это понимаешь, когда скриптов и программ приходится писать много и такие вот мелкие "пережитки прошлого" в один прекрасный момент оказываются жизненно необходимы.

Кто пенится? Я просто указал на то, что ты глуп. :)
А этот пример указывает на то, что бывает при использовании неинициализированных переменных. Заодно показывает, что книжек ты таки не читал, глупышка. :)
Про неожиданное содержимое тебе уже выше пример выдавали.
И куда уж конкретнее писать? Тут тебе всем форумом говорят про ошибки, которые могут возникнуть из-за неинициализированных переменных. Подсказывают, что можно значение подефолту таким способом установить. Но ты упорно не хочешь слушать и продолжаешь устраивать клоунаду. Скучно.

А точно bash виноват? Может, парсер или в разных версиях snmpwalk разный вывод?
Просто я впервые вижу, чтобы bash при вставке в файл переменные в кавычки самостоятельно брал. Со времён восьмой мандраки такого не встречал.
Ну и да. Я бы лучше писал вот так:

1	echo "${if1_name}:${if1_index}_${if2_name}:${if2_index}" > $CONFDIR/$ip.conf

google: Smart Questions HOWTO

Опять двадцать пять.
Ты не поверишь, но есть люди, которые работают на линуксах и чувствуют себя лучше, чем в альтернативных осях(да-да, для меня венда с макосями именно слабые альтернативы GNU/Linux). И все приведённые аргументы уже сто раз обсуждались. Так что это таки твоя имха.

Ну не лез бы уже, раз мозгов нет:

1 2 3 4 5 6 7 8 9

#!/bin/bash TESTVAR="" : ${TESTVAR?} echo "$TESTVAR" : ${TESTVAR2?} echo "$TESTVAR2"

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

А какой реакции ты ожидал, задав тупой вопрос?

Ты бы хотя бы ABS Guide осилил, прежде чем идти скрипты обсуждать. А заодно принципы работы в nix-системах. А то нагуглить по имени автора название книжки это легко. Но вот понять, о чём оно по описанию - это сложнее.

Ух ты, какой толстенький. Давненько такой школоты не забредало.

Да без проблем.
find ./ -name "*.bz2" -o -name "*.gz"
Ну и т.д. Вписать все нужные типы архивов.

"/usr/share/locale/en/LC_MESSAGES/gtk30-properties.mo"
Вот на эту шнягу сильно матерно ругается, но вообще как бы starce в отрыве от хода выполнения самой проги не очень удобно смотреть. Правда, может тут у нас есть программеры и они чего больше скажут.
Попробовать запустить, конечно можно как-нибудь потом, но не уверен, что будет толк от того, что я его у себя в генте скомпилю со всеми этими библиотеками и запущу. Для начала стоило бы поискать на багтерекере этого рокстерма что-нибудь похожее.

Код определения полного пути к директории(начиная с 60-ой строки) лучше заменить командой realpath.
Самописную рекурсию в функции listdir я бы реализовал через find. Проще и надёжнее.
В функции convert можно обойтись без временной директории. Сейчас не помню возможностей 7z, а смотреть лень, но, например для bzip2/gzip это выглядело бы примерно так:

1	gzip -d files.tar.gz | bzip2 > files.tar.bz2 && rm files.tar

Это так, именно по скрипту.
Ну а вообще по-моему это всё тем же find'ом можно в одну строку написать. :)
Типа: find ./ -type f -name "*.gz" -exec ...

Ну как обычно. Что если запустить из консоли и посмотреть на выхлоп при этих действиях?

А вот вот это всё надо выполнить после пятого пункта моих "курсов". :)

Почему-то работодатели с этим несогласны. ;)

s/начал с шестого/начал с пятого/g

Курсы от меня:
1. Снеси венду. Т.е. вообще снеси. Поставь любой дистр линухи и полностью перенастрой его под себя. Например, возьми бубунту и сделай так, чтобы она няшно и красиво работало, но в качестве WM был fluxbox, основного шелла какорй-нибудь там zsh, основные задачи оптимизируй скриптами(запись дисков через growisofs, монтирование флешек через udev, музыку через mpg123 с автосоставляемыми списками воспроизведения и т.д.). Потом снеси бубунту, поставь федору и сделай тоже самое, только вместо флюкса icewm, а вместо zsh bash, но чтобы функциональность не хуже. Потом повторить на слаке, дебиане, $distroname по вкусу.
2. После того, как появятся базовые навыки с помощью п.1 купи книжку типа "Руководство администратора Linux"(Э. Немет, Г. Снайдер, Т. Хейн) и проштудируй от корки до корки. Там в конце каждой главы есть упражнения. Их все сделай. Так же можешь поискать книжки "Руководство администратора сети" и другие из серии "Руководство администратора..." издательства O'Reilly. Русских авторов не бери. Раньше были неплохие книги у Д. Колисниченко("Linux-сервер своими руками", например), но сейчас они уже устарели.
3. Поставь где-нибудь сервак(или VPS возьми) и подними на нём что-нибудь реально работающее. Хотя бы зеркало какого-нибудь дистра, блог там какой-нибудь, торрент-трекер, почтовый сервер, etc. Если локалка есть городская - это проще пропиарить среди пользователей и под какой-никакой нагрузкой погонять. Для мониторинга за всей этой системой настрой что-нибудь с кучей самописных скриптов(munin + плагины или свои модули к nagios'у, или ещё чего-нить). Сделай полностью автоматическую систему бекапа и учёта проходящего траффика.
4. После п.1 у тебя должен появиться дистр, в котором удобнее всего. Подпишись на его рассылки, следи за багтерекерами наиболее интересующих программ, начни засылать багрепорты/переводы/патчи.
5. Можно устраиваться работать. Скорее всего сначала без официального опыта возьмут только в какую-нибудь быдлоконторку или быдлолокалку, но сидя там на окладе можно потихоньку мониторить объявления и искать что-нибудь получше. Потом главное попасть на собеседование. Причём смотреть, чтобы объявление было написано грамотно(т.е. его составлял спец, а не ОК). Тогда и собеседование будет проводить спец, а значит оценить твои знания реально.
6. PROFIT

P.S. Сам я, правда, начал с шестого пункта, а потом перешёл на первый. ;)

Как раз у IBM'ов лучше читать английские материалы. На русском 90% банальщины, разжёванной для первоклашек.

Ну, раз ничего не помогает, надо бы логи посмотреть.
Как обычно погрепать по messages, а так же включить в
/etc/default/bootlogd опцию BOOTLOGD_ENABLE=Yes, после чего появится подробный лог загрузки.

Здесь не слагаемые. Здесь родитель и ребёнок. И их местами менять не стоит.

Да как бы изначально уныло было.

А вот тут соглашусь. Я всегда придираюсь к кривому софту.

Удачи. :)

И да. Не надо мне новости и обновления кидать. Я по долгу службы уже о них знаю. :)
Я три дистрибутива использую дома и ещё два на работе. Плюс постоянно слежу за актуальным софтом и в песочнице держу специально для этого несколько снимком lfs для опытов. Работа такая.
И даже если я не ставил ещё ни разу systemd - это не потому, что руки не дошли или я не знаю о нём, а потому, что я не считаю нужным пока даже пробовать это забагованное поделие - как уже неоднократно писал, минусов на данный момент у него в разы больше, чем плюсов.

Цитата побилась слегка(Разрабы, чего такое с парсером? То код бьёт, то простые цитаты? Багрепорт есть или надо заслать?)
В общем, она тут есть.

Баги не в дебиане. Баги в systemd в принципе. То, что в других дистрах на них забивают или просто там нет такого количество пакетов - это не оправдание. И это тоже одна из причин по которой мне не нравится systemd. Пихать это сырое поделие в стабильный дистр - глупо. Поттеринг, может и хорош на выдумки, но все его реализации кривы и недоделаны. Как смеялись мы как-то с одним знакомым админом:

А про хорошесть, полезность и прогресс когда говорили в контексте hald. Многие и я в том числе плевались и руками выпиливали его, когда он появился в lenny. Ничего, пережили. Здравый смысл победил и от этого мусора отказались. По ссылке я так и не увидел, где там сказано, что systemd собираются впиливать подефолту, как раз наоборот - пишут, что в ближайшее время это нереально. А дальше. А дальше либо его полностью переделают(как по ссылке пишут для поддержки нормальных инит-скриптов), либо как и hal выпилят со временем за ненадобностью.
От себя ещё добавлю, не так давно говорили, что и pulseaudio станет дефолтом во всех дистрах. К счастью этого не случилось - некоторые разработчики всё ещё придерживаются KISS и unix-way.
Так что ты можешь хоть в каждом сообщении переходить на личности и обзывать меня троллем, но даже те ссылки, которые ты сам приводишь, говорят в мою пользу.

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

А про то, что проекты udev и systemd слились под общим названием я знаю, потому как systemd тянет на себя часть функционала udev'а и не может без него работать(то, что я говорил - прибит гвоздями). Но udev всё так же компилится отдельно.

Гы. В bsd арч-стиль загрузки? Такого я ещё не слышал. А как ребята из Беркли в далёкие времена UNIX'ов узнали об арче? Машину времени попутно изобрели? :)

А в debian'е везде используется один унифицированный интерфейс. Что для инит-скриптов, что для базовой системы. Только в GNU/Linux ядро Linux, а в GNU/kFreeBSD, соответственно фряшное ядро.

Если так сравнивать, то ничем. Я лично скрином пользуюсь только тогда, когда надо оставить какую-нибудь задачу выполняться на сервере, не боясь закрыть ssh.

screen же.

Всё просто.
Debian - это не только Linux. Это ещё как минимум Hurd и kFreeBSD(официальный). А это значит, что пока какая-то его часть не умеет freebsd, она не будет в дефолтной поставке. Или они откажутся от поддержки FreeBSD'шного ядра, или от systemd в дефолте.

И где там написано, что он дефолтным будет? ;)
Я ведь не сказал, что его вообще в дебиане не будет.

Там уже нет главной свистелки. Простоты.
Ну и красношапка красношапкой, но hal таки отовсюду выпилили. А к тому же systemd - это только линукс, а значит он никогда не станет дефолтным в debian'е. Что не может не радовать.

Ну извините, не удержался:
пользуешься арчем - ССЗБ
:))

Даже не догадываюсь, как это делать в арче. Ни разу не ставил и вряд ли когда попробую.
А вот в дебиане, например, можно заглянуть в те же стартовые скрипты и посмотреть на опции Required-Start, Required-Stop, Default-Start, Should-Start, X-Start-Before и т.д.
В генте я пока не разбирался, как работает параллельная загрузка и как оно определяет зависимости, но оно работает.

Любая современная система загрузки умеет устанавливать зависимости между сервисами.

Ну, возможно.
В общем, ждём ответа ТС.

И как же тогда у меня работает система?

1 2 3 4 5 6 7 8 9 10

$ grep -vE "(#|^$)" /etc/fstab /home/cppmm/.swapfile swap swap sw 0 2 shm /dev/shm tmpfs nodev,nosuid,noexec 0 0 UUID=0c48ee2c-3625-4f04-af25-4c8af5220c38 / ext4 defaults 1 2 UUID=6ee945c4-eec7-472c-aa55-6706cfc11517 /boot ext2 defaults 0 0 UUID=fb3e71ee-86b8-432b-8528-74c19c29bb50 /usr ext4 defaults 0 2 UUID=5ad62b35-2494-4c42-8256-24291435de31 /var ext4 defaults 0 2 UUID=01180708-0780-4816-821d-f943c05e0dbd /tmp ext4 defaults 0 2 UUID=78e8526e-ff09-41c4-8e39-8d9476e04f13 /opt ext4 defaults 0 2 UUID=18f44ed7-5ada-4ce8-8143-e8e37316edd6 /home ext4 defaults 0 2

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

Порядок расположения записей в fstab не влияет ни на что. А вот последние цифры указывают на очерёдность монтирования.

Попробуй его попозже поставить. Я обычно где-нить на 0 2 ставлю.

Ух ты класс какой. Спасибо, я лично не знал про такую утилиту.