Озадаченно смотрю на версии «свежего софта»…

На моей бубунте уже как минимум Гном, офис и ядро более новых версий. Подозреваю, если посмотрю на прочий установленный или доступный в репозиториях софт — ситуация будет аналогичной.

Объясните — в чем смысл? Только в «проверенности» и стабильности этих версий?

Ответ:

Да. И это «только» весьма дорогого стоит. Более того, в рамках политики дебиана обновляться версии будут только на security fix’ы, то есть никаких новых фич до момента явного dist-upgrade’а. Сравните с убунтой, в которой каждые N дней пачка обновляемых пакетов.

Для десктопа это, может быть и нормально, но для сервера — неприемлимо. Я лично несколько раз сталкивался с дурацкими проблемами при обновлении версий (к счастью, только на декстопе). В списке лидеров — evolution (похерил архив почту), krusader (похерил половину настроек), deluge (криво подцепил старые настройки).

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

Таким образом, stable — это идеальное решение для сервера. А sid/ubuntu — вполне хорошо для _своего_ десктопа (решать проблемы похерившейся почты у себя неприятно, но решать их же у главбуха — куда грустнее).

Кстати, ровно той же политики придерживается и RHEL (CentOS) — у них в пятой версии до сих пор 2.6.18, хоть и с кучей бэкпортов.

© amarao, Хабрахабр.

Чтобы решить проблему отказа серверов Gmail от обслуживания  при отправке большого числа писем на несуществующие адреса, используем для отправки почты из скриптов сайта локальный почтовый SMTP-сервер (MTA). Локальный сервер будет выступать в качестве mail relay. В дополнение мы откажемся от подключения из скрипта к удаленному серверу, что может быть медленно. Локальные подключения всегда должны быть быстрее и стабильнее.

Локальный сервер мы будем использовать только для отправки писем. Причем, не важно, как будет происходить отправка: непосредственно через SMTP, или с помощью MUA. Получение почты по-прежнему будет происходить с серверов Gmail.

В дистрибутиве Debian 5 по умолчанию устанавливается MTA Exim4. Он отлично подойдет для наших задач. Причем его настройка производится с помощью мастера и невероятно проста. Настроить сервер требуется на прием соединений исключительно с локального соединения. При этом не нужно поручать ему обслуживание доменов, кроме дефолтного локального (localhost).

Итак, если Exim у вас не установлен, то установим его:

# aptitude install exim4

Далее запускаем его конфигурацию:

# dpkg-reconfigure exim4-config

1. На первом шаге необходимо выбрать конфигурацию сервера. В Exim есть несколько стандартных конфигураций, предназначенных для разных случаев. Подробнее о них в мануале. Нам нужна конфигурация “internet site; mail is sent and received directly using SMTP”.

2. Далее укажите имя сервера. Оно будет передаваться в SMTP-протоколе в команде HELLO, т.е. будет видно получателям вашей почты. Лучше всего, чтобы это имя совпадало с доменом, с которого шлется почта. Например, valera.ws.

Если у вас на сервере несколько сайтов с разными доменами (см. ниже), то лучше это имя сделать нейтральным, чтобы «не палиться». Например, можно выбрать local-mail-agent.

3. Далее требуется указать, какие интерфейсы должен слушать Exim. В нашем случае удаленные подключения мало того, что не нужны, так еще и опасны: кто угодно сможет рассылать почту через ваш сервер. Указываем только 127.0.0.1.

4. Далее спрашивается, какие домены должен обслуживать сервер. Т.е. для каких доменов не нужно пересылать письма на удаленные SMTP-сервера, пользователь заберет их с этого сервера. Нам не нужно обслуживание наших доменов. Можно указать только localhost, т.к. его больше обслужить некому.

Не указывайте здесь адрес вашего сервера (подставляется по умолчанию), т.к. его обслуживание делегировано Gmail. Если его указать, то письма, отправленные на ящики вашего домена, в Gmail не попадут и останутся на сервере. Это не нужно.

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

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

