The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..., opennews (??), 08-Авг-11, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


20. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  –1 +/
Сообщение от Аноним (-), 08-Авг-11, 11:05 
проблема обновления в freebsd многих отпугивает, не каждый сдюжит сидеть пару часов обновляя зависимости, тем более на боевом сервере, а в случае всяких кед и опенофис так вообще обновления затягивается на сутки на рабочих станциях, за то проблемы бекапа и переноса сервера с одной железки на другую вообще нет(ну или почти нет).
Ответить | Правка | Наверх | Cообщить модератору

22. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Аноним (-), 08-Авг-11, 11:12 
Да. А представь если у тебя парк из 50 машин? Причем некоторые пакеты собраны с разными опциями. Тут уже приходится держать машину для сбора пакетов :))
Не все так ужасно, просто плохо.
Ответить | Правка | Наверх | Cообщить модератору

56. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +2 +/
Сообщение от Аноним (-), 08-Авг-11, 12:26 
> Да. А представь если у тебя парк из 50 машин? Причем некоторые
> пакеты собраны с разными опциями. Тут уже приходится держать машину для
> сбора пакетов :))
> Не все так ужасно, просто плохо.

А Вам зачем?
Имеется парк рабочих машин кол-вом до 200. Большинство из них имеют единую конфигурацию, отличающуюся лишь конфигрурациями.
Обновление системы занимает меньше 10 минут, удаленно.
ЧЯДН?

Ответить | Правка | Наверх | Cообщить модератору

64. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +1 +/
Сообщение от Аноним (-), 08-Авг-11, 12:35 
> Имеется парк рабочих машин кол-вом до 200. Большинство из них имеют единую
> конфигурацию, отличающуюся лишь конфигрурациями.
> Обновление системы занимает меньше 10 минут, удаленно.
> ЧЯДН?

Нужно чтобы обновление всех 200 машин разом занимало 10 минут. 10 минут на одну машину неприемлемо.

Ответить | Правка | Наверх | Cообщить модератору

77. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от lagman (?), 08-Авг-11, 12:58 
Обновляешь эталонный образ машины
Перегружаешься
...
Profit!!!
Ответить | Правка | Наверх | Cообщить модератору

98. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  –1 +/
Сообщение от Аноним (-), 08-Авг-11, 13:39 
> Обновляешь эталонный образ машины
> Перегружаешься
> ...
> Profit!!!

и так каждый день.... 4-5 рабочих часов на обновление всего парка говорите ? :-)
Переход на новую версию ОС - это отдельный вопрос, людей волнует обновление софта для исправления дыр и багов.

Ответить | Правка | Наверх | Cообщить модератору

106. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Аноним (-), 08-Авг-11, 13:46 
>> Обновляешь эталонный образ машины
>> Перегружаешься
>> ...
>> Profit!!!
> и так каждый день.... 4-5 рабочих часов на обновление всего парка говорите
> ? :-)
> Переход на новую версию ОС - это отдельный вопрос, людей волнует обновление
> софта для исправления дыр и багов.

Похоже вы говорите о desktop системах. Я же говорю про продакшн системы, у которых downtime не должен превышать пары часов в год.
Занимайтесь лучше линуксом:)

Ответить | Правка | Наверх | Cообщить модератору

117. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Аноним (-), 08-Авг-11, 13:58 
> Похоже вы говорите о desktop системах. Я же говорю про продакшн системы,
> у которых downtime не должен превышать пары часов в год.

Я говорю об обновлении серверных и системных приложений. А вы почему то пытайтесь всести все к обновлению всей системы c непременной перезагрузкой. Если для обновления какого-нибудь php или java вам требуется перезагружать сервер, это нонсенс. Обновлять их приходится регулярно, так как и дыры регулярно в них появляются.

Ответить | Правка | Наверх | Cообщить модератору

138. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Аноним (-), 08-Авг-11, 14:52 
>> Похоже вы говорите о desktop системах. Я же говорю про продакшн системы,
>> у которых downtime не должен превышать пары часов в год.
> Я говорю об обновлении серверных и системных приложений. А вы почему то
> пытайтесь всести все к обновлению всей системы c непременной перезагрузкой. Если
> для обновления какого-нибудь php или java вам требуется перезагружать сервер, это
> нонсенс. Обновлять их приходится регулярно, так как и дыры регулярно в
> них появляются.

upd@fupdater:/home/upd>clusupdate 'show php*'|wc -l
       12
upd@fupdater:/home/upd>clusupdate 'show java*' | wc -l
       3
upd@fupdater:/home/upd>clusupdate 'show sudo*' | wc -l
       318

у нас с Вами разные задачи.

Ответить | Правка | Наверх | Cообщить модератору

141. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Аноним (-), 08-Авг-11, 15:00 
> upd@fupdater:/home/upd>clusupdate 'show sudo*' | wc -l

/home/upd и clusupdate говорит о том, что у вас самописное решение. Проблема не в том, что нельзя организовать систему обновления кластера, а в том, что из коробки таких решений нет.

Ответить | Правка | Наверх | Cообщить модератору

143. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Аноним (-), 08-Авг-11, 15:17 
>> upd@fupdater:/home/upd>clusupdate 'show sudo*' | wc -l
> /home/upd и clusupdate говорит о том, что у вас самописное решение. Проблема
> не в том, что нельзя организовать систему обновления кластера, а в
> том, что из коробки таких решений нет.

Увы, у каждой компании/IT отдела задачи разнятся.
мы планировали портировать данное решение. но в реальности, наши коллеги обкатав его, нашли не пригодным для себя/своих нужд (решение было предоставлено порядка 40 компаний средней и "длинной" руки). По этому "обломались". Увы.

Ответить | Правка | Наверх | Cообщить модератору

327. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +3 +/
Сообщение от vegus (ok), 09-Авг-11, 01:26 
> /home/upd и clusupdate говорит о том, что у вас самописное решение. Проблема
> не в том, что нельзя организовать систему обновления кластера, а в
> том, что из коробки таких решений нет.

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

лениво класть в коробку что-то "универсальное" и для всех? - можно положить самописное и для себя, - опенсурс, не?

лениво самому писать и класть для себя? - проблема, видимо, в лени, а не во FreeBSD, ведь так?

Ответить | Правка | К родителю #141 | Наверх | Cообщить модератору

400. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Аноним (-), 09-Авг-11, 08:42 
> лениво самому писать и класть для себя? - проблема, видимо, в лени,
> а не во FreeBSD, ведь так?

Вы только подчеркнули ту проблему о которой идет речь "Мне не нужно, значит и другим тоже". Вы такие вещи как система инициализации и инструменты работы с пакетами тоже сами на коленке скриптами пишете ? Понадобился драйвер - без проблем, напиши сам. Это не промышленный подход, должно быть готовое стандартное решение. А писать операционную систему самостоятельно у пользователей нет желания, а у компаний нет лишних денег, ресурсов, квалифицированных разработчиков и главное, нет лишнего времени на отладку и тестирование.  Поэтому люди понемногу отворачиваются от FreeBSD.

Ответить | Правка | Наверх | Cообщить модератору

410. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +1 +/
Сообщение от vegus (ok), 09-Авг-11, 09:08 
> Вы только подчеркнули ту проблему о которой идет речь "Мне не нужно,
> значит и другим тоже". Вы такие вещи как система инициализации и
> инструменты работы с пакетами тоже сами на коленке скриптами пишете ?

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

> Понадобился драйвер - без проблем, напиши сам. Это не промышленный подход,

:-) интересно, почему этот драйвер _вдруг_ понадобился при "промышленном"-то подходе ;-)

> должно быть готовое стандартное решение. А писать операционную систему самостоятельно

что должно? кому должно?
есть мнение, что никто никому никаких "готовых стандартных решений" не должен - "...AS-IS, NO WARRANTY..."

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

...и наконец разговор пошел про ресурсы.
и если откинуть разговоры про и так несуществующее время, отсюда можно сделать вывод, что "отворачиваются от FreeBSD":
- компании, у которых _не_хватает_денег_ на обслуживание FreeBSD;
- пользователи, у которых _нет_желания_ находить существующие или создавать свои собственные "решения" на основе FreeBSD

так получается, Аноним?

кажется, мы все можем очень удивиться, выяснив корневые причины оттока пользователей от FreeBSD ;-)

Ответить | Правка | Наверх | Cообщить модератору

685. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от XPEHemail (?), 10-Авг-11, 16:16 
>  - компании, у которых _не_хватает_денег_ на обслуживание FreeBSD;

Жалкие ничтожные люди.

>  - пользователи, у которых _нет_желания_ находить существующие или создавать свои  "решения" на основе FreeBSD

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

Ответить | Правка | К родителю #410 | Наверх | Cообщить модератору

837. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от nuclightemail (ok), 11-Авг-11, 22:13 
>> Понадобился драйвер - без проблем, напиши сам. Это не промышленный подход,
>  :-) интересно, почему этот драйвер _вдруг_ понадобился при "промышленном"-то подходе ;-)

Элементарно. Ставим вычислительный кластер, задача требует карточек Infiniband. Где для него дрова под фрю? Нету? Всё, фря пролетела. Промышленный подход, вот никто его писать и не стал.

