В статье (http://www.dzti.edu.lv/isp-serv/index.php?l=6) подробно рассказано про этапы загрузки системы, раскрыта тема уменьшения времени загрузки Fedora Core 4, через максимально возможное упрощение загрузочных скриптов.URL: http://www.dzti.edu.lv/isp-serv/index.php?l=6
Новость: http://www.opennet.me/opennews/art.shtml?num=7025
"в моем случае время загрузки сократилось с 16сек. (сервисы: syslogd,sshd,network,crond,gpm) до 7сек, для P4-2.8GHz"Сразу видно, что нечем заняться человеку.
Дело не в секундах, а в том, чтобы у начинающего администратора была ясная картина о том что происходит от включения питания до приглашения
bash.Из статей в интернете да и из книг, сложно сформировать такое представление, поскольку там разбирают достаточно сложные для
начинающего пользователя загрузочные скрипты, а также не
объясняют некоторые мелочи, через которые рано или поздно пройдешь.
В статье для этих целей описаны эпизоды из реальных проблем
через которые я прошел.PS
В принципе, те у кого мало времени используют MS-Windows :)
Эх, любимая Слакваря, таким людям мы можем только посочувствовать!
Говорил и буду говорить, все равно какой дистрибутив использовать для _сервера_ !Поскольку все програмные пакеты пересобираются из одних и тех же
исходников. Если что то не нравится -- пересобери непонравившийся
пакет сам, как это было описано в предыдущих статьях:
http://www.dzti.edu.lv/isp-serv/index.phpЕсли говорить о том, какой десктоп удобнее для НЕ-програмиста или
НЕ-администратора отвечу Windows, по статистике посещений сайта,
не более 40% посетителей используют Linux, при том, что тематика
статей сугубо Linux.
>не более 40% посетителей используют Linux,
Сам посчитал?
http://www.puls.lv/
Aga, u menja na rabote, otkuda ja chitaju novosti, tol'ko XP, a doma - tol'ko Linux. Wy znaete, komu takaja statistika nuzhna?
Не надо вырывать фразу из контекста, статистика упоминалась
для того, что бы подвести черту к фразам типа
"Такой-то Linux дистр лучше всех",
поскольку данные утверждения имеют место быть в большинстве
случаев для десктопа, ну а раз была затронута тема десктопов,
то и была приведена статистика.Вообще на работе человек проводить бОьшую часть своей жизни,
к тому же реально выполняет возложенные на него задачи.Может мне тоже горько видеть эту статистику (правда глаза колет),
отчасти такое положение дел связано с тем, что для освоения Linux, надо
затратить намного больше времени чем Windows. Но главная проблема,
что Linux не хватает много чего, чтобы полностью перейти на него,
например аналога MathCad, полнофнкционального/совместимого Autocad,
удобного для студентов Multisim (gEDA http://geda.seul.org/ ) и так
далее. Об игрушках просто умолчим:)
>Говорил и буду говорить, все равно какой дистрибутив использовать для _сервера_ !Ну, глупости говорили и ещё и грозитесь в том упорствовать. Может, через пару-тройку лет пообтешется.
Hints:
- управляемость
- обновляемость (как updates, так и при необходимости -- обычно вследствие прекращения поддержки предыдущего выпуска -- между major releases)
- отчуждаемость и делегируемость управления
- надёжностьТак вот, самопальство ухудшает обычно это всё, в т.ч. последний пункт -- несмотря на то, что более сложные скрипты очевидно могут сломаться в большем количестве мест, их необязательно наивные люди писали и рассчитывали не только на более общее применение, а и на более широкий круг нештатных ситуаций, которые могут возникнуть.
Вы там ошибки обрабатываете?
>Поскольку все програмные пакеты пересобираются из одних и тех же
>исходников.Ерунда. За этот "довод" держатся только чайники-слакваристы, какового Вы пока и напоминаете (ничего личного, сам когда-то курочил очень подобным образом четвёртый или пятый редхат; но при переезде на пятый или шестой вот и задумался -- а часто ли вообще тазик загружается и не лучше ли это время потратить более разумным и полезным образом).
Чтобы не быть голословным -- можете посмотреть спеки пакетов apache или xmms, которые в ALT поддерживаю:
http://sisyphus.ru/srpm/apache/spec
http://sisyphus.ru/srpm/xmms/spec(уже молчу про glibc, rpm или apt)
>Если что то не нравится -- пересобери непонравившийся
>пакет сам, как это было описано в предыдущих статьях:
>http://www.dzti.edu.lv/isp-serv/index.phpЭто осмысленно в двух случаях:
- сильно локальные изменения (это дорасти ещё надо);
- понимание, как улучшить пакет в используемом дистрибутиве, чтобы и свои изменения были "из коробки", и по возможности другим жизнь не испортить. Для этого надо дорасти ещё довольно заметно.> главное в статье то, чтобы _начинающий_ администратор
> имел ясное представление о загрузке системыЕсли исходить при этом из важности времени загрузки или "в пять строк" -- ничего хорошего из такого "представления" не выйдет. См. выше.
> по опыту проведения лабороторных занятий по Linux
"Кто не умеет -- учит"? ;-) (я-то и учить не умею, приходится учить, как учить -- в смысле методички квазаровские местами писал ;-)> даже простая конструкция типа
> [ -x /usr/sbin/named ] || exit 1
Так разбирать скрипты надо начиная с Керниган-Пайка "UNIX: универсальная среда программирования" или там Bash conspect (гуглится). Это раз. Два -- нормальному (не претендующему) администратору вообще сиренево, что там в скриптах, постольку, поскольку их поведение соответствует документации.Кусок разбора RH-like /etc/sysconfig/network-scripts/, который Вы привели, достаточно понятен (единственно что спросонья не соображу, что именно приходит на | sort, ну и LANG=C можно было в subshell воткнуть в одном экземпляре или просто выставить в начале скрипта и восстановить в конце/трапилке (явно напоролись на грабли с UTF-8 или порядком сортировки и фиксили на скорую руку)).
> у меня нет страха показатся некомпентным
Да тут не "страх" и не "показаться", просто стоит выслушать, что народ говорит, и подумать, а чего эт они хором набросились. Поскольку прививание слакваризма начинающим адимнистраторам суть смертный грех, потом такие пересобаченные на скору руку по принципу "шоб мне понятней" системы проще отодвигать в сторонку и строить с нуля, чем поддерживать.
> В заглавие статьи есть слово СЕРВЕР, ну какие могут быть сложности
> с обновлением для сервера,
Любые.> В принципе, кто нибудь читал статью
Продиагоналил => "о, знакомо".> PS В принципе, те у кого мало времени используют MS-Windows :)
"...и эту глупость я говорю и буду говорить!" (c)
PS: вот, почитайте лучше статью, написанную Вашим коллегой (на время написания) -- о том, как надо заниматься промышленными системами: http://www.linux.kiev.ua/ru/docs/articles/ideal-sysadm-rpm/
PPS: он же -- автор /etc/net (http://etcnet.org, http://wiki.sisyphus.ru/admin/etcnet/). Думаю, многие здесь могут посмотреть на свои нетривиальные скрипты с активным использованием iproute2, посмотреть туда -- и оценить квалифицированную работу по обобщению.
Может из-за того что Вы прочли
>> В принципе, кто нибудь читал статью
>Продиагоналил => "о, знакомо".так как из серии "чукча писатель, а не читатель"
отвечу простым языком:Все статьи сайта
http://www.dzti.edu.lv/isp-serv/index.phpнаписаны для создания сервера по управлению трафиком,
чтобы сервер поддерживал ESFQ,Layer 7,geoip, connbytesЧто для этого надо?
Внести изменения в kernel,iproute2,iptablesMichael Shigorin>
- управляемость
- обновляемость (как updates, так и при необходимости -- обычно вследствие прекращения поддержки предыдущего выпуска -- между major releases)
- отчуждаемость и делегируемость управления
- надёжностьИзвеняюсь за выражения "наxера" мне это надо в моем конкретном случае?
Я давно заметил, что стоит написать что то посложнее, народ молчит...
к примеру: http://www.dzti.edu.lv/isp-serv/index.php?l=3
А вот когда поднимается вопрос, через который прошел "бывалый" админ,
шума поднимается много, а в чем причина такой активности:
я это знаю.. поэтому надо себя показать, даже в когда Michael Shigorin
писал столь длительную нотацию, не прочел по диоганали тот факт,
главная задача сервера это управление трафиком, и при чем тут (отчуждаемость и делегируемость управления и т.д.)Цель статьи проста:
1) разобраться в этапах загрузки Linux на понятных
большинству начинающих админов скриптах
2) использовать полученные занания для создания ISP-serv
>Может из-за того что Вы прочли
>>> В принципе, кто нибудь читал статью
>>Продиагоналил => "о, знакомо".
>так как из серии "чукча писатель, а не читатель"Вот-вот-вот. Уж не обижайтесь, но даже по общему уровню грамотности (количиству ашибок и очипяток) это стало быстро ясно -- но как бы дело наживное.
>отвечу простым языком:
Вы лучше прочтите простыми глазами, вот как от друга. Бывает, и друзьям так пишу, и от них порой принимаю, когда чего-то почти, но всё же не того налепил. Оно ж не ради наездов, а чтобы хорошему человеку срезать дорогу по граблям, которая уже пройдена многими (повторюсь, на конкретно этом куске -- мной тоже).
>Все статьи сайта http://www.dzti.edu.lv/isp-serv/
>написаны для создания сервера по управлению трафиком,
>чтобы сервер поддерживал ESFQ,Layer 7,geoip, connbytesНу.
>Что для этого надо?
>Внести изменения в kernel,iproute2,iptablesДля этого надо либо воспользоваться специализированными дистрибутивами, либо предложить в имеющиеся соответствующие изменения. Из спец может иметь смысл посмотреть на radlinux.org и freesco (те, с авторами которых знаком), но вообще их множество.
Почему? Да потому, что когда в следующий раз понадобится сгородить такую систему -- на это уйдёт намного меньше времени. Да и для уже построенных такие задачи, как обновление при имеющих отношение дырках ядра или юзерспейса будет менее чреватым.
> >- управляемость
> >- обновляемость
> >- отчуждаемость и делегируемость управления
> >- надёжность
>Извеняюсь за выражения "наxера" мне это надо в моем конкретном случае?Значит, Вашему работодателю следует порекомендовать задуматься, зачем ему такой "спициалист". И тем более не следует Вас допускать кого-либо учить строить и администрировать Linux-серверы.
Поймите правильно, я сам *благодарен* людям, которые в своё время заставили задуматься над очередной статьёй (такого себе экстремистски-линуксического плана "о десктопе") -- а *зачем* оно такое надо?
При этом я преподавал и до сих пор порой преподаю линуксовые курсы в крупнейшем образовательном ИТ-центре Украины, а наша фирма (http://emt.com.ua) как раз и занимается созданием поддерживаемых линуксовых решений. Потому и не ради "поопускать", а стараюсь подсказать, что ещё лучше обдумать, прежде как применять таланты техписателя и преподавателя (у Вас они явно наблюдаются, просто любой талант можно применить не по делу и будет хуже).
>Я давно заметил, что стоит написать что то посложнее, народ молчит...
>к примеру: http://www.dzti.edu.lv/isp-serv/index.php?l=3(сорри, тут читать некогда) Возможно, помимо "немассовости" ещё следствие того, что и сами более адекватно и серьёзно подошли к теме. А тут -- тьфу, скрипты, да ща мы их. :-)
>А вот когда поднимается вопрос, через который прошел "бывалый" админ,
>шума поднимается много, а в чем причина такой активности:
>я это знаю.. поэтому надо себя показатьДа мне-то что, просто сам попадался на необдуманные руководства, которых лучше бы не было вообще, чем такими.
Поэтому пишу ради архива и новичков, каким сам был и есть. Можете проверить, в рассылках и ньюсах веду себя точно так же.
>даже в когда Michael Shigorin
>писал столь длительную нотацию, не прочел по диоганали тот факт,
>главная задача сервера это управление трафиком, и при чем тут >(отчуждаемость и делегируемость управления и т.д.)Обычно *главная* задача сервера -- это *надёжное* выполнение *поставленной* задачи.
На пальцах -- если завтра его юные бразильцы взымеют через найденную и не заткнутую вовремя дырку в каком ssh или слабый пароль на угадываемом аккаунте и с Вашей системы мне спам придёт, то тот факт, что сервер продолжает управлять трафиком, не помешает мне накатать на соответствующий выуженный whois или whob контакт и/или spamhaus телегу (форвард).
Проблемы Вашего работодателя при необходимости замены (подмены, страховки) ушедшего (заболевшего, перегруженного) работника -- Вас -- меня в данном разе волнуют мало, но хороший работник и сам умеет подстраховаться, чем зарабатывает ещё и правильную репутацию. Причём документировать деятельность -- хорошо, но пользоваться типичными решениями вместо изобретения самопальных -- ещё лучше.
>Цель статьи проста:
>1) разобраться в этапах загрузки Linux на понятных
>большинству начинающих админов скриптахЕщё раз: этот опус и Ваши скрипты *не решают* этой задачи для современного Linux. А древнюю слакварь уже давно изобрели и тыщу раз переизобрели.
Предложение превращать каждый линукс в слакварь отметается по вышеизложенным причинам.>2) использовать полученные занания для создания ISP-serv
Знания именно из этой статьи использовать противопоказано, боюсь.
Хотите верьте, хотите нет (впрочем, это тоже можно нагуглить, не впервые говорю) -- у нас на фирме слакваристов в штат попросту не принимают, слишком много проблем.Если же человек умудрился из обобщённого редхата слакварь сделать -- вдвойне нельзя подпускать к промышленным системам, пока не научится делать нужное не ломающим системообразующие вещи образом.
Андрей, ну только не обижайтесь -- примите на подумать, не бросайтесь отвечать. (хоть сам и обижался, бывало, да потом понимал, что зря :-)
Если Вы принимаете участие в курсах,
то навреняка согласитесь с тем,
что обучение должно начинаться с понятных и ясных примеров.Мне бы очень хотелось посмотреть на Ваш курс, где излагаются темы затронутые в статье, может оставите ссылочку с главой из курса по Linux?
>Если Вы принимаете участие в курсах,
>то навреняка согласитесь с тем,
>что обучение должно начинаться с понятных и ясных примеров.
Разумеется. Ещё хорошо, когда они не абстрактные, а прикладные; в лицее на факультативе когда-то детишкам предложил оскриптовать задачку переименования стопки *.htm в *.html с соответствующим исправлением ссылок в изменяемых файлах... вроде даже интересно вышло ;-)При этом современные инитскрипты к таковым действительно не относятся, почему сразу и сказал -- _начинающему_ администратору туда в r/w лезть незачем, хотя при хорошем настроении почитать для общего развития полезно. А если зазор жиклёров регулировать, так лучше к знатокам съездить раз-другой в год :-)
>Мне бы очень хотелось посмотреть на Ваш курс, где излагаются темы затронутые
>в статье, может оставите ссылочку с главой из курса по Linux?
Увы, он принадлежит УЦ Квазар-Микро (хотя насколько знаю -- в ряде случаев "добро" на передачу студентам или коллегам извне Украины давалось).Оставьте почту, черкну человеку, который за него отвечает. Может, когда и польза из этого выйдет.
http://www.edu.kvazar-micro.com/education/it/linux/la_1.php (не мой)
http://www.edu.kvazar-micro.com/education/it/linux/la_adv.php
http://www.edu.kvazar-micro.com/education/it/linux/la_net.php
Уважаемый, а чем Вам слакварь не угодила? Сколько знаю альтовцев - поголовно все её ругают. Может, из-за того, что "can't install and configure slackware"? ;-)
P.S. На самом деле любой дистрибутив можно превратить в помойку.
P.P.S. Знаю полно и чайников-альтовцев и хороших спецов-слакварщиков. И наоборот.
>Уважаемый, а чем Вам слакварь не угодила?
Воспитанием отношения "ща мы это быренько перехачим" с описанными (не только мной) последствиями.>Сколько знаю альтовцев - поголовно все её ругают.
>Может, из-за того, что "can't install and configure slackware"? ;-)
А среди альтовцев есть и бывшие слакваристы (причём в т.ч. и довольно матёрые), они-то и склонны поминать особо незлым тихим ;-)>P.S. На самом деле любой дистрибутив можно превратить в помойку.
Чему великолепным примером и есть эта статья. И наоборот, на слаквари можно пользоваться пакетами и не разламывать то, что есть.Собственно, первым увиденным мной линуксом была именно слакварь (3.6, что ли ;-)
>P.P.S. Знаю полно и чайников-альтовцев и хороших спецов-слакварщиков. И наоборот.
Знаю двух хороших спецов-слакварщиков (один в Одессе, другой -- папа DeepStyle). Остальные давно свалили, преимущественно на дебиан... эти, в общем, в курсе, но одному лениво (хотя вроде подумывал), другой прекрасно понимает, что это дело личного вкуса, а не техническое. В его случае.Моя-то проблема тут в другом -- в Украине спрос на хорошо построенные линуксы едва ли не выше предложения. Вот только какого-то лешего (после появления на Петровке перевода патриковской книжки?) появились тонны чайников-слакваристов и найти толкового человека в штат/на проект/заказчику стало едва ли не сложней. Привычки махать кувалдой по поводу и без повода очень трудно вытравливаются :-( [опять же проверено на себе]
Вот и рубаюсь с ветряными мельницами, пока остатки молодёжи не смололи ни за что :-)
>>Уважаемый, а чем Вам слакварь не угодила?
>Воспитанием отношения "ща мы это быренько перехачим" с описанными (не только мной)
>последствиями.
Т.е. тому, кто использует Слакварь не нужна помощь от гуру из Альта - там и так все просто и понятно. А кушать то хочется...>А среди альтовцев есть и бывшие слакваристы (причём в т.ч. и довольно
>матёрые), они-то и склонны поминать особо незлым тихим ;-)
Ага, если все сядут на слаку - кому нужна будет альт?>>P.S. На самом деле любой дистрибутив можно превратить в помойку.
Хваленые большие дистрибутивы типа шапки и ее клонов - это уже помойки. Сначала ты ставишь такую хрень, а потом выковыриваешь из нее то, что попало туда благодаря зависимостям. Или молишся, чтобы в тонне ненужного ПО никто не нашел багов и не подломал тебя. А ведь баги найдут...В слаке, которую вы так усердно ругаете, я имею полный контроль над системой. Я точно знаю, что там стоит, почему оно там стоит, когда запускается и для чего.
В слаке прозрачные, простые и понятные загрузочные скрипты, чего о шапкоподобных монстрах сказать никак нельзя. И в них легко разобраться может даже очень зеленый админ. А понимание того, как и что происходит во время загрузки - это важнейший шаг к контролю за системой.>
>Собственно, первым увиденным мной линуксом была именно слакварь (3.6, что ли ;-)
>
Плохо вы ее рассмотрели, значит. Обычно люди переходят на нее, когда понимают ущербность тяжеловесных монстров.>Моя-то проблема тут в другом -- в Украине спрос на хорошо построенные
>линуксы едва ли не выше предложения. Вот только какого-то лешего
>(после появления на Петровке перевода патриковской книжки?) появились тонны чайников-слакваристов и
>найти толкового человека в штат/на проект/заказчику стало едва ли не сложней.
> Привычки махать кувалдой по поводу и без повода очень трудно
>вытравливаются :-( [опять же проверено на себе]
>
>Вот и рубаюсь с ветряными мельницами, пока остатки молодёжи не смололи ни
>за что :-)
По моим наблюдениям, массовое распространение шапкоподобных дистрибутивов с графическими конфигурялками привело к появлению огромного количества людей, которые ничего, кроме тыканья кнопочек в этих конфигурялках делать не умеют. Как только возникает более-менее нестандартная задача, такие люди садятся в лужу. Потому, что кнопочками много не натыкаешь. А кувалды эти люди и в глаза не видели.
>>>Уважаемый, а чем Вам слакварь не угодила?
>>Воспитанием отношения "ща мы это быренько перехачим" с описанными
>>(не только мной) последствиями.
>Т.е. тому, кто использует Слакварь не нужна помощь от гуру из Альта
>- там и так все просто и понятно. А кушать то
>хочется...Дружище, сделайте милость, перечитайте предыдущий ответ и не передёргивайте. Не "т.е.".
>>А среди альтовцев есть и бывшие слакваристы
>Ага, если все сядут на слаку - кому нужна будет альт?if.
>>>P.S. На самом деле любой дистрибутив можно превратить в помойку.
>Хваленые большие дистрибутивы типа шапки и ее клонов - это уже помойки.В некоторой мере (у универсальности есть цена, но оно того стоит). Собственно, по минимизации себе и подбирал (чуть не свалил на Debian с редхат-лайк, да как раз с альтом пересёкся в 2001).
Фигня одна -- бардак не есть только состояние, а ещё и процесс. И одно дело -- вылизывать один тазик и трястись над ним с бабушкиными плюс сегодняшними патчами и ./configure && make && make install от рута (ловя каждый configure-троян дня), другое -- иметь возможность те же обновления по безопасности накатывать на все используемые хосты и vserver'ы просто по cron.
Почитайте и Вы http://www.linux.kiev.ua/ru/docs/articles/ideal-sysadm-rpm/ , что ли. ("rpm" в названии можно игнорировать :)
>Сначала ты ставишь такую хрень, а потом выковыриваешь из нее то,
>что попало туда благодаря зависимостям.Всё правильно говорите, только это болячка в основном именно редхата с его крупноблочной порезкой и традиционным апгрейдом вида rpm -Fvh *.rpm. И горе-админов с привычкой к full install :-E
К нам она не то чтобы совсем не относится (мягких зависимостей в rpm всё-таки не хватает), но уже в 2001 всё было довольно неплохо (тогда интерес бывал и в том, чтоб на гиговый винчестер поплотнее встать :-), а сейчас так скорее хорошо.
По крайней мере минимальный vserver с образом ALM2.4 у меня в тарболе занимает 16Mb: ftp://ftp.altlinux.org/pub/people/mike/vserver/
>Или молишся, чтобы в тонне ненужного
>ПО никто не нашел багов и не подломал тебя. А ведь
>баги найдут...FYI: базовая система ALT Linux по части безопасности ближе к OpenBSD (как и Owl GNU/*/Linux -- у нас sec teams пересекаются и давно сотрудничают).
Это помимо ненужности установки ненужного и выдачи лишних прав (у нас хороший серверный процесс -- это непривелегированный и в чруте; если возможно, то идеал -- в пустом r/o (c) ldv).
>В слаке, которую вы так усердно ругаете
Да не слаку я ругаю, а попрекаю хвалящих её в отсутствии желания думать.
Байтики-то в чём виноваты...>я имею полный контроль над системой.
Ещё один типичный FUD. А я что -- не имею? У меня что -- отобрали vim и gcc? Нет, мне просто дали инструменты более высокого уровня. Хочу/умею -- применяю, а могу и знать про них, но по привычке брать в руки vim.
Это не довод, иными словами.
>Я точно знаю, что там стоит, почему оно там стоит,
>когда запускается и для чего.Будьте добры, расскажите, откуда, когда и зачем на Вашей системе взялся бинарник protoize.
>В слаке прозрачные, простые и понятные загрузочные скрипты, чего о шапкоподобных монстрах
>сказать никак нельзя. И в них легко разобраться может даже очень
>зеленый админ.Плохо другое -- зелёным он и остаётся в большинстве случаев из-за подмены целей и понятий. Не может перерасти уровень localhost.
>А понимание того, как и что происходит во время
>загрузки - это важнейший шаг к контролю за системой.Это если её важнейшая задача -- загружаться ;-) (помните статью?)
>>Собственно, первым увиденным мной линуксом была именно слакварь (3.6, что ли ;-)
>Плохо вы ее рассмотрели, значит.Да нет, достаточно. И её, и фрю. Выводы до сих пор применимы. :-)
>Обычно люди переходят на нее, когда понимают
>ущербность тяжеловесных монстров.Да если куда и перейду -- то разве что на Debian/Ubuntu, и то маловероятно -- с "родным" сообществом туговато, а с буржуями общаться даже при своём fluent english неинтересно, чуть за технические темы выйти. Политкорректность, блин, вместо человека слишком часто :-(
Повторяю: если новичка обманули и вместо нормального рабочего в разных условиях дистрибутива подсунули "учебную" слакварь -- ему проблемы будут при первом десятке серверов, работодателю -- при первой проблеме с ними, а посоветовавшему -- за лапшу на уши, даже если искреннюю.
Вот же ж -- повылазят гентушники со слакваристами и начнут орать -- "да мы! проффисионалы!"... Правда, потом выясняется, что ядро они -- не хачили, в gcc и glibc -- тоже не лазили, но однако же с умным видом (TM) говорят, что знают систему как свои пять пальцев, прочитав нехитрых патриковских скриптов.
Ну-ну.
>> Привычки махать кувалдой по поводу и без повода очень трудно
>>вытравливаются :-( [опять же проверено на себе]
>По моим наблюдениям, массовое распространение шапкоподобных дистрибутивов с графическими конфигурялками
>[...] Потому, что кнопочками много не натыкаешь.Эт да, но другая крайность. А разумно не по сторонам метаться, а посредине идти. Вот между прочим, как раз в дебиане и альте уважают многослойный инструментарий, который и сам по себе пригоден, и под морду запихать можно.
Например, у нас есть чудная и простая как двери системка, control(8) называется. Можно написать и положить в пакет sudo файлик /etc/control.d/facilities/sudo вида
#!/bin/sh
. /etc/control.d/functions
BINARY=/usr/bin/sudonew_fmode public 4711 root root
new_fmode wheelonly 4710 root wheel
new_fmode restricted 700 root rootnew_help public "Any user can execute $BINARY"
new_help wheelonly "Only \"wheel\" group members can execute $BINARY"
new_help restricted "Only root can execute $BINARY"control_fmode "$BINARY" "$*" || exit 1
-- и после этого регулировать права на бинарник командами вида
control sudo wheelonly
при этом обновление пакета автоматически восстанавливает указанные права.
Подумайте сами, насколько такие вот мелочи (скорее невозможные без пакетов или эквивалентной по усложнению жизни технологии) полезны на многие серверо-годы...
>А кувалды эти люди и в глаза не видели.
Знаете, после этой зимы уже даже не скажу, что это плохо. Страшна она в последствиях. Не дай Бог Вам разбирать завалы за мощным кувалдистом.
PS: IMCO простые задачи должны решаться просто, а для решения сложных задач необходимо желание учиться. И никуда тут не денешься.
>Фигня одна -- бардак не есть только состояние, а ещё и процесс.
> И одно дело -- вылизывать один тазик и трястись над
>ним с бабушкиными плюс сегодняшними патчами и ./configure && make &&
>make install от рута (ловя каждый configure-троян дня), другое -- иметь
>возможность те же обновления по безопасности накатывать на все используемые хосты
>и vserver'ы просто по cron.
>
Да, если серверов много - возможность полезная.>Почитайте и Вы http://www.linux.kiev.ua/ru/docs/articles/ideal-sysadm-rpm/ , что ли. ("rpm" в названии можно игнорировать
>:)
Почитал. Согласен с большинством положений. Особенно правильно было сказано про сохранение конфигурации. Единственное - автор забывает указать, что таким же макаром прекрасно сохраняется конфигурация откомпилированных пакетов. Хотя нельзя не признать, что время на компиляцию больше, чем время на установку бинарника. Но, с другой стороны, откомпилирован пакет будет конкретно под вашу машину, тогда как бинарник будет откомпилирован под минимально доступную конфигурацию.>
>>Сначала ты ставишь такую хрень, а потом выковыриваешь из нее то,
>>что попало туда благодаря зависимостям.
>
>Всё правильно говорите, только это болячка в основном именно редхата с его
>крупноблочной порезкой и традиционным апгрейдом вида rpm -Fvh *.rpm. И
>горе-админов с привычкой к full install :-E
>
>К нам она не то чтобы совсем не относится (мягких зависимостей в
>rpm всё-таки не хватает), но уже в 2001 всё было довольно
>неплохо (тогда интерес бывал и в том, чтоб на гиговый винчестер
>поплотнее встать :-), а сейчас так скорее хорошо.
>
>По крайней мере минимальный vserver с образом ALM2.4 у меня в тарболе
>занимает 16Mb: ftp://ftp.altlinux.org/pub/people/mike/vserver/
Вот про этот аспект я не знал. Если у вас правда так хорошо с независимостью от левых программ, значит не все потеряно.>FYI: базовая система ALT Linux по части безопасности ближе к OpenBSD (как
>и Owl GNU/*/Linux -- у нас sec teams пересекаются и давно
>сотрудничают).
>
Честно говоря мне слабо в это верится, но если говорите правду - очень хорошо. Мне очень нравится подход команды OpenBSD - я считаю, что сисадмин просто обязан быть параноиком.>Это помимо ненужности установки ненужного и выдачи лишних прав (у нас хороший
>серверный процесс -- это непривелегированный и в чруте; если возможно, то
>идеал -- в пустом r/o (c) ldv).
Очень здравый подход.>>я имею полный контроль над системой.
>
>Ещё один типичный FUD. А я что -- не имею?
>У меня что -- отобрали vim и gcc? Нет, мне
>просто дали инструменты более высокого уровня. Хочу/умею -- применяю, а
>могу и знать про них, но по привычке брать в руки
>vim.
Как сказать. В таких системах (может я неправ, так как сужу по Шапке), надо очень аккуратно редактировать что-то руками, так как есть масса скрытых взаимосвязей и легко что-то поломать. А конфигурялки зачастую не дают того, что надо. Да и знать про их существование надо :)>Будьте добры, расскажите, откуда, когда и зачем на Вашей системе взялся бинарник
>protoize.
root@lanserv:/var/log# slocate protoize
root@lanserv:/var/log#Т.е. нет ее у меня, так как не нужна она мне.
"Программа protoize является необязательной частью GNU C. Вы можете использовать ее, чтобы добавить прототипы к программе, конвертируя, таким образом, программу к ANSI C в одном отношении. Сопутствующая программа unprotioze делает обратное: она удаляет типы аргументов из всех прототипов, которые она находит." Цитата с ОпенНЕТ.>>В слаке прозрачные, простые и понятные загрузочные скрипты, чего о шапкоподобных монстрах
>>сказать никак нельзя. И в них легко разобраться может даже очень
>>зеленый админ.
>
>Плохо другое -- зелёным он и остаётся в большинстве случаев из-за подмены
>целей и понятий. Не может перерасти уровень localhost.
По этому пункту я не могу с вами согласится. Считаю, что тут вы неправы. То, до какого уровня поднимется человек зависит от него самого, а вовсе не от того, какими инструментами он пользуется.>>А понимание того, как и что происходит во время
>>загрузки - это важнейший шаг к контролю за системой.
>
>Это если её важнейшая задача -- загружаться ;-) (помните статью?)
Да нет. Это в любом случае важнейшая задача. Ведь именно на этом этапе система просыпается к жизни. Это, так сказать, ее детство. И для адимна крайне важно, чтобы оно было счастливым :)>
>>>Собственно, первым увиденным мной линуксом была именно слакварь (3.6, что ли ;-)
>>Плохо вы ее рассмотрели, значит.
>
>Да нет, достаточно. И её, и фрю. Выводы до сих
>пор применимы. :-)
Текущая версия 10.2 Как мне кажется, ваши выводы несколько устарели.>Да если куда и перейду -- то разве что на Debian/Ubuntu, и
>то маловероятно -- с "родным" сообществом туговато, а с буржуями общаться
>даже при своём fluent english неинтересно, чуть за технические темы выйти.
> Политкорректность, блин, вместо человека слишком часто :-(
>
>Повторяю: если новичка обманули и вместо нормального рабочего в разных условиях дистрибутива
>подсунули "учебную" слакварь -- ему проблемы будут при первом десятке серверов,
>работодателю -- при первой проблеме с ними, а посоветовавшему -- за
>лапшу на уши, даже если искреннюю.
Не вижу, отчего бы у него возникли проблемы. Да и слака не только учебная.>Вот же ж -- повылазят гентушники со слакваристами и начнут орать --
>"да мы! проффисионалы!"... Правда, потом выясняется, что ядро они --
>не хачили, в gcc и glibc -- тоже не лазили, но
>однако же с умным видом (TM) говорят, что знают систему как
>свои пять пальцев, прочитав нехитрых патриковских скриптов.
Я не орал, что я профессионал. Но кое что я умею. Для того, чтобы хачить ядро или внутрь glibc лазить - подготовки маловато, да и не нужно оно мне.>>> Привычки махать кувалдой по поводу и без повода очень трудно
>>>вытравливаются :-( [опять же проверено на себе]
>>По моим наблюдениям, массовое распространение шапкоподобных дистрибутивов с графическими конфигурялками
>>[...] Потому, что кнопочками много не натыкаешь.
>
>Эт да, но другая крайность. А разумно не по сторонам метаться,
>а посредине идти. Вот между прочим, как раз в дебиане
>и альте уважают многослойный инструментарий, который и сам по себе пригоден,
>и под морду запихать можно.
>
>Например, у нас есть чудная и простая как двери системка, control(8) называется.
> Можно написать и положить в пакет sudo файлик /etc/control.d/facilities/sudo вида
>
>
>#!/bin/sh
>. /etc/control.d/functions
>BINARY=/usr/bin/sudo
>
>new_fmode public 4711 root root
>new_fmode wheelonly 4710 root wheel
>new_fmode restricted 700 root root
>
>new_help public "Any user can execute $BINARY"
>new_help wheelonly "Only \"wheel\" group members can execute $BINARY"
>new_help restricted "Only root can execute $BINARY"
>
>control_fmode "$BINARY" "$*" || exit 1
>
>-- и после этого регулировать права на бинарник командами вида
>
>control sudo wheelonly
>
>при этом обновление пакета автоматически восстанавливает указанные права.
>
>Подумайте сами, насколько такие вот мелочи (скорее невозможные без пакетов или эквивалентной
>по усложнению жизни технологии) полезны на многие серверо-годы...
>
>>А кувалды эти люди и в глаза не видели.
>
>Знаете, после этой зимы уже даже не скажу, что это плохо.
>Страшна она в последствиях. Не дай Бог Вам разбирать завалы
>за мощным кувалдистом.
>
Подобные системы полезны только при условии ПОЛНОЙ их документации, включая взаимосвязи с другими участками системы и доступности этой документации для конечного пользователя на его родном языке. Иначе возможна ситуация, когда вместо того, чтобы людям жизнь облегчить они будут ее портить. Поясню: это вы хорошо знаете, что там происходит и почему, а другой человек может этого не знать.
Стандартный ответ гуру: читай ман. НЕПРАВИЛЬНЫЙ ОТВЕТ.
Гуру смотрит со своей колокольни. Ему все понятно. А новичок рад бы почитать ман, да не знает, с какой стороны к этой задачи подойти, КАКОЙ ему ман читать. Пример из собственной практики: давно, когда я еще начинал работать с никсами, был у меня Мандрейк Линукс. И поставил я его себе на комп. Рад был, как чайник - красота, кнопочки, КДЕ вобщем. А вот тут, после примерно месяца эксплуатации, возьми у меня русский язык, да и слети. Инета небыло, вопроса задать было некуда, книжки про русский ничего не сообщали. Тыкался я очень долго и в конце-концов переставил систему, так как несмог найти в помощи, как же все исправить. Русский появился. Ненадолго...
Это сейчас я знаю, где надо было искать и что делать. Но и сейчас не знаю, ПОЧЕМУ тогда слетел русский. По науке, слетать он не должен был, так как настраивался при помощи тех самых конфигурялок. И конфигурялки потом никак не смогли исправить ситуацию, или же я не знал, какие из них использовать, чтобы смогли.
Сейчас в слаке я использую для русификации загрузочный скрипт из нескольких строчек. Не было ни одного случая, чтобы при руссификации вылез хоть какой-то намек на глюк. И все очень просто и понятно. Скрипт прекрасно переносится между системами, и не требует какого-либо обслуживания.>PS: IMCO простые задачи должны решаться просто, а для решения сложных задач
>необходимо желание учиться. И никуда тут не денешься.
Вот тут я полностью согласен. Учиться всегда надо.
"Выдало ошибку:
warning: kernel-2.6.11-1.1369_FC4.i686.rpm: Header V3 DSA signature: NOKEY, keyID 4f2a6fd2"
Не ошибку, а предупреждение. :)
Так и хочется сказать автору - посмотри загрузочные скрипты в Slackware или в Archlinux. У Archlinux они простые донельзя. И грузится она почти мгновенно.
>загрузочные скрипты в Slackware
Для когото они простые, но все таки проще приведенных в статье скриптов они наверное не будут.Еще раз повторюсь, главное в статье то, чтобы _начинающий_ администратор имел ясное представление о загрузке системы, а по опыту проведения лабороторных занятий по Linux, скажу что студенты просто сереют когда
им разъясняешь об этапах загрузки системы и демонстрирую скрипты.даже простая конструкция типа
[ -x /usr/sbin/named ] || exit 1
вызывает у них непонимание, когда им впервые
расказывается Linux и отом как он загружается.А конструкции типа (уверен что подобное есть и в Slacke )
interfaces=`ls ifcfg* | LANG=C egrep -v '(ifcfg-lo|:|-range|rpmsave|rpmorig|rpmnew)' | \
LANG=C egrep -v '(~|\.bak)$' | \
LANG=C egrep 'ifcfg-[A-Za-z0-9\._-]+$' | \
sed 's/^ifcfg-//g' |
sed 's/[0-9]/ &/' | LANG=C sort -k 1,1 -k 2n | sed 's/ //'`убивают наповал даже слегка знакомых с Linux ребят.
>А конструкции типа (уверен что подобное есть и в Slacke )
Может, сначала посмотреть, чтобы не выглядеть некомпетентным?
>>А конструкции типа (уверен что подобное есть и в Slacke )
>Может, сначала посмотреть, чтобы не выглядеть некомпетентным?нету у меня Slack,
может приведешь пару строк, как сетевой интерфейс поднимается в
загрузочных скриптах слаки?мне кажется, что проще чем приведено в статье не будет:
ifconfig eth0 xx.xx.xx.ip upТоли многие читать умеют, но не понимают то что написано:
ГЛАВНАЯ ЦЕЛЬ ОЗНАКОМИТЬ НАЧИНАЮЩИХ АДМИНИСТРАТОРОВ С ЭТАПАМИ ЗАГРУЗКИ
СИСТЕМЫ, ДЛЯ ЭТОГО МАКСИМАЛЬНО УПРОЩАЕТСЯ ЗАДАЧА, И ЗАГРУЗОЧНЫЕ СКРИПТЫ
СОСТАВЛЯЮТ НЕ БОЛЕЕ 25 СТРОК В СУММЕ.PS
у меня нет страха показатся некомпентным,
так как большинство ошибок люди совершают
со знающим выражением лица!
Извиняюсь, если задел за личное :-). Я имел ввиду, что скрипты в Федоре действительно замороченные. В Archlinux они просты до такой степени, что человек даже мало знакомый с программированием на bash их поймет. И основная задача скриптов это поднять систему в ЛЮБОЙ конфигурации железа. естественно, что настроенные руками все равно будут быстрее, чем "дистрибутивные". Но Archlinux действительно стартует быстрее.
Если есть интерес, скачай пакет initscripts c сайта ftp.archlinux.org (это обычное затаренное дерево файлов). Он содержит все скрипты. Я думаю, что это того стоит. Может тогда к Федоре захочется прикрутить схему загрузки Archlinux :-).
P.S. Про выражение с "ошибками со знающим выражением лица" согласен на 150%
Да, естественно, чуть посложнее. А всё из-за того, чтобы отделить данные от программ(в нашем случае - скриптов). Любой опытный администратор скажет, что всё надо хранить в пакетах, кроме данных.
Тоже согласен. Обновление еще никто не отменял :-).
И все-таки я имел ввиду, что правленное руками (для себя) по-любому будет быстрее, чем "дистрибутивное" (сделанное так, чтобу "угодить" всем).
Простите, что встреваю, но зачем вам вот тут:
>interfaces=`ls ifcfg* | LANG=C egrep -v '(ifcfg-lo|:|-range|rpmsave|rpmorig|rpmnew)' | \
> LANG=C egrep -v '(~|\.bak)$' | \
>
>LANG=C egrep 'ifcfg-[A-Za-z0-9\._-]+$' | \
>
>sed 's/^ifcfg-//g' |
>
>sed 's/[0-9]/ &/' | LANG=C sort -k 1,1 -k 2n |
>sed 's/ //'`
так много LANG=C ? Ведь можно присвоить значение этой переменной или в начале скрипта или в начале нужного фрагмента скрипта, и вернуть к предыдущему значению в конце скрипта или его части. Если эти скрипты вы используете в учебных целях в своих статьях, то лучше сразу учить хорошему тону и не перегружать скрипты лишними деталями.
>Простите, что встреваю, но зачем вам вот тут [...]
>так много LANG=C ?Свои догадки по этому поводу несколько выше писал... у нас-то скрипты другие. :-)
Офигительно! Зачем нужно сервер "загружать"? Он работать должен, а не "загружаться" :-(
На самом деле, проще всего удалить udev+hotplug и выключить бутсплаш при загрузке, а не менять в корне загрузочные скрипты, ибо потом обновляться крайне сложно будет.
>На самом деле, проще всего удалить udev+hotplug и выключить бутсплаш при загрузке,
>а не менять в корне загрузочные скрипты, ибо потом обновляться крайне
>сложно будет.В заглавие статьи есть слово СЕРВЕР, ну какие могут быть сложности
с обновлением для сервера, по сути NAT сервера, описанного в статьях
http://www.dzti.edu.lv/isp-serv/index.phpна ISP-serv практически все что активно использвана собрано
своими усилиями, а доступ имеет тоько админ.
В принципе, кто нибудь читал статью, или прочли заголовок,
начали писать коментарии?
Я все статьи прочитал. Т.е. то, что собрал сам, обновлять не надо ни в коем случае? А если дыру найдут?
Если:
дыра в кернеле -- пересобираешь его,
дыра в iptables -- пересобираешь его,
дыра в iproute2 -- пересобираешь егоКак мне кажется большинство дыр, используют тот факт,
что пользователь (которому разрешили доступ в систему)
может выполнить в системе программу, которая повышает
его привелегии. Поскольку в случае рассматриваемого
ISP-serv только у админа есть такой доступ, то подобного
рода дыры можно не учитывать.
Нет.
Дыра в iptables - надо пересобирать iptables+kernel. Читай внимательно свою же статью :)
Правильным выходом было бы заворачивать в пакеты(с написанием spec-файла/Slackbuild/etc), чтобы потом, в случае необходимости, быстро пересобрать. Да и даже на другой машине, т.е. держать компилятор на продакшне - жестоко.
спасибо за поправку, увлекся copy-past:)в принципе и дыра в iproute2 тоже пересборка ядра, поскольку
esfq патчит и ядро в том числе.этот вопрос по поводу rpm обсуждался нами, действительно,
сборка производится на другой, более мощной машине,
но я остаюсь сторонником не делать rpm по нескольким причинам
1. менее наглядно виден процесс сборки
2. изложенные шаги в статьях позволят человеку на базе полученных
знаний самому при желание создавать spec для rpm.
3. в реальной жизни, малый процент тех, кто использует всякие продукшен
сервера, чаще всего человек имеет полюбившийся ему дистр, его задача
вывести локалку в интернет (в моем случае общага). Изложенный мною
материал позволит это сделать практически в любом дистре, а далее
если он видит необходимость во всяких упомянутых:- управляемость
- обновляемость (как updates, так и при необходимости -- обычно вследствие прекращения поддержки предыдущего выпуска -- между major releases)
- отчуждаемость и делегируемость управления
- надёжностьпускай сам дорабатывает!
Если на мое место придет другой сисадмин, я надеюсь он с легкостью
разберется с 24 строками загрузочных скриптов.По мне чем проще, тем надежнее.
Да и потом посмотрите на патчи, их авторы не пишут всяких rpm,
они полагают что это не их забота. Точно так поступил и я.Если кто то заинтересовался переколбасить изложенный мной на
http://www.dzti.edu.lv/isp-serv/index.php
материал, как это подабает в rpm или что либо ещё, то ради бога!дело в том, что прежде чем создавать rpm нужно знать что ты
хочешь и как это реализовать без всяких наворотов.Реализация без наворотов и предлагается мною.
ЗЫ
Одной статьей нельзя убить всех зайцев, мое мнение такое:
в статьях излагается основной практический подход и основная идеология,
а остальное пускай сами заинтересованные админы дорабатывают.По отзыву в форуме можно подумать я предлагаю создать свой спец дистр,
а на самом деле все что мною написано дает необходимую начальную,
идейную и практическую базу для решения задачи управления трафиком
в своем любимом дистре.
>но я остаюсь сторонником не делать rpm по нескольким причинам
>1. менее наглядно виден процесс сборки
Эт на первых порах, сам тоже дооолго боялся -- спасибо доброму Vladimir Bormotov, терпеливо отучал от пакетофобии новичков вроде меня в fido7.ru.linux :-)>2. изложенные шаги в статьях позволят человеку на базе полученных
> знаний самому при желание создавать spec для rpm.
Эт да.>3. в реальной жизни, малый процент тех, кто использует всякие продукшен сервера
Ну вообще-то production -- это "производство", т.е. production server == "боевой сервер". Вне зависимости от того, как он создан и что внутри, если используется для работы, а не тестов или так, поиграться в серверы науки ради -- то такой и есть.
>Да и потом посмотрите на патчи, их авторы не пишут всяких rpm,
>они полагают что это не их забота. Точно так поступил и я.
Не стоит расписываться за всех, это не так.
>дело в том, что прежде чем создавать rpm нужно знать что
>ты хочешь и как это реализовать без всяких наворотов.
>Реализация без наворотов и предлагается мною.А я говорю, куда _дальше_ думать помогает :-)
>ЗЫ
>Одной статьей нельзя убить всех зайцев, мое мнение такое:
>в статьях излагается основной практический подход и основная идеология,
>а остальное пускай сами заинтересованные админы дорабатывают.Андрей, да спасибо же :-)
>Нет.
>Дыра в iptables - надо пересобирать iptables+kernel. Читай внимательно свою же статью
>:)Ну это если patch-o-matic баловаться, то практически обязательно :-(
>Правильным выходом было бы заворачивать в пакеты(с написанием spec-файла/Slackbuild/etc), чтобы потом, в
>случае необходимости, быстро пересобрать. Да и даже на другой машине, т.е.
>держать компилятор на продакшне - жестоко.Вооот -- видите, всё Вы знаете :-)
> Вооот -- видите, всё Вы знаете :-)
Я не просто знаю - это единстенный правильный путь, который я советовал автору статьи.
>Поскольку в случае рассматриваемого
>ISP-serv только у админа есть такой доступ, то подобного
>рода дыры можно не учитывать.Для байтогонялки и если игнорировать DoS, которые тоже порой откапывают -- то да; народ когда-то делал рутеры с патчиком к ядру, чтоб не паниковало при отстреле init(8): скрипты настраивают систему и под конец прибивают init, остаётся только ядро.
Но это маршрутизатор, ни разу не сервер.
А для серверов сильно рекомендую linux-vserver.org... (у нас, опять же, поддерживается "из коробки" начиная с Master 2.4)
Просто интересно, в приводимых Вами роутеров из коробки можно реализовать1. идею Layer-7 (фильтрация по контенту, а не по портам) ?
2. ESFQ (справедливое распределение не по сессиям, а IP) ?
3. connbytes (отслеживание сессий передающих большой объем данных) ?
ЗЫ
жду когда Michael Shigorin намылит мне аналог моей статьи, только
тот который читается на курсах, я Вам письмо вчера отправил.ЗЫЫ
А защита от DoS реализована на уровне ядра, так что особо боятся её не стоит:
http://www.dzti.edu.lv/isp-serv/index.php?l=3#firewall
Недавно тоже занимался "упрощениями" rc.sysinit'а. Пришёл к выводу, что смысл есть только в том, чтобы не вешать демонов, которые не используются. Легко исправляется chkconfig'ом. А тот же udev сам помирает сразу после запуска, если CONFIG_HOTPLUG отключен.
Но в чём автор однозначно прав: стоит всё это расковырять и понять. Очень интересно и полезно.
Целиком и полностью согласен. А статья полезна для тех, кто не совсем понимает механизмы загрузки системы. В этом ее ОСНОВНАЯ ценность. =)
Andrejs Spunitis'у - респект.
Я тоже согласен что поковырять стоит, мне тоже было интересно почитать хоть сам и сижу на слакваре.
статья интересная только одно но, желательно в скриптах указывать полные имена команд, а не так ifconfig lo 127.0.0.1
ifconfig eth0 xx.xx.xx.ip up
ifconfig eth1 192.168.0.1 up
route add default gw xx.xx.xx.gw
все таки о безопасности надо думать сразу.
Вы писали:
>...но, желательно в скриптах указывать полные имена команд,
>а не так ifconfig lo 127.0.0.1
>ifconfig eth0 xx.xx.xx.ip up
>ifconfig eth1 192.168.0.1 up
>route add default gw xx.xx.xx.gw
Все-же, проще установить в начале скрипта переменную PATH - ведь все программы так или иначе будут запускаться из одинх и тех-же системных каталогов - и при использовании полных имен, и при использовании переменной PATH.
переменные типа PATH, JAVA_HOME, LD_LIBRARY_PATH .... и т.п.
занимают место в памяти.
На 16Gb RAM по барабану, но по привычке жалко :)
>переменные типа PATH, JAVA_HOME, LD_LIBRARY_PATH .... и т.п.
>занимают место в памяти.
>На 16Gb RAM по барабану, но по привычке жалко :)а разве не больше места в памяти займет скрипт в котором много длинных полных путей? чем тот же скрипт, но с одной переменной и без путей к бинарям.
Обесните мне почему говорят что типа гента, намного быстрей всех дестрибутивов, а федора или тот же самый мандрейк медленные ? Если собраны на одном и том же ядре тот же набор программ ?
каждый кулик сdое болото хвалит :)
Это миф гентоводов.
> Обесните мне почему говорят что типа гента, намного быстрей всех дестрибутивов,
Может потому что ее до недавних пор хочешь, не хочешь а при инсталле компиляешь под СВОЕ железо?Соответственно можно оптимизнуть под свой проц.Вот и весь секрет.Врядли вы будете компилять при установке мандраку, ага? :)))
Плюс: прирость производительности _ОТДЕЛЬНЫХ_ приложений(не всей системы в целом!!!) в пределах 3-5%. Некоторые программы и библиотеки не стоит(а некоторым категорически запрещено) компилять с -O3 -march=pentium4 -mtune=pentium4(например, иксы{ф генте для иксов системные флаги переписываются на менее "оптимизнутые"} или мозилла). Скорости совсем не прибавится, а стабильность резко упадёт.
Минусы:
1) Полностью теряется портабельность. Система, собранная с march=mctune=pentium4 никогда не запустится на amd и остальных процах=> телодвижений по переносу системы больше.
2) Падает стабильность отдельных программ и системы в целом.
3) Неприменимо для фермы серверов, вытекает из минуса #1
Разкричались-то... Не кувалдой админ махать должен, а отверткой , в крайнем случае скальпелем.
То Michael Shigorin:
Обновления системы ставить в cron... Вы "по собственному желанию" ещё не написали?
На любую prodution-систему должна быть соответствующая документация и там уже не важно - Slack / Debian / RH , потому что перед какими-нибудь действиями с системой, эту документацию примут к сведению и учтут все изменеия в скриптах и тд.
Уж полночь близится, а Германа (Michael Shigorin) все нет....А мне так хотелось посмотреть хотябы на одну из глав нахваливаемых курсов,
но увы -- не судьба!Да и что то не видно что бы предлагаемые и сделанные по всем правилам
продакшен сервера [ linux-vserver.org... (у нас, опять же, поддерживается "из коробки" начиная с Master 2.4) ] могли тоже, что и самопал сделанный согласно подборке
статей
http://www.dzti.edu.lv/isp-servА без этого сложно... поверьте сложно!
К сожалению никто из знатоков rpm-spec не показал, как не сложно все что касается сборки kernel,iproute2,iptables&pom оформить согласно своим представлениям.
Поклонники секьюрити не ткнули пальцем, в том что такого опасного
написано в предлагаемых загрузочных скриптах, да и вообще в описание
создания NAT-сервера (ISP-serv) с расширенными возможностями по
управлению трафиком.Подводя итог, отмечу, что из подборки статей читатель найдет
намного больше конкретики, чем из всего что написано в форуме посвященном статье.ЗЫ
Главное в статье
http://www.dzti.edu.lv/isp-serv/index.php?l=6
это, на мой взгляд, ясное и четкое изложение этапов от включения питания до приглашения командного шел (а по поводу загрузочных скриптов, используйте то что больше Вам нравится).
>Уж полночь близится, а Германа (Michael Shigorin) все нет....>А мне так хотелось посмотреть хотябы на одну из глав нахваливаемых
>курсов, но увы -- не судьба!>Да и что то не видно что бы предлагаемые и сделанные по всем
>правилам продакшен сервера [ linux-vserver.org... (у нас, опять же,
> поддерживается "из коробки" начиная с Master 2.4) ] могли тоже, что и
> самопал сделанный согласно подборке статей
> http://www.dzti.edu.lv/isp-serv
Это... не перегибай палку. Серьёзно. После этого ты выглядишь крайне некрасиво.
>К сожалению никто из знатоков rpm-spec не показал, как не сложно все
>что касается сборки kernel,iproute2,iptables&pom оформить согласно своим представлениям.
Нет ничего проще. Берутся src.rpm'ы ядра, iproute2, iptables, POM-ng, правятся spec-файлы с накладыванием дополнительных патчей и собираются в бинарные rpm. Благо велосипед изобретать каждый раз заново не надо.
>Поклонники секьюрити не ткнули пальцем, в том что такого опасного
>написано в предлагаемых загрузочных скриптах, да и вообще в описание
>создания NAT-сервера (ISP-serv) с расширенными возможностями по
>управлению трафиком.
Опасностей в загрузочных скриптах нет. Есть обычная их неприменимость для тиражирования и управления.
Большая ощибка(ИМХО!) в знакомстве с правилами iptables - это то, что нигде не написано, что политика безопасности должна быть "всё запретить, нужное разрешить", а не наоборот, как в статье.
>Подводя итог, отмечу, что из подборки статей читатель найдет
>намного больше конкретики, чем из всего что написано в форуме посвященном статье.
Не умеем принимать здоровую критику? Ну-ну...
>ЗЫ
>Главное в статье
>http://www.dzti.edu.lv/isp-serv/index.php?l=6
>это, на мой взгляд, ясное и четкое изложение этапов от включения питания
>до приглашения командного шел (а по поводу загрузочных скриптов, используйте
>то что больше Вам нравится).
>Уж полночь близится, а Германа (Michael Shigorin) все нет....
>А мне так хотелось посмотреть хотябы на одну из глав нахваливаемых курсов,
>но увы -- не судьба!
Я ж Вам писал -- давайте почту, свяжу с отвечающим за материалы. Раздавать не могу.Вы ж бросаетесь отвечать с первых строк, до конца не дочитав.
>Да и что то не видно что бы предлагаемые и сделанные по
>всем правилам [...] могли тоже, что и самопал сделанный согласно
>подборке статей http://www.dzti.edu.lv/isp-serv
>А без этого сложно... поверьте сложно!*sigh*
Они могут то, что от них требуется (вообще-то они *серверы*, а не байтогонялки). Для более маршрутизаторов -- ссылки на radlinux.org и etcnet.org дал, если решите[сь] посмотреть, как то, о чём говорите, по уму делается людьми, которые успели не один общажный рутер сварганить, а по стае собак на крупных ISP съесть. Уж простите на прямоте.
>К сожалению никто из знатоков rpm-spec не показал
Вы просто не читаете, что люди пишут. И уж тем более не ходите по ссылкам "см. тж." страниц, на которые они ссылаются. Справа вверху текста упоминавшейся дважды (в т.ч. Вам) статьи ideal-sysadm-rpm есть ссылки на федорину документацию и классический фолиант Maximum RPM.>как не сложно все что касается сборки kernel,iproute2,iptables&pom
>оформить согласно своим представлениям.
Собирать ядра с POM на конвейере, включая апдейты -- противопоказано. Может, когда-нибудь поймёте, почему. Сам, выпросив себе это щастье в штатном ядре ALM2.0 года четыре тому (кажется, ради HTB) -- давно понял. Но это стоило сегфолтов iptables после обновления ядра из updates многим коллегам (пока не поняли, в чём проблема, и не перебрали и iptables).По части же "как оформить" -- см.
http://wiki.sisyphus.ru/admin/KernelBuild
http://alt.linux.kiev.ua/srpm/kernel-image-vs26-smp/spec
http://alt.linux.kiev.ua/srpm/kernel-fix-net
http://alt.linux.kiev.ua/srpm/kernel-fix-security/changelog
http://alt.linux.kiev.ua/srpm/iproute2/spec
http://alt.linux.kiev.ua/srpm/iptables/spec>Поклонники секьюрити не ткнули пальцем, в том что такого опасного
>написано в предлагаемых загрузочных скриптах
Вы их ещё ближе к глазам поднесите, вообще ничего за своей прелестью не увидите.Но хорошо, напросились. Сейчас отдельным сообщением отвечу. Не поленился прочитать Вашу статью подробно, вследствие чего отдельные пассажи были награждены хмыканьем и [пожалеем самолюбие].
>Подводя итог, отмечу, что из подборки статей читатель найдет
>намного больше конкретики, чем из всего что написано в форуме
>посвященном статье.
Забавный человек. Сам пишет, сам и итоги подводит. :-)Вы пишете о том, как два сложить с двумя, и гордитесь, как трёхлетний ребёнок, который сумел разломать довольно даже сложную игрушку на болтики и несколько болтиков обратно на жвачке сцепить.
Некоторые другие тут -- о том, почему проблема несколько шире, чем "ааа я тута запускаю вот такие камандочки и у меня круто всё вертитса". Типа, что четырёхлетнему ребёнку уже не пристало обязательно пальцы в розетку совать.
>Главное в статье это, на мой взгляд, ясное и четкое изложение
Хавтушка (From-PowerUp-To-Bash-Prompt-HOWTO), на которую сами и ссылаетесь -- куда как полезней и ни разу не вредна (в отличие от), не стройте иллюзий. Вы ясно и чётко шлёпаете в тупичок бесплатного администратора одной байтогонялки, которая разве из-за хотя бы чрутнутого BIND называется "сервером", кому-то должна быстро грузиться, непонятно зачем выполнена на четвёртом пне вместо первого, рилтеке вместо e100, и создаст нетривиальные проблемы с восстановлением при первой же непредвиденной newbie грабле с тем же диском.
Не, пишите документацию, разбирайте линуксы и собирайте системы, но хоть иногда-то задумывайтесь -- может, это всё уже давно сделано за нас и куда лучше. И может -- те дядьки и хлопцы по другую сторону монитора не такие уж и глупые, что не осилили сляпать скрипт в пять строк и наворотили пятьсот.
Успехов :-)
Писал на почту вам, но ответа так и не получил,
мой е-mail: spunitis@one.lvС уважением,
АндрейPS
раздавать данный материал никому не буду!
>Писал на почту вам, но ответа так и не получил,
Точно, простите -- в спам угодило.Готово.
>Поклонники секьюрити не ткнули пальцем, в том что такого опасного
>написано в предлагаемых загрузочных скриптах, да и вообще в описание
>создания NAT-сервера (ISP-serv) с расширенными возможностями по
>управлению трафиком.Да, так вот.
Что будут делать эти поделки, если fsck серьёзно взорвётся (например, после неудачного выключения питания или от внезапно осевшего на блины бэд-блока)?
Что будет делать эта железка, если у неё /dev/hda действительно склеит ласты? И главное -- сколько времени займёт восстановление работоспособности? Ах, rescue на болванке мы ещё ломать не научились, только /boot тереть для разнообразия.
Получится ли загрузить систему (если полученная каша ещё может так называться) в single mode при оставленных в inittab
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
?Что будет, если init останется без initdefault вследствие очередного ляпа очумелых ручек в mc при переколбашивании menu.lst?
Что будет, если те же самые новобранцевы лапы, сидя в winxp, комфортно покорёжат sshd_config и наивная последняя строчка самопального rc.sysinit счастливо вернёт return code == 1? (у нас по глупости и расточительству в /etc/init.d/sshd проверка валидности конфигурации есть, а многие ещё и monit на серверах практикуют)
Что будет, если потребуется перезапустить sshd вследствие накатывания исправления дырки? Как именно это предполагается делать?
Что, наконец, предполагается делать с логами? С одной стороны, запуск syslogd/klogd не обнаружен, с другой -- если таким же образом их угораздит запустить, то рано или поздно начнутся тихие вопли (почту же мы не пишем, не таскаем и не читаем, как и на winxp) пухнущих и дохнущих под ENOSPC процессов.
PS: выдать этот вот скриптик? Он тоже много чего "вычищал" и "оптимизировал":
3670 Feb 19 1999 /opt/pub/works/bin/rh5.1clean
Действительно НЕ НАУЧИЛСЯ boot диск!У меня эта мысль уже давно в голове крутится,
поэтому просьба, помогите ссылкой на толковые
статьи как это делается!
для тестов пень-4
для так называемого продакшен -- целерон-750
(видно из того же конфига ядра)ПС
Лет пять обратно, соприкоснулся с автоматизацией на производстве,
поэтому и не понял что такое продакшен сервера в Вашем понимание.Поскольку в моем понятие продакшен сервер, это промышленный контроллер,
с визуализацией Windows (99,9% для Латвии: это Aldaris,Очистиловки,ТЭЦ-2 и многие другие серьезные объекты). А почему -- да потому что все те же
приведенные аргументы Вами, говорят крупные компании, только в сторону
Windows.И все крупные компание Simiens, ABB и тд давно отказались от Unix/Linux!
Хотя и был у этих фирм попытки сделать на Unix.
А вот если бы я смотрел с Ваших слов, то обязательно начал бы говорить
что все что связано с Linux детские игрушки.А возмутился я так, потому что хотел конкретной критики, что бы
подправить свои недочеты! Просто пока не заденешь за живое...
У меня все основные файлы на флешке, так что просто копировать,
ну а если винт умрет, то посидит общага часик без инета, сидели
и сутки без инета, никто не умирал:)А там где нужна отказоустоичвость, то надо кластерное решение по всей видимости, пусть те кому это надо и реализуют.
Дырка в ssh ...
# yum update openssh-server
не могу сказать что пройдет на 100% поскольку перед настройкой сервера
сделал полный его updateВ принципе я сторонник решать проблемы по мере их возникновения,
а не делания особо гибких решений... которые могут приголится раз в сто
лет.
Забыл упомянуть еще из серьезных объектов Железную Дорогу (Siemiens) тоже Linux / Unix нету.Кажеся что в Мочкве метрополитен на RedHat-9
если не так, то Москвичи поправьте:)
Еще забыл упомянуть яркий отечественный примерфирма http://www.lcard.ru/
Взялась за поддержку своих производимых АЦП плат под Linux,
написала более менее стабильные дрова под ядро 2.4 но
ушла с поддержки Linux. И по форуму можно явно видеть что и
в планах нет возобновлять поддержку своей продукции под Linux.Так что, этих самых продакшен серверов, в их исконно правильном
понимание под Linux как кот наплакал.Друзья линуксоиди, только не нападайте на меня за приведенные примеры,
я остаюсь поклонником ОС Linyx :)
Теоретиков развелось аж тошнит, написал человек серию толковых статей, надо обхаять показать собственную крутость, больше всего убивает то, что те кто хает обычно не в теме.
То Michael Shigorin: много слов и нихрена по делу, мол курсы не могу показать, статей нет зато критиковать это мы гуру.
К вашему сведению специализированных дистрибутивов отвечающих требованиям ИСП нет то, что приведено radlinux и freesco детские игрушки, хороши, что бы вывести офис в интернет не более.
Можете лучше милости просим, не можете не мешайте людям, всегда можно сделать лучше только почему-то легче не делать.
P.S. Наболело.
P.P.S. Автору спасибо за статью.
В статье в _загрузочных_ скриптах системы ни какой обработки ошибок, дальше и ни читал.Долбанись выполнение скрипта в 2 строчке не запустится 3.
Зачем в freebsd в rc.subr и других системных скриптах функции err(), warn(), как пример вырваный из того что есть под руками.
И то что пишет Michael Shigorin это не просто критика, а достаточно легкий пинок задуматься что есть что, даже в простых вещах.
Мне не надо система, системы... писанные так.
P.S. Спасибо за критику.
P.S.S. Спасибо за интересное, конструктивное, обсуждение.
Вот читал и задумался,
вместо того что бы по человечески сказать
подравь строку где проверятся целостность
файловой системы проверку на возвращаемой
значение fsck, например как это сделано в
слаке:fsck -T -A -a
RETVAL=$?if [ $RETVAL -ge 2 ]; then
if [ $RETVAL -ge 4 ]; then
sulogin
fi
umount -a -r
mount -n -o remount,ro /
echo "Rebooting system."
sleep 2
reboot -f
fiКуча полемики + борьба у кого дистр дучше!
А нахваливаемые курсы, от Michael Shigorin,
так и не пришли мне на почту.
Дело не в проверяемом возвращяемом значении 2, 5, или 403 строке скрипта.
Думаю дело в
> - управляемость
> - обновляемость
> - надёжностьЯ сам учусь и не на что не претендую. Но стараюсь смотреть не вещи не с одной стороны (как-то сравнивать по чему там так, а там так)
А, это крайне надоело.
> Воспитание отношения "ща мы это быренько перехачим" с описанными
> (не только мной) последствиями.И, разговоры с нотками геройства, а не здравого смысла.
> - управляемость
> - обновляемость
> - надёжностьc таким подходом надо Windows юзать :)
>c таким подходом надо Windows юзать :)
Нет ;) пока этим не впечатляла. А, вобщем не знаю, сильно не рыл.
Но цели то есть и они ясны ;)
На мой взгляд, сам по себе Linux расчитан на
использование на свой страх и риск,
и в серьезных объектах его стараются не ставить!А статья была совсем не про:
обновляемость, управляемость и т.д.Главное показать как сделать систему решающую
проблемы управления трафиком и сделать загрузочные
скрипты максимально простыми и работающими.Многие из аргументов в пользу Linux это то что
вы делаете систему для Себя, ну лично Вам не кажется
странным после этого полемика про обновляемость,
управляемость, переносимость, универсальность, понятность
и так далее???
Возможно меня занесло в сторону.
Статья в принципе полезная для начинающих. Но название неудачное. Действительно для "сервера" подход в принцине неверен, т.к. его сопровождаемость здесь куда важнее скорости загрузки. А вот для embedded server-а это самое оно!