При этой конфигурации есть один негативный момент. Если ваш сайт поломают, то злоумышленники смогут слать почту с любых доменов через ваш сервер. Если на сервере 1—2 сайта, то лучше на этом шаге оставить поле пустым, а на предыдущем шаге внести список этих доменов (для возврата на шаг назад нажмите кнопку “Cancel”). При появлении новых доменов не забывайте их заносить в конфиг. Если вы считаете свои сайты надежными, то проще всего указывать здесь 127.0.0.1.

7. Дале уточняется, является ли для нас проблемой постоянные DNS-запросы при отправке каждого письма. В 99,9% это не проблема, так что выбираем ответ на вопрос “Keep number of DNS-queries minimal (Dial-on-Demand)?” “No”.

8. Где хранить локальную почту (помните, мы указали серверу обслуживать домен localhost?) нам по сути не важно, так как этим как правило никто не пользуется. Можно выбрать вариант по умолчанию: складывать все в /var/mail.

9. Предпоследний шаг — выбор конфигурации. Хранить все в одном файле, или раскидать по множеству мелких файлов. В большой файл проще вносить большие изменения, а с мелкими проще работать в случае мелких правок. Выберите вариант на свой вкус. Я выбрал “unsplit configuration” (ответ “No”).

10. На последнем шаге укажем на какой аккаунт реального пользователя системы пересылать сообщения, отправленные на служебные аккаунты postmaster, root и т.д. Здесь имеет смысл указать ваше имя пользователя в системе.

Переконфигурировать Exim в любой момент можно тем же способом. Мастер подставит в значения по умолчанию текущие значения вашей конфигурации.

Правильная настройка SPF

Если кратко, то SPF — это способ борьбы со спамом.

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

SPF-запись — это обыкновенная запись доменной зоны, имеющая тип TXT. Узнать текущее ее значение для домена можно с помощью команды host в Linux:

$ host -t TXT valera.ws
valera.ws TXT record currently not present

В данном примере SPF-запись не задана. Зададим ее. С моего домена почта может отправляться с серверов Gmail и с моего сервера. Для начала узнаем, какой PTR моего сайта (valera.ws):

$ nslookup valera.ws
Server:      194.224.52.4
Address:     194.224.52.4#53

Non-authoritative answer:
Name:     valera.ws
Address:  93.174.6.118

IP-адрес моего сервера 93.174.6.118. Узнаем PTR:

$ nslookup 93.174.6.118
Server:      194.224.52.4
Address:     194.224.52.4#53

Non-authoritative answer:
118.6.174.93.in-addr.arpa name = server.valera.ws.

Видно, что PTR IP, к которому привязан мой домен (IP моего сервера) — server.valera.ws.

v=spf1 a mx ptr include:_spf.google.com ~all

По порядку:

• v=spf1 — версия SPF (первая);
• a — разрешение отправлять почту с IP, указанного в A-записи домена (собственно с сервера, на который ваш домен ссылается);
• mx — разрешение отправлять почту с IP, указанных в MX-записях домена (в нашем случае сервера Gmail);
• ptr — разрешение отправлять почту с IP, PTR-запись которых содержит ваш домен (т.е. сам домен и поддомены);
• include:_spf.google.com — подключение разрешений для серверов отправки почту Gmail (совсем не обязательно почта будет слаться с серверов, указанных в MX-записи);
• ~all — нейтральная реакция на всю остальную почту; здесь можно указать -all, что будет значить, что почта, не попадающая под эти правила, — спам.

Если вы хотите отправлять почту с сервера, не попадающего под все эти правила, его можно указать по IP или домену PTR, например:

v=spf1 a mx ptr ptr:example.com include:_spf.google.com ~all

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

valera.ws.      TXT      v=spf1 a mx ptr include:_spf.google.com ~all

После обновления зоны host выдаст следующее:

$ host -t TXT valera.ws
valera.ws      TXT      »v=spf1 a mx ptr include:_spf.google.com ~all»

PHP mail()

