LINUX.ORG.RU

Доступен CentOS 6.8

 ,


0

1

Представлен релиз дистрибутива CentOS 6.8, основанный на пакетной базе Red Hat Enterprise Linux 6.8. Выпуск поставляется для платформ i386 и x86_64 в виде DVD-сборки, минимального установочного образа (300 Мб) и сокращенного образа для установки по сети — netinstall.iso (200 Мб).

Пакеты SRPMS и debuginfo доступны через vault.centos.org. Пакеты из различных репозиториев RHEL, например, из серверной и из десктоп редакции, объединены в единый репозиторий пакетов и распространяются одним установочным комплектом. Дистрибутив на 100% бинарно совместим с RHEL, внесенные в пакеты изменения как правило сводятся к ребрендингу и замене художественного оформления.

Из изменений, внесенных в CentOS 6.8, можно отметить:

  • Реализация IPsec переведена с Openswan на Libreswan (поддержка добавлена в NetworkManager).
  • В SSSD добавлена поддержка аутентификации через смарткарты для системных входов и привилегированных операций (например, вызов sudo).
  • Максимальный размер файловой системы XFS увеличен со 100 до 300 Тб
  • Прекращена поддержка SSLv2. В OpenLDAP, yum, stunnel, vsftpd, Git и Postfix реализована поддержка TLSv1.2. Во многих пакетах использование TLSv1.2 включено по умолчанию.
  • Во многих приложениях появилась поддержка параметров эллиптических кривых, в том числе в Perl Net:SSLeay и Perl IO::Socket::SSL.
  • В dmidecode добавлена поддержка SMBIOS 3.0.0.
  • В kickstart добавлена поддержка загрузки файлов по HTTPS.
  • Добавлен пакет с системой синхронизации точного времени chrony.
  • Добавлен пакет squid34 с новым выпуском прокси-сервера Squid 3.4.14, который заменил собой пакет squid31.
  • В драйверы для работы под управлением Hyper-V добавлена поддержка хранилищ с 4096-байтовыми секторами, поддержка TRIM, поддержка 2-го поколения виртуальных машин, поддержка протоколов Windows 10 и Windows Server 2016.
  • Libreoffice обновлён до версии 4.3.7.2.
  • Обновлены версии пакетов elfutils, SystemTap, ipmitool, memtest86+, icedtea-web, shadow utils, virt-who, а также различных драйверов.
  • Объявлены устаревшими и могут быть удалены в следующих выпусках драйверы и пакеты: python-qmf, python-qpid, qpid-cpp, qpid-qmf, qpid-tests, qpid-tools, ruby-qpid, saslwrapper, 3w-9xxx, 3w-sas, 3w-xxxx, aic7xxx, i2o, ips, megaraid_mbox, mptbase, mptctl, mptfc, mptlan, mptsas, mptscsih, mptspi, sym53c8xx.
  • Переведены в разряд не поддерживаемых экспериментальные компоненты: openswan, seabios, Btrfs, eCryptfs, mingw, virtio-win, fence-agents, systemtap, matahari и openscap.
  • Изменено содержимое 32 пакетов, среди которых anaconda, dhcp, firefox, gnome-applets, gnome-desktop, httpd, initscripts, ipa, kde-settings, kernel, ntp, thunderbird, xorg-x11-server, yum и zsh.
  • Удалено 30 пакетов, присутствующих в RHEL, среди которых libehca, libservicelog, lsvpd, libvpd, openssl-ibmca, powerpc-utils, ppc64-diag, ppc64-utils, python-rhsm, redhat-*, rhn-*, servicelog, s390utils, yaboot, yum-rhn-plugin.

>>> Подробности

★★★

Проверено: Klymedy ()

Ответ на: комментарий от kep

Попробуй тогда «Можжевеловый эль» от пивоварни «Сурок», может тоже понравится.

DELIRIUM ★★★★☆ ()
Ответ на: комментарий от Olegarch

