> Если верить вики, центось 4.9 вышла на 2 недели позднее шапки

Вот мы и знаем время, которое требуется, чтобы разместить симлинк по серверам. :)

Вопрос спорный. Центось следовала линии партии, SL логике и удобству.

Я простой смертный, и не знаю, что там сделала Red Hat. Но что-то мне не верится, что и у Red Hat вся версия 4.9 заключалась только в симлинке. Исошек может и не быть, но не 4.8 же под видом 4.9 они «выкатывали»?

> А если net start wuauserv? Если что, это не я, это гугель :)

Ну я же не такой бестолковый... Ж;-) Пока она вообще ни на какую версию «net start» не реагирует.

> Но что-то мне не верится, что и у Red Hat вся версия 4.9 заключалась только в симлинке. Исошек может и не быть, но не 4.8 же под видом 4.9 они «выкатывали»?

Правильно не верится — http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/4/html/4.9_Release...

Похоже просто обозвали некий набор апдейтов на 4.8 следующей версией, и всё.

А, тогда пардон. Думал дело в локализованном названии службы, и это типа фича, а не баг.

>И что же вас так позабавило? Вы хотите сказать, что несущая на порту есть всегда? Ж;-)

Месье теоретик не знает что такое несущая ?

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

>А если мне нужны разные ACL (кстати, укажу на то, что далеко не на всех коммутаторах L2 есть ACL - и даже больше, на большинстве их нет; сюрприз?) в зависимости от суммы результатов несколькиз проверок (ну, скажем, имя пользователя, физическое расположение коммутатора, тип и версия ОС, уровень обновлений, наличие специфического ПО, наличие специфических настроек)?

При таких желаниях нужно хорошо подумать и если они не исчезли, тогда написать заявление по собственному желанию

Такое впечатление что месье представляет собой представителя быдло админов у которых удаленный офис подключен через cisco 800 а внутри заадминенная винда (типовое кстати быдло решение - пока мне попался только один случай его относительно нормальной работы)

> Месье теоретик не знает что такое несущая ?

Нет, мсьё практик - и уже устал от некоторых теоретиков, которые даже прочитать не осилили.

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

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

Вообще же, мсьё рекомендуется внимательно прочитать две вещи:

а) сообщение, где я писал про эту самую несущую - там написано не совсем то, что обсуждает мсьё;

б) описание протокола IEEE 802.1x - для общего образования.

> При таких желаниях нужно хорошо подумать и если они не исчезли, тогда написать заявление по собственному желанию

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

Такое впечатление что месье представляет собой представителя быдло админов у которых удаленный офис подключен через cisco 800 а внутри заадминенная винда (типовое кстати быдло решение - пока мне попался только один случай его относительно нормальной работы)

Гмм... А не стыдно в одной фразе называть оппонента быдло-админом и тут же расписываться в своей криворукости? Ибо только на всю голову обиженный и на все руки кривой деятель не осилит настройку описанного типового решения (оно ведь не просто так типовое, да?) и будет иметь с ним постоянные проблемы вместо того, чтобы про него не вспоминать никогда - за исключением случаев, когда нужно добавить функционал (IP-телефонию там прикрутить, например).

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

>Или дайте пример, где Debian долго не латала, а RHEL быстро залатал и CO/SL быстро перелопатили и выпустили.

А самим посмотреть )? Сотни их, ссылку ж давал выше. Скромный пример:

http://security-tracker.debian.org/tracker/CVE-2010-4251

deb поставили unimportant issues, так как RH выставили статус «moderate» (баг, как обычно, запостили в багзилле RH). И висит оно себе. Подробности не разбирал, но как бы «allows remote attackers to cause a denial of service (memory consumption)». RH выложили src 25.02.11 . Update SL - 07.03.11, CentOS 14.04.11. Всего там было 3 security issues. Обычно на ядерные апдейты у CentOS, SL уходит 3-14 дней. Это чтоб собрать из готовых сырцов, протестировать.. Не патчить. Вот вам и enterprise.

Зимой наблюдал в debian довольно много important issues в php и mysql. Висели месяцами. Себе поставил актуальные версии. Сейчас глянул, вроде более-менее ).

Плохо. Для меня из «red hat для самых маленьких» остался только SL.

Будем надеется на лучшее. CentOS плотно сидит в инфраструктуре, должен выжить.

> deb поставили unimportant issues, так как RH выставили статус «moderate»

Можно суть проблемы в двух словах? А особенно то, чем это всё грозит пользователям Debian?

Я говорил про серьёзные уязвимости, которые грозят бедой. Например, как java поломали, когда она падала от каждого чиха, или потом php.

Что касается php. Вроде бы, контакт тоже падал от этой проблемы. Но в Debian Stable этой проблемы не было (в sid и в testing была). Не думаю, что там стоит не Stable. Скорее всего, там стоит какой-то особый php, который может худо-бедно справляться с такой нагрузкой, потому что просто php - не справится, вестимо. :)

Что было в security.debian.org, я не знаю, не знаю даже, есть ли они для testing или sid, поскольку обновляюсь только с локального зеркала, а зеркалировать дважды одно и то же не вижу необходимости на данный момент, но в sid php_5.3.3-7 (исправление) пришло в тот же день, в squeeze (на тот момент testing) оно перешло на следующий день. Вообще, судя по тому, как exim4 один раз из security в proposed-updates сутки шёл, может быть, оно в security ещё раньше появилось, мне это обновление было не нужно и я за этим цирком по синхронизации локального зеркала и изменению там версий наблюдал.

Но и с php, и с exim всегда обновления для Debian были в тот же день. Да и вообще, мне даже на alien-arena и widelands приходят обновления безопасности, так что за качество исполнения Debian Security Team я спокоен. :)


Я не знаю, что там у вас, но привычки что-то собирать вручную у многих нет, Debian большой, пакеты есть, пакеты обслуживаются Debian Security Team и за них не надо волноваться. А соберёшь новую версию вручную, и потом же вручную нужно будет обновления для безопасности отслеживать. Лениво то как...

> а если у компании свой штат админов, зачем платить XXXX баксов за поддержку от рх в год, если можно туже систему поставить из центос? :)

поставить - да. сопровождать без поддержки непросто. и дело не в знании/навыках, а нас все синиоры вполне себе ядро под дебаггером прогнать могут. просто времени на это уходит много, да и не возможно в каждой подсистеме ядра и каждом драйвере хорошо на уровне кода ориентироваться. для этого есть «специально обученные люди» в РХ, а конкретнее разработчики этих самых систем и драйверов. получается всем материальная выгода от такого сотрудничества.

Вообще судя по последним веяниям и из-за качества некоторых редхатовских программистов, я бы им не платил чисто из-за вредности.

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

> если баг нашелся, то и фикс уже есть. Закрываем баг, если требуется то и пересобрали ядро. И все дела.

да ты что? ни разу не встречал бага, на который репорта даже нет пока?

>> уже пройдёт добрая половина срока поддержки RHEL.

Рекомендую посмотреть время поддержки RHEL.

что не так? мы до пятерки еще не апгрейдились, только для новых инсталляций пока. а шестерка пока так, только побаловаться админам.

> да, номер поддержки free/open/net/bsd я оч. тоже хочу услышать!

пожалуйста. коммерческая поддержка OpenBSD в Украине: +380919116750

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

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

Спасибо за вопрос

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

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

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

:) встречал один раз за все 10 лет. Так что думаю этим можно принебречь.

вставлю свои пять копеек

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

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

а еще бывают городские сети ethernet и иногда даже с маршрутизаторами

а еще «эффективный» менеджер ДЦ всем сказал что купил правильные бесперебойники, а купил неправильные и как шандорахнет...

а тупой случай - забыли вовремя аккумуляторы поменять ?

:) и sla с манибеком за простой больше оговоренного они выплачивают?

>Можно суть проблемы в двух словах? А особенно то, чем это всё грозит пользователям Debian?

3 слова :) - «denial of service». Если вам не роняют сервер, это не значит, что этого нельзя сделать. Вы хотите эксплоит в новостях лора? Ещё висит кучка локальных уязвимостей, тоже с denial of service. Актуально для шар хостинга (но на шарах адекватные админы, если и юзают deb, то старшие версии ПО, свои пакеты).

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

Это ж не фейсбук, а г контора. Только что посмотрел - nginx/0.7.59 , PHP/5.2.6-1+lenny9. То-есть у них даже php до актуальной версии Lenny не обновлён (было 4 апдейта). Нет слов.

Вы думаете, что поломанный сервер это rm * / ? Это ботнет и спам. «Бизнес» же. Запросто сервера «вконтакта» могут кишеть этим.

так что за качество исполнения Debian Security Team я спокоен. :)

Ну не волшебники они. Висят баги. Что могут правят, что нет - через полгода или никогда.

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

На debian - lamp обычный. Шар для парочки отечественных производителей. Так получилось. Уже как-то жаловался. Ядро - rhel от OpenVZ, php 5.2.17, так как в 5.2.6 были незакрытые уязвимости + кривые движки не дружат с 5.3 + mysql старших версий + мелочи. Периодически набегают ломальщики. Эксплойты на автоматах кидают, брутфорсят админку, ищут phpmyadmin. Как обычно. Сервера в Европе. Что характерно, на серверах в Украине - тишина, изредка брутфорсят ssh.

да, и еще даже ни разу не пришлось этого делать =)

ну, честно говоря я такое видел не раз, в апстриме есть несколько фиксов, которые РХ писал по нашему репорту. нечасто, да, но бывает. очень спасает оперативное реагирование разработчиков, сами бы конечно существенно дольше ковырялись.

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

нене, пусть расскажет, мне прям интересно.

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

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

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

а еще бывают городские сети ethernet и иногда даже с маршрутизаторами

а еще «эффективный» менеджер ДЦ всем сказал что купил правильные бесперебойники, а купил неправильные и как шандорахнет...

а тупой случай - забыли вовремя аккумуляторы поменять ?

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

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

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

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

он первый начал троллить :)

когда будут srpm-пакеты?

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

Все начиналось с таких загадочных вещей а свелось к банальному EAP 802.1x Вот поэтому многие относятся с улыбкой когда кто-то начитавшись рекламных проспектов начинает рассказывать об Ынтырпрайз.

Скажем так, в масштабах сети предприятия проблемы безопасности это не решает так как остается слабым местом абонентское устройство в котором хранятся аутентификационные данные.

А проблему смены мест пользователями проще решать привязыванием влан к маку, для абонентского устройства гемороя меньше.

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

Где-то тут ложь.

Я вообще-то админ ISP

Если не измените своё отношение к делу, вас скоро выгонят.

>Если не измените своё отношение к делу, вас скоро выгонят.

я смотрю тут манажоры мессаги вырезают :-D

>да ты что? ни разу не встречал бага, на который репорта даже нет пока?

Я полагаю мы говорим о критических багах с которыми рут можно получить и нету фикса. Такой видел 1. Хоть и не было фикса но были альтернативные пути закрытия пока не исправят. В других случаях на такие вещи решения есть всегда.

Да понятно, что есть другие, которые пока исправят, придется подождать. Но они погоды не делают, из-за которых, бизнес рушится и все в 0. Собственно не вижу серьезных причин почему не стоит использовать centos для серверов в плане неимения хотфиксов от RH. Но я говорю о хостинге, возможно в каких других целях все намного сложней.

> Я полагаю мы говорим о критических багах с которыми рут можно получить и нету фикса.

У вас весьма специфическое представление о критических багах :)

>>Мне нужен. Дебиан на моём сервере дико тупит на дисках, а центось - нет. Выбор очевиден.

это тупит, а это не тупит....фигня какая-то....

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

Чувак я сюда троллится хожу, поскольку умных людей здесь мало...а как же троллится без пафоса ? (хотя наверно там другое слово уместнее...

и кстати все Ваши причины отключения якобы не связанные с электричеством были с ним связаны, я просто добавил в список еще немного вариантов

RE: Где-то тут ложь.

>Где-то тут ложь.

Нет чистейшая правда

И результат выходных уже известен 2 cisco 800 перезалили и они заработали

Cisco очень «надежное» оборудование (особенно при удаленном администрировании)

> Чувак я сюда троллится хожу, поскольку умных людей здесь мало...

Ооо, какое у нас ЧСВ.. Черепная коробка не жмет? Или ты этим хотел сказать, что себя к умным не относишь?

и кстати все Ваши причины отключения якобы не связанные с электричеством были с ним связаны, я просто добавил в список еще немного вариантов

Давай, поясни нам, сирым, каким образом связаны kernel panic и отключение электричества, умник ты наш доморощенный.

ЗЫ. val-amart, походу, просто ошибся, ибо то, на что ты ответил, явно предназначалось ТС'у xpahos'у.

> Cisco очень «надежное» оборудование (особенно при удаленном администрировании)

если руки из жопы растут, то никакое оборудование не поможет

> Я полагаю мы говорим о критических багах с которыми рут можно получить и нету фикса. Такой видел 1

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

> и кстати все Ваши причины отключения якобы не связанные с электричеством были с ним связаны, я просто добавил в список еще немного вариантов

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

ага, спутал их.

> Чувак я сюда троллится хожу, поскольку умных людей здесь мало...

Начни с себя, и другие подтянутся.

>Скажем так, в масштабах сети предприятия проблемы безопасности это не решает так как остается слабым местом абонентское устройство в котором хранятся аутентификационные данные.

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

А проблему смены мест пользователями проще решать привязыванием влан к маку, для абонентского устройства гемороя меньше.

В сети, где я сейчас, под 4000 тыс пользователей разбросанных по двум десяткам регионов и примерно стольким же удаленным офисам, соединенным L3 линками, микроволновыми или через спутник. Вланы, соответсвенно, толко в двух центральных офисах и ближайших к ним локациях. Между регионами каждый день перемещается не меньше пары десятков человек со своими ноутами. Каждый день кто-то получает новый компьютер, кому-то меняют сгоревшую сетевуху или базовую станцию лэптопа. Свичей на замену вышедшим из строя мы только сегодня отконфигурировали две штуки (по счастью, всего лишь 8-ми портовых L2). Что-то мне подсказывает, что глобальная безопасность на основе мак адресов в подобных сетях представляет собой ненаучную фантастику. А вот 802.1x + домен (на чем бы он ни был построен) - в самый раз. Публика перемещается между проводными и беспроводными сетями, между разными локациями, совершенно прозрачно, и при этом левые машины и юзера отсекаются достаточно надежно.

Вот поэтому многие относятся с улыбкой когда кто-то начитавшись рекламных проспектов начинает рассказывать об Ынтырпрайз.

Кто б спорил. Ынтырпрайз это и правда смешно, когда не грустно.

> В сети, где я сейчас, под 4000 тыс пользователей

В натуре 4 лимона пользователей? Что ж это за контора такая? Брешешь поди :)

> В натуре 4 лимона пользователей? Что ж это за контора такая? Брешешь поди :)

Это я одновременно еще два дела делал. В тысячу раз меньше, конечно :)

Known issues:

• The installer needs at least 392MB of memory to work. Text mode will automatically be used if the system has less than 652MB of memory.
• The message «Insufficient memory to configure kdump!» appears during install. This is a known upstream bug which appears on systems with less than 4 GB RAM and solved by updating to kexec-tools-2_0_0-153_el6 or newer.

Вот уже и линукс может без бубна и не встать на систему с менее чем 4 гигами рамы, а если памяти меньше 652 мег, то и возможности по установке оказываются кастрированными дальше некуда. Куда катится этот мир...

Эпичненько >_<

>Что-то мне подсказывает, что глобальная безопасность на основе мак адресов в подобных сетях представляет собой ненаучную фантастику. А вот 802.1x + домен (на чем бы он ни был построен) - в самый раз.

От чего защищаетесь ?

IMHO не совсем понятна роль доменов в современном мире разве переход на веб-интерфейсы неправильное направление ?

>От чего защищаетесь ?

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

IMHO не совсем понятна роль доменов в современном мире разве переход на веб-интерфейсы неправильное направление ?

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

Да, есть веб интерфейсы. Есть приложения для Лотуса. Но это не панацея. Особенно если учесть, что разработчики тоже люди, и руки у них растут всяко. Можно еще помечтать, о том, чтобы вместо пользовательских машин у всех были тонкие клиенты, никто не работал с рабочими ноутами дома, не слушает музыку и не пользуется фейсбуком. Помечтав, вернуться в реальность.

Boot has failed, sleeping forever.

Не встал Centos 6 64-bit на vmware server 2. Анаконда чисто отработала, а после перезагрузки No root device found. Ставил из netinst.iso, с яндексовского зеркала.

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

я к тому, что с веб-интерфейсами задача решается проще

соответственно появляется философский вопрос «домены или web?»

Рабочий ноут в домене держать сложнее чем взаимодействовать через веб...

а насчет музыки, так это вопрос управленческой культуры в организации а не сетевого администрирования

тут вспомнил про старое понятие АРМ, может быть оно вернется в массы? говорят что из некоторых организаций оно и не уходило...