>> должно быть готовое стандартное решение. А писать операционную систему самостоятельно
>  что должно? кому должно?
>  есть мнение, что никто никому никаких "готовых стандартных решений" не должен
> - "...AS-IS, NO WARRANTY..."

Вот те, у кого такое мнение, в жопе-то и сидят.

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

Ололо. Время - это единственное, что в конечном итоге ценно. Потерянные деньги можно заработать снова, время - нет.

> сделать вывод, что "отворачиваются от FreeBSD":
>  - компании, у которых _не_хватает_денег_ на обслуживание FreeBSD;
>  кажется, мы все можем очень удивиться, выяснив корневые причины оттока
> пользователей от FreeBSD ;-)

Это было и так очевидно любому с мозгом, кто читал пост. Вопрос-то каков - а почему это фря получается в обслуживании дороже? Стало быть, она не лучше. Решение компаний вполне логично, значит, проблема у FreeBSD.

Ответить | Правка | К родителю #410 | Наверх | Cообщить модератору

919. "Опубликован анализ ключевых проблем FreeBSD и начат сбор..."  +1 +/
Сообщение от anonymous (??), 12-Авг-11, 20:52 
> Вопрос-то каков — а почему это фря получается в обслуживании дороже?

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

Ответить | Правка | К родителю #837 | Наверх | Cообщить модератору

937. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Аноним (-), 14-Авг-11, 02:38 
>Элементарно. Ставим вычислительный кластер, задача требует карточек Infiniband. Где для него дрова под фрю? Нету? Всё, фря пролетела.

FREBSD 9 - всё фря не пролетела, пролетел ты :)

>Вопрос-то каков - а почему это фря получается в обслуживании дороже?

А с какого перепугу она получается дороже то?! Миф.

Ответить | Правка | К родителю #837 | Наверх | Cообщить модератору

191. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Sememail (ok), 08-Авг-11, 18:28 
А зачем их обновлять *каждый день*. Каждый день дыр не обнаруживается.
Ответить | Правка | К родителю #117 | Наверх | Cообщить модератору

173. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +1 +/
Сообщение от Сама Доброта (?), 08-Авг-11, 17:14 

> Похоже вы говорите о desktop системах. Я же говорю про продакшн системы,
> у которых downtime не должен превышать пары часов в год.
> Занимайтесь лучше линуксом:)

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

Ответить | Правка | К родителю #106 | Наверх | Cообщить модератору

925. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Аноним (-), 12-Авг-11, 21:16 
> да и kexec помогает. а при работах на железе - просто
> смигрировать на другую ноду.

А на чем еще может работать виртуалка? В другой виртуалке чтоли? :)

Ответить | Правка | Наверх | Cообщить модератору

91. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Аноним (-), 08-Авг-11, 13:20 
И все одновременно перегружать?
Ну да, ну да:)
Пойдите работать в контору средней руки, и осуществите это все.
Самое слабое будет - выговор начальника....

Ну нас все тщательно обкатано за много лет.
Обновление данного парка машин занимает в общей сложности 4-5 рабочих часов одного человека.

Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

97. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +1 +/
Сообщение от Аноним (-), 08-Авг-11, 13:36 
> Ну нас все тщательно обкатано за много лет.
> Обновление данного парка машин занимает в общей сложности 4-5 рабочих часов одного
> человека.

Т.е. вы после обновления какого-нибудь userlang пакета обновляйте и перезаливайте образ всей системы и перезагружайте ?  95% обновлений можно произвести без перезагрузки. Обновление это не только ядро, а прежде всего софт в портах.


Ответить | Правка | Наверх | Cообщить модератору

102. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Аноним (-), 08-Авг-11, 13:43 
>> Ну нас все тщательно обкатано за много лет.
>> Обновление данного парка машин занимает в общей сложности 4-5 рабочих часов одного
>> человека.
> Т.е. вы после обновления какого-нибудь userlang пакета обновляйте и перезаливайте образ
> всей системы и перезагружайте ?  95% обновлений можно произвести без
> перезагрузки. Обновление это не только ядро, а прежде всего софт в
> портах.

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

Ответить | Правка | Наверх | Cообщить модератору

128. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Аноним (-), 08-Авг-11, 14:20 
> рабочие машины. Механизм обновления  портов(если больше полутора десятков портов обновляется,
> то уже по другому) полностью отточен за долгое время и происходит
> полностью автоматически. В последние два-три года, т-т-т, без единого сбоя.

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

Ответить | Правка | Наверх | Cообщить модератору

333. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от vegus (ok), 09-Авг-11, 01:37 
> Про то и речь, что нет готового из коробки решения и приходится
> самому велосипед изобретать и писать свои скрипты.

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

Ответить | Правка | Наверх | Cообщить модератору

403. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Аноним (-), 09-Авг-11, 08:47 
>  мне интересно и постараюсь осторожно поинтересоваться: писать свои скрипты - это
> бывает как-то дискомфортно? или, может быть, иногда отнимает порядочно сил?
>  я просто пытаюсь представить, как это бывает у других людей...

Не все админы localhost-а и могут позволить себе засунуть в систему написанный на коленке скрипт. Автор этого скрипта потом уволится и кто с этим самописным парком работать/разбираться будет ? Для enterprise такой подход неприемлем.

Ответить | Правка | Наверх | Cообщить модератору

406. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +3 +/
Сообщение от lagman (ok), 09-Авг-11, 08:55 
>>  мне интересно и постараюсь осторожно поинтересоваться: писать свои скрипты - это
>> бывает как-то дискомфортно? или, может быть, иногда отнимает порядочно сил?
>>  я просто пытаюсь представить, как это бывает у других людей...
> Не все админы localhost-а и могут позволить себе засунуть в систему написанный
> на коленке скрипт. Автор этого скрипта потом уволится и кто с
> этим самописным парком работать/разбираться будет ? Для enterprise такой подход неприемлем.

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

Ответить | Правка | Наверх | Cообщить модератору

501. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Pan Prdel (?), 09-Авг-11, 16:37 
> Дружок, энтерпрайз на то и энтепрайз, что все решения, которые разрабатываются в
> рамках энтерпрайза - хорошо документируются и не имеют проблем с поддержкой
> в будущем.

такой вариант приводит к тому, что в каждой компании рождаются свои костыли для апдейта/управления софтом => при смене места работы надо изучать новую систему костылей.
в случае rhel/sles/debian надо минимум усилий для аналогичных вещей.

Ответить | Правка | Наверх | Cообщить модератору

494. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Stanislavvv (?), 09-Авг-11, 16:05 
>> Про то и речь, что нет готового из коробки решения и приходится
>> самому велосипед изобретать и писать свои скрипты.
>  мне интересно и постараюсь осторожно поинтересоваться: писать свои скрипты - это
> бывает как-то дискомфортно? или, может быть, иногда отнимает порядочно сил?
>  я просто пытаюсь представить, как это бывает у других людей...

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

А писать велосипеды... Эт конечно можно. Но задалбывает, ибо есть уже написанные.

Ответить | Правка | К родителю #333 | Наверх | Cообщить модератору

660. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от vleemail (ok), 10-Авг-11, 13:39 
> Из вашего ответа можно сделать вывод о том, что во фре невозможно
> что-то подобное apt-cron, которое можно _из_коробки_ поставить на бОльшую часть хостов
> и пусть оно занимается рутиной по обновлениям (тут, конечно, лучше свой
> репозиторий, но на многих хостах можно и напрямую).

В принципе, у них все есть, если взять наработки NetBSD,
не в будущем, а уже сейчас, даже в двойном экземпляре.

http://pkgsrc.se/pkgtools/nih
http://pkgsrc.se/pkgtools/pkgin

По поводу перехода FreeBSD на pkgsrc даже шутка была от фришников
первоапрельская года 4 назад.

> А писать велосипеды... Эт конечно можно. Но задалбывает, ибо есть уже написанные.

А вот этого не надо ;-)

Ответить | Правка | Наверх | Cообщить модератору

119. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +1 +/
Сообщение от Аноним (-), 08-Авг-11, 14:02 
http://www.vuxml.org/freebsd/ - это все нужно постоянно обновлять. Или вы на дырявом софте сидите ?
Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

139. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Аноним (-), 08-Авг-11, 14:53 
> http://www.vuxml.org/freebsd/ - это все нужно постоянно обновлять. Или вы на дырявом софте
> сидите ?

См. пост 138.

Ответить | Правка | Наверх | Cообщить модератору

26. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от RicoXemail (?), 08-Авг-11, 11:29 
проблему переноса линуха решил через ClonezillaSE, для бэкапов хватает бакулы, не вижу принципиальных преимуществ dump/restore. Хотя чтоб уже совсем не гнобить фрю, мне в ней нравится разделение на сюсспейс и юзерспейс, более вменяемый шейпер (dummynet) чем любой из тех что пробовал в линухе, удобство пересборки ядра под свои нужды.
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

29. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Аноним (-), 08-Авг-11, 11:36 
Bacula - вещь. Только копировать джобы не умеет на несколько Storage'й. ;(
Ответить | Правка | Наверх | Cообщить модератору

181. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Forthemail (??), 08-Авг-11, 17:36 
Умеет вроде. Я сам пока на 3.0.3. Некогда директор обновлять. Но в 5.x вроде уже умеет.
Ответить | Правка | Наверх | Cообщить модератору

31. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +2 +/
Сообщение от Аноним (-), 08-Авг-11, 11:37 
да только у бсд dump/restore из коробки работает, и является нативным решением...а в линуксе еще и покривляться надо
Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

61. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от QuAzI (ok), 08-Авг-11, 12:34 
pax же, не?
Ответить | Правка | Наверх | Cообщить модератору

287. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Michael Shigorinemail (ok), 08-Авг-11, 23:41 
> да только у бсд dump/restore из коробки работает, и является нативным решением...
> а в линуксе еще и покривляться надо

"В линуксе" эти сроду кривые костыли давно (ЕМНИП в 2.2.x) объявили неподдерживаемыми.  А кому и при каких обстоятельствах вообще пришло в голову брать данные со смонтированной ФС мимо реализации этой самой ФС, обслуживающей mountpoint -- даже узнавать неохота.

Покривляетесь ещё или хоть немножко стыдно стало?

PS: rsync (и стопка инкрементальных обвязок вокруг) и bacula решают в принципе ту же задачу, но на совсем другом уровне.  Что характерно.

Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

298. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от myc (?), 09-Авг-11, 00:07 
> "В линуксе" эти сроду кривые костыли давно (ЕМНИП в 2.2.x) объявили неподдерживаемыми.  А кому и при каких обстоятельствах вообще пришло в голову брать данные со смонтированной ФС мимо реализации этой самой ФС, обслуживающей mountpoint -- даже узнавать неохота.

ИМХО, брать данные со снапшота - вполне валидная операция.

Ответить | Правка | Наверх | Cообщить модератору

364. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +1 +/
Сообщение от nuclightemail (ok), 09-Авг-11, 03:19 
>> да только у бсд dump/restore из коробки работает, и является нативным решением...
>> а в линуксе еще и покривляться надо
> "В линуксе" эти сроду кривые костыли давно (ЕМНИП в 2.2.x) объявили неподдерживаемыми.
>  А кому и при каких обстоятельствах вообще пришло в голову
> брать данные со смонтированной ФС мимо реализации этой самой ФС, обслуживающей
> mountpoint -- даже узнавать неохота.
> Покривляетесь ещё или хоть немножко стыдно стало?
> PS: rsync (и стопка инкрементальных обвязок вокруг) и bacula решают в принципе
> ту же задачу, но на совсем другом уровне.  Что характерно.

Михаил, и Вы после этого "стыдно" вместо полного анализа технических аргументов будете еще что-то заявлять о гордыне? Ну смешно же, право слово. Эти самые "средства другого уровня" весьма долго не умели полностью сохранять структуру FS (скажем, тех же файлов с дырками), а заявлять о костылях при необходимости тех же инкрементальных обвязок и умалчивании об уже давно реализованном доступе к снапшотам вместо живой FS - по меньшей мере, демагогично. Как и игнорирование того факта, что развитием идеи dump/restore в "правильном ключе" является zfs send/receive, а не отказ от подобного способа решения целиком в пользу изначально предназначенных для слегка других целей утилит.

Ответить | Правка | К родителю #287 | Наверх | Cообщить модератору

719. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Michael Shigorinemail (ok), 10-Авг-11, 19:25 
>> Покривляетесь ещё или хоть немножко стыдно стало?
> Михаил, и Вы после этого "стыдно" вместо полного анализа технических аргументов

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

А за _полный_ анализ вопроса применимости dump/restore во FreeBSD и Linux (если Вы его имели в виду) могу при необходимости выставить Вам счёт -- поскольку придётся привлекать наших ядерщиков и системщиков как минимум.

> будете еще что-то заявлять о гордыне?

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

> Эти самые "средства другого уровня" весьма долго не умели полностью сохранять
> структуру FS

1) или у Вас оригинальное определение структуры ФС, или это не так;
2) зачем? (если мне нужен образ блокдевайса с отмонтированной или ro-ФС, его сделает dd; образ блокдевайса с rw ФС мне до сих пор нужен не бывал IIRC)

> (скажем, тех же файлов с дырками)