В научных кругах чаще используется термин «чёрный ящик», - понятно, что на входе, понятно, что на выходе, но совершенно непонятно - что внутри.

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

leg0las ★★★★★ ()
Ответ на: комментарий от soko1

Поэтому у systemd как минимум несколько сторон, ты рассмотрел одну, я показал другую и это не предел.

Я не говорил, что других сторон нет. Но пока эта штука в активной разработке, и заменяет своим ...гм... часто нехорошим кодом - стабильные и работающие решения. Более того - сам стиль разработки этого продукта, и возгласы его автора о том, что поглоченные этим продуктом компоненты специально делаются несовместимыми с не-systemd дистрибутивами (на примере udev), причем выглядит это так, как будто автор показывает сообществу язык и бросает ему вызов «а ну-ка, гентушнички, сделайте что-нибудь теперь, бе-бе-бе, это вам сигнальчик»... Напоминает поведение моего малолетнего сынули - это и смешно и печально, что большой и серьезный проект просто не должен позволять себе иметь подобного «лидера». Но это третья - этическая сторона отношения одних разработчиков к другим.

уметь найти в плюсах минусы, а в минусах плюсы и не бояться их обсуждать и делиться ими, тогда всё будет более-менее объективно.

Это четвертая сторона, и также - этическая. Юношеский максимализм не даёт трезво мыслить апологетам этого решения. Все несогласные с ними - должны, как минимум, умереть. А как максимум - адски страдать при жизни.

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

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

Давай-ка мы не будем его обсуждать? Хорошо? 8)

Olegarch ()
Ответ на: комментарий от leg0las

зачем ломать то, что работало и работает?

Самоцитируюсь, пардон: «Заставить клиентов переучивать своих админов, срубить на этом денег, выпусить новые мануалы, и, наконец - понизить порог входа для начинающих. Ребята думают о будущем - кто будет приносить им деньги, когда мы умрём? Сакральные знания мы унесём с собой, а новое поколение обучаться способно с трудом - этот продукт создаётся для них, а не для нас.»

Olegarch ()

Centos 7

Что то не совсем понятно на сайте присутствует версия 7 и 6.8 , у 7 версии LTS до 2024 года , получается она более свежая ? или я что то упустил ?

JackMas ()
Ответ на: Centos 7 от JackMas

Упустили. Выход Red Hat Enterprise Linux 15 лет назад. 6.x и 7.x - это разные ветки.

buratino ★★★★★ ()

В рабочем порядке обновилось сегодня на нетбуке (ASUS EeePC 1001PX) - полет нормальный

Belen ★★ ()

И чем заменить btrfs? У меня эта файловая система монтируется ночью, делается ro снапшот и производится на эту фс бэкап измененых за сутки файлов, кроме логов, на диск перезаписывается даже не весь файл, а только измененые в файле блоки. Таким образом у меня есть бэкапы на любой день за последние n лет с десятков серверов, при том, что размер хранилища бэкапов даже в 1.5 раз не превышает размера саммих данных в продакшине. И все это в продакшине, и проблем именно в этой функциональности не было. И что мне теперь пытается все это на ZoL переносить? Если я скажу, что отныне, мне надо хранилище в 10-ки раз больше для тех же бэкапов, я понимания не найду.

Viper ()
Последнее исправление: Viper (всего исправлений: 1)
Ответ на: комментарий от Viper

А попробуй ядро своё собрать и пакет btrfs-tools. Или поставить последнее старое ядро с btrfs и залочить обновление ядра, если не очень критично конечно в плане безопасности.

Хотя в идеале конечно патчик и на каждый новый релиз его применять и пересобирать.

Но вообще да, печально вышло

soko1 ★★★★★ ()
Ответ на: комментарий от soko1

В тестовом окружении обновился, btrfs работает. Видимо, просто обновлений для btrfs не будет.

Viper ()
Ответ на: комментарий от Olegarch