После всей этой настройки функция mail() в PHP начнет слать почту через ваш локальный сервер на законных основаниях для антиспам-ботов. Но косяк будет в том, что в поле отправителя будет фигурировать адрес системного пользователя www-data@localdomain. Нас это не устраивает. Чтобы почта правильно слалась из mail(), необходимо использовать ее дополнительный параметр.

bool mail ( string $to , string $subject , string $message [, string $additional_headers [, string $additional_parameters ]] )

Именно $additional_parameters нас и интерисует. В него надо передавать реального отправителя:

mail($to, $subject, $message, $additional_headers, $additional_parameters.» -frealsender@valera.ws»);

Указывается отправитель слитно с параметром -f.

Теперь отправленные через mail() письма будут абсолютно адекватны (при условии, что вы указываете все нужные SMTP-заголовки, вроде “FROM:”, “TO:” и т.д.).

А если несколько сайтов с разными IP (настройка Exim для отправки писем с разных IP)?

Мы хотим использовать локальный SMTP-сервер для отправки почты со всех сайтов на сервере. Никаких проблем нет, если настроен Exim правильно (см. выше). Но проблема появляется, если разные сайты работают на разных IP. Мы не хотим в почте «палить» то, что все наши сайты живут на одном сервере. Но Exim по умолчанию шлет всю почту с основного (первого) IP сетевого интерфейса, а этот IP всем получателям в SMTP-заголовках “Received:” письма. Кроме того, там указывается и имя сервера, которые мы в случае с разными сайтами на сервере выбрали нейтральными.

Чтобы не «палить» IP сервера, нужно отсылать письмо на удаленный сервер с IP, равного A-записи домена сайта. Делается это несложно путем изменения конфига Exim. Внесем изменения в настройки транспорта SMTP Exim. Если вы выбрали монолитный конфиг, то нужно отредактировать файл:

# nano /etc/exim4/exim4.conf.template

Находим в файле строку “remote_smtp:” (поиск в nano — F6). Добавляем в конец этого блока:

interface = «${lookup{$sender_address_domain}lsearch{/usr/share/exim4/domain2ip}{$value}}»
helo_data = «$sender_address_domain»

Это значит, что при отправке письма нужно определить домен отправителя почты (для sender@valera.ws это valera.ws) и отправить почту с IP, к которому этот домен привязан. Само собой разумеется, что домен должен быть привязан к серверу, где установлен Exim.

Так же нужно создать файл в любом месте файл привязки доменов к IP (у домена может быть несколько IP, так что просто lookup-ить его не прокатит). Я выбрал для файла место: /usr/share/exim4/domain2ip

# nano /usr/share/exim4/domain2ip

Туда вводим наши домены по шаблону:

valera.ws: 123.123.123.123
vasya.ws: 123.123.123.124

Не забудьте дописать домен в файл в случае появления нового сайта.
Кстати, строку helo_data = «$sender_address_domain» можно добавить в файл даже если у вас один IP на все сайты. Тогда в команде HELLO SMTP-протокола (а, следовательно, и в заголовках писем) будет фигурировать ваш домен.

Идея с указанием интерфейса взята отсюда: http://www.directadmin.com/forum/showthread.php?t=36468

Проверка

Остается проверить, чтобы все ваши настройки работали верно. Для этого просто отправим письмо с локального сервера через консоль.

$ mail -a «From:feedbee@valera.ws» -s Test feedbee@gmail.com — -ffeedbee@valera.ws
Test <Ctrl-D>
Cc:

Проверяем отосланное письмо в ящике получателя:

А вот текст SMTP-протокола:

Delivered-To: feedbee@gmail.com
Received: by 10.236.109.139 with SMTP id s11cs13826yhg;
Wed, 24 Nov 2010 02:18:14 -0800 (PST)
Received: by 10.227.145.134 with SMTP id d6mr9025492wbv.195.1290593893066;
Wed, 24 Nov 2010 02:18:13 -0800 (PST)
Return-Path: feedbee@valera.ws
Received: from valera.ws (server.valera.ws [93.174.6.118])
by mx.google.com with ESMTP id b7si11085685wer.164.2010.11.24.02.18.12;
Wed, 24 Nov 2010 02:18:12 -0800 (PST)
Received-SPF: pass (google.com: domain of feedbee@valera.ws designates 93.174.6.118 as permitted sender) client-ip=93.174.6.118;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of feedbee@valera.ws designates 93.174.6.118 as permitted sender) smtp.mail=feedbee@valera.ws
Received: from root by server.valera.ws with local (Exim 4.69)
(envelope-from <feedbee@valera.ws>)
id 1PLCQW-0006KD-Pc
for feedbee@gmail.com; Wed, 24 Nov 2010 10:18:12 +0000
To: feedbee@gmail.com
Subject: Test
From:feedbee@valera.ws
Message-Id: E1PLCQW-0006KD-Pc@server.valera.ws
Date: Wed, 24 Nov 2010 10:18:12 +0000

Test

P.S. Чтобы отправленная почта не попадала в спам, отправляйте письма только от имени реально существующих на серверах Gmail адресов на ваших доменах. Туда же повалятся уведомления о недоставках.

В Windows, которым я пользуюсь на работе, протестировал только что купленную Cruser. Скорость чтения около 12 Мбит/с, запись — за 20 Мбит/с. Меня такие скорости устраивали полностью. Эпик фэйл случился, когда я попробовал писать на нее с Linux. Сказать, что SanDisk Cruser в нем был медленный — ничего не сказать. Скорость записи упорно не превышала 4,5 Мбит/с. Проверил на другом ПК с Linux — тоже самое. Поигрался с размером блока, толку ноль. Флэшка должна быть в NTFS, чтобы ее видела Windows. Так что другие FS даже не стал пробовать, просто выставил ее на продажу.

Снова пришлось что-то выбирать. Перерыл все Интернеты. Точной информации о скоростях в Linux не было практически нигде. Вообще, из того, что есть в наличии и по нормальной цене, были выделены два варианта: OCZ Rally 2 и Silicon-Power LuxMini 920. Причем скорости у второй вообще были подозрительно высоки (запись до 20 Мбит/с, чтение — до 30). Эти данные подтверждали обладатели флэшек. Но практически все отзывы были от виндузятников.

У моего коллеги на работе оказалась купленная долгое время назад OCZ Rally 2 16 Гб. Он так же пользуется Linux и никаких нареканий к флэше и скоростям не имел. Реальные скорости флэшки у него — до 15 Мбит/с запись и до 25 — чтение.
Рисковать второй раз я не захотел и купил себе такую же — OCZ Rally 2 16 Гб. Главный ее минус — колпачек. Но выбора то не было.

Отформатировал флэшку в NTFS с размером сектора 16 Кб. И начал тестить. Реальная скорость в Winsows и Linux почти не отличалась. Запись была все же не 15, но плавала от 12 Мбит/с. Правда потом, почему-то несколько упала, но все равно оставалась выше 11 Мбит/с при копировании больших файлов.

В поисках решения начал мучать Гугл. Большого количества материалов не было, но несколько тем, касающихся чипсета Интела, разрешения 1680×1050 и Убунту было. В большинстве материалов упоминалось решение с использованием софтины 915resolution. Но практически сразу выяснилось, что она устарела и в последних версиях Debian и Ubuntu ее нет смысла использовать вовсе.

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

Далее нашел упоминание еще одной замечательной софтины — gtf. Она очень нужна для того, чтобы определить правильные параметры режима моего внешнего монитора.

Так же познакомился таки с системой видеовыходов в ОС. Как то раньше разбираться с этим не приходилось. А вот по мере изучения Линуксов все больше и больше приходится вдаваться в такие тонкости :) Ну да ладно. Если выполнить в консоли команду xrandr, то она покажет вам в ответ ваши текущие видеовыходы и подключенные на них мониторы. Вывод будет примерно такой:

feedbee@debian:~$ xrandr
Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 2048 x 2048
VGA connected 1680×1050+0+0 (normal left inverted right x axis y axis) 433mm x 271mm
1280×800 60.0 +
1680x1050x74.9 74.9*
[...]
LVDS connected 1280×800+0+0 (normal left inverted right x axis y axis) 331mm x 207mm
1280×800 60.0 + 60.0*
[...]
TV disconnected (normal left inverted right x axis y axis)

Такой вывод говорит, что у меня в системе один «экран» (Screen 0). Показаны его разрешения (текущее и экстремумы). Разрешения имеют значения, если мы раздвигаем мониторы (то есть делаем на каждый разную картинку; тогда они оба должны помещаться в экран). Так же показано, что у меня есть 3 видеовыхода: VGA, LVDS, TV. По VGA подключен внешний монитор, LVDS — это встроенный дисплей ноутбука. TV-выход не подключен. Звездочка напротив режима обозначает, что он активный.

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

Чтобы определить нужный режим и активировать его, надо сделать следующее:

1)Выключить ноут.

2)Подключить внешний монитор.

3)Включить ноут и сразу зукройте его (или переключитесь на внешний монитор Fn+F4), т.е. работать сейчас вы будите через внешний монитор с неродным разрешением.

4)Выполнить ~$ gtf 1680 1050 60
Я получил от команды такой вывод:
~$ gtf 1680 1050 60
# 1680×1050 @ 60.00 Hz (GTF) hsync: 65.22 kHz; pclk: 147.14 MHz
Modeline «1680x1050_60.00″ 147.14 1680 1784 1968 2256 1050 1051 1054 1087 -HSync +Vsync
Это и есть рассчитанные параметры режима для моего внешнего монитора.

5)Полученную строку добавить в /etc/X11/xorg.conf в Section «Monitor». Получится так:
Section «Monitor»
Identifier «Универсальный монитор»
Option «DPMS»
Modeline «1680x1050x74.9″ 187.00 1680 1800 1976 2272 1050 1053 1059 1099 -hsync +vsync
EndSection

6)Перезапустить X-сервер (Ctrl+Backspace).
После этого остается только переключить нужный режим на нужный видеовыход. Это делается командой:

~$ xrandr –output VGA –mode 1680x1050x74.9

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

Чтобы сбросить режим на нормальный для ноутбучного дисплея, просто выполните:

~$ xrandr –auto

P.S. Выход был найден благодаря http://forums.debian.net/viewtopic.php?p=210202&sid=18c11b5eb193a4399ca4cbbfd206e4a4

Так же полезной оказалась страничка https://answers.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+question/26807

В прошлый раз я писал, что у меня ноутбук HP Compaq nx7300 с сетевой Broadcom BCM4311 802.11b/g WLAN (rev 01). Эта карточка числится в списке поддерживаемых драйвером bc43 при условии свежести ядра (2.6.24 или старше). Чтобы проверить, какая карта у вас, выполните команды:

update-pciids
lspci -nn

В выводе последней команды в конце у меня есть следующая строка:
10:00.0 Network controller [0280]: Broadcom Cor poration BCM4311 802.11b/g WLAN [14e4:4311] (rev 01)

Это и ест ь мой сетевой адаптер Broadcom BCM4311.

Поддерживаются карты:

• bcm4303 (802.11b-only chips, uses b43legacy)
• bcm4306 (Rev. 2 uses b43legacy, Rev. 3 uses b43)
• bcm4309 (only the 2.4GHz part)
• bcm4311 rev 1 / bcm4312
• bcm4311 rev 2 / bcm4312 (needs patches for 2.6.24)
• bcm4312 (only the 2.4GHz part)
• bcm4318

Для карты BCM4306 Rev 2 или для работы с лишь 802.11b режимом используется дрвйвер b43legacy. Во всех других случаях используется b43. Об установке b43 и поговорим :)

Для ядер 2.6.25 и выше надо выполнить лишь 2 следующие пачки команд, и все:

wget http://bu3sch.de/b43/fwcutter/b43-fwcutter-011.tar.bz2
tar xjf b43-fwcutter-011.tar.bz2
cd b43-fwcutter-011
make
cd ..

export FIRMWARE_INSTALL_DIR=»/lib/firmware»
wget http://mirror2.openwrt.org/sources/broadcom-wl-4.150.10.5.tar.bz2
tar xjf broadcom-wl-4.150.10.5.tar.bz2
cd broadcom-wl-4.150.10.5/driver
sudo ../../b43-fwcutter-011/b43-fwcutter -w «$FIRMWARE_INSTALL_DIR» wl_apsta_mimo.o

Тем самым мы скачали и собрали b43-fwcutter, которому затем подсунули скачанный драйвер. Он его «вставил» в систему. Все, сетевая работает.

Про настройку сетевой читайте в старом посте.

1) Для поднятия соединения необходимо установить пакеты PPTP и PPP.

Опционально можно установить пакет для мониторинга PPP-соединения:

2) Далее требуется поправить конфиг /etc/ppp/options. Если брать за основу дефалтный файл, надо закомментить лишние строки и добавить недостающие. Но проще удалить все и вставить следующие строки:

3) Необходимо создать файл ppp-соединения в каталоге /etc/ppp/peers. Имя файла может быть любое, но его придется указывать каждый раз при подъеме соединения. Например, /etc/ppp/peers/adsl.by

В данном примере требуется заменить имя пользователя (22222pupkin), а при необходимости и IP шлюза.

3) В файл /etc/ppp/chap-secrets добавляем пароль от Интернета. Для параноиков обращаю внимание, что файл можно писать и читать только из-под root’а. Остальным пользователям заглянуть в него не удастся. В файл требуется добавить строку, в которой все значения разделены не пробелом, а табуляцией.

22222pupkin adsl.by пароль *

4) Если вы еще не указали DNS-сервера Инфонета при настройке сети, сделайте это. Это можно сделать через Network Manager, или вручную в файле /etc/resolv.conf

5) Теперь пропишем роуты. Это можно делать каждый раз после загрузки, можно сделать скрипт (например у меня роуты прописываются после поднятия wi-fi-соединения скриптом), можно засунуть в «автозагрузку». Роут нужен следующий:

192.168.0.1 — это адрес вашего модема.

Настройки готовы. Теперь можно пользоваться. Запуск соединения (из-под  root’а):

Останов всех ppp-соединений:

Останов только данного соединения:

Просмотр статистики (если соответствующий ставили пакет в начале):

(Чтобы выйти из просмотра статистики, наберите !q)

После команды pon adsl.by между вами и сервером поднимается соединение по протоколу PPP, поверх которого идет туннелирование PPTP. Соединению PPP соответствует появившийся сетевой адаптер ppp0. Если создать больше одного соединения, появятся адаптеры ppp1 и т.д. Именно на этот адаптер прописывается default route автоматически (если ваши настройки соответствуют приведенным выше).

Удачи! ;)

В своем блоге я опишу результат собственных изысканий по подъему wi-fi адаптера на ноутбуке HP Compac nx 7300 для дистрибутива Debian (etch). Стоит упомянуть, что вся информация актуальна на момент ноября 2008 года, и что все описанное ниже не претендует на «руководство», это лишь описание моих действий и результатов.

UPD: Внимание! В связи с выходом Debian 5.0 Lenny сначала прочитайте эту запись!

Гуглинг на тему моего wi-fi в Debian привел к замечательному описанию-руководству по поднятию беспроводной сети. В этом мануале рассказывается про установку драйверов для беспроводных адаптеров на базе чипсетов Broadcom 43xx и 1390. Вот как раз 4311 и установлен в ноутбук HP Compac nx7300.

Драйвера от Broadcom есть и под Linux, и под Windows. Для линукса есть даже 2 разных версии:

• Linux b43 / bcm43xx driver (начиная с ядра 2.6.24 его просто переименовали),
• Linux b43_legacy driver (отделен в ядре 2.6.24 для совместимости со старыми чипсетами).

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

Сначала требуется определить, какой сетевой адаптер используется. Как это сделать, написано в отдельном руководстве. Самый простой вариант — выполнить следующие команды:

update-pciids

lspci -nn

В выводе последней команды в конце у меня есть следующая строка:

10:00.0 Network controller [0280]: Broadcom Cor poration BCM4311 802.11b/g WLAN [14e4:4311] (rev 01)

Это и ест ь мой сетевой адаптер  Broadcom  BCM4311. Теперь пробуем заставить его работать. Стоит отметить, что до установки дров сетевой интерфейс wlan0 просто не существует, а диод на ноуте не горит и не включается кнопкой.

Установкой я занимался по порядку, описанному в статье. Принцип там такой: попробуйте сделать это, если не поможет, попробуйте это, если не поможет, попробуйте это и т.д.

Сразу отмечу, что ядро у меня 2.6.18 (т.е. меньше) 2.6.24, а значит b43_legacy и Native b43 driver рассматривать смысла нет вообще. Cтавим Native bcm43xx driver.

Руководство по установке этого драйвера начинается с этого места. Подзаголовки (option 1, 2, 3, 4, 5) — это этапные варианты установки драйвера. Последним пунктом идет установка Ndiswrapper’а. Я прошел все эти 6 уровней, адаптер заработал у меня только после установки  Ndiswrapper’а. Если у вас не адаптер BCM4311 в связке с linux kernel 2.6 .18, рекомендую попробовать все варианты по порядку (пройти этот увлекательный к вест :), иначе можете сразу приступать к установке  Ndiswrapper’а.

Если в конце концов у вас таки появилось устройство wlan0, поздравляю, драйвер установлен!

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

allow-hotplug wlan0

iface wlan0 inet static

wireless-essid ZyXEL

address 192.168.0.30

netmask 255.255.255.0

gateway 192.168.0.1

ZyXEL — точка доступа, IP понятны, вторая строка обозначает, что IP пр описаны статически, а не по DHCP. Так же есть файл /home/feedbee/wlan следующего содержания:

echo "Loading ndiswrapper..."

modprobe ndiswrapper

echo "Setting mode Managed..."

iwconfig wlan0 mode Managed

echo " -- Setting ESSID"

iwconfig wlan0 essid ZyXEL

echo " --Setting to channel 6..."

iwconfig wlan0 channel 6

echo " --Turning on managed mode..."

iwconfig wlan0 mode Managed

echo " --Setting encryption key"

iwconfig wlan0 key restricted E3374866EE

echo "Bringing up interface wlan0..."

ifconfig wlan0 up

echo "Disable interface eth0 to kill its routes. .."

ifconfig eth0 down

echo "--Setting routing..."

route add default wlan0

route add -net 81.25.32.0 netmask 255.255.255.0 gw 192.168.0.1 wlan0

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

В этом файле все должно быть понятно, отмечу только следующие моменты. Последняя строка строго индивидуальна, она прописывает нужный для работы роут на провайдера. Вообще, после поднятия интерфейса wlan0 остаются старые роуты на eth0 и к ним добавляются новые на wlan0. В этом случае роутиговая система ядра пытается слать пакеты через eth0 даже в том случае, если сетевой кабель не подключен. Именно по этой причине в файле wlan гасится интерфейс eth0 (при этом роуты на него автоматически удаляются). Дефалтные роуты на wlan0 прописываются автоматически.

Строка iwconfig wlan0 key restricted E3 374866EE в файле обозначает, что используется WEP-шифрование.  E3374866EE — это ключ, который введен на точке (в HEX-формате). Для WEP-64 это 10 шестнадцатеричных цифр, для WEP-128 — 26. Если шифрование не используется, эту строчку можно просто убрать.

Если интерфейс wlan0 и соединение с точкой доступа поднялись, но пакеты на сеть не ходят (хосты не пингуются), разбирайтесь с роутами.