1. Звідки ж ноги? ..
2. Ох вже ці баги
3. Рішення. спосіб перший
4. Рішення. спосіб другий
5. що почитати

Вирішено було на днях підняти-таки Jabber-сервер на одному з серверів, що працюють під FreeBSD. Рішення рішенням, але з огляду на те, що зайві кілька хвилин простою сервера, якщо щось трапиться, будуть не самим радісною подією, здалося цілком логічним потренуватися, що називається, «на кішках». Повноцінної FreeBSDшной «кішки» у мене, природно, не знайшлося. Ну, не виходить поки з мене BSD-шника :-) Загалом, подумалося, а чому б і не старий добрий VirtualBox? Сказано зроблено. Був роздобути ISO-шник FreeBSD-7.0, на швидку руку з якого і була поставлена ​​ОС. Поки ставилася сама операційка, у мене було трохи часу погортати вже відомий для мене Хендбук, з якого вдалося зрозуміти, що так вже швидко з Ubuntu в BSD зануритися у мене не вийде. Хех, а так хотілося ...

Отже, ОС встановилася, завантажуємося. І тут, як то кажуть, «От чорт». З усього побаченого в повідомленнях, що не поспішає завантажуватися свіжовстановленому BSD, вдалося зрозуміти, що мережевий інтерфейс ніяк не бажає підніматися. Точніше не має можливості отримати мережеву адресу по DHCP.

Звідки ж ноги? ..

Почекавши якийсь час, поки DHCP-клієнт припинить-таки судомні і марні спроби отримати адресу, вдалося увійти в систему. Озирнувшись навколо і зрозумівши в черговий раз, що Юнекс Лінукс, м'яко кажучи, не рівня, вирішено було почати розбиратися з проблемою, а не шукати схожості з тим, чим мені так хотілося їх бачити. Насамперед було перевірено стан мережевих інтерфейсів, зокрема злощасного «pcn0»:

Хм ... Чомусь система вважає, що Ethernet-кабель не застромлять в плату. Ясна річ, що у випадку з віртуальною машиною просто не вийде поглянути на задню стінку системного блоку і подивитися, чи не випав чи шнурок :-) Пошук по лог-файлів завантаження системи нічого не дав. Ядро урочисто відзвітувало, що пристрій, і все чудово. З цього моменту стає ясно, що проблема явно не в DHCP, оскільки система просто «фізично» не може отримати доступ до середовища передачі даних. Однак, маючи в своєму розпорядженні усім цим так і не ясно, що ж робити далі? Взагалі, зараз дивуюся, як раніше без доступу до Інтернет мені вдавалося знаходити потрібну мені інформацію. Так, Інтернет робить людину ледачим. Або людина себе за допомогою Інтернету. Загалом, добре. Ліземо в Гугль з питаннями, а може, не я перший.

Ох вже ці баги

Після декількох хвилин колупання видачі Гугля вдалося з'ясувати, що таки да, проблема не у одного мене, коханого. Сенс такий. VirtualBox емулює мережеву плату AMD PCnet-FAST III (Am79C973) для гостьової ОС (це один з чотирьох варіантів, не звернувши уваги на який я і поплатився витраченим часом і отриманими знаннями). Так ось, VirtualBox емулює її добре, просто чудово, за винятком однієї деталі. Коли драйвер мережевої плати в FreeBSD, використовуючи функцію автоматичного визначення, намагається виявити, який же media підключений до плати в даний момент, VirtualBox-овий варіант AMD-шной мережевої повідомляє, що, «вибачте, мовляв, помилочка вийшла». Ясна річ, що драйверу зайнятися більше нічим, як влаштовувати експерименти і пошуки безвісти зниклих. Він просто повертає ifconfig-у повідомлення про те, що ніякого media виявити не вдалося. Інтерфейс з цього моменту вважається активним, хоч і без доступу до середовища передачі. Після цього, через деякий час dhclient починає відправляти широкомовні, природно невдалі, запити в пошуках DHCP- сервера. І чекає, чекає, чекає ... Що і видно на найпершому скріншоті. По ходу розвитку подій якось незрозуміло стає. Це що ж виходить, dhclient-у пофіг, що пристрій не в змозі передавати дані? Тобто, «я свою роботу роблю, а ви - як хочете». Мда, забавно.

Рішення. спосіб перший

Перед тим, як робити якісь дії, потрібно було встановити, яким же чином FreeBSD піднімає даний пристрій. Поглянувши в /etc/rc.conf стало ясно, що ніяких екстраординарних дій не виконується, і мережева карта конфигурируется «за замовчуванням»:

Заглянувши в «man 4 pcn» з'ясовуємо, що драйвер підтримує 3 варіанти того самого media: autoselect, 10baseT / UTP і 100baseTX. Що ж, пробуємо всі наявні варіанти:

Ага! Судячи з усього, останній варіант media не викликає у драйвера ніяких питань, про що свідчить мовчазна реакція ifconfig. Перевіряємо, що змінилося:

Штовхає dhclient з проханням ще разок спробувати отримати-таки цей довбаний адреса:

Вуаля! Мережевий інтерфейс ожив, dhclient зміг, нарешті, достукатися до DHCP-сервера. Загалом, всі задоволені і я більше всіх :-) Залишилося лише автоматизувати вищеописаний процес, щоб не кнопать щоразу після завантаження ОС одне і те ж, тримаючи при цьому все в голові. Деякі панове пропонують для цієї мети написати bash-скрипт, задати автоматичне його виконання в яких тільки заманеться місцях конфігураційних файлів системи. Навіщо все це - незрозуміло, бо ж є /etc/rc.conf, в якому все чудово описується і працює на благо вітчизни. Отже, модифікуємо:

Перезавантажуємо операційну систему і отримуємо задоволення! :-)

Рішення. спосіб другий

Ну і, як завжди, найсмішніше і цікаво мало не виявилося за кадром.Всем, хто дочитав до цього місця - «респект і уважуха» ©. Колись, ще зовсім недавно, у мене була звичка постійно лізти в усі конфіги, опції, що випадають списки, закладки та цікавитися кожним чекбоксів в настройках будь-якої програми. Потім, з часом, я привчив себе не витрачати час на нікому непотрібне вивчення всього, що навидумують розробники. Сьогодні очей вже навчився ігнорувати все це різноманітність параметрів конфігурації софта. Безсумнівно, часу такий підхід економить масу, особливо якщо потрібно «дуже швидко щось налаштувати». Але ось тут ця звичка зіграла-таки злий жарт. Хоча, жарт чи що? Привід замислитися - мінімум.

Загалом, рішення цієї проблеми другим способом полягає всього лише ... У зміні типу емульованого пристрої VitrualBox! Хто б міг подумати...

Ну і, звичайно ж, не забуваємо відзначити появу нового інтерфейсу в самій FreeBSD:

що почитати

http://www.freebsd.org/doc/ru_RU.KOI8-R/books/handbook/config-network-setup.html