(//...и какой дебил придумывал раскладку на макбуках... трындец... уж унифицировали бы с вендовой, чтоли..., - там где запятая - вопросик, со слешом, ё вобще возле энтера... трындец//)

Менять не пробовали? Там их как и на онтопике >одной

anc ★★★★★ ()
Ответ на: комментарий от soko1

Просто с такой логикой можно вообще любой более-менее удачный компонент назвать вирусом

Вот здесь коренное слово «удачный» к xxxxD оно не имеет никакого отношения.

anc ★★★★★ ()
Ответ на: комментарий от Olegarch

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

Это не только «по сугубо моему мнению», я его поддерживаю.

anc ★★★★★ ()
Ответ на: комментарий от soko1

.... потому что до systemd был полный хаос.....

Где закупаетесь? System V и bsd init это «хаос» ? А «systemd» нет? Я что-то не то курю походу...

anc ★★★★★ ()
Ответ на: комментарий от leg0las

Оно конечно работает, но такое ощущение, что это какой-то ящик пандоры.

man NetworkManager избавит от этого ощущения.

dexpl ★★★★★ ()
Ответ на: комментарий от Viper

btrfs
бэкап
за последние n лет с десятков серверов

Вы явно что-то делаете нетак, при учете что btrfs (Experimental) до сих пор, а уж вводить это «n лет» назад как систему бэкапа... ну ну...
Вы случайно не из тех кто «уже делает бэкапы, но еще не проверяет?»

anc ★★★★★ ()
Ответ на: комментарий от anc

Вот здесь коренное слово «удачный» к xxxxD оно не имеет никакого отношения.

это твоё субъективное мнение и оно имеет право на существование :)

soko1 ★★★★★ ()
Ответ на: комментарий от anc

Мелькнула та же самая мысль. Видать «за последние n лет» было «небольшим» преувеличением :)

soko1 ★★★★★ ()
Ответ на: комментарий от anc

(сорь что на ты, со мной тоже лучше на ты плз)
System V и BSD init - ты назвал лишь один компонент systemd. Возможно ты не в курсе что помимо системы инициализации systemd это унифицированный инструмент для кучи всяких других вещей.
Плиз, осиль этот док (желательно максимально отстранённо): https://wiki.archlinux.org/index.php/Systemd_(Русский) и посмотри сколько всего умеет эта штука. С каждой новой версией кол-во настроек и фич увеличивается. И всё это работает абсолютно одинаково на всех системах.

Возможно для кого-то Поттеринг невоспитанный говнюк, осуждать не возьмусь, вполне вероятно что есть косяки в процессе разработки (в взаимодействии с другими разработчиками, своеобразной монополии), но идея положена очень неплохая. Сначала я был противником systemd, особенно когда оно только-только появилось в арче и дико глючило, потом глючить перестало, но я продолжал называть systemd говном по привычке и за кампанию + мне было лень в нём разобраться. Как только я себя заставил и прочитал пару довольно объёмных мануалов, покрутил в живую всё это - понял что ошибался, признал это и забрал все свои слова обратно.
Ну и плюс то что очень многие дистрибы, в том числе Ubuntu/Debian перешли на systemd тоже о многом говорит. Всё же там не такие глупые люди сидят. По крайней мере не более глупые чем мы :)

soko1 ★★★★★ ()
Последнее исправление: soko1 (всего исправлений: 1)
Ответ на: комментарий от Olegarch

Спасибо за инфу, довольно интересно, не знал про эти нюансы ранее.
Окей, закрыли тему :)

soko1 ★★★★★ ()
Ответ на: комментарий от anc

Хочу привести пару примеров, чтобы заинтриговать.

Ранее всегда было гемором настраивать ACPI без всяких кедогномов (реакция на закрытие крышки, спящий режим, етц). От версии к версии что-то менялось и скрипты написанные в /etc/acpi постоянно отваливались. Сейчас же это всё работает везде и со всем где есть systemd через файлик /etc/systemd/logind.conf, где достаточно раскоментить нужную строчку и вписать нужное значение.

Поехали далее. Бинарные логи. Ух как же это круто! Хотя раньше я бы подумал что такое может придумать только человек под веществами. Но сейчас я понимаю насколько это гениальное решение!
Во-первых текстовые логи можно подредактировать, чем очень успешно пользуются злоумышленники, попавшие на сервер и получившие привилегии. С бинарными логами почистить ничего не получится (исправьте кто нибудь, если ошибаюсь).
Во-вторых рулить journalctl одно удовольствие. Ранее логи были разбросаны по разным файлам, везде по своему. Сейчас всё в одном месте и очень гибко сортируется и парсится.
Показать последние сообщения за 20 минут? Не проблема:

# journalctl --since "20 min ago"
Показать все сообщения для конкретного исполняемого файла:
# journalctl /usr/lib/systemd/systemd
Показать все сообщения для конкретного процесса:
# journalctl _PID=1
Не говори мне что это не удобно - либо это будет лицемерие, либо упрямство и глупость.
Система долго грузится и ей что-то мешает? Выполняй:
# systemd-analyze blame
и увидишь отсортированный список по процессам и затраченному времени. Можно даже SVG-файл графический замутить с графиками:
# systemd-analyze plot > plot.svg

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

soko1 ★★★★★ ()
Последнее исправление: soko1 (всего исправлений: 1)
Ответ на: комментарий от Viper

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

soko1 ★★★★★ ()
Ответ на: комментарий от soko1

(реакция на закрытие крышки, спящий режим, етц)

Так, понятно, Вы похоже о десктопе.

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

wtmp - бинарный. Что не мешает его редактировать, просто надо быть немножко «хакиром», почти уверен что такое же можно провернуть и с ненужноД.

anc ★★★★★ ()
Ответ на: комментарий от soko1

Ну и плюс то что очень многие дистрибы, в том числе Ubuntu/Debian перешли на systemd тоже о многом говорит. Всё же там не такие глупые люди сидят. По крайней мере не более глупые чем мы :)

Патрикоугодный нет, Вот это как раз говорит о том что глупые скорее там «Ubuntu/Debian/etc» :)

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)

А вот вопросец, не совсем в тему просто может кто сталкивался ?

Из за последнего обновления самбы все ХП отвалились от самба-PDC, в 6.7 я самбу заисклюдил в юме :((( Что теперь так и дальше тянуть ?

anonymous ()
Ответ на: комментарий от anc

Все очень просто. Бэкапы были перенесеня с ленточек на btrfs (на самом деле через ext3 и rsync с предыдущей скопированной лентой и так по циклу, но не суть). Некоторые дни, недели были утеряны, так как пару-тройку ленточек не смогли нормально считать. Сейчас файловый бэкап btrfs на ленточки делается раз месяц. И да, наверное мы из таких, кто не пробовал из этих бэкапов полностью все восстановить. Но проблем btrfs не показывает при копировании подтомов с бэкапами на ленту. Частично данные из bttfs восстанавливать приходится, проблем не было.

Viper ()
Ответ на: комментарий от anonymous

Из за последнего обновления самбы все ХП отвалились от самба-PDC

Поищите здесь, недавно тема была: хрень->обновление_самбы

anc ★★★★★ ()
Ответ на: комментарий от Viper

Ну и ладно, успехов вам до первого «факапа». А уж при учете что экономим на летнах то вообще ссзб. ( Это не в обиду, а только констатация факта)

anc ★★★★★ ()
Ответ на: комментарий от anc

На лентах экономить смешно. Но: Ленты могут не читаться; Бэкап на ленты долго, а если две копии делать, с надеждой, что какая-то одна из двух уж точно считается/не испортится то ночи не хватит. Купить крутую библиотеку многопоточную, дорого. Нормальное ПО для не ручной работы с ленточками и руления этой тру библиотекой, то же дорого, в итоге поиск в ручную нужных данных при необходимости частичного восстановления и само восстановление этих данных занимает уж очень много времени. Надеюсь факапа не будет, но если что-то случится с btrfs есть бэкап на ленточке месячной давности и актуальные данные на серверах. Плохо будет если одновременно btrfs порушится и raid на серверах развалится. Даже не знаю какая вероятность такого события.

Viper ()
Последнее исправление: Viper (всего исправлений: 1)
Ответ на: комментарий от anc

Короч фанатизм на лицо и ноль аргументов (слака - вообще не аргумент, где она а где дебиан в процентном соотношении на серверах, хорошо если на 0.001% серверов). Ну и ладненько. Не вижу смысла далее вести диалог :)

soko1 ★★★★★ ()
Ответ на: комментарий от soko1

СЧастья вам на остальных процентах.
А вот слака неплохо себя почему-то чувствует например в технологии, ичсх не жалуется. :)

anc ★★★★★ ()
Ответ на: комментарий от anc

Так, понятно, Вы похоже о десктопе.

По барабану, хоть о Linux на тостере

wtmp - бинарный. Что не мешает его редактировать, просто надо быть немножко «хакиром», почти уверен что такое же можно провернуть и с ненужноД.

Тут вопрос не в том «можно», или «не можно» (в конце-концов любой лог можно за'shred'ить и удалить, или вообще всю систему снести к чёртовой матери), а в том что в большинстве случаев никто не будет с этим заморачиваться и скорее забьёт на затирание следов.

soko1 ★★★★★ ()
Ответ на: комментарий от soko1

Тут вопрос не в том «можно», или «не можно» (в конце-концов любой лог можно за'shred'ить

Ну, ну... для начала wtmp научитесь чистить, ох не легкая это тема.

... а в том что в большинстве случаев никто не будет с этим заморачиваться и скорее забьёт на затирание следов.

Ну и тогда о чем речь Карл?!? В чем профит бинарныеVSтекстовые?

anc ★★★★★ ()
Ответ на: комментарий от soko1

Это можно сравнить с эволюцией и ГМО продуктами. Мо ... ития были бы люди, если бы не она?

Бла-бла-бла... Рассуждаешь как средне статистическое быдло. Твое место у параши пацан.

anonymous ()
Ответ на: комментарий от anc

Ну, ну... для начала wtmp научитесь чистить, ох не легкая это тема.

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

# fwtmp < wtmp.mmdd > wtmp.new
# vi wtmp.new
# fwtmp -ic < wtmp.new > wtmp

чертовски сложная процедура, вот тут я с тобой полностью соглашусь!

... а в том что в большинстве случаев никто не будет с этим заморачиваться и скорее забьёт на затирание следов [у бинарных логов].

Ну и тогда о чем речь Карл?!? В чем профит бинарныеVSтекстовые?

Прочти плз внимательно ещё раз моё цитируемое сообщение и потом попробуй его сопоставить со своим.

soko1 ★★★★★ ()
Последнее исправление: soko1 (всего исправлений: 2)
Ответ на: комментарий от soko1

Да, ведь нужно заставить себя в гугле ввести редактирование wtmp

Во блина «до чего техника дошла». Каюсь, я лох. Живу воспоминаниями многих лет назад, тогда пришлось прогрумулину на сях ради этого писать.

anc ★★★★★ ()
Ответ на: комментарий от anc

Во блина «до чего техника дошла». Каюсь, я лох.

Вау, ты меня удивил. Приятно встретить человека на лоре, готового признать свою ошибку. Респект)

Лан, предлагаю трубку мира! Каждому - своё и systemd не исключение :)

soko1 ★★★★★ ()
Последнее исправление: soko1 (всего исправлений: 1)
Ответ на: комментарий от soko1

помимо системы инициализации systemd это унифицированный инструмент для кучи всяких других вещей

Это, с одной стороны - вроде (в теории) и хорошо, а с другой - вековая народная мудрость гласит: «никогда не держи все яйца в одной корзине». Если один из компонентов этой монолитной системы «встанет в позу известного членистоногого» - вся система накроется медным тазом. Примеры тому уже были, - периодически почитывая (после очередного релиза) «их» багтракер, я иной раз диву даюсь - как такое возможно? То есть, на релиз ставится продукт, у которого есть критические баги, которые «прилетают» пользователям из дистрибутивного репозитария с очередным обновлением. После чего появляется волна «возмущений», часть ответов на которые сводится к тому, что система, в очередной раз, проявляет неадекватное поведение - то она грузится перестала, то rootfs смонтировать не может, то одно, то другое...

Следующая штука совершенно не связана с systemd, просто пример неочевидного поведения софта, которое «пьёт кровь» в продакшене (а предмет нашего обсуждения этим изобилует): однажды, у одного клиента, внезапно перестал работать DNS. Обновления системы происходили ежедневно, ставились апдейты, а конфиги подтягивались из SVN. И вот, внезапно, после очередного mass update перестал работать DNS - он запускался, но никаких данных не отдавал. ОКАЗАЛОСЬ, что в очередном апдейте bind'а втихаря решили, что в конце файла-зоны должна быть пустая строка, содержащая '\n'. При этом - все предыдущие ревизии бинда работали прекрасно и без нее. При этом бинд просто ругался на то, что «зона ему не нравится» и он ее игнорирует, без объяснения причин - «почему»... А ведь DNS - это всего-навсего один из множества не-системных серверов. Что же будет, если разрабы systemd в очередной раз включат подобную «фичу» в свой продукт, и вся система (а не один её компонент) перестанет функционировать? Отвалится сеть, например, или fsck наглухо повиснет при попытке проверить сменившийся uuid диска, замененый udev'ом, или случится еще что-то непредсказуемое? Что делать админу в продакшене, когда он расчитывает, что его сервера будут работать и тогда, когда он на работе, и тогда, когда он спит? Не спать, и ждать, что в любой момент раздастся звонок разъяренного заказчика, у которого что-то случилось?

Уж лучше CentOS6, чем такое...

Olegarch ()
Ответ на: комментарий от Olegarch

Если один из компонентов этой монолитной системы «встанет в позу известного членистоногого» - вся система накроется медным тазом.

Но почему, если systemd многокомпонентный? Ну допустим у тебя поломается systemd-timesync - как это скажется на работе всего остального? Ведь точно так же может навернуться ntpdate

То есть, на релиз ставится продукт, у которого есть критические баги, которые «прилетают» пользователям из дистрибутивного репозитария с очередным обновлением.

Ты уверен что это был не какой-нибудь арч линукс? Я очень сомневаюсь что с этими же багами встречаются пользователи redhat'а. Возможно потому что там используются не последние версии systemd, а хорошо проверенные. Но у меня в голове не укладывается что редхатовцы могут допускать регулярно подобного рода баги у себя в 7-ке. А поскольку ты на центоси, то по логике можно смело переходить на 7-ку, если загвоздка только в этом.

Что же будет, если разрабы systemd в очередной раз включат подобную «фичу» в свой продукт, и вся система (а не один её компонент) перестанет функционировать? Отвалится сеть, например, или fsck наглухо повиснет при попытке проверить сменившийся uuid диска, замененый udev'ом, или случится еще что-то непредсказуемое?

А что будет если Линус пропустит критический баг, который поломает всем загрузку системы при очередном обновлении ядра? Ядро уж точно более монолитный и больший по объёму компонент нежели systemd...
Так ведь можно абсолютно к любому разработчику придраться. Мне кажется тут нужно больше боятся за пофигизм разработчиков дистрибутивов, ведь их задача состоит как раз в том, чтобы не допустить проникновение в стабильные ветви плохо проверенные и нетабильные компоненты. Если арч со скоростью света штампует билды новых программ не успев их особо протестить - это не проблема программ, это проблема тех кто не выделяет достаточное кол-во времени на их проверку у себя в системе.

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

soko1 ★★★★★ ()
Ответ на: комментарий от soko1

Ты уверен что это был не какой-нибудь арч линукс?