Я уже забыл, когда --sparse сделали в rsync (хотя багфиксы corner case'ов были и не так давно, e.g. в 3.0.8); в GNU tar поддержка sparse files была, когда я с ним столкнулся.

> а заявлять о костылях

Давайте уточним: я сказал, что согласен с тем, что dump и restore, которые ходят к блокдевайсу мимо драйвера ФС -- костыли (и против unix way, btw).

> при необходимости тех же инкрементальных обвязок

Если это было о надстройках над тем же rsync -- то лукавите: это как раз unix way.

Если нет -- то задача распределённого бэкапа (которая востребована) обычно решается с применением реализации инкрементального или инкрементально-дифференциального бэкапа для обеспечения разумного баланса периода, оперативности и стоимости резервных копий.  И не решается разумно в пределах локальной ФС.  Это так удивляет?

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

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

RAID, снапшоты, бэкап, rsync, bacula, диски, ленты, охрана периметра -- друг друга не заменяют, а дополняют.  У них разные плюсы, минусы и зоны применимости.  Местами перекрывающиеся.

> Как и игнорирование того факта, что развитием идеи dump/restore в
> "правильном ключе" является zfs send/receive

С этим незнаком, потому обсуждать не могу.

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

По смыслу их предназначение такое же -- копирование информации; по реализации -- да, другое, только IMHO не "слегка", а существенно.  Вы о чём?

Dump was a stupid program in the first place. Leave it behind.
  -- Linus Torvalds (http://lwn.net/2001/0503/a/lt-dump.php3)

Ответить | Правка | Наверх | Cообщить модератору

853. "dump/restore"  +/
Сообщение от nuclightemail (ok), 12-Авг-11, 02:15 
>>> Покривляетесь ещё или хоть немножко стыдно стало?
>> Михаил, и Вы после этого "стыдно" вместо полного анализа технических аргументов
> Каких-каких аргументов?!  В сообщении, на которое я отвечал, их просто нет.

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

> А за _полный_ анализ вопроса применимости dump/restore во FreeBSD и Linux (если
> Вы его имели в виду) могу при необходимости выставить Вам счёт
> -- поскольку придётся привлекать наших ядерщиков и системщиков как минимум.

...И всё равно не даст ответа, потому что такая постановка вопроса рассматривает лишь конкретную имплементацию, а вовсе не идею, и вопрос вовлеченного кругозора для полного научного исследования тоже неясен - Вы, как оказалось, про zfs send/receive не знаете, например.

>> будете еще что-то заявлять о гордыне?
> Вадим, мне бы за то, что спорол некто откомментированный, действительно было стыдно.
>  Чтоб Вам было понятно -- _естественно_, я _не_ свободен от
> гордыни.  За себя стыдно в части резкости, но предпочитаю сказать
> в лоб, что человек дурь сказал, чем поморгать глазками, поулыбаться и
> показать кукиш в кармане.

Кхе-кхе. Ну да про ad hominem я уже выше сказал, не буду повторяться.

>> Эти самые "средства другого уровня" весьма долго не умели полностью сохранять
>> структуру FS
> 1) или у Вас оригинальное определение структуры ФС, или это не так;

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

> 2) зачем? (если мне нужен образ блокдевайса с отмонтированной или ro-ФС, его
> сделает dd; образ блокдевайса с rw ФС мне до сих пор
> нужен не бывал IIRC)

Ранее всегда это делалось чаще всего для того, чтобы вместо dd переливать только ту часть FS, которая действительно занята данными. Полный dd не только долог, но и не позволяет воссоздать FS на диске другого размера. Кроме того, формат записи дампа таков, что в начале идут все каталоги. Соответственно, restore имеет функциональность чтения сначала заголовка и позволяет выбрать только часть файлов для восстановления. Я этим неоднократно пользовался. Очень удобно, когда многогигабайтный образ сжат - с tar пришлось бы для чтения оглавления читать _весь_ архив. А уж на магнитной ленте - так и подавно.

>> (скажем, тех же файлов с дырками)
> Я уже забыл, когда --sparse сделали в rsync (хотя багфиксы corner case'ов
> были и не так давно, e.g. в 3.0.8); в GNU tar
> поддержка sparse files была, когда я с ним столкнулся.

Ну, вот видите, даже для такой элементарной штуки corner case'ы были еще вон сколько. А уж специфические вещи типа флагов файлов кроме dump вообще долгое время никто сохранять не умел. Неудивительно, что он эволюционировал в средство для бэкапов, при наиболее полной поддержке фич конкретной fs. В наше время, конечно, альтернативные средства уже доросли, но это ж не отменяет громадную историческую практику, и не означает, что надо сразу же выкинуть.

>> а заявлять о костылях
> Давайте уточним: я сказал, что согласен с тем, что dump и restore,
> которые ходят к блокдевайсу мимо драйвера ФС -- костыли (и против
> unix way, btw).

Э, не, так не получится. Во-первых, здесь два варианта смешаны в кучу: идея знания о некотором устройстве конкретной fs и её реализация прямым чтением с диска - могли быть недокументированные хуки в драйвере.

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

В-третьих, все остальные программы комплекта - fsck, newfs, fsdb - уже работали с диском напрямую, в силу своей природы. Логично было использовать общий код из них и не встраивать хуки в драйвер (а в ядерном коде цена усложнения больше) для еще всего лишь одной программы.

