The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

Принято решение об официальной поддержке архитектуры kFreeBS..., opennews (ok), 08-Окт-09, (0) [смотреть все]

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


95. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +1 +/–
Сообщение от aZ (ok), 09-Окт-09, 13:54 
"Осиливать" в то там нечего, просто неудобное громоздкое говно.
Ответить | Правка | Наверх | Cообщить модератору

97. "Принято решение об официальной поддержке архитектуры kFreeBS..."  –2 +/–
Сообщение от www2email (ok), 09-Окт-09, 14:24 
>"Осиливать" в то там нечего, просто неудобное громоздкое говно.

ifupdown - это network manager. Прописал настройки в /etc/network/interfaces, добавил по вкусу в /etc/network/ip-[up|down].d/ скрипты, которые нужно выполнить при поднятии интерфейса (или повесил команду на pre-up, post-up, pre-down, post-down), сделал ifup интерфейс и всё заработало. Сделал ifdown - и всё связанное с этим интерфейсом удаляется (в том числе, например фаерволльные правила, таблицы маршрутов, демоны).

А во фре слабо то же самое сделать, чтобы при поднятии/опускании интерфейса выполнялась куча связанных операций? Костыли devd не предлагать - это не сетевой менеджер, этак и в Debian можно всё сделать средствами udevd.

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

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

99. "Принято решение об официальной поддержке архитектуры kFreeBS..."  –1 +/–
Сообщение от aZ (ok), 09-Окт-09, 14:48 
ifupdown и есть ваш велосипед на костылях. Чем он отличается от самописных скриптов? Его кто-то не писал, он "автописный" или как? Какие конкретные преимущества помимо встроенной кофеварки? Если через devd/udevd можно это делать, то на кой чёрт писать велосипед? Ничего дебильного как ваш арп-пинг или тоже запоминание названия интерфейса по мак адресу я ещё не видел. Это уже прямо винда - засирать в /etc (!) автоматом какое-то дерьмо типа "очень нужной штуки" - параметры сетевой карты.

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

Но просто даже в жизни, банально - прописать альясы на интерфейс в /etc/network/interfaces - это уж извините, придумать такой убогий синтаксис нужно ещё постараться.

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

102. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от ram_scan (?), 09-Окт-09, 15:19 
А чем там убогий синтаксис ?

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

А то я помню, как когда был еще молодой, зеленый, и еще не носил очков, прописал в красношляпе еще тогда создание виланов по "фряховски", в скрипте. Как какое-то писание нагугленое велело. И грохнулось все мое творчество после автообновления какой-то сетевой приблуды, которая rc.network фикшеный подложила, уж не вспомню какой, вместе с виланами.

С той поры я в гробу видел хоть одну букву в системных скриптах исправлять.

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

103. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от aZ (ok), 09-Окт-09, 15:38 
Прописывать альясы убого. :)

"Кайф" в дебияне относителен. Лично когда я работал (в принципе и сейчас работаю, ставлю на очень дешёвые, не важные сервера, где хостер не хочет ставить фрибсд) с дебияном меня бесили автоматические скрипты после установки/обновления софта. Вот на кой чёрт запускается тот же апачь или нгингс сразу после установки? Неужели разработчики действительно думают, что нормальный человек будет использовать то, как оно по дефолту настроено? Или вот почтовик был на цирусе.. ну и после обновления цируса оно почему-то решает сделать chown на все файлы почтовой базы, а то что база там на десятки гигабайт и пока оно раздаст уже разданные права пройдёт не один час, а почтовик "вежливо" остановлен - разработчикам такого "умного" скрипта в голову не пришло.

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

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

104. "Принято решение об официальной поддержке архитектуры kFreeBS..."  –1 +/–
Сообщение от www2email (ok), 09-Окт-09, 15:50 
>ifupdown и есть ваш велосипед на костылях. Чем он отличается от самописных
>скриптов?

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

>Его кто-то не писал, он "автописный" или как? Какие конкретные
>преимущества помимо встроенной кофеварки? Если через devd/udevd можно это делать, то
>на кой чёрт писать велосипед?

На кой чёрт /etc/rc.conf, если настройки можно делать скриптами в /etc/rc.local? Аналогия ясна?

>Ничего дебильного как ваш арп-пинг или
>тоже запоминание названия интерфейса по мак адресу я ещё не видел.

А ничего дебильнее прыгающей нумерации сетевушек в вашей фре я не видел. Стоят три сетевушки одинаковой модели: rl0, rl1, rl2. Вынимаем вторую, вставляем ещё одну, но другой модели и что мы видим? rl0, rl1, xl0. Вперед, переписывать в трёхстах местах название интерфейса. Или алиасики на сетевушки припедаливать через devd.

>Это уже прямо винда - засирать в /etc (!) автоматом какое-то
>дерьмо типа "очень нужной штуки" - параметры сетевой карты.

Если переместить настройки udev в /var, как это сделано в RedHat, ты успокоишься?

>Для каждой сети я единоразово пишу скриптики с добавлением адреса на интерфейс,
>роутинга или же просто запускаю дшсц-клиента если не знаю настройки сети.

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

>Трудно сообразить тебе в какой же ты сети? Дома, в офисе
>или в кафе?

Пришёл из офиса в кафе, заюзал su, и давай редактировать udev и самописные скриптики?

>Но просто даже в жизни, банально - прописать альясы на интерфейс в
>/etc/network/interfaces - это уж извините, придумать такой убогий синтаксис нужно ещё
>постараться.

Ты про это?

auto eth2:0
iface eth2:0 inet static
        address 10.3.17.1
        netmask 255.255.255.0

Это убогий синтаксис? Да, конечно ifconfig_rl0_alias0="inet 10.3.17.1/24" гораздо лучше. А если так:

auto eth2:0
iface eth2:0 inet static
        address 10.3.17.1
        netmask 255.255.255.0
        up echo "eth2:0 up" > /root/log
        down echo "eth2:0 down" > /root/log

То ты уже полез в дебри devd.

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

108. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от aZ (ok), 09-Окт-09, 16:22 
> На кой чёрт /etc/rc.conf, если настройки можно делать скриптами в /etc/rc.local? Аналогия ясна?

На то, чтот там запускаются уже готовые скрипты, а rc.local то что нет в скриптах, всё просто и логично.

Нумерация сетевух не прыгает. Она логично раставляется чем мне и нравится. Более того - сменив сетевуху в дебияне - сменится и интерфейс, а вы поди не знали? Причём сменится автоматом каждый раз при новой сетевухе и вот тут уж менять правила или прыгать с бубном вокруг этого автоматического определения новой сетевухи и ручками править имя интерфейса.

> Если переместить настройки udev в /var, как это сделано в RedHat, ты успокоишься?

Успокоюсь когда на кернел.орг сделают rm -rf /

> На каждый случай свой велосипедный скриптик.

Чем плохо? Оно работает и отлично, чем "универсальные" которые работают через раз и не так как хочется.

> Пришёл из офиса в кафе, заюзал su, и давай редактировать udev и самописные скриптики?

Ну если вам делать нечего - можете этим заниматься. А я просто запускаю /root/bin/network-home, /root/bin/network-office /root/bin/network-имя_кафе, очень просто.


> Ты про это?

Да, про это. А то что показал дальше - я ни в одном страшном сне даже делать не буду. Просто в 99.9% это не нужно. Хотя что вам говорить, вы же не знаете что фря по дефолту логирует поднятие интерфейса в /var/log/messages

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

114. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от www2email (??), 09-Окт-09, 17:08 
>> На кой чёрт /etc/rc.conf, если настройки можно делать скриптами в /etc/rc.local? Аналогия ясна?
>
>На то, чтот там запускаются уже готовые скрипты, а rc.local то что
>нет в скриптах, всё просто и логично.

Ну так и ifupdown - тоже готовый скрипт, а всё, чего в нём нет, помещается в /etc/network/ip-[up|down].d, "всё просто и логично".

>Нумерация сетевух не прыгает. Она логично раставляется чем мне и нравится. Более
>того - сменив сетевуху в дебияне - сменится и интерфейс, а
>вы поди не знали? Причём сменится автоматом каждый раз при новой
>сетевухе и вот тут уж менять правила или прыгать с бубном
>вокруг этого автоматического определения новой сетевухи и ручками править имя интерфейса.

Да, поменять привязку названия интерфейса к мак-адресу в конфиге udev - для вас непосильная задача.

>> Если переместить настройки udev в /var, как это сделано в RedHat, ты успокоишься?
>
>Успокоюсь когда на кернел.орг сделают rm -rf /

В таком случае ПНХ, дальше разговаривать с тобой не о чем.

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

Рассказывай давай. Ты же и про пакет resolvconf поди тоже не знаешь.

auto eth0
iface eth0 inet static
        address 10.0.0.1
        netmask 255.255.255.252
        dns-nameservers 10.2.0.1 10.3.0.1

auto eth1
iface eth1 inet dhcp

auto provider
iface bis inet ppp
        provider provider

А теперь внимание, вопрос. Как ты своими велосипедными скриптами будешь изменять содержимое файла /etc/resolv.conf, да ещё чтобы учитывались приоритеты DNS-серверов в таком порядке eth1, eth0, provider (прописываются через /etc/resolvconf/interface-order), да ещё чтобы об изменении файла /etc/resolv.conf узнавали squid и named (при этом named чтобы делал форвардинг DNS-запросов на этот список именно в указанном порядке). Время пошло.

>> Пришёл из офиса в кафе, заюзал su, и давай редактировать udev и самописные скриптики?
>
>Ну если вам делать нечего - можете этим заниматься. А я просто
>запускаю /root/bin/network-home, /root/bin/network-office /root/bin/network-имя_кафе, очень просто.

Что делать мне?
0. Один раз настроил
1. Пришёл в кафе - заработал инет,
2. Пришёл на работу - заработал инет,
3. Пришёл домой - заработал инет,
4. Повторил по желанию любой из пунктов 1, 2, 3 сколько угодно раз и в любой последовательности,
5. ...
6. PROFIT!

>> Ты про это?
>
>Да, про это. А то что показал дальше - я ни в
>одном страшном сне даже делать не буду. Просто в 99.9% это
>не нужно. Хотя что вам говорить, вы же не знаете что
>фря по дефолту логирует поднятие интерфейса в /var/log/messages

HINT: В правилах up и down может стоять любая команда, а в каталогах /etc/network/if-[up|down].d/ может лежать любой скрипт. А заготовки вроде "dns-nameservers 10.2.0.1 10.3.0.1" позволяют иногда и вовсе обойтись без велосипедных скриптов с ручным приводом и при этом добиваться очень сложного поведения системы.

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

118. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от aZ (ok), 09-Окт-09, 17:50 
Ты чудик. Ты придумываешь решение проблем которые не существуют. Более того, очень я сомневаюсь что твои супер скрипты автоматом цепляют вайфай в моменты когда оно нужно. Или ты в кафешке заказываешь кофе с кабелем? Или какую-то софтину для инвалидов запускаешь? В ней то поди что-то ищешь и потом "кликаешь" что-то чтобы законнектиться. Да уж, элегантное решение, лучше чем запустить уже подготовленную для этого команду.

P.S. днс я использую свой и в /etc/resolv.conf у меня прописан 127.0.0.1, доверять чёрти каким серверам у меня никогда не было желания, а также из-за специфики моей работы мне не нужен чужой кеш запросов.

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

123. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от www2email (ok), 09-Окт-09, 18:12 
>P.S. днс я использую свой и в /etc/resolv.conf у меня прописан 127.0.0.1,
>доверять чёрти каким серверам у меня никогда не было желания, а
>также из-за специфики моей работы мне не нужен чужой кеш запросов.

Ты ещё скажи что сам начиная с корневиков DNS-запросы решаешь. Короче всё ясно - "у меня есть всё, что нужно, а чего нет - то и не нужно".


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

135. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +1 +/–
Сообщение от QuAzI (ok), 10-Окт-09, 23:06 
>>P.S. днс я использую свой и в /etc/resolv.conf у меня прописан 127.0.0.1,
>>доверять чёрти каким серверам у меня никогда не было желания, а
>>также из-за специфики моей работы мне не нужен чужой кеш запросов.
>
>Ты ещё скажи что сам начиная с корневиков DNS-запросы решаешь. Короче всё
>ясно - "у меня есть всё, что нужно, а чего нет
>- то и не нужно".

Я что-то не понял в чём проблема. Вы вдвоём какую-то проблему из пальца высосали и со смаком обсасываете. Выбрал себе два-три DNS-сервера, которые нормально работают, прописал их адреса однажды и забыл о ваших проблемах. И они у меня работают не зависимо от того, использую я беспарольный dialup, ADSL, точку wifi в кафешке или gprs - ОНИ ВСЕГДА ДОСТУПНЫ в инете.
Более того, в своё время у провайдера работали какие-то укурки, благодаря которым адреса DNS-серверов выдавались через раз и чтобы нормально сёрфить по инету приходилось их прописывать их статично на любых ОС. Благодаря этим укуркам я на память помню два DNS-сервера - для работы хватает, доступны всегда, работают отовсюду, где есть доступ в интернет. Где доступа по дефолту нет (домосеть и рабочая локалка) - DHCP умные люди придумали ДАВНО.
Лениво мне ещё какие-то ваши настройки, скрипты ковырять... стар я уже для этого =)

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

211. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от Дмитрий Ю. Карпов (?), 23-Окт-09, 11:52 
> Ты ещё скажи что сам начиная с корневиков DNS-запросы решаешь.

Он вообще держит у себя копию содержимого корневой зоны.

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

213. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от Аноним (-), 23-Окт-09, 14:13 
>> Ты ещё скажи что сам начиная с корневиков DNS-запросы решаешь.
>
>Он вообще держит у себя копию содержимого корневой зоны.

Да, но он забывает про домены второго, третьего и т.д. уровней. Кажется я начинаю догадываться, что может означать фраза "скачать весь интернет".

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

215. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от PereresusNeVlezaetBuggyemail (ok), 23-Окт-09, 14:17 
>>> Ты ещё скажи что сам начиная с корневиков DNS-запросы решаешь.
>>
>>Он вообще держит у себя копию содержимого корневой зоны.
>
>Да, но он забывает про домены второго, третьего и т.д. уровней. Кажется
>я начинаю догадываться, что может означать фраза "скачать весь интернет".

А помните лет восемь (?) назад был большооой DDoS корневых серверов? Теперь мы знаем виновника!

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

120. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от аноним (?), 09-Окт-09, 18:01 
Вы ниже очень хороший термин употребили - `восторженный хомячок'. По этому сообщению он вам на 100% соответствует, между тем FreeBSD позволяет делать все абсолютно то же самое.

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

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

124. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от www2email (ok), 09-Окт-09, 18:14 
>Вы ниже очень хороший термин употребили - `восторженный хомячок'. По этому сообщению
>он вам на 100% соответствует, между тем FreeBSD позволяет делать все
>абсолютно то же самое.

Только кучей велосипедных скриптов, уже знаем.

>Хотя я лично не понимаю зачем все это надо, у меня на
>ноуте прописано ifconfig_xxx=DHCP, и с этим у меня работает сеть без
>каких-либо телодвижений, как дома по проводу, так и где угодно по
>wifi.

То, что у вас чего-то там работает - ни разу не показатель. Продолжая мысль, "А меня всё есть. А чего нет - то не нужно." Мне нужно, а у вас нет. Или есть, но надо писать скрипты. Как быть? Это преимущество?

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

129. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +1 +/–
Сообщение от iZEN (ok), 09-Окт-09, 21:40 
>>Вы ниже очень хороший термин употребили - `восторженный хомячок'. По этому сообщению
>>он вам на 100% соответствует, между тем FreeBSD позволяет делать все
>>абсолютно то же самое.
>
>Только кучей велосипедных скриптов, уже знаем.

Какие такие "велосипедные скрипты" в FreeBSD?

Новые hot-plug(!) интерфейсы поднимаются devd: при втыкании-вытыкании USB-адаптера, при втыкании-вытыкании Ethernet-кабеля выполняется определённый "велосипедный скрипт", если он(внимание!) специально ОЧУМЕЛЫМИ_РУКАМИ прописан в /etc/devd.conf. А если скрипт не прописан (что естественно на незамусоренной системе), то и подниматься нечему при хот-плаге какой-то железки.
Все остальные интерфейсы жёстко прописываются в /etc/rc.conf и получают настройки при старте системы или же во время её работы (DHCP).

Ещё тут нафантазировал о смене адресации сетевушек при выдёргивании одной из них -- бред. Если есть несколько однотипных сетевух, использующих один драйвер, то в /etc/rc.conf их интерфейсы привязывают к MAC-адресам и они уже никак не перепутываются.

"eth0".."eth6" в Linux перепутываются постоянно даже с разными карточками, использующими разные драйвера -- для FreeBSD такой случай исключён из практики правильной АРХИТЕКТУРОЙ.

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

152. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от Денис Юсуповemail (?), 12-Окт-09, 17:05 
> в /etc/rc.conf их интерфейсы привязывают к MAC-адресам

Это где/как там такое?

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

177. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от sHaggY_caT (ok), 17-Окт-09, 20:17 
>"eth0".."eth6" в Linux перепутываются постоянно даже с разными карточками, использующими >разные драйвера -- для FreeBSD такой случай исключён из практики правильной АРХИТЕКТУРОЙ.

Это называется "ниасилить" :))) И это как раз про упоминавшихся уже хомячков :)
В тех же RH-системах в /etc/sysconfig/network-scripts/ifcfg-бла-бла есть опция HWADDR, которая по-дефольту верно выставляется Анакондой.

Встречный вопрос фряховодам: fstab(5) Linux,  

=============================================
       Instead  of  giving  the  device explicitly, one may indicate the (ext2 or xfs) filesystem that is to be mounted by its
       UUID or volume label (cf.  e2label(8) or xfs_admin(8)), writing LABEL=<label> or  UUID=<uuid>,  e.g.,  ‘LABEL=Boot’  or
       ‘UUID=3e6be9de-8139-11d1-9106-a43f08d823a6’.   This  will  make  the system more robust: adding or removing a SCSI disk
       changes the disk device name but not the filesystem volume label.
============================================

туда же можно писать девайсы lvm и md, которые сами (by design) нормально привязываются к железкам

fstab freebsd (тоже 5), где там хоть что-то аналогичное? Может быть, я не замечаю? Да, девайсы геома привязываются нормально, но вот с одиночными дисками, и, особенно, с LUN аппаратных контроллеров, это _проблема_

Вопрос не праздный, и, хотя и с подколкой, ответ мне очень интересен, я бы хотела оказаться не правой и чего-то не осилевшей, так как приходится работать со фрей, но пока недостатки by design по нумерованию железок, простите, вижу не у Linux'а

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

178. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от Bulgarin (ok), 18-Окт-09, 01:55 
>>"eth0".."eth6" в Linux перепутываются постоянно даже с разными карточками, использующими >разные драйвера -- для FreeBSD такой случай исключён из практики правильной АРХИТЕКТУРОЙ.
>
>Это называется "ниасилить" :))) И это как раз про упоминавшихся уже хомячков
>:)
>В тех же RH-системах в /etc/sysconfig/network-scripts/ifcfg-бла-бла есть опция HWADDR, которая по-дефольту верно
>выставляется Анакондой.

Товарищъ имел ввиду, что индексы к сетевым интерфесам вычисляются последовательно +1 c нуля, по мере обхода всего дерева шин-устройств c dev_probe()/dev_attach().

pcib1@pci0:1:0: class=0x060400 card=0x00008086 chip=0x29f18086 rev=0x01 hdr=0x01
pcib2@pci0:6:0: class=0x060400 card=0x00008086 chip=0x29f98086 rev=0x01 hdr=0x01
pcib3@pci0:28:0:        class=0x060400 card=0x00000000 chip=0x29408086 rev=0x02 hdr=0x01
pcib5@pci0:28:2:        class=0x060400 card=0x00000000 chip=0x29448086 rev=0x02 hdr=0x01
pcib6@pci0:28:3:        class=0x060400 card=0x00000000 chip=0x29468086 rev=0x02 hdr=0x01
pcib7@pci0:28:4:        class=0x060400 card=0x00000000 chip=0x29488086 rev=0x02 hdr=0x01
pcib8@pci0:28:5:        class=0x060400 card=0x00000000 chip=0x294a8086 rev=0x02 hdr=0x01
...
uhci0@pci0:29:0:        class=0x0c0300 card=0x31fe103c chip=0x29348086 rev=0x02 hdr=0x00
uhci1@pci0:29:1:        class=0x0c0300 card=0x31fe103c chip=0x29358086 rev=0x02 hdr=0x00
uhci2@pci0:29:2:        class=0x0c0300 card=0x31fe103c chip=0x29368086 rev=0x02 hdr=0x00
uhci3@pci0:29:3:        class=0x0c0300 card=0x31fe103c chip=0x29398086 rev=0x02 hdr=0x00
..
bge0@pci3:4:0:  class=0x020000 card=0x703e103c chip=0x167814e4 rev=0xa3 hdr=0x00
bge1@pci3:4:1:  class=0x020000 card=0x703e103c chip=0x167814e4 rev=0xa3 hdr=0x00

Это универсальная логика для всех устройств, и для понимания просто где какой интерфейс нужно знать имя класса устройства, и его порядок данных устройств на шине при опросе.
Для PCI это по степени удаления слота от моста.
Добавил карту такого же класса на ту же шину перед существующей - подумай, сдвинь индекс +1 в настройках.
Автомагичность по hw-адресам - нафик-нафик... От лукавого это, лишнее. Змеи еще какие-то, анаконды...

Шинно-классово-древовидную топологию устройств придумали давно, если не изменяет память еще в Беркли в 80-x, писатели Linux kernel таки решили толи выпендрится, то ли от великого ума, и сделали именование network interfaces гм... другим.

>Встречный вопрос фряховодам: fstab(5) Linux,

Гм... После "фряховодам" отвечать не хочется... :|
Ответил - значит "фряховод" :) Хотя такой зоопарк иной раз в проекте бывал...

>Вопрос не праздный, и, хотя и с подколкой, ответ мне очень интересен,
>я бы хотела оказаться не правой и чего-то не осилевшей, так
>как приходится работать со фрей, но пока недостатки by design по
>нумерованию железок, простите, вижу не у Linux'а

Таки тебе недостатки искать, или работать? :)

# man glabel
...
     This class also provides volume label detection for file systems.  Those
     labels cannot be set with glabel, but must be set with the appropriate
     file system utility, e.g. for UFS the file system label is set with
     tunefs(8).  Currently supported file systems are:
           ·   UFS1 volume names (directory /dev/ufs/).
           ·   UFS2 volume names (directory /dev/ufs/).
           ·   UFS1 file system IDs (directory /dev/ufsid/).
           ·   UFS2 file system IDs (directory /dev/ufsid/).
           ·   MSDOSFS (FAT12, FAT16, FAT32) (directory /dev/msdosfs/).
           ·   CD ISO9660 (directory /dev/iso9660/).
           ·   EXT2FS (directory /dev/ext2fs/).
           ·   REISERFS (directory /dev/reiserfs/).
           ·   NTFS (directory /dev/ntfs/).
     Support for partition metadata is implemented for:
           ·   GPT labels (directory /dev/gpt/).
           ·   GPT UUIDs (directory /dev/gptid/).
     Generic labels are created in the directory /dev/label/.
...

Собственно, этого более чем хватает что бы "пилевать" на шинную адресацию, SCSI LUN, ATA CH, USB ADDR, ... Опознание-отображение делается по все иерархии GEOM.
Указание корня при загрузке в соотв. glabel так же возможно, man loader. Естественно, даже если корень на другом физическом диске относительно загрузчика и считанного в память ядра.


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

179. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от Bulgarin (ok), 18-Окт-09, 02:10 
>>>"eth0".."eth6" в Linux перепутываются постоянно даже с разными карточками, использующими >разные драйвера -- для FreeBSD такой случай исключён из практики правильной АРХИТЕКТУРОЙ.
>>
>>Это называется "ниасилить" :))) И это как раз про упоминавшихся уже хомячков
>>:)
>Собственно, этого более чем хватает что бы "пилевать" на шинную адресацию, SCSI
>LUN, ATA CH, USB ADDR, ... Опознание-отображение делается по все иерархии
>GEOM.
>Указание корня при загрузке в соотв. glabel так же возможно, man loader.
>Естественно, даже если корень на другом физическом диске относительно загрузчика и
>считанного в память ядра.

И вдогонку - если сделаешь FS whole disk
# newfs -L suberlabel /dev/ad2
то этикетка диска также будет опознана

Можно придумывать даже странные топологии (не пробовал :) ), типа UFS in BSD slice in MBR in GPT - и этикетка также будет опознана, даже если ты выставишь тип раздела для UFS вместо 165 - 6, MSDOS.

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

180. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от Bulgarin (ok), 18-Окт-09, 15:07 

>Шинно-классово-древовидную топологию устройств придумали давно, если не изменяет память еще в Беркли
>в 80-x, писатели Linux kernel таки решили толи выпендрится, то ли
>от великого ума, и сделали именование network interfaces гм... другим.

"Тихо сам с собой я веду беседу". А там глядишь, кто и прочитает :)

Но самому захотелось освежить в памяти, и посмотрел код
- BSD 2.9..2.11 (~82-93гг,DEC PDP11),
- BSD4.2-4.4 (~82-94гг, DEC VAX) и
- Linux kernel 1.0...1.3 (~93-96гг,Intel i386).

Действительно, имена драйверов в его дескриптор struct somedev_softc{} были введены примерно в 83-84 году.
4.2BSD, фрагменты:
---
/*      if_en.c 6.1     83/07/29        */
#include "en.h"
/*
* Xerox prototype (3 Mb) Ethernet interface driver.
*/
struct uba_driver endriver =
        { enprobe, 0, enattach, 0, enstd, "en", eninfo };

struct  en_softc {
        struct  ifnet es_if;            /* network-visible interface */
        struct  ifuba es_ifuba;         /* UNIBUS resources */
        short   es_delay;               /* current output delay */
        short   es_mask;                /* mask for current output delay */
        short   es_lastx;               /* host last transmitted to */
        short   es_oactive;             /* is output active? */
        short   es_olen;                /* length of last output */
} en_softc[NEN];

enattach(ui)
        struct uba_device *ui;
{
        register struct en_softc *es = &en_softc[ui->ui_unit];
        es->es_if.if_unit = ui->ui_unit;
        es->es_if.if_name = "en";
        es->es_if.if_mtu = ENMTU;
        es->es_if.if_init = eninit;
        es->es_if.if_output = enoutput;
        es->es_if.if_ioctl = enioctl;
        es->es_if.if_reset = enreset;
        es->es_ifuba.ifu_flags = UBA_NEEDBDP | UBA_NEED16 | UBA_CANTWAIT;
#if defined(VAX750)
        /* don't chew up 750 bdp's */
        if (cpu == VAX_750 && ui->ui_unit > 0)
                es->es_ifuba.ifu_flags &= ~UBA_NEEDBDP;
#endif
        if_attach(&es->es_if);
}
---

Благодаря именованию появилась возможность собирать устойства c одним драйвером в субклассы вне зависимости от шинной топологии, и в дальнейшем - и вне зависимости от типа шины (1982-83гг и по настоящее время).
В Linux kernel 1.3 (~1996г) данное именование напрочь отсутствует.

Почему Торвальдс (или T&К?) в 93-94гг решил примитивно именовать сетевые интерфейсы в соотвествии с type of network frame of level 2 - аллах акбар, не знаю. Может просто потому что плохо знал-понимал основы сетевой коммуникации? :)

Теперь "linux-кульное поколение" говорит что это фича, и придумывает AI-костыли для обхода косяков непродуман... пардон - базарной архитектуры.

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

---

PS К вопросу об имени UNIX/BSD, репринт этикетки с ленты:
Back of tape:
        4.3 RENO        6250 VAX
        30 JUL 90        Distribution Master
Front of tape:
        4.3BSD-RENO Vax UNIX System 7/1/90
        7 files on tape
        1 bootstrap FS,  bs=1024
        2 mini root,  bs=10240
        3 root dump,  bs=10240
        4 /usr
        5 /usr/src
        6 /usr/src/sys
        7 /usr/src/contrib

На других аналогично, в 80-е писали просто - BSD lalala UNIX.

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

184. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от Аноним (-), 19-Окт-09, 13:03 
>>Шинно-классово-древовидную топологию устройств придумали давно, если не изменяет память еще в Беркли
>>в 80-x, писатели Linux kernel таки решили толи выпендрится, то ли
>>от великого ума, и сделали именование network interfaces гм... другим.

Каким другим? Если заглянуть в /sys/, то можно увидеть ту самую шинно-классово-древовидную топологию.

>Благодаря именованию появилась возможность собирать устойства c одним драйвером в субклассы вне
>зависимости от шинной топологии, и в дальнейшем - и вне зависимости
>от типа шины (1982-83гг и по настоящее время).

Какой в этом практический смысл? Сказать: "вот в линупсе - куйня, там все Ethernet-интерфейсы называются eth, а в бздях - круто, там всё по драйверам"?

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

>В Linux kernel 1.3 (~1996г) данное именование напрочь отсутствует.
>Почему Торвальдс (или T&К?) в 93-94гг решил примитивно именовать сетевые интерфейсы в
>соотвествии с type of network frame of level 2 - аллах
>акбар, не знаю. Может просто потому что плохо знал-понимал основы сетевой
>коммуникации? :)

Просто потому что пользователю накуй не сдалось знать, что за драйвер рулит устройством. Пользователь воткнул модем - появилось ppp, воткнул Ethernet-карточку - появилось eth, настроил SLIP или PLIP - появилось sl или plip, запустил программу, эмулирующую сетевой интерфейс - появилось tun или tap. Всё логично.

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

>Теперь "linux-кульное поколение" говорит что это фича, и придумывает AI-костыли для обхода
>косяков непродуман... пардон - базарной архитектуры.

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

>А модифицировать механизм ассоциации некому, и много зацепок вылезает, да и бардак
>в драйверах, там воистине китайская классификация - "животные делятся на шестиногих,
>драконов, летающих, принадлежащих Императору, ...".

Классифицировать можно по разным признакам. Одно и то же устройство может быть одновременно "летающим" и "принадлежащим Императору". А то, что они в Linux именно "делятся на" - это ваша буйная фантазия.

>Поверх это громоздится HAL, с ничем кроме Linux kernel нормально не работающая...

HAL вообще к Linux никаким боком не относится. Это продукт жизнедеятельности FreeDesktop.

Давайте уж не будет обвинять Linux во всех смертных грехах. В популярности HAL виноваты пользователи KDE, Gnome и прочих "интегрированных" с HAL'ом систем. Я HAL'ом в Linux не пользуюсь. Немного неудобно, поскольку проторенных дорожек тут похоже нет, но магистральная линия HAL мне претит.

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

201. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от Bulgarin (ok), 22-Окт-09, 13:05 
>>>Шинно-классово-древовидную топологию устройств придумали давно, если не изменяет память еще в Беркли
>>>в 80-x, писатели Linux kernel таки решили толи выпендрится, то ли
>>>от великого ума, и сделали именование network interfaces гм... другим.
>
>Каким другим? Если заглянуть в /sys/, то можно увидеть ту самую шинно-классово-древовидную топологию.

Начало шинной организации уже хорошо прослеживается в Unix V7 (1979г), и четко прописано в Беркелейских BSD UNIX (1982г и далее).

Но писал именно о именах собственных интерфейсов.

struct dev_softc {} в BSD 1983 г. уже содержит поле собственного имени драйвера, в Linux kernel 1996г. его нет, нет и по сей день.

>>Благодаря именованию появилась возможность собирать устойства c одним драйвером в субклассы вне
>>зависимости от шинной топологии, и в дальнейшем - и вне зависимости
>>от типа шины (1982-83гг и по настоящее время).
>
>Какой в этом практический смысл? Сказать: "вот в линупсе - куйня, там
>все Ethernet-интерфейсы называются eth, а в бздях - круто, там всё
>по драйверам"?

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

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

/boot/kernel/if_ae.ko
/usr/src/sys/dev/ae/if_ae.c
# ifconfig ae0
ae0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500

# devinfo -v | grep ae
            ae0 pnpinfo vendor=0x1969 device=0x2048 subvendor=0x1043 subdevice=0x8233
                class=0x020000 at slot=0 function=0

# pciconf -l | grep ae
ae0@pci0:3:0:0:    class=0x020000 card=0x82331043 chip=0x20481969 rev=0xa0 hdr=0x00

Что мы имеем в Linux kernel device/net, начиная с 90-х?
Относительно "причесанности" BSD это выглядит как свалка разностильного кода, слегка упорядоченная.

И это не повод для "криков" "linux дерьмо, bsd рулит". Просто немного труднее разобратся в системе при необходимости, добавить код или поправить. Драйвера сразу из воздуха же не появляются?

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

Так можно и новую систему написать. А че - барабан на шею... :)
200 тыс строк для начала, потом добъем остальные...

>Просто потому что пользователю накуй не сдалось знать, что за драйвер рулит
>устройством. Пользователь воткнул модем - появилось ppp, воткнул Ethernet-карточку - появилось
>eth, настроил SLIP или PLIP - появилось sl или plip, запустил
>программу, эмулирующую сетевой интерфейс - появилось tun или tap. Всё логично.

Простая якутская логика. Вот Солнце, вот море, вот снег...

Пользователь воткнул модем? И появилось... что?
Потому что модем как бы в самом низу DSL протоколы, а выше него ATM (если ADSL, или HDLC какой-нить), а выше либо с PPP, либо Eth, либо PPPoEth. Так как нам именовать интефейс, таки dsl, atm, ppp или eth?

Пользователь воткнул другой модем... Теперь как именовать - ppp или gprs, или edgi?

А тут был создан туннель - интерфейс как назвать, gre или ipip?

Опять включаем простую якутскую логику? :)

Когда в 90-х код linux ядра писался, да и по сей день, о пользователях кто-то думает? :)
Не смешите мои тапочки. Если бы не получал/скачивал linux-рассылки в оригинале, то еще бы может и поверил. Там сплошной жастофан товарищей.
И не товарищи из RedHat, не Caldera, ни все остальные особо переписывать ничего не собирались. Просто юзают жаcтофан как есть.

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

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

Не, это ньюансы все конечно, но из них и складывается эволюция технической системы.

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

202. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от Аноним (-), 22-Окт-09, 13:45 
Так и вижу разгуливающего вправо-влево перед доской старого пердуна с лысиной и убранными за спину руками, который начитывает студентам лекции.

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

Вот Эндрю Танненбаум как мечтал о правильной архитектуре, так до сих пор и мечтает. На Minix 3 портированы SDL, браузер Dillo и OSS. Теперь на Minix 3 можно слушать "Hello, this is Linus Torvalds, and I pronounce Linux as Linux!", смотреть на интернет с квадратиками вместо непонятных браузеру букв и играть в Super Tux'а.

Вот Ричард Столлман мечтал о правильной архитектуре, начиная Hurd. Так и до сих пор не могут решиться, какая же архитектура более красива - по типу Mach-ядра или по типу L4-ядра. Подыхает перед выбором, как буриданов осёл.

Вот авторы Unix'а, Кен Томпсон, Деннис Ричи и свежая кровь Роб Пайк, которые наконец довели концепцию Unix до совершенства и сделали сначала Plan 9, а затем и Inferno.

Вот разработчики NetBSD и pkgsrc, портировать которые на новую процессорную архитектуру вместе со всеми дровами и программами - дело пары дней.

Вот Тео ДеРадт, со своей OpenBSD безопасной по самое не хочу и правильными инструментами вроде pf, openntpd, openbgpd и прочих.

Вот разработчики FreeBSD со своей правильной и красивой архитектурой в виде унифицированного CAM, GEOM и NetGraph, ZFS. И с правильно названными именами сетевых интерфейсов типа rl0, ae1 и прочими.

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

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

203. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от PereresusNeVlezaetBuggyemail (ok), 22-Окт-09, 13:58 
>Хорошая архитектура - вещь полезная, но Linux - это паровоз всего свободного
>ПО. Пока академики сравнивают стотысячную красивую архитектуру с каждой из предыдущих,
>дроча на какой-то один конкретный аспект красоты этой архитектуры, Linux пробует
>каждую архитектуру и уделяет меньшее, но более равномерное внимание всем аспектам
>красоты. Прыгает, спотыкается, встаёт, кружит на месте, набивает шишки, синяки и
>болячки, но всё равно идёт впереди остальных.

Вот именно поэтому Windows всё ещё самая популярная ОС, между прочим. Идёт впереди остальных. Хотя когда-то была всего лишь зачуханной оболочкой для DOS (да, да, я знаю, что NT — это совсем другая песня, но тогда об NT и речи не было), которая тоже прыгала, спотыкалась, но как-то работала. А потом всё-таки сдохла.

В самом Microsoft признают, что Windows через некоторое время умрёт. Но и Linux умрёт тоже. Где-то в течение 10 лет наступит время совсем других разработок, связанных, в том числе, и с представляющими ныне больше маркетинговый «пф-ф-ф» облаками. Google уже просёк тренд, Apple тоже. Microsoft, очевидно, тоже, но они темнят успешнее всех.

Так что все умрут, :) останутся лишь отточенные в «красивых проектах» идеи, которые и лягут в основу новых решений.

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

205. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от Bulgarin (ok), 22-Окт-09, 16:36 
>Хорошая архитектура - вещь полезная, но Linux - это паровоз всего свободного
>ПО. Пока академики сравнивают стотысячную красивую архитектуру с каждой из предыдущих,
>дроча на какой-то один конкретный аспект красоты этой архитектуры, Linux пробует

Mach2,3,4 - проекты дали жизнь многим идеям и разработкам, использованных в других системах. Wiki/Google. Если не ошибаюсь, nextStep был основан BSD4.4+Math3.
Проблема была вполне логически-техническая - чрезмерно высокие затраты на обработку сообщений между компонентами, IPC.
---
Пока писал с перерывами на работу :)
freebsd# grep -l 'Mach Operating System' /usr/src/sys/vm/*
/usr/src/sys/vm/pmap.h
/usr/src/sys/vm/vm_contig.c
/usr/src/sys/vm/vm_fault.c
/usr/src/sys/vm/vm_glue.c
/usr/src/sys/vm/vm_init.c
/usr/src/sys/vm/vm_kern.c
... Итого - 17 файлов из 44, значительная часть системы управления памятью.
---

Minix3 - совершенно новый проект. Ему по техническим меркам от году неделя. Показывает неплохие результаты, затраты на IPC намного меньше чем в Math - ~6% Minix3 и ~15-80% по разным инкарнациям Math, в сравнении с работой ~того же кода в ядерном режиме.
Не столь большая стоимость за устойчивость.

pf, bgpd, ipsec портированы из OpenBSD в другие системы. Действительно, компактный и устойчивый код.

ну и так далее...

Да, с помощью кода Linux kernel от рабатывается много идей, и хороших.
Но в чем проблема, причем корни ее уходят в саму идеологию разработки.
Fast & dirty. Сейчас работает - и ладно. И можно забыть. Нет вдумчивого пересмотра, нет вдумчивой идеологии с запасом на будущее.
Только появился LVM1 (только - по проектно-техническим меркам), как уже обкатывается LVM2, со структурой c LVM1 несовместимой.
Только-только устаканился Xen - все, извините, в новых ядрах его не будет. Наигрались, объявили устаревшей технологией.
И так далее...
Нет приемственности и переноса кода даже внутри проекта Linux kernel.
И очень плохие возможности переноса кода ядра в другие системы. Этого как бы и не предусматривается в техничеcкой постановке задач на компоненты. Есть только kernel, и все другое пусть идет лесом.

Большинство кода, составляющего дистрибутивы (приложения), с успехом может работать и с другим ядром.
И неисключено, что наступит момент, когда 350Mb+ кода ядра будет проще "покрасить и выбросить", чем использовать в новой инкарнации.
И очередное поколение будет говорить "Linux - старье, L'alix - это ново, это круто, вереди планеты всей".
Не исключено, что (а почему бы и нет?) этой основой станет тот же Minix3,4,5.

Распиаренный "паровоз" - это да.

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

206. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от sHaggY_caT (ok), 22-Окт-09, 18:02 
>Fast & dirty. Сейчас работает - и ладно. И можно забыть. Нет
>вдумчивого пересмотра, нет вдумчивой идеологии с запасом на будущее.
>Только появился LVM1 (только - по проектно-техническим меркам), как уже обкатывается LVM2,
>со структурой c LVM1 несовместимой.
>Только-только устаканился Xen - все, извините, в новых ядрах его не будет.
>Наигрались, объявили устаревшей технологией.
>И так далее...

Эта модель разработки не мешает промышленной эксплуатации :) старые RHEL3 и RHEL 4 будут поддерживаться еще несколько лет (при том, что RHEL 3 на 2.4 ядре!), в четвертый RHEL все еще добавляются новые фичи из последних ядер, а Xen будет поддерживаться (включая развитие функционала) как минимум до 2014.
Стоит разделять инновационный проект kernel.org, и тестовые дистрибутивы для гиков, и таки револиционного развития платформы, как Gentoo, Arch, Fedora, и то, что используется в промышленности (RHEL, SLE, Oracle Unbreakable Linux, даже Ubuntu LTS, хотя и с натяжкой)
В последних опробованная технология как раз используется годами :)

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

207. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от Bulgarin (ok), 22-Окт-09, 20:23 
>Эта модель разработки не мешает промышленной эксплуатации :) старые RHEL3 и RHEL
>4 будут поддерживаться еще несколько лет (при том, что RHEL 3

Промышленная эксплуатация в промышленности, давайте не будем путать
a) вспомогательные дата-центры, рабочие станции и
b) автоматизированные системы управления и контроля производственными линиями.  
Хранилище с бухгалтерскими данными - это еще не промышленность, хотя и очень важная задача :)
Шутка.

RH - коммерческое предприятие. Бизнес циничен. Бизнес-мэн заинтересовано в получении прибыли, и все его остальные действия вытекают из этого.
В развитие именно kernel RH, Ltd. заинтересовано ровно в той степени, насколько это будет приносить прибыль.
И если разработчики kernel вдруг решать объявить переход на что-то version Б, несовместимой с версией А, то это повод лишний раз для заработать, скажем, подписав на бинарные пакеты, или продавая иной свой сервис по своим маркетинговым каналам-сети.
По похожей схеме наше изменчивое законодательство дает возможность заработать
массе 1С-программистов.


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

И коммерческий саппорт RH нисколько не меняет ситуации с портативностью кода kernel в другие системы.

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

208. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от sHaggY_caT (ok), 23-Окт-09, 00:39 

>RH - коммерческое предприятие. Бизнес циничен. Бизнес-мэн заинтересовано в получении прибыли, и
>все его остальные действия вытекают из этого.
>В развитие именно kernel RH, Ltd. заинтересовано ровно в той степени, насколько
>это будет приносить прибыль.

Да, это именно так, но что это меняет?

>И если разработчики kernel вдруг решать объявить переход на что-то version Б,
>несовместимой с версией А, то это повод лишний раз для заработать,
>скажем, подписав на бинарные пакеты, или продавая иной свой сервис по
>своим маркетинговым каналам-сети.

Ну да, все-таки деньги управляют этим миром. Это может нравится, может не нравится, но это так.

>Впрочем, могу ошибатся, естественно. И RH занимается исключительно благотворительностью :)

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

>И коммерческий саппорт RH нисколько не меняет ситуации с портативностью кода kernel
>в другие системы.

А это нужно kernel.org? Если Вы внимательно посмотрите на список коммитеров в линуховое ядро, там сплошь корпорации и крупные конторы, индивидуальные разработчики, конечно, не в меньшинстве, но тон задают крупные компании. Только что в этом плохого? Тот же Yahoo! сделал очень и очень много хорошего для проекта FreeBSD.

Возможно, это эгоизм. Но GPL вообще эгоистическая лицензия, больше защищающая вендора, чем потребителя, может быть, это правильно, и более жизнеспособно?

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

209. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от Bulgarin (ok), 23-Окт-09, 10:05 
>не в меньшинстве, но тон задают крупные компании. Только что в
>этом плохого? Тот же Yahoo! сделал очень и очень много хорошего

Да, отчасти, думаю, вы конечно правы.
(Лирика за утренней чашкой чая, уж позвольте :) )

Немного присматриваюсь к эволюции технических систем, программные компоненты "живут" вообще без году неделя - 35-40 лет. Был нулевой период переключателей, был первый период RT11, RTRS, RSX, DOS, NetWare и прочих, теперь период UNIX&NT, далее дело (опять) идет к модульно-системно-распределенным системам локально, в одном шасси & стойке, кампусе & городе, ...

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

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

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

Про коммерческие тенденции молчу, там такой кавардак & бордель, бордель в квадрате :)

Поживем, увидим. Надеюсь, решающими будут все таки не "деньги" как общественная условность (и не жадность :) ), а таки _здравые_ чувства и намерения наиболее талантливых и деятельных из людей.

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

212. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от sHaggY_caT (ok), 23-Окт-09, 14:02 
>Kernel еще будет существовать долгое время, но эта программная архитетура быстро дошла
>до своего плато развития, и либо будет тщательно реинкарнирована - кодом
>и архитекурой кода, либо плавно уйдет за многие (и возможно, весьма-весьма
>многие) годы со сцены.
>
>Параллельно будет развиватся и эволюционировать неcколько BSD систем, мигрируя кодом между проектами,
>и интуитивно делаю вывод, не более, за этой мета-веткой большие перспективы.

Это уже вопрос религии :) Мне же, наоборот, кажется, что схема роста ради роста (революционного прогресса) стоит того, что бы ее сохранить.

Вопрос же приемственности кода, смерти FreeBSD, OpenBSD, NetBSD да и Linux в их нынешнем виде, конечно, лишь вопрос времени.
Что там будет в облаках за платформа, никто не знает...

>наиболее талантливых и деятельных из людей.

:) Или что бы чувства и желания наиболлее талантливых людей совпали с бизнес-устремлениями:))


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

204. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от Аноним (-), 22-Окт-09, 14:24 
>Пользователь воткнул модем? И появилось... что?
>Потому что модем как бы в самом низу DSL протоколы, а выше
>него ATM (если ADSL, или HDLC какой-нить), а выше либо с
>PPP, либо Eth, либо PPPoEth. Так как нам именовать интефейс, таки
>dsl, atm, ppp или eth?

По канальному уровню, доступ к которому предоставляет устройство, естественно. Если поверх Ethernet можно передавать IP-пакеты, это не значит что теперь сетевая карточка должна именоваться ip0. Из-за того, что все дружно забили на уровни модели OSI, чётко этот уровень бывает и не определить.

>Пользователь воткнул другой модем... Теперь как именовать - ppp или gprs, или
>edgi?

Точно так же - по канальному уровню, предоставляемому устройством компьютеру.

>А тут был создан туннель - интерфейс как назвать, gre или ipip?

В зависимости от того, какой это туннель.

>Опять включаем простую якутскую логику? :)

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

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

Как к этому относится вопрос именования интерфейса?

Если работаёт не так, как вами задумывалось, можете поменять название интерфейса на fuck0.

>Не, это ньюансы все конечно, но из них и складывается эволюция технической
>системы.

А Linux развивался не эволюционным, а революционным путём.

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

210. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от Bulgarin (ok), 23-Окт-09, 10:36 
>А Linux развивался не эволюционным, а революционным путём.

"Я плакалъ" :)

Все, ует, умыт и сражен. На этот аргумент сказать ответить нечего :)

"Долгих 15 лет изнурительной революции, в результате которых была получена совершенно уникальная и не имеющая аналогов кострукция велосипе... управления памятью, шинами, устройствами, процессами, файловые системы, набор системных вызовов, ... Именно благодаря этой революционной конструкции, написанной на уникальном языке SI, удалось применить ранее написанные GNU&PNU-утилиты, применит огромное число революционных проектов, таких как Imacs, Torzilla, Z11, lendmail, ..."

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

214. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от sHaggY_caT (ok), 23-Окт-09, 14:14 
>[оверквотинг удален]
>
>Все, ует, умыт и сражен. На этот аргумент сказать ответить нечего :)
>
>
>"Долгих 15 лет изнурительной революции, в результате которых была получена совершенно уникальная
>и не имеющая аналогов кострукция велосипе... управления памятью, шинами, устройствами, процессами,
>файловые системы, набор системных вызовов, ... Именно благодаря этой революционной конструкции,
>написанной на уникальном языке SI, удалось применить ранее написанные GNU&PNU-утилиты, применит
>огромное число революционных проектов, таких как Imacs, Torzilla, Z11, lendmail, ..."
>

Нет, "за долгие 15 лет эволюции" была создана платформа, которая с успехом заменила, в большинстве случаев, коммерческие UNIX'ы.
Где в BSD кластерные файловые системы? Где нормальные контейнеры (извините, но jails по сравнению с OVZ, тем более PVC, и даже с Solaris Zones выглядит просто неубедительно и смешно), где, в конце концов, нормальная тяжелая виртуализация?
Почему в качестве Dom0 все ведущие мировые вендоры используют Linux, а не NetBSD, в крайнем случае, Solaris? Где аналог своего гипервизора, как KVM Linux? Где прямая бинарная пакетная система?
Извините, но я вижу глобальное отставание BSD платформы, сейчас ощущается рывок (в семерке фрибсд появились некоторые вкусные вещи), но... как-то бесконечно далеко. Все новшества, это бэкпорт фич Solaris, в котором не смотря на явный застой развитие видно...

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

217. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от Bulgarin (ok), 23-Окт-09, 15:19 
>Нет, "за долгие 15 лет эволюции" была создана платформа, которая с успехом
>заменила, в большинстве случаев, коммерческие UNIX'ы.

Очень хорошо.

Меня просто порадовала фраза "Linux - революционная система" :)

Обсуждение с позиции "А где в системе Ъ возможность Тыдыц, А?!!! Почему не сделали?!!!", извините, считаю неконструктивным.
Займитесь и сделайте. Или бартером :)

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

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

218. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от iZEN (ok), 23-Окт-09, 18:25 
>Нет, "за долгие 15 лет эволюции" была создана платформа, которая с успехом
>заменила, в большинстве случаев, коммерческие UNIX'ы.
>Где в BSD кластерные файловые системы?

Известно где -- у проприетарщиков, которые код не дают, но используют FreeBSD. А что? Имеют право.

>Где нормальные контейнеры (извините, но jails
>по сравнению с OVZ, тем более PVC, и даже с Solaris
>Zones выглядит просто неубедительно и смешно),

O_o, а Solaris Zones уже научилось делать вложенные Zones, как это умеет jail2?

Чем OVZ лучше jail?

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

219. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от sHaggY_caT (ok), 23-Окт-09, 19:15 
>[оверквотинг удален]
>
>Известно где -- у проприетарщиков, которые код не дают, но используют FreeBSD.
>А что? Имеют право.

Где я могу купить FreeBSD с параллельной файловой системой с репликацией между нодами, как междельмашовская проприетарная GPFS? Так, что бы держала массивные load'ы?
Если нигде, то это просто слова)

>>Где нормальные контейнеры (извините, но jails
>>по сравнению с OVZ, тем более PVC, и даже с Solaris
>>Zones выглядит просто неубедительно и смешно),
>
>O_o, а Solaris Zones уже научилось делать вложенные Zones, как это умеет
>jail2?

Zones единственные из контейнеров, которые умеют запускать Virtual Enviroment с другими ОС, не совпадающими с базовой.

>Чем OVZ лучше jail?

Если коротко, то всем: это абсолютно несравнимые технологии:) Для PVC это вообще разгром: SLM в дополнение к UBC менеджменту, VZFS с OS и аппликешн темплейтами, нормальный менеджмент уровня дата-центра через PIM/VZCP (готовое решение для бэкапов, управления тысячами физических серверов, темплейтами и несметным количеством контейнеров)

OVZ (PVC это все так же, конечно, умеет):

- live migration
- чекпоинт (сохранение состояния контейнера в дамп и восстановление в любой момент, в том числе на другом физическом сервере)
- Жесткий менеджмент ресурсов всех Virtual Enviroments(память, cpu, лимиты, приоритеты, барьеры по выделению ресурсов - если ресурса избыточно, ядро поделится им  с остальными контейнерами, если это разрешено для этих контейнеров), двухуровневый CPU планировщик, внутри контейнера можно сделать renice:), даже есть виртуализация PID'ов процессов (у init'а каждого контейнера, внутри его Enviroment, номер 1)
- двухуровневая дисковая квота (внутри VE поддерживаются свои квоты и acl так, как будто это не VE)
- Приоритеты по i/o для процессов контейнера (к сожалению, пока нет лимитов), контейнерам с массивными запросами к диску можно дать меньше disk time
- Свой пакетный фильтр для каждого контейнера (я про iptables)
- Вообще, виртуализированный сетевой стек (что там с IP адресами у jails?), три вида сетевых интерфейсов у контейнеров (быстрый venet, почти "настоящий" veth с мак-адресами и arp-таблицами, физические интерфейсы машины, на которой крутится контейнер)
- Поддержка подавляющей части системных вызовов абсолютно прозрачно для ПО (например, bind ставится и работает искоропки в chroot)
- Невероятная плотность, достигающая 50-ти контейнеров на одном средненьком физическом сервере, постоянно находящихся под нагрузкой, и, в целом, не мешающих друг другу, и даже более 100-150 в случае быстрой дисковой подсистемы

резюме: это просто не сравнимые технологии, как несравнима, например, 3BSD с семеркой, а уже на базе VZ созданы LXC с их аппликейшн контейнерами(которые, правда, пока так же не стоит использовать в production как FreeBSD 8 c ZFS), оставание, мне кажется, уже безнадежное.

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

220. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от Bulgarin (ok), 23-Окт-09, 23:42 
>находящихся под нагрузкой, и, в целом, не мешающих друг другу, и
>даже более 100-150 в случае быстрой дисковой подсистемы

Умничаете, да? Листовку нафигачили... :) Шутка.
Вы же все равно наверняка в работе пользуетесь тем чем пользуетесь, и ничем иным.
И подобные прокламации  рассматриваю не более чем рационализацию исторически сложившегося хода событий.

Но если вы действительно интересуетесь, обработка вызова jail в FreeBSD 8 сильно переделана. В сочетании с остальными возможностями (jailed sockets/route/ipfw, virt. ip-stack, secure level, zfs quota, system quota, ...) конструкция получается вполне отвечающая техническому заданию на изоляцию (скажем, для хостера), с учетом ограничений самой идеи chroot-переростка.
Без бантиков, но то уж звиняйте. Кому шо бильше треба.

Небольшой документ про jail, объясняющий некоторые моменты реализации:
http://docs.freebsd.org/44doc/papers/jail/jail.html
Документация
http://www.freebsd.org/cgi/man.cgi?query=jail&sektion=8
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ja...

Ну а насчет быстро и впереди планеты всей... Тараканы тоже быстро бегают :)

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

216. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от Аноним (-), 23-Окт-09, 14:29 
>[оверквотинг удален]
>"Я плакалъ" :)
>
>Все, ует, умыт и сражен. На этот аргумент сказать ответить нечего :)
>
>
>"Долгих 15 лет изнурительной революции, в результате которых была получена совершенно уникальная
>и не имеющая аналогов кострукция велосипе... управления памятью, шинами, устройствами, процессами,
>файловые системы, набор системных вызовов, ... Именно благодаря этой революционной конструкции,
>написанной на уникальном языке SI, удалось применить ранее написанные GNU&PNU-утилиты, применит
>огромное число революционных проектов, таких как Imacs, Torzilla, Z11, lendmail, ..."

Не надо утрировать. Я имел в виду, что во-первых в Linux никогда не было унаследованного кода - весь код изначально был написан "с нуля". Во-вторых, я имел в виду то, что разработчики Linux не боятся пробовать новые решения. Сколько было попробовано и переписано фаерволлов, сколько файловых систем устройств, сколько менеджеров управления томами, сколько подсистем модулей ядра, сколько планировщиков процессов?

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

Сейчас Linux вышел на некое плато, где он практически не развивается. Пишутся новые драйверы, переписываются отдельные небольшие подсистемы, но в целом ядро Linux уже несколько лет как созрело. Большинство разных направлений перепробовано, в них найдены лучшие решения. Цена превосходства - может быть несколько бардачный код и сравнительно большое количество ошибок. Что будет дальше? Возможно код Linux будет подвергнут рефакторингу, а возможно будет пущен под нож на детали для нового ядра с GPL-совместимой лицензией.

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

195. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от sHaggY_caT (ok), 19-Окт-09, 20:13 
>"Тихо сам с собой я веду беседу". А там глядишь, кто и прочитает :)

Прочитала:)


>>>"eth0".."eth6" в Linux перепутываются постоянно даже с разными карточками, использующими >разные драйвера -- для FreeBSD такой случай исключён из практики правильной АРХИТЕКТУРОЙ.

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

В этой ситуации нумерация девайсов по шине просто не нужна. Нужен параметр в ether в rc.conf (не важно, будет он ставится sysinstall или скриптом при PXE заливке системы), нужна прогрессивная система конфигурации /etc/network(c), нужна Anaconda

>Автомагичность по hw-адресам - нафик-нафик... От лукавого это, лишнее. Змеи еще какие-то,
>анаконды...

Не нравится, ставьте руками :) Это же не Windows, а "прогрессивная система /etc/network". sysinstall, Anaconda, и т д

>Что за змея? Почему не знаю? Есть новый POSIX-стандарт на змей?

Думаете на слово "sysinstall" нельзя придумать что-то подковыристое?


>[оверквотинг удален]
>     Generic labels are created in the directory
>/dev/label/.
>...
>
>Собственно, этого более чем хватает что бы "пилевать" на шинную адресацию, SCSI
>LUN, ATA CH, USB ADDR, ... Опознание-отображение делается по все иерархии
>GEOM.
>Указание корня при загрузке в соотв. glabel так же возможно, man loader.
>Естественно, даже если корень на другом физическом диске относительно загрузчика и
>считанного в память ядра.

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

А про нумерацию девайсов, в Linux это by design делается в UDEV/DeviceKit. Кто и где сказал, что девайсы обязательно должны нумероваться кёрнелем? Если это было так в дремучих временах Денниса Ричи и Ко с Bell Labs & AT&T, с тех пор уже прошли десятилетия!

Может быть, юзер-мод конфигурялки часто удобнее? СТоит вспоминить тот же pf и сравнить его с исключительно ядерным iptables, тут как раз сравнение очень не в пользу iptables по функционалу и гибкости.
Вспомнить тот же УГ, который называется IIS(много ему дал ядерный листенер)?

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

196. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от Bulgarin (ok), 19-Окт-09, 23:16 
>такое прочее, которые случайно (например, при замене платформы вместе с карточкой)
>могут быть ткнуты не туда и не так.

Поменять ifconfig_ab0 на ifconfig_bc0 в одном файле при старте - минутное дело.
Учитывая, сколько занимает возня в аппаратной зачастую - это мгновение :)

>Правильная архитектура это лишь повод для гордости девелоперов и фанатиков, системным администраторам все равно, что там внутри ядра :)

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

>Не нравится, ставьте руками :) Это же не Windows, а "прогрессивная система
>/etc/network"

Наверное, становлюсь старым ретроградом :)

>Что мне не нравится во всем этом, так это то, что уже
>просетапленную систему без переформатирования дисков нельзя привести к предсказумому,
>при перетасовки дисков, виду.

Кто вам такое сказал? Labels in GPT, UFS, названия томов ZFS легко меняются, естественно, в отмонтированной FS. После устаканивания меток меняйте диски на той же SCSI как хотите - монтирование будет производится по меткам (именам томов).

# gpart modify -i N -l suberlabel
# tunefs -L /dev/adXpN
# zpool export oldname; zpool import oldname newname

#mount /dev/ufs/suberlabel /mnt
#zfs import suberpoolname

C ZFS есть ньансы по монтированию, нужно привыкнут к другой методике.
Автомонтирование можно не использовать.

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

Извини, не понял ситуацию. Вечер, голова совсем глупый.

>А про нумерацию девайсов, в Linux это by design делается в UDEV/DeviceKit.
>Кто и где сказал, что девайсы обязательно должны нумероваться кёрнелем? Если
>это было так в дремучих временах Денниса Ричи и Ко с
>Bell Labs & AT&T, с тех пор уже прошли десятилетия!

И так, и не так. Шинная архитектура как была так и осталась. Граф устройств как был, так и есть. Появились новые уровни абстракции (в FreeBSD это CAM & GEOM), но в его ближнем к аппаратуре слое логика ядра так или иначе отражает аппаратное устройство.

>Может быть, юзер-мод конфигурялки часто удобнее? СТоит вспоминить тот же pf и
>сравнить его с исключительно ядерным iptables, тут как раз сравнение очень
>не в пользу iptables по функционалу и гибкости.

"Вы кошек готовить не умеете" :)
iptables также встроен в ядреный сетевой стек на стыках in/out.

>Вспомнить тот же УГ, который называется IIS(много ему дал ядерный листенер)?

Это есть и будет в микроядерных архитектурах, где уровни абстракции будут вынесены в отдельные процессы-трансляторы представлений, настраиваемые хуками друг к другу в нужном порядке.
Пока работаем с тем что есть, и не думаю что оно самый худший вариант (вспоминая IBM370/Серия EC, и их километровые руководства по танцам :) )

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

181. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от iZEN (ok), 19-Окт-09, 01:43 
>>"eth0".."eth6" в Linux перепутываются постоянно даже с разными карточками, использующими >разные драйвера -- для FreeBSD такой случай исключён из практики правильной АРХИТЕКТУРОЙ.
>
>Это называется "ниасилить" :))) И это как раз про упоминавшихся уже хомячков
>:)
>В тех же RH-системах в /etc/sysconfig/network-scripts/ifcfg-бла-бла есть опция HWADDR, которая по-дефольту верно
>выставляется Анакондой.

Что за змея? Почему не знаю? Есть новый POSIX-стандарт на змей?


>[оверквотинг удален]
>       UUID or volume label (cf.  e2label(8) or xfs_admin(8)), writing LABEL=<label> or  UUID=<uuid>,  e.g.,  ‘LABEL=Boot’  or
>       ‘UUID=3e6be9de-8139-11d1-9106-a43f08d823a6’.   This  
>will  make  the system more robust: adding or removing
>a SCSI disk
>       changes the disk device name
>but not the filesystem volume label.
>============================================
>
>туда же можно писать девайсы lvm и md, которые сами (by design)
>нормально привязываются к железкам

Приведу только свой /etc/fstab:
> cat /etc/fstab

# Device    Mountpoint    FStype    Options        Dump    Pass#
/dev/mirror/Swap       none    swap    sw              0       0

-- это только swap, так как остальное место для ZFS == собственный кэш имён дисковых устройств в файловой системе, а кроме ZFS на дисках у меня никаких ФС нет.


Пример работы с носителями по UUID (GPT ID) в FreeBSD
0) Подготовительные операции:
% echo 'geom_mirror_load="YES"' >> /boot/loader.conf
и, на всякий случай:
% echo 'geom_label_load="YES"' >> /boot/loader.conf

% kldload geom_mirror
% kldload geom_label

1) Ищем идентификаторы разделов:
% gpart list
...
Geom name: ad4p3
Providers:
1. Name: gptid/6e34319f-83a6-15de-4bc4-02203d4562eb
...
Geom name: ad5p3
Providers:
1. Name: gptid/7b263792-52a6-11ed-7cb6-06531d23a4eb
...

2) Создаём зеркало (для двух физических разделов ad4p3 и ad5p3):
% gmirror label -v Data gptid/6e34319f-83a6-15de-4bc4-02203d4562eb
Metadata value stored on gptid/6e34319f-83a6-15de-4bc4-02203d4562eb
Done.

3) Форматируем зеркало (а фактически -- единственный носитель в нём):
% newfs -U /dev/mirror/Data

4) Вносим запись в /etc/fstab:
# Device    Mountpoint    FStype    Options        Dump    Pass#
/dev/mirror/Data       /Data    ufs    rw              1       1
Всё. Его уже и в таком виде можно использовать —- даст бог, не развалится. :))

5) Опционально добавляем ещё один зеркалирующий носитель в зеркало:
% gmirror insert Data gptid/7b263792-52a6-11ed-7cb6-06531d23a4eb

6) Смотрим статус (после полной синхронизации зеркала):
% gmirror status
       Name    Status  Components
mirror/Data  COMPLETE  gptid/6e34319f-83a6-15de-4bc4-02203d4562eb
                       gptid/7b263792-52a6-11ed-7cb6-06531d23a4eb

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

197. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от iZEN (ok), 19-Окт-09, 23:47 
>1) Ищем идентификаторы разделов:
>% gpart list
>...

Не "% gpart list", а "% glabel list".

Ещё. Сейчас проверил: в статусе gmirror, когда смонтирована файловая система, пишутся не метки/идентификаторы gptid, а реальные устройства. Когда ФС зеркала не смонтирована, вместо устройств -- метки.
Наводит на мысль, что семантика использования меток в ключе использования GEOM RAID поменялась при переходе с FreeBSD 7.x на 8.x.

Вот лог действий:
% glabel list
Geom name: ad6p2
Providers:
1. Name: gpt/rio_swap1
   Mediasize: 2147483648 (2.0G)
...
Geom name: ad6p2
Providers:
1. Name: gptid/e0fa02b3-81a6-11de-8aa6-02508d92a2eb
   Mediasize: 2147483648 (2.0G)
...
Geom name: ad10p2
Providers:
1. Name: gpt/rio_swap2
   Mediasize: 2147483648 (2.0G)
...
Geom name: ad10p2
Providers:
1. Name: gptid/e2aef92e-81a6-11de-8aa6-02508d92a2eb
   Mediasize: 2147483648 (2.0G)
...
% gmirror label Swap gpt/rio_swap1
% gmirror status
       Name    Status  Components
mirror/Swap  COMPLETE  ad6p2
% cat /etc/fstab
# Device    Mountpoint    FStype    Options        Dump    Pass#
/dev/mirror/Swap       none    swap    sw              0       0
% swapon -a
swapon: adding /dev/mirror/Swap as swap device
% gmirror insert Swap gptid/e2aef92e-81a6-11de-8aa6-02508d92a2eb
gmirror: Unknown provider gptid/e2aef92e-81a6-11de-8aa6-02508d92a2eb.
% gmirror insert Swap gpt/rio_swap2
% gmirror status
       Name    Status  Components
mirror/Swap  DEGRADED  ad6p2
                       ad10p2 (16%)
% gmirror status
       Name    Status  Components
mirror/Swap  COMPLETE  ad6p2
                       ad10p2
% swapoff -a
swapoff: removing /dev/mirror/Swap as swap device
% gmirror stop Swap
% gmirror status
       Name    Status  Components
mirror/Swap  COMPLETE  gpt/rio_swap2
                       gpt/rio_swap1
% swapon -a
swapon: adding /dev/mirror/Swap as swap device
% gmirror remove Swap gpt/rio_swap1
% gmirror status
       Name    Status  Components
mirror/Swap  COMPLETE  gpt/rio_swap2
% gmirror remove Swap gpt/rio_swap2
% gmirror status
       Name  Status  Components
mirror/Swap     N/A  N/A
% swapoff -a
swapoff: /dev/mirror/Swap: No such file or directory
% gmirror stop Swap
gmirror: No such device: Swap.
% gmirror insert Swap gpt/rio_swap2
gmirror: No such device: Swap.
% gmirror label Swap gpt/rio_swap1
% swapoff -a
% swapon -a
swapon: adding /dev/mirror/Swap as swap device
% gmirror status
       Name    Status  Components
mirror/Swap       N/A  N/A
mirror/Swap  COMPLETE  ad6p2
% swapoff -a
swapoff: removing /dev/mirror/Swap as swap device
% gmirror remove Swap gpt/rio_swap1
gmirror: No such provider: gpt/rio_swap1.
% gmirror remove Swap ad6p2
% gmirror status
       Name  Status  Components
mirror/Swap     N/A  N/A
% gmirror stop Swap
gmirror: No such device: Swap.


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

200. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от Bulgarin (ok), 20-Окт-09, 12:34 
>Ещё. Сейчас проверил: в статусе gmirror, когда смонтирована файловая система, пишутся не
>метки/идентификаторы gptid, а реальные устройства. Когда ФС зеркала не смонтирована, вместо
>устройств -- метки.
>Наводит на мысль, что семантика использования меток в ключе использования GEOM RAID
>поменялась при переходе с FreeBSD 7.x на 8.x.

Есть изменения в /src/sbin/geom/class/part/geom_part.c  gpart_show_geom() - появился вызов новой функции gpart_autofill(), мэй би это она рисует провайдеров по новому?

# svn diff http://svn.freebsd.org/base/stable/7/sbin/geom/ \
#    http://svn.freebsd.org/base/stable/8/sbin/geom/

На заметку, это как-то не отражено в документации, просмотр реальной иерархии GEOM, из sys/geom/geom_dump.c:
# sysctl -b kern.geom.conftxt

Можно .confdot, если установлен graphviz
# sysctl -b kern.geom.confdot > geom.dot
# dot -Tps  geom.dot > geom.ps
Или
# dot -Tpng geom.dot > geom.png


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

119. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от Bulgarin (ok), 09-Окт-09, 17:51 

>А ничего дебильнее прыгающей нумерации сетевушек в вашей фре я не видел.
>Стоят три сетевушки одинаковой модели: rl0, rl1, rl2. Вынимаем вторую, вставляем
>ещё одну, но другой модели и что мы видим? rl0, rl1,
>xl0. Вперед, переписывать в трёхстах местах название интерфейса. Или алиасики на

Хех, добавим огня, с сохранением стиля :)

Ничего дебильнее обезличивающего наименования в линуксе я не видел - eth0, eth1, eth2.
Выдернул сетевушку, вставил новую - и не поймешь, к какой интерфейс относится?

---
1. Если вы меняете сетевые карты так часто, то это печально.
2. Если часто меняемая локация
ifconfig ...
route delete ...
route add ...
Скрипт в три команды, думаю, не проблема.
3. Для постоянного изменить нужно только в /etc/rc.conf
Кроме guagga/zebra, влет не припоминаю ПО, сильно или вообще зависимого от имени интерфейса.
Firewall, пожалуй, вешь индивидуальная, по уму там хорошо макроподстановкой.

И нечего городить огород там, где можно гораздо проще.

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

139. "Принято решение об официальной поддержке архитектуры kFreeBS..."  +/–
Сообщение от bugmenot (??), 12-Окт-09, 04:14 
> Костыли devd не предлагать

а в чем костыльность способа с devd(8)?

При поднятии и опускании интерфейса в /dev/devctl или /var/run/devd.pipe
появляются такие строчки

!system=IFNET subsystem=xl0 type=LINK_DOWN
!system=IFNET subsystem=xl0 type=LINK_UP

На основе примера из devd.conf(5) получим

notify 0 {
    match "system"                  "IFNET";
    match "type"                    "LINK_DOWN";
    action "/etc/network/ip-down.d/$subsystem";
};

notify 0 {
    match "system"                  "IFNET";
    match "type"                    "LINK_UP";
    action "/etc/network/ip-up.d/$subsystem";
};

Таким образом будут выполняться /etc/network/ip-(up|down).d/ скрипты.
Однако detach/attach будут выглядеть так

!system=DEVFS subsystem=CDEV type=CREATE  cdev=xl0
!system=DEVFS subsystem=CDEV type=DESTROY cdev=xl0

поэтому они *не будут* попадать под сие правило и конфликта не будет.

Чем этот метод плох? Он не привязан к имени интерфейса.

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

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

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




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

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