На серверах в critical zone - стоит RHEL6. На серверах попроще - цент-6. На некритичных серверах - раньше (до перехода на systemd) иногда случался debian, - вполне неплохо работал, кстати. Ставить arch на прод?! Я может и всеядный линуксоид, но не до такой же степени, чтобы «жрать что мимо проплывает». 8)

На специфичном железе у меня, как ни странно, тоже rhel, заточенный под это самое железо. А вот embedded железяки - мелкие роутеры, «планшетики», медиа-кубики - имеют уже свои дистрибы: где-то openwrt, где-то - void linux, где-то вобще «кастом» (там где цикл жизни продукта ограничен, и поддерживать его никто не будет).

А вот у клиентов на десктопах и сторонних заказах (даже в проде) было много разного - от неплохих дистров (gentoo), до полного мусора (sourceror). - У некоторых заказчиков приходилось работать с тем, что поставили «до нашего прихода», - а вот там «сон разума» цветет буйным цветом. Каких только «чудес» я не видел в продакше! И гибридные дистры, слепленные из redhat6.3+ubuntu 6.10, и полудебианы-полугенту, и полностью кастомные дистры - админы изголялись кто на что горазд... ужос. И как я представлю, что к этому зоопарку теперь добавится еще и прослойка на systemd, которую, ради обратной совместимости какой-нибудь... специалист... срастит со старыми sysvinit скриптами через предлагаемый systemd альтернативный костыль (а такие любители найдутся, я уверен!), - у меня волосы по всему телу дыбом становятся...

Olegarch ()
Ответ на: комментарий от anc

Менять не пробовали? Там их как и на онтопике >одной

На онтопике у меня клавиатура IBM Model M («ещё та»), без всякого русского языка на клавишах. И на тошибовском ноуте под линем со светящимися кнопками. И на соньке... А на макбуке, хоть под линем, хоть под макосью - долбаная русская раскладка светится в темноте наравне с английской, - слепой ввод для этой недоклавы - неактуален, - у клавиатуры макбука раскладка не вполне стандартная (даже для US/UK; + русский, как назло, - на клавиатуре «прямо с завода») - ремап только всё запутает. Уж лучше пусть она будет идиотской, но видимой, чем искать - куда ты на этой недоклаве замапил те или иные символы...

И вобще, это к сабжу данного треда не имеет отношения. Это я так, мысли вслух выразил...

//И как линуз работает на макбуке, - непонятно... да еще и хвалит...//

Olegarch ()
Ответ на: комментарий от Olegarch

Ставить arch на прод?! Я может и всеядный линуксоид, но не до такой же степени, чтобы «жрать что мимо проплывает». 8)

Не-не, я ж и не предлагал арч в прод, а в пример привёл где бы systemd мог вполне себе глючить :)

Так а конкретно с семёркой дело имел? Неужели там всё так плохо из-за systemd? Что-то мне подсказывает что всё это стереотипы и связанные с ними боязни. Ну и да, я не про переход продакшна с 6-ки на 7-ку (тут полюбому проблемы какие-то будут, особенно если костыли всякие применялись), а поднятие новых серверов на семёрке.

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

soko1 ★★★★★ ()
Ответ на: комментарий от Olegarch

что в конце файла-зоны должна быть пустая строка, содержащая '\n'.

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

anc ★★★★★ ()
Ответ на: комментарий от Olegarch

//И как линуз работает на макбуке, - непонятно... да еще и хвалит...//

Вы по аккуратнее, модераторы рядом :)
Реально меня не парит раскладка мака, все дело привычки. Скорее когда на расширенной приходиться работать больше не удобств получаешь.

anc ★★★★★ ()
Ответ на: комментарий от anonymous

после обновления на 6.8 имеем kernel panic's проявляется только на i386 на x86_64 всё норм. баг замечен под vmware esxi, nic vmxnet3 на e1000 полёт нормальный

------------[ cut here ]------------ WARNING: at kernel/softirq.c:159 local_bh_enable+0x59/0x90() (Not tainted) Hardware name: VMware Virtual Platform Modules linked in: autofs4 vsock(U) ppdev parport_pc parport microcode vmware_balloon vmci(U) i2c_piix4 sg ext4 jbd2 mbcache be2iscsi bnx2i cnic uio cxgb4i iw_cxgb4 iw_cm sd_mod cxgb4 crc_t10dif cxgb3i sr_mod cdrom libcxgbi iw_cxgb3 ib_core vmxnet3 ib_addr ipv6 cxgb3 mdio libiscsi_tcp vmw_pvscsi qla4xxx iscsi_boot_sysfs pata_acpi libiscsi ata_generic scsi_transport_iscsi ata_piix vmwgfx ttm drm_kms_helper drm i2c_core dm_mirror dm_region_hash dm_log dm_mod [last unloaded: mperf] Pid: 1978, comm: zabbix_agentd Not tainted 2.6.32-642.1.1.el6.i686 #1 Call Trace: [<c04624b9>] ? warn_slowpath_common+0x89/0xe0 [<c0469e79>] ? local_bh_enable+0x59/0x90 [<c046252b>] ? warn_slowpath_null+0x1b/0x20 [<c0469e79>] ? local_bh_enable+0x59/0x90 [<c07bc3a6>] ? skb_copy_bits+0x126/0x210 [<c07bcf0e>] ? __pskb_pull_tail+0x6e/0x2b0 [<c04343a5>] ? smp_apic_timer_interrupt+0x35/0x50 [<f93af164>] ? vmxnet3_xmit_frame+0xba4/0xef0 [vmxnet3] [<c05d1796>] ? selinux_ip_postroute+0x56/0x320 [<c045dbf2>] ? enqueue_entity+0x102/0x460 [<c044d89b>] ? check_preempt_wakeup+0x16b/0x220 [<c0448c2a>] ? check_preempt_curr+0x5a/0x70 [<c0456656>] ? try_to_wake_up+0x206/0x3c0 [<c07ca77d>] ? dev_hard_start_xmit+0x1dd/0x400 [<c07c2dba>] ? __netdev_pick_tx+0x16a/0x1b0 [<c07e27f3>] ? sch_direct_xmit+0x113/0x180 [<c07cabb5>] ? dev_queue_xmit+0x1b5/0x290 [<c07fc172>] ? ip_finish_output+0x152/0x2d0 [<c07fb7c5>] ? ip_local_out+0x15/0x20 [<c07fbc25>] ? ip_queue_xmit+0x145/0x3b0 [<c04cbc54>] ? __rcu_process_callbacks+0x44/0x2f0 [<c04cbf35>] ? rcu_process_callbacks+0x35/0x40 [<c0469b5e>] ? __do_softirq+0xce/0x1f0 [<c080f257>] ? tcp_transmit_skb+0x447/0x860 [<c04343a5>] ? smp_apic_timer_interrupt+0x35/0x50 [<c087b6e5>] ? apic_timer_interrupt+0x31/0x38 [<c08114a6>] ? tcp_write_xmit+0x1c6/0xa40 [<c0811fb1>] ? __tcp_push_pending_frames+0x31/0xe0 [<c0802be1>] ? sk_stream_alloc_skb+0x91/0xe0 [<c08048d3>] ? tcp_sendmsg+0x613/0x970 [<c07b677e>] ? sock_aio_write+0x13e/0x190 [<c087af58>] ? _spin_lock_bh+0x8/0x30 [<c0543945>] ? do_sync_write+0xd5/0x120 [<c0485be0>] ? autoremove_wake_function+0x0/0x40 [<c05c49fc>] ? security_file_permission+0xc/0x10 [<c0543b16>] ? rw_verify_area+0x66/0xe0 [<c0543d08>] ? vfs_write+0x178/0x190 [<c05447eb>] ? sys_write+0x4b/0xa0 [<c0409bbf>] ? sysenter_do_call+0x12/0x28 ---[ end trace 28603d7a288456a7 ]---

iamnewborn_ru ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.