>> при необходимости тех же инкрементальных обвязок
> Если это было о надстройках над тем же rsync -- то лукавите:
> это как раз unix way.

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

> Если нет -- то задача распределённого бэкапа (которая востребована) обычно решается с
> применением реализации инкрементального или инкрементально-дифференциального бэкапа
> для обеспечения разумного баланса периода, оперативности и стоимости резервных копий.
>  И не решается разумно в пределах локальной ФС.  Это
> так удивляет?

Общие слова какие-то. Что конкретно сказать-то хотели?

>> и умалчивании об уже давно реализованном доступе к снапшотам вместо живой FS -
>> по меньшей мере, демагогично.
> Позвольте поинтересоваться, используете ли Вы эту реализацию в своей практике в сколь-нибудь
> существенной мере или же именно что демагогию разводите?  У меня
> давным-давно были под рукой снапшоты в XFS и LVM, но я
> ими попросту не пользовался (в отличие от иных коллег) -- не
> требовалось.  И соответственно не носился с ними, как дурак с
> торбой.

Использовал несколько лет. На UFS, конечно, для ограниченных целей, ибо их возможности там ограничены, в основном для дампов как раз. А на ZFS ныне их используют все подряд, ибо это попросту удобно.

> RAID, снапшоты, бэкап, rsync, bacula, диски, ленты, охрана периметра -- друг друга
> не заменяют, а дополняют.  У них разные плюсы, минусы и
> зоны применимости.  Местами перекрывающиеся.

Спасибо, кэп.

>> Как и игнорирование того факта, что развитием идеи dump/restore в
>> "правильном ключе" является zfs send/receive
> С этим незнаком, потому обсуждать не могу.

На чем сей спор можно и завершить, в таком случае.

>> а не отказ от подобного способа решения целиком в пользу
>> изначально предназначенных для слегка других целей утилит.
> По смыслу их предназначение такое же -- копирование информации; по реализации --
> да, другое, только IMHO не "слегка", а существенно.  Вы о
> чём?
> Dump was a stupid program in the first place. Leave it behind.
>   -- Linus Torvalds (http://lwn.net/2001/0503/a/lt-dump.php3)

Ну да, абстрагируемся до небес с полной потерей смысла, и приправим мнением Торвальдса от мохнатого года, будто бы оно истина в последней инстанции (а вот ребята из Sun c ним не согласились и сделали элегантный zfs send/receive, и чо?). Демагогично, при подобной глухоте к альтернативным вариантам желания продолжать не имею.

Ответить | Правка | Наверх | Cообщить модератору

912. "dump/restore"  +/
Сообщение от Аноним (-), 12-Авг-11, 20:15 
> элегантный zfs send/receive, и чо?).

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

Ответить | Правка | Наверх | Cообщить модератору

950. "dump/restore"  +/
Сообщение от nuclightemail (ok), 15-Авг-11, 00:42 
>> элегантный zfs send/receive, и чо?).
> А почему это должно быть прибито гвоздями к одной файловой системе? Возможность
> реализации каких-то еще файловых систем в будущем вы не рассматриваете даже
> теоретически?

А кто-то у Вас такую возможность забирает разве? Реализуйте, я не против.

Ответить | Правка | Наверх | Cообщить модератору

415. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Аноним (-), 09-Авг-11, 09:23 
>  А кому и при каких обстоятельствах вообще пришло в голову
> брать данные со смонтированной ФС мимо реализации этой самой ФС, обслуживающей
> mountpoint -- даже узнавать неохота.

во freebsd: man dump на предмет ключика -L.

Ответить | Правка | К родителю #287 | Наверх | Cообщить модератору

174. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Сама Доброта (?), 08-Авг-11, 17:16 
>более вменяемый шейпер
> (dummynet) чем любой из тех что пробовал в линухе, удобство пересборки
> ядра под свои нужды.

ipfw & dummynet есть на linux.

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

193. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Аноним (-), 08-Авг-11, 18:32 
>более вменяемый шейпер (dummynet) чем любой из тех что пробовал в линухе

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

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

289. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Michael Shigorinemail (ok), 08-Авг-11, 23:47 
>>более вменяемый шейпер (dummynet) чем любой из тех что пробовал в линухе
> Если вы думаете, что в линуксе несколько шейперов

Даже я строил cbq и htb, а это разные шейперы (строго говоря, queue disciplines, но по сути именно то, что определяет поведение).

> то вы явно никогда не имели дело с шейпингом трафика в линуксе.

Напрашивается нескромный встречный вопрос.

PS: а ещё лучше бы всё-таки помочь мужукам по теме, если это в принципе возможно.

Ответить | Правка | Наверх | Cообщить модератору

151. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Ян Злобинemail (ok), 08-Авг-11, 16:01 
> ...не каждый сдюжит сидеть пару часов обновляя зависимости...

Прям сидеть?  Этот процесс неплохо идёт параллельно и на боевой машине.  Всегда так делаю.  Просто не надо доводить процесс обновления до абсурда - обновляться по три раза в неделю.

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

894. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Аноним (-), 12-Авг-11, 19:05 
> до абсурда - обновляться по три раза в неделю.

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

Ответить | Правка | Наверх | Cообщить модератору

910. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Аноним (-), 12-Авг-11, 19:55 
>> до абсурда - обновляться по три раза в неделю.
> А хакеры, типа, будут вас месяц ждать "в случае чего"? Ну да,
> размечтались.

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

Ответить | Правка | Наверх | Cообщить модератору

913. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Аноним (-), 12-Авг-11, 20:17 
> дыры то тут, то там...

Баги есть в любых системах. Потому что людям свойственно ошибаться. Вы хотите сказать что в фряхе дыр не бывает в софте? Так это заведомо будет наглым враньем. В системе такого масштаба не может не быть багов.

Ответить | Правка | Наверх | Cообщить модератору

941. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Аноним (-), 14-Авг-11, 10:51 
>> дыры то тут, то там...
> Баги есть в любых системах. Потому что людям свойственно ошибаться. Вы хотите
> сказать что в фряхе дыр не бывает в софте? Так это
> заведомо будет наглым враньем. В системе такого масштаба не может не
> быть багов.

Сравните кол-во секьюр фиксов тут и там и поймете о чем речь.

Ответить | Правка | Наверх | Cообщить модератору

935. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Ян Злобинemail (ok), 13-Авг-11, 08:46 
> А хакеры, типа, будут вас месяц ждать "в случае чего"? Ну да,
> размечтались.

Обновляйтесь хоть каждый день, если так хочется - обновления-то выходят чаще.

Ответить | Правка | К родителю #894 | Наверх | Cообщить модератору

156. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Аноним (-), 08-Авг-11, 16:20 
Я бы рекомендовал тяжелые вещи таки тягать через pkg_add -r
удобнее и без головной боли.
Давно не встречался с какими либо проблемами при таком подходе (правда тягать на чистую систему).
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

241. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от iZEN (ok), 08-Авг-11, 21:08 
> проблема обновления в freebsd многих отпугивает, не каждый сдюжит сидеть пару часов
> обновляя зависимости

О каких "обновлениях зависимостей" идёт речь?

> тем более на боевом сервере

Вы что, на боевом сервере пакеты собираете из портов? А заранее собранные пакеты для обновления вы не можете подсунуть?

Дарю волшебную строчку из man portupgrade:
% env PKG_PATH=/path/to/mntnfsrepo/packages/All portupgrade -aPP

> а в случае всяких
> кед и опенофис так вообще обновления затягивается на сутки на рабочих
> станциях

KDE4 ВСЯ собирается из исходников на полудохлом 4x феномчике за 12 часов. OOo 3.2 — за 4 часа.

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

Конечно нет — онлайновые снапшоты ФС рулят. В Linux до сих пор мучаются, что у них нет этого.

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

291. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +1 +/
Сообщение от Michael Shigorinemail (ok), 08-Авг-11, 23:51 
>> а в случае всяких кед и опенофис так вообще обновления затягивается на сутки на
>> рабочих станциях
> KDE4 ВСЯ собирается из исходников на полудохлом 4x феномчике за 12 часов.
> OOo 3.2 — за 4 часа.

Надо на фряшников и гентушников натравить гринписятников.  И залечь за бруствер.

>> за то проблемы бекапа и переноса сервера с одной железки на другую вообще нет
> Конечно нет — онлайновые снапшоты ФС рулят. В Linux до сих пор
> мучаются, что у них нет этого.

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

Изен Петросян, однако.

Ответить | Правка | Наверх | Cообщить модератору

389. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от анон (?), 09-Авг-11, 07:53 
> - есть проблемы переноса сервера по железкам, когда он разложен по контейнерам.

Перенос снимков ФС реализован "изящно" - через виртуализацию.

Ответить | Правка | Наверх | Cообщить модератору

895. "Опубликован анализ ключевых проблем FreeBSD и начат сбор пре..."  +/
Сообщение от Аноним (-), 12-Авг-11, 19:08 
> KDE4 ВСЯ собирается из исходников на полудохлом 4x феномчике за 12 часов.
> OOo 3.2 — за 4 часа.

А я как полный козел за 7 минут кде из пакетов установил. Что, всего в 102 раза быстрее? oO

Ответить | Правка | К родителю #241 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру