Анонсирован (http://lists.centos.org/pipermail/centos-announce/2011-April...) релиз Linux дистрибутива CentOS 5.6 (http://wiki.centos.org/Manuals/ReleaseNotes/CentOS5.6), основанного на пакетной базе Red Hat Enterprise Linux 5.6 (https://www.opennet.ru/opennews/art.shtml?num=29261). Релиз CentOS 5.6 вышел спустя почти три месяца с момента появления RHEL 5.6, что привело к нарушению штатного режима выпуска обновлений: до выхода CentOS 5.6 для ветки 5.5 было решено портировать только обновления с исправлением критических уязвимостей. Все обновления, выпуск которых был задержан с начала января, теперь доступны (http://ftp.funet.fi/pub/mirrors/centos.org/5.6/updates/i386/.../) для ветки CentOS 5.6.
В отличие от RHEL в CentOS пакеты из серверной и из десктоп редакции RHEL объединены в единый репозиторий пакетов и в один установочный комплект. CentOS 5.6 поставляется (http://ftp.funet.fi/pub/mirrors/centos.org/5.6/isos/) для платформ i386 и x86_64 в сборках: LiveCD (693 Мб (http...URL: http://lists.centos.org/pipermail/centos-announce/2011-April...
Новость: https://www.opennet.ru/opennews/art.shtml?num=30190
Как принято здесь говорить... Ура товарищи :)
Ну что, теперь на финишной прямой к centos6? А то заждались уже )
http://mirror.flhsi.com/centos/5.6/isos/x86_64/CentOS-5.6-x8...
http://mirror.flhsi.com/centos/5.6/isos/i386/CentOS-5.6-i386...
Не халивара ради, народ объясните чем он так хорош этот центос, понятно что на пакетной базе красной шапки, но мне кажется федора лучше в этом плане там хоть разработчиков больше да само сообщество, просто какой смысл использования если получать обновления от рхел все равно нельзя или тока через некоторое время.
не холивара ради : чем ветка debian stable лучше debian testing ?
наверно тем что поставлю первую на сервер и клиентские машины в офисе , а вторую себе дома фильмы посмотреть ?
Временем поддерки.В федоре всё время приходится переходить на новые мажорные версии, из-за чего постоянно ломается часть конфигов.
на первой работе стоял RHEL, с техсаппортом иногда приходилось общаться
под впечатлением их профессионализма сейчас использую на серверах CentOS
У тебя федора на продакшенах стоит?
нет у меня на продакшене дебиан и фря, т.к. считаю тот же дебиан гораздо лучше чем центос, с временем поддержке все нормально, если нету денег на рхел, то костыль в виде центос не особо хочется пользоваться
Я конечно не спорю, что debian очень хороший дистрибутив, тем более что сам часто отдаю ему предпочтение. Но мне не понятна эта категоричность. Чем конкретно дебиан предпочтительнее для продакшена?К примеру мои аргументы, почему в я больше отдаю предпочтение использованию CentOS, чем Debian:
Debian 4.0 Etch: релиз - 8 апреля 2007, окончание поддержки - февраль 2010 г.
Debian 5.0 Lenny: релиз - 14 февраля 2009, окончание поддержки - февраль 2012 г.Centos 5.0: релиз 12 аперля 2007, поддерживается до сих пор и будет поддерживаться до 2014.
Аргумент совсем не плохой, вообщем вывод если нужна длительная поддержка ставь центос, но такая длительная поддержка не часто нужна, уже в 2012 это будет очень древний софт, рано или поздно надо будет все равно обновится на более новую версию
> уже в 2012 это будет очень древний софти что? в работе главное стабильность.
у нас на работе рабочие места все на centos5, в основном используется собственная информационная система, openoffice, firefox + thunderbird, последние три естественно скачанные. А то что еще поддержка базовых библиотек будет до 2014 это большой плюс.
1. Можно аргументы добавить почему centos костыль?
2. По поводу дебиана. Недавно отказался от него полностью. Пакетная база ну ооочень старая. Дебиановцы софт в репозиторий принимают дольше, чем его пишут девелоперы. В результате каждый новый пакетик в дебиане уже заведомо старый.
3. Не могу также удержаться чтобы не отметить CentOS с подключенным epel.repo.Отличный дистр. Ждем 6.
Вы какой-то не тот Debian смотрели. В 6.0 почти весь софт свежее чем в RHEL 6, уж про Центось 5.6 и вовсе молчать можно.
> Вы какой-то не тот Debian смотрели. В 6.0 почти весь софт свежее
> чем в RHEL 6, уж про Центось 5.6 и вовсе молчать
> можно.С давних пор сидел на Debian (в качестве десктопа). Версии пакетов в Lenny просто древние. Анстейбл у деба очень сильно анстейбл. Ну а сквиз я просто не дождался. Перешел на Федору. Очень доволен.
Как серверный дистрибутив Дебиан хорош и достаточно стабилен. И тут уже холивары разводить не стану - кто к чему привык. Сам предпочитаю CentOS и Фрю.
Эх, не понимаем главную фишку...RedHat знаменит тем что он БИНАРНО совместим с многоми проприетарными поделками для дорогущих экзотических железок/программ. Причем сами производители заявляют о том что они более-менее поддерживают это дело.
Несмотря на то что исходники доступны, их надо еще скомпилировать. RedHat хвастается, что у них есть суперсекретный стоящий миллиарды долларов набор тестов, позволяющий хоть как то гарантировать что БИНАРНИК будет исполняться правильно. И они держат в секрете тот конкретный стек компиляторов, которым пользуются для достижения этого. Хотя сами исходники есть, но на 100% неизвестно какой именно набор патчей был использован.
Короче, Centos пытаются реверс-инжинирингом нащупать тот набор патчей к binitils, gcc и прочая, чтобы сами бинарники были идентичны. На мой дилетанский взгляд это адский труд, сотни попыток, милиионы вариантов. Но вот пока у них как то получалось.
То есть если вы не владельцы InfiniBand, NAS, TOP100-подобных железок, не админите Лондонскую биржу или хотя бы задрипаный мериканский авианосец, то Fedora намного лучше во всех отношениях.
Fedora - как бы тот же RHEL, те же люди пишут его, но еще не пропущен через этот матрицу тестов.
> RedHat знаменит тем что он БИНАРНО совместим с многоми проприетарными поделками для дорогущих экзотических железок/программ. Причем сами производители заявляют о том что они более-менее поддерживают это дело.А можно хоть пару наименований, неужели ради бинарной совместимости с недемократичными девайсами, две ОС с кучей ответвлений...
> Fedora - как бы тот же RHEL, те же люди пишут его, но еще не пропущен через этот матрицу тестов.
Fedora - это, скорее, лаборатория, в которой проводят опыты на сообществе, определяя сильные/слабые стороны того, что в последствии попадет в RHEL.
По сути рхел это и есть федора, просто всех пугает слово лаборатория, но рхел практически не отличается от неё, разница лишь в поддержке, многие наивно пологают, что в рхел существуют супер патчи которые которые в корне меняют дело, на самом деле это все фигня, в корне это одно и тоже, хотя кое что имеется.
Представьте себе равнинную реку, горный поток, а затем подумайте -- по чему легче сплавляться, а по чему больше андреналину.Вот и здесь где-то так: дело не столько в каких-то "суперпатчах", а в том, что от точки "икс" rhel фиксируют и фиксят, а федору лопатят дальше почём зря.
>Короче, Centos пытаются реверс-инжинирингом нащупать тот набор патчей к binitils, gcc и >прочая, чтобы сами бинарники были идентичны. На мой дилетанский взгляд это адский >труд, сотни попыток, милиионы вариантов. Но вот пока у них как то получалось.Заметно, что дилетантский. CentOS Team не ведёт реверс-инжиниринга RHEL. Они берут официально публикуемые исходники (src.rpm), и на их основе делают дистрибутив. Т.е. патчи для пакетов там искать не надо ? их надо _правильно_ собрать из того, что уже есть.
>>Короче, Centos пытаются реверс-инжинирингом нащупать тот набор патчей к binitils, gcc и >прочая, чтобы сами бинарники были идентичны. На мой дилетанский взгляд это адский >труд, сотни попыток, милиионы вариантов. Но вот пока у них как то получалось.
> Заметно, что дилетантский. CentOS Team не ведёт реверс-инжиниринга RHEL. Они берут официально
> публикуемые исходники (src.rpm), и на их основе делают дистрибутив. Т.е. патчи
> для пакетов там искать не надо ? их надо _правильно_ собрать
> из того, что уже есть.Ну вот и попробуй - src.rpm рхел6 в свободном доступе; Теперь собери его так, что бы совпали контрольные суммы всех компонентов, включаяя диски.
Когда нащупаешь набор софта в сборочной машине - поделись с разрабами Центоса - они его 4-ре месяца окольными путями искали.
Добро пожаловать в реальность :)
> Ну вот и попробуй - src.rpm рхел6 в свободном доступе; Теперь собери
> его так, что бы совпали контрольные суммы всех компонентов, включаяя диски.причем здесь вообще контрольные суммы? вы хотите обвинить Redhat Team в нарушении лицензии и утаивании информации?
>> Ну вот и попробуй - src.rpm рхел6 в свободном доступе; Теперь собери
>> его так, что бы совпали контрольные суммы всех компонентов, включаяя диски.
> причем здесь вообще контрольные суммы? вы хотите обвинить Redhat Team в нарушении
> лицензии и утаивании информации?Справедливости ради, стоит заметить, что собрать дистрибутив из тех исходников, что дают, далеко не тривиальная задача.
Ну вот и попробуй теперь прочитать ещё раз моё сообщение, может таки дойдёт его смысл.P.S. как однако надоела устаревшая кодировка, приводящая к замене в т.ч. тире на знак вопроса...
>Теперь собери его так, что бы совпали контрольные суммы всех компонентов, включаяя диски.Что-то я сомневаюсь, что контрольные суммы бинарников совпадают. Сами сравнивали?
Если из хотя бы одного пакета выдернули редхатовский брендинг, то сменится сумма и у пакета, и у содержащей его исошки.2 prapor: из фиксированной пакетной базы дистрибутив тоже ой как по-разному можно собрать, кстати...
> 2 prapor: из фиксированной пакетной базы дистрибутив тоже ой как по-разному можно
> собрать, кстати...Вот и я про это. Ох, не собирали местные дистры, ох, не собирали
Миша, к вам это естественно не относится :)
ну да, теперь господа мэйнтейнеры может расскажут как реверсинжиниринг соотносится с аби и, далее цитата, с "БИНАРНО совместим с многоми проприетарными поделками"?
а то вон к примеру ораклобой бд, да и всем оракловым поделкам, нас рать на контрольную сумму каких то там пакетов, когда они и сами то в тарах.
зыж
х/з чем центосники реверсинжинируют, но хорошо бы и пруфы иметь с их сайта. ???
тем боле что несколько ключевых пакетов только что глянул - хрен они с рх "бинарноконтрольносуммово" "совместимы".
Вы можете дать пруф на редхат, где был бы описан тот жуткий набор софта, что стоял на сборочной машине ? :) Вит и я нет. центосовцы очевидно могут кого то попинать, но не всегда
Не знаю про реверс-, но шляпники зуб дают за неизменность ABI в т.ч. при накатывании апдейтов все эти годы. При этом CentOS дать не может, насколько помню читанное с обеих сторон этого вопроса (в недавно виденном упоминали отрыв kabi check, кажется).Строго говоря, конкретный выпуск CentOS не может гарантировать даже бинарную совместимость со RHEL, из исходных пакетов которого пересобирался -- это может быть доводом со стороны поставщика собственно нужного софта/железа: "заявлена совместимость с RHEL, воспроизведите проблему на нём". Хотя по факту она, как правило, есть.
> Если из хотя бы одного пакета выдернули редхатовский брендинг, то сменится сумма
> и у пакета, и у содержащей его исошки.Я то это понимаю, вот и удивился. Потом не во всех же бинарниках лежат логотипы redhat ). Копирайты никто не чистит ).
Ты с ума сошёл чтоли? Centos гарантирует БИНАРНУЮ совместимость, а никак не на уровне md5-сумм бинарей и iso-шников.Почему Centos отстаёт от релизов - это то, что очень сложно сделать 100% идентичную систему из дикой смеси fedora и rh rpm'ов, которая уже СОБИРАЕТ те src.rpm, которые выложены.
Можно ссылочку на гарантии? Я и таких не видел.Почему отстаёт -- центосники объясняют тоже несколько иначе: http://lwn.net/Articles/417849/ (ну и "100% идентичных" диких смесей не бывает, JMHO :).
>> Теперь собери его так, что бы совпали контрольные суммы всех компонентов, включаяя диски.Когда нащупаешь набор софта в сборочной машине - поделись с разрабами Центоса - они его 4-ре месяца окольными путями искали
Вы что сдурели? Если лого поменять уже суммы не совпадут. А они еще и пакетов докинули. Центос заявляет что их компеляция будет работать тютелька в тютельку (так раньше было) как и RHEL, а это не совсем одно и тоже что и контрольная сумма
> RedHat знаменит тем что он БИНАРНО совместим [...]
> Несмотря на то что исходники доступны, их надо еще скомпилировать.Да.
> И они держат в секрете тот конкретный стек компиляторов, которым пользуются
> для достижения этого. Хотя сами исходники есть, но на 100% неизвестно какой
> именно набор патчей был использован.Насколько понимаю, дело не в "стеке компиляторов", а в сборочной системе -- наборе кода, который отвечает за то, чтоб из src.rpm получился набор бинарных пакетов (в том числе и запуская компиляторы по дороге).
> Короче, Centos пытаются реверс-инжинирингом нащупать тот набор патчей к binitils,
> gcc и прочая, чтобы сами бинарники были идентичны.Насколько знаю, нет. (а бинарники и не будут идентичны как минимум за счёт таймстампов)
> То есть если вы не владельцы InfiniBand, NAS, TOP100-подобных железок, не админите
> Лондонскую биржу или хотя бы задрипаный мериканский авианосец, то Fedora намного
> лучше во всех отношениях.Хм, ну для меня и альт лучше что с Infiniband, что на не-авианосце, с которого пишу ;) в том числе и благодаря своей системе сборки.
PS: всех админов, пользователей и особенно участвовавших в выпуске $subj -- поздравляю :)
> Хотя сами исходники есть, но на 100% неизвестно какой именно набор патчей был использован.Все патчи включены в .src.rpm пакеты. Также из спеков ясно, какой компилятор использовался. Для этого не надо гадать на кофейной гуще.
Для продакшена на серверах, там где нужны по настоящему стабильность, безболезненные (ну насколько это возможно) обновления и переход с версии на версию, и (главное!!!) предсказуемость, (по моему субъективному мнению) лучше чем CentOS/RHEL просто нет.
Федора - это не плохо для десктопа. И то только для домашнего. Хотя опять же я, например, для десктопа предпочитаю Debian/Ubuntu.
Для продакшена на серверах, там где нужны по настоящему стабильность, безболезненные (ну насколько это возможно) обновления и переход с версии на версию нужен стабильный и безболезненный мозг, прямые руки и отсутствие красноглазого продакшен-фанатизма. После этого можно ставить то , что наиболее подходит под задачу.
рхел хорош на серверах, прежде всего из поддержки рхел, но центос под сомнением, дебиан смотрится гораздо лучше в этом плане, да и та же слака
не понимаю людей которые на сервера пихают слакваре или генту
скажем на домашний , да , но на работе ...
представьте что Вы перешли на др работу , кто будет поддерживать Ваше лего ?
думаю придут , снесут и поставят цент \ дебиан \ слес \ ред хат \ фрибзд , на крайняк нетварь или вин сервер или альт (намек на фстэк) - все будет зависеть от предпочтений нового администратора
Во-первых, хрень, в которой надо еще разобраться, чтобы отстроить "нормальный серв" гарантирует, что админа не уволят, а если уволят, то пожалеют и скорее всего потеряют инфу/время, короче деньги.Во-вторых, это нормальная практика в других отраслях, скажем, как новый губернатор со своей командой, или премьер со своим правительством, или новый топ-манагер нокии с теплыми чувствами к своей старой работе в мс, пытающийся пропихнуть его и теперь. Если человек справляется с поставленной задачей, то не один ли хрен какими средствами, думаю работодателю, даже предпочтительнее чтобы использовалась система, которую его сотрудник знает лучше, а значит эффективнее работает. Генту на сервере, конечно заставляет задуматься о вменяемости, но почему не слака, там скриптов на 50Кб, чаще, проще решить задачу чутка их подправив, чем гуглить штатное средство для любой из перечисленных ОС.
есть такое понятие как корпоративный стандарт , если я шел на работу и сказали сверху будешь использовать слес , значит использовать слес
если уйду с этой работы то будут искать человека со знанием именно слеса , будь ты семь пядей во лбу со знаниями еще полусотни дистрибутивов
так что <<< Если человек справляется с поставленной задачей, то не один ли хрен какими средствами, думаю работодателю, даже предпочтительнее чтобы использовалась система, которую его сотрудник знает лучше, а значит эффективнее работает. >>> рассуждения на уровне небольшой конторы - тогда согласен--
как в приборостроение : взаимозаменяемость и стандартизация
давно прошли дни что системный администратор это Б в компании и как он сказал так и будет
какую разнарядку спустили сверху какой софт использовать и каких версий так и будет---
также сравните затрату сил на обновления ПО \ дистрибутива в слакваре и дебиане \ слесе \ центе - Вам не жалко своего времени ?
>> также сравните затрату сил на обновления ПО \ дистрибутива в слакваре и дебиане \ слесе \ центе - Вам не жалко своего времени ?В слаке давно все автоматизировано. slackpkg update && slackpkg upgrade-all -- и все патчи приехали.
Между релизами аналогично.
Время поддержки релиза в слаке, между прочим, самое большое из всех дистров. Версия 8.1, вышедшая в 2002 году, до сих пор получает обновления. Задумайтесь.
спасибо , не знал , особенно про обновления , давно ее пробовал
выйдет , надеюсь , скоро , может на десктоп поставлю
А что в Slackware появился пакетный менеджер ?
Раньше не было
Там он не _менеджер_, поскольку _управление_ зависимостями вынесено вне системы и выполняется специальным слоем API между стулом и клавиатурой ;-)Например, список бубнов для обновления yum'ом в новости мне глаз резанул. Интересно, сколько и каких нужно действий (и насколько они документируемы) для обновления предыдущей слаквари до текущей?
2 zomg: нет, не "самое большое", а "внушительное, но всё равно меньше RHEL": http://www.redhat.com/rhel/server/extended_lifecycle_support/
И одно дело -- кто-то порой собирает и выкладывает, а совсем другое -- систематически и в ожидаемый срок выпускаются обновления. Я вон и сейчас изредка делаю апдейты для ALM2.4 (2004 г.в.) и даже их выкладываю -- но ко времени _поддержки_ релиза это не относится.
> Время поддержки релиза в слаке, между прочим, самое большое из всех дистров.
> Версия 8.1, вышедшая в 2002 году, до сих пор получает обновления.
> Задумайтесь.Да, только и период выхода опубликованных критикалов, тоже самый большой, до 2-ух недель доходит (LAMP). Для старых релизов что-то апдейтится, что-то нет. Как захочется. Так что не надо. Можно конечно самому, ручками всё собрать, но смысл?
Ядро в слаке всегда чисто ванильное. Для узких задач может быть плюc. Но ядра rhel рулят. И патчами и временем поддержки одной ветки (на слаку ядерные апдейты заканчиваются с поддержкой юзаемого ванила), бекпортов нет. Несерьёзно это всё. Для несерьёзного юзания, just for fun.
> сказали сверху будешь использовать слес , значит использовать слесЕсли речь о предприятии чей бизнес не связан с IT, то нафиг такую гнилую контору, потому что, нет гарантии, что завтра генерального не осинит идея вин98 на серверах. А аргументы против, как шерифа проблемы индейца. Партия сказала - надо, коммунист ответил - есть. За содержание инфраструктуры деньги платят админу, значит это его ответственность и решение, другое дело, если админ не очень-то компитентен и предприятию приходится пользоваться поддержкой извне.
> рассуждения на уровне небольшой конторы
И да, и нет. У больших контор этим занимается специальный отдел, у которого есть начальник, которому виднее, понятное дело устраиваться в эту компанию простым админом домена и диктовать условия - мол я сервак на что-то там переведу, мне так удобнее, а тех.поддержка пусть с клиентскими машинами как хочет изголяется, - не правильно. Но устраиваясь начальником отдела, подиктовать условия очень даже можно.
> также сравните затрату сил на обновления ПО \ дистрибутива в слакваре и дебиане \ слесе \ центе -
Обновление обновлению рознь, когда речь идет о внесении незначительных изменений, типа пхп с 5.2 до 5.3, то можно выбирать - любой дистр справится с разной степенью корявости. С обновлением glibc где-то уже могут начатся проблемы, а если речь идет об обновлении фс с ext3 до ext4, или перенос системы на виртуальный сервер, где журналируемая фс вообще без надобности.
> Вам не жалко своего времени?
Именно по-этому, предпочитаю доводить сервера до состояния, когда им уже не требуется никаких обновлений, чтобы года 3 и не вспоминать про его существование, сам не упадет, а чтобы не помогли, время от времени мониторить логи, - статистику обращений к портам хотя бы, на 99% попытку взлома можно отловить на шлюзе. Более того, 2 месяца на https в глобале висела web-морда управления кое-чем на тестовом компе, - 3 попытки обнаружить там phpmyadmin, зато ssh ломают - в урожайный день по ~40 ip в черном списке, короче по личному опыту, в своих силах я уверен больше, чем в обновлениях от "дяди", а 60% рабочего времени трачу на сторонние проекты.
> но почему не слака, там скриптов на 50Кб, чаще, проще решить задачу чутка их подправивУ меня есть один коллега -- вроде бы опёнковец и дебианщик, а по сути именно слакварист. Вот он там "чутка поправит", тут "напишет своё", а потом смотреть на это всё сердце кровью обливается.
Предлагаю к ознакомлению вот эту статью (автор сейчас в яндексе работает): http://www.linux.kiev.ua/ru/docs/articles/ideal-sysadm-rpm/
PS: смотрю, про 8.1 уже отметились -- не буду повторять в качестве "впрочем" ;-)
Не предлагаю слаку на сервера ставить всем и всегда, но в неких "идеальных" условиях вполне вариант, лично по мне, так она как автомат калашникова, там ломаться нечему, хотя автоматизации - ноль, из каробки не заработает и какое-то время придется допиливать. Чую щас опять заминусуют, но как вы штатными средствами (без ковыряния скриптов) запустите второй процесс FastCGI демона, с правами рута, который бы формировал страничку-отчет о состоянии впн соединений, дабы не лазить в консоль каждый раз когда в филиале чета отваливается, rh вон пилит свою мега systemd, но что-то я не нашел в спеках на нее заявленной поддержки более 1 копии процесса со отдельными pid файлами. Да я обеими руками за стандарты, тока их уже давно не принимают, то судятся, то жопу мнут, html5 уже на финишную прямую вышел, и бах - а мы хотели, но нас так мало, а надо всем, и в итоге дырка от бублика, зато ее на всех хватает.
Дядьку, так "вторые экземпляры" распихиваются по контейнерам и обычно от этого получается гораздо всё чище, аккуратней и поддерживаемей, чем месиво из всего в одном корне.Посмотрите не openvz, так lxc -- только один момент: когда накладные расходы на каждый контейнер невелики, то это нормально, а вот даже на одном хосте держать десяток слакварей вместо одной -- боюсь, ближе к застрелиться (разве что очень аккуратно прошаблонить и следить за тем, что одинаковые изменения делаются одинаковым образом).
А насчёт "ломаться нечему" -- так из редхата слакварь сделать можно, а вот наоборот -- практически нет (SuSE от корней отучали много лет, но aaa & K не так давно выкорчевали).
IMHO слакварь хороша разве что баги в апстримы файлить -- без патчей ситуация ближе к ожидаемой их разработчиками получается. Но у меня, скажем, основные задачи линуксового дистрибутива немного другие :)
#include "http://forum.lafox.net/?showtopic=11769"
> Дядьку, так "вторые экземпляры" распихиваются по контейнерам
> и обычно от этого получается гораздо всё чище,
> аккуратней и поддерживаемей, чем месиво из всего в
> одном корне.Не надо ляля. Это в вашем линупсе для таких
простых вещей нужны контейнеры и прочая тяжелая артилерия
с оверхедом и на поддержку и на ресурсы компа.В NetBSD такие вещи делаются гораздо удобнее и проще, чем
в любом линупсе.
Во FreeBSD, думаю, примерно так же.Совершенно недавно запускал на сервере ДВА демона dictd
на разных портах В READ-ONLY CHROOT-е.Ниже пример.
Вот дефолтный стартап скрипт./etc/rc.d/dictd:
#!/bin/sh
#
# PROVIDE: dictd
# REQUIRE: LOGIN. /etc/rc.subr
name="dictd"
dictd_flags=${dictd_flags-"--pp '/usr/bin/m4 -P'"}
rcvar=$name
command="/usr/pkg/sbin/${name}"
pidfile="/var/run/${name}.pid"
required_files="/usr/pkg/etc/dictd.conf"load_rc_config $name
run_rc_command "$1"А вот стартап для дополнительного демона на другом порту.
/etc/rc.d/dictd_pkg_online:
#!/bin/sh
#
# PROVIDE: dictd_pkg_online
# REQUIRE: LOGIN. /etc/rc.subr
name="dictd_pkg_online"
dflt_flags="-c /usr/pkg/etc/dictd_pkg_online.conf --pp '/usr/bin/m4 -P'"
dictd_pkg_online_flags=${dictd_pkg_online_flags-$dflt_flags}
rcvar=$name
command="/usr/pkg/sbin/dictd"
pidfile="/var/run/${name}.pid"
required_files="/usr/pkg/etc/dictd_pkg_online.conf"load_rc_config $name
run_rc_command "$1"wdiff, думаю, ты получишь сам.
/etc/rc.conf:
dictd=YES
dictd_chroot=/srv/dictddictd_pkg_online=YES
dictd_pkg_online_chroot=/srv/dictd_pkg_onlineЕстественно, /etc/rc.d/foobar [start|status|restart|stop|...]
работает, как положено.> (SuSE от корней отучали много лет,
> но aaa & K не так давно выкорчевали).Опять сплетни распространяем?
12 лет назад SuSE-6.1 был сильно мало похож на слаку,
уж поверь.
>rh вон пилит свою мега systemd, но что-то я не нашел в спеках на нее заявленной поддержки более 1 копии процесса со отдельными pid файламиВо-первых, пилит не редхат, у которого rhel теперь на upstart, а коллектив разработчиков из разных компаний (rh, novel, ibm, nokia, mandriva и т.д.).
Во-вторых, systemd не использует pid-файлы. В линаксе давно уже поддерживаются контрольные группы, которые не только упрощают отслеживание процессов, включая их потомков, но и автоматом дают возможность ограничивать для них ресурсы. Проще говоря, в линаксе pid-файлы уже давно не нужны.
В-третьих, systemd использует такую занятную фичу линакса, как filesystem namespaces. Например, для заданного процесса можно сделать корень доступным только на чтение. А еще можно сделать так, чтобы процесс видел свой собственный каталог /tmp, не тот, который видят другие процессы. Не говоря уже о нативной поддержке чрута.
В общем, в systemd запускать параллельно одинаковые процессы для разных задач не просто легко, а очень легко.
chroot - ну, как же, пложение сущностей - есть в сущности зло. По темповику каждому процессу, по собственному корню, так уж проще виртуальных серверов наплодить пусть там и по персональному ядру будет, если у мс тенденция к разделению данных на системные и пользовательские, пытаются уйти от сохранения данных в системе или програм-файлз, то это движение в обратную сторону, хранить не в /etc, а каком-нить /srv/http/etc или еще черти где.
>> но почему не слака, там скриптов на 50Кб, чаще, проще решить задачу чутка их подправив
> У меня есть один коллега -- вроде бы опёнковец и дебианщик, а
> по сути именно слакварист. Вот он там "чутка поправит", тут
> "напишет своё", а потом смотреть на это всё сердце кровью обливается.Мойша, ви меня таки извините, но на правах того самого "одного коллеги" не могу не заметить, что глядя на ваши поделия меня таки неудержимо тянет на смех. Не выносите сор из избы, вам же хуже будет =)
Все решают затраты по времени. Очень часто нарисовать свое означает экономию времени на изучении чужого, разумеется, при соблюдении условия - я могу это сделать на должном уровне и в предсказуемые сроки.
В случае же Мойши Шигорина все значительно сложнее - он, фигурально выражаясь, пытается сделать репозиторий с одним рпм-пакетом ради одной инсталляции одного шелл-скрипта. Такая нерациональная трата ресурсов выглядит, по крайней мере, глупо; но Миша не признаёт наличие проблемы, и тем самым часто доставляет =)
Если нужны нестандартные решения то без генты не обойтись, к тому же на серверах она себя очень даже хорошо чувствует, надо лишь правильно её развертывать, все боятся компиляции на рабочем сервере, а нем не чего собирать не надо, это делается на другой машине, к тому же это единственный дистр на котором можно наворачивать любой класс защиты, я про профиль hurd вроде как единственный дистр где можно построить систему защиты 5-го класса, тут на опеннете даже был топик про это, сравнение используемых средств защиты в дистрибутивах, гента была там на высоте)))
> Если нужны нестандартные решения то без генты не обойтись, к тому же
> на серверах она себя очень даже хорошо чувствует, надо лишь правильно
> её развертывать, все боятся компиляции на рабочем сервере, а нем не
> чего собирать не надо, это делается на другой машине, к тому
> же это единственный дистр на котором можно наворачивать любой класс защиты,
> я про профиль hurd вроде как единственный дистр где можно построить
> систему защиты 5-го класса, тут на опеннете даже был топик про
> это, сравнение используемых средств защиты в дистрибутивах, гента была там на
> высоте)))Пардон, а сертификатик будет о том, что это действительно система '5го уровня защиты' и тд и тп?
Юноша, научитесь выговаривать hardened и не путать с hurd, пожалуйста. Также хорошо бы на http://openwall.com заглянуть для общего образования.И вдумайтесь: если для Gentoo можно собирать барахлишко на другом хосте, то и для других дистрибутивов, наверное, тоже -- так что это не довод в пользу, а смягчение типичного контрдовода разве что.
2 klalafuda: "это нам не задавали, тарам-пам-пам" (ц)
hard извиняюсь описался, но сути это не меняет, про другие системы молучу, на других системах это можно делать, но с каким бубнум, к тому же в некоторых случаях придется если нужен пакет из не более старый или новый не из репов, придется пол системы перелапатить в некоторых случаях, а здесь всё стандартными средствами портеж
>В 54 пакета, поставляемых в RHEL 5.6, были добавлены улучшения от разработчиков CentOS.Вроде парадигма CentOS "всё как в RHEL, включая ошибки", т.е. никаких исправлений, патчей, дополнений и пр., только сборка из исходников. Или подход сменился?
> Вроде парадигма CentOS "всё как в RHEL, включая ошибки", т.е. никаких исправлений,
> патчей, дополнений и пр., только сборка из исходников. Или подход сменился?написано же что усовершенствовали левый софт. в ядро не лезли, разве только копирайты и логотипы перепилили
Обновился, полет нормальный.
На 6 релиз забили?
> На 6 релиз забили?Стучат пяткой в грудь, что вот теперь занимаются только им и допилят до выхода RHEL 6.1
Что я вижу! Неужели центос отныне действительно будет предоставлять нормальный работающий debuginfo?? Или опять через месяц все поедет, когда обновления выходят, а debuginfo - нет?
$ yum info boost
Loaded plugins: changelog, fastestmirror
Available Packages
Name : boost
Arch : i386
Version : 1.33.1
Release : 10.el5
Size : 863 k
Repo : base
Summary : The Boost C++ Libraries
URL : http://www.boost.org/
License : Boost Software License
Description: Boost provides free peer-reviewed portable C++ source libraries. The
: emphasis is on libraries which work well with the C++ Standard
: Library, in the hopes of establishing "existing practice" for
: extensions and providing reference implementations so that the Boost
: libraries are suitable for eventual standardization. (Some of the
: libraries have already been proposed for inclusion in the C++
: Standards Committee's upcoming C++ Standard Library Technical Report.)Name : boost
Arch : x86_64
Version : 1.33.1
Release : 10.el5
Size : 861 k
Repo : base
Summary : The Boost C++ Libraries
URL : http://www.boost.org/
License : Boost Software License
Description: Boost provides free peer-reviewed portable C++ source libraries. The
: emphasis is on libraries which work well with the C++ Standard
: Library, in the hopes of establishing "existing practice" for
: extensions and providing reference implementations so that the Boost
: libraries are suitable for eventual standardization. (Some of the
: libraries have already been proposed for inclusion in the C++
: Standards Committee's upcoming C++ Standard Library Technical Report.)Эмм... Ну-ну. Удачи в бою :)
PS: Нет, я понимаю, что это вам не деб и тут все критически важные вещи собирают сами и под себя. Но нужно же иметь в конце то концов советь! Ну не 33я же версия чес слово :-/
> $ yum info boost
> Loaded plugins: changelog, fastestmirror
> Available Packages
> Name : boost
> Arch : i386
> Version : 1.33.1RHEL как правило не используется разработчиками софта.
Да и сам по себе boost не сказать, чтоб сильно был популярен
среди opensource программистов.
> RHEL как правило не используется разработчиками софта.Зато он как правило используется как конечная система. На которой в свою очередь крутится то, что вышло из под пера разработчиков софта.
> Да и сам по себе boost не сказать, чтоб сильно был популярен среди opensource программистов.
Не думаю, что RHEL в 1ю очередь нацелен на разработчиков opensource. Для этого есть другие дистрибутивы. Коммерческий же проект на C++ среднего и выше размера без буста - это оксюморон. Именно поэтому стабильное отсутствие вменяемой версии буста не может не удивлять. В том же Debian-е, как ни странно, с этим делом на порядок лучше. Это конечно же не повод менять коней - не тот уровень геморрою, но позиция редхата как минимум вызывает удивление.
> Коммерческий же проект на C++ среднего и выше
> размера без буста - это оксюморон.Коммерческий закрытый софт, использующий boost,
просто напросто соберется с нужной библиотекой статически.
Более того, он будет собираться
единственно верным компилятором, и не факт, что это будет gcc,
входящий в поставку Redhat-а.
Так что пакет boost из дистрибутива особо
никому не нужен -- нечему удивляться.
yum clean all
yum update glibc\*
yum update yum\* rpm\* pyth\*
yum clean all
yum update mkinitrd nash
yum update selinux\*
yum update
shutdown -r nowRedHat такой RedHat
(скребя в затылке) Про убунту слайды показать? Там похлеще, только бумажкой накрыто: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2011...
Это рекомендованный безопасный путь, чтобы обновление проходило с последними glibc/rpm/yum, и чтобы ядро собиралось новыми утилитами при установке.Лично я обновил пару машин через yum clean all; yum update. Прошло нормально. Вообще там прописана последовательность приоритетов и по дефолту новое ядро ставится после установки новых mkinitrd/nash, но видимо, на всякий случай рекомендуют разрулить ручками.
Не понимаю, а чего все это считают магией? Ведь всё логично и понятно. Что такое glibc знаем. rpm и yum тоже. Вообще это рекомендация и то про версии <5.5. Обновлял сегодня 5.5:yum update
rebootВсё. Следил кстати, в какой последовательности всё накатывалось само. Как раз было почти как в рецепте.
Кто знает когда будет в CentOS официальная поддержка ext4?
Думал в этом релизе но нет... Облом.
В этом релизе официальная поддержка ext4, читаем релиз ноты внимательно!
Более того - именно с этого релиза он и стал работать нормально. На 5.5 были глюки под тяжелой нагрузкой (oops'ы и прочая хрень), как перешли на 5.6, все стало нормально. Это про редхат, правда, но здесь должно быть то же самое.
> В этом релизе официальная поддержка ext4, читаем релиз ноты внимательно!
> Более того - именно с этого релиза он и стал работать нормально.
> На 5.5 были глюки под тяжелой нагрузкой (oops'ы и прочая хрень),
> как перешли на 5.6, все стало нормально. Это про редхат, правда,
> но здесь должно быть то же самое.Не знаю как про редхат, но в CentOS в инсталяторе нет выбора ext4. Уже скачивал дистрибутив и пробовал на виртуалке.
> Не знаю как про редхат, но в CentOS в инсталяторе нет выбора ext4наверно там нужно опцию добавить при старте?
А почему после yum update в Webmin так и пишется CentOS 5.5?Одной строчки достаточно же для обновления? Репы все стандартные.
Linux ldap.mgkb1.local 2.6.18-238.5.1.el5 #1 SMP Fri Apr 1 18:42:32 EDT 2011 i686 i686 i386 GNU/Linux
cat /etc/redhat-release
CentOS release 5.6 (Final)
Особенно радостно, что наконец обновили GCC до 4.4! Завтра на работе обновляюсь первым делом!
> Особенно радостно, что наконец обновили GCC до 4.4! Завтра на работе обновляюсь
> первым делом!Ну 'обновили' - это наверное не совсем так. Скорее - добавили:
$ cat /etc/redhat-release
CentOS release 5.6 (Final)$ yum search gcc
gcc.x86_64 : Various compilers (C, C++, Objective-C, Java, ...)
gcc-c++.x86_64 : C++ support for GCC
gcc-gfortran.x86_64 : Fortran 95 support
gcc-gnat.x86_64 : Ada 95 support for GCC
gcc-java.x86_64 : Java support for GCC
gcc-objc++.x86_64 : Objective-C++ support for GCC
gcc-objc.x86_64 : Objective-C support for GCC
gcc44.x86_64 : Preview of GCC version 4.4
gcc44-c++.x86_64 : C++ support for GCC version 4.4
gcc44-gfortran.x86_64 : Fortran support for GCC 4.4 preview$ gcc --version
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-50)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Это даже лучше, ничего не сломается зато :)
про 6й центос, вот пишут мол сложно, долго траляля какой гемор.... однако сайнтифик линукс 6.0 вышел довольно быстро, http://www.scientificlinux.org/
У них всё-таки надобность в халявном редхате более другими ресурсами подпёрта.
Товарищи, а как на счет бага с залипанием процессов из-за неизвестной причины? :))))
Честно говоря уже надоело перегружать сервер из-за этого:=======================
INFO: task sendmail:10090 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
sendmail D 00009B39 2572 10090 10067 10088 (NOTLB)
da5d1ed0 00200086 dcce8022 00009b39 00009b37 0000000e 00000000 00000007
f7f78000 dcce91e2 00009b39 000011c0 00000000 f7f7810c c2b02c00 f779e3c0
00000002 004eea4f 00000000 da5d007b c041007b ffffff03 da5d1ed8 f7c48650
Call Trace:
[<c041007b>] mtrr_attrib_to_str+0x3/0x14
[<c043614b>] prepare_to_wait+0x24/0x46
[<f88691da>] log_wait_commit+0x80/0xc7 [jbd]
[<c0435fff>] autoremove_wake_function+0x0/0x2d
[<f8864661>] journal_stop+0x195/0x1ba [jbd]
[<c04944e2>] __writeback_single_inode+0x1a3/0x2af
[<c045db7e>] do_writepages+0x2b/0x32
[<c04596eb>] __filemap_fdatawrite_range+0x66/0x72
[<c0494b7e>] sync_inode+0x19/0x24
[<f8983007>] ext3_sync_file+0xaf/0xc4 [ext3]
[<c0478067>] do_fsync+0x41/0x83
[<c04780c6>] __do_fsync+0x1d/0x2b
[<c0404f17>] syscall_call+0x7/0xb
=======================