Новости :

Использование доменных аккаунтов Windows аутентификации в squid

Использование доменных аккаунтов Windows аутентификации в squid

Задача.
Необходимо аутентифицировать пользователей в squid на основе доменных аккаунтов. Не всегда подходит классическая схема учета трафика по IP адресам примеры случаев когда подобная ситуация не устраивает достаточно полно описаны в [1]. Кроме того, стояла задача защищать подключение к Internet в большой сети от приносимых ноутбуков.

Инструменты.
1. OC FreeBSD использовались версии 4.11-RELEASE и 5.3-RELEASE-p5
2. Windows 2003 - контроллер домена.
3. samba-3.0.11
4. squid-2.5.8


Сеть и топология.
Домен - piva.net
Контроллер домена - lab002.piva.net
Рабочие станции соответственно - labxxx.piva.net
Машина на которой установлен squid - lab003.piva.net

Практическое руководство.
1. Настройка клиента Kerberos
В FreeBSD существует две реализации Kerberos производства MIT и HEIMDAL, соединиться с сервером Kerberos используемым в Windows 2003 у меня получилось только в случае использования Kerberos клиента производства HEIMDAL. Более того, он работает, только если версия старше 0.6. В пятой ветке FreeBSD в базовой системе идет Kerberos производства HEIMDAL версии 0.6.1, поэтому для его использования необходимо добавить в файл /etc/make.conf следующие параметры:

MAKE_KERBEROS5 = yes
ENABLE_SUID_K5SU = yes

После этого необходимо пересобрать мир (make buildworld && make installworld). Как это делается, я описывать не буду, обратитесь к руководствам по этой теме.
В базовой системе четвертой версии FreeBSD идет клиент Kerberos производства HEIMDAL однако довольно старой версии 0.5.1. Для использования сервера Kerberos производства HEIMDAL версии 0.6.х в четвертой версии FreeBSD необходимо установить порт

/usr/ports/security/heimdal.

Важное замечание - DNS сервер, прописанный в /etc/resolv.conf ДОЛЖЕН ЗНАТЬ о зоне используемой для построения Windows домена (наиболее удобный путь настроить его как вторичный DNS сервер). Клиент Kerberos будет искать записи типа SRV _kerberos._udp.

Настраиваем клиента Kerberos. В файл /etc/krb5.conf необходимо добавить информацию о сервере Kerberos в моем случае это:

[libdefaults]
default_realm = PIVA.NET
[realms]
PIVA.NET = {
        kdc = lab002.piva.net
        admin_server = lab002.piva.net
}


Все остальные опции можно оставлять по умолчанию. Попробуем соединиться с сервером Kerberos.

[root@lab003 ~] kinit -p Administrator@piva.net
Administrator@PIVA.NET's Password:


и вводим пароль, система должна выдать

kinit: NOTICE: ticket renewable lifetime is 1 week

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

[root@lab003 ~] klist
Credentials cache: FILE:/tmp/krb5cc_0
        Principal: administrator@PIVA.NET

  Issued           Expires          Principal
Feb 22 17:10:40  Feb 23 03:10:38  krbtgt/PIVA.NET@PIVA.NET


Отлично, соединение есть.

2. Samba
Устанавливаем /usr/ports/net/samba3/
Необходимые опции

[X] ADS With Active Directory support
[X] WINBIND With WinBIND support


Далее необходимо настроить smb.conf
Отличное руководство по этому процессу [6].
Замечание: на четвертой версии FreeBSD при использовании Kerberos клиента версии 0.6.3 программа wbinfo не могла проверить наличие доверительного аккаунта в домене(wbinfo -t). Проблема решилась использованием security level domain вместо ads.
Приведу опции, которые добавлял я:

workgroup = piva
server string = lab003
netbios name = lab003
realm = piva.net
security = ads
password server = lab002.piva.net
encrypt passwords = yes

winbind separator = +
winbind use default domain = yes
winbind uid = 10000-20000
winbind gid = 10000-20000
winbind enum users = yes
winbind enum groups = yes

template homedir = /home/winnt/%D/%U
template shell = /usr/local/bin/bash

Как и советует автор [1], добавим необходимы нам имена в файл
/usr/local/etc/lmhosts

10.10.10.1 lab001.piva.net
10.10.10.2 lab002.piva.net
10.10.10.3 lab003.piva.net


Входим в домен:
net ads join -U Administrator%password
Joined 'LAB003' to realm 'PIVA.NET'


3. winbindd
Следующим шагом у нас запуск winbindd.
Я запускал с ключиком -d10, в debug режиме.

Проверить работоспособность winbind можно командой wbinfo Необходимо удостовериться, что winbind нормально работает и может получать списки пользователей и групп с сервера.

[root@lab003 ~] wbinfo -t
checking the trust secret via RPC calls succeeded
Это означает что доверительный аккаунт компьютера создан.

Посмотрим на список пользователей.
[root@lab003 ~] wbinfo -u (для просмотра пользователей)
administrator
guest
support_388945a0
lab002$
krbtgt
iusr_lab002
iwam_lab002
lab001$
iwam_lab001
iusr_lab001
lab003$
pablo
lab005$

Как видно, аккаунт для нашего компьютера уже создался (lab003$) и взаимодействие налажено.

Попробуем аутентифицироваться в домене:

[root@lab003 ~] wbinfo -a administrator%password
plaintext password authentication succeeded
challenge/response password authentication succeeded

На этом настройку winbind можно считать законченной.

4. squid
Устанавливаем /usr/ports/www/squid
Насколько видно из Makefile helper для winbind включен по умолчанию. Т.е. ничего особенного конфигурировать не нужно.
После установки при запущенном winbindd необходимо проверить работу helper'а Для этого запускаем

/usr/local/bin/ntlm_auth --helper-protocol=squid-2.5-basic
Вводим piva+administrator password

Если получен ответ OK значит все отлично. Иначе необходимо смотреть логи winbindd

Настраиваем собственно сам squid. Отличное руководство по это делу [3]

В данном случае были добавлены следующие стороки:

auth_param ntlm program /usr/local/bin/ntlm_auth
--helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 10
auth_param ntlm max_challenge_reuses 0
auth_param ntlm max_challenge_lifetime 2 minutes

auth_param basic program /usr/local/bin/ntlm_auth
--helper-protocol=squid-2.5-basic
auth_param basic children 10
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours

Данная конфигурация описывает два helper'a один дня IE (ntlmssp) другой для всех остальных пользователей (mozilla, opera, etc).

Необходимо отметить что для нормальной работы из броузера у пользователя под который работает squid должно хватать прав для обращения к сокету на котором слушает winbindd. Согласно man ntlm_auth это winbindd_privileged в $LOCKDIR. В моем случае сокет находиться в /var/db/samba/winbindd_privileged. Для решения проблемы я изменил группу владельца этой директории на squid.

После этого можно приступать к полноценному тестированию из веб броузера.

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

6. Дополнительный функционал
Дополнительно можно использовать возможность управлять доступом в Internet из Windows. Для этого можно воспользоваться параметром --require-membership-of= ntlm_auth. Как видно из названия при аутентификации helper будет требовать наличие пользователя в определенной группе. В моем случае указание там названия группы проблемы не решило. Пришлось указывать универсальный идентификатор группы в домене (SID). Узнать его можно с помощью уже знакомой программы wbinfo. Например, если необходимо узнать SID группы inetusers:

[root@lab004 ~] wbinfo -n inetusers
S-1-5-21-1828638205-4279006917-513177360-1121 Domain Group (2)

После этого необходимо изменить конфигурационный файл squid указав в местах описания хелперов необходиму директиву.
auth_param ntlm program /usr/local/bin/ntlm_auth
--require-membership-of=S-1-5-21-1828638205-4279006917-513177360-1121
--helper-protocol=squid-2.5-ntlmssp

Теперь пользователи которые не входят в группу inetusers не смогут выйти в Internet.

Источники.

1. http://www.opennet.ru/base/net/win_squid.txt.html
2. http://www.squid-cache.org
3. http://www.squid-cache.org/Doc/FAQ/FAQ-23.html
4. http://devel.squid-cache.org/ntlm/squid_helper_protocol.html
5. http://groups-beta.google.com
6. http://samba.org/samba/docs/man/Samba-HOWTO-Collection/domain-member.html
7. http://www.wlug.org.nz/ActiveDirectoryKerberos

 

Автор: Misha Volodko

Материал взят с сайта linux.ru

Комментарии: (0) | Linux | 2006-06-05

Регистрация в DMOZ aka The Open Directory Project (ODP)

Регистрация в DMOZ aka The Open Directory Project (ODP)

Автор: Фил Крэвин
www.webworkshop.net

Перевод: Webmasterpro

Добавление сайта в Open Directory может оказаться затруднительным. Известно, что присутствие сайта в DMOZ повышает рейтинг в поиске Google, но процесс регистрации может длиться очень долго. В этой статье я объясню, почему регистрация часто занимает много времени и что нужно делать, когда заявка на добавление является причиной задержки. Но сперва я объясню, что такое DMOZ и почему стоит обратить на него внимание.

DMOZ (от Directory Mozilla, еще известен как The Open Directory Project (ODP)) — большой, разбитый по категориям каталог сайтов, который поддерживается добровольцами. Каждый сайт или страница просматривается вручную перед добавлением в каталог. Регистрация бесплатна. На самом деле немного людей используют DMOZ для поиска в той же мере как Yahoo!, поэтому каталог сам по себе является слабым трафикогенератором. Однако его базой можно воспользоваться в целях создания собственного каталога сайтов. Одним из крупных сайтов, использующих DMOZ, является Google. Фактически, каталог Google не что иное как загруженный DMOZ'овский каталог.

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

Внесение в DMOZ создает две важных ссылки на сайт — одну из DMOZ (Google сканирует DMOZ точно так же как любой другой сайт) и одну из каталога Google. Обе обычно имеют приличный PageRank. Теперь, добавив сюда ссылки на тысячах маленьких сайтов, которые загрузили и используют каталог DMOZ, вы поймете, почему весьма выгодно для сайта быть внесенным в DMOZ. Простое внесение в DMOZ может поднять значение Toolbar PageRank от 3 до 4, и даже от 4 до 5.

Почему регистрация в DMOZ занимает много времени?

Во время написания статьи, главная страница DMOZ заявляла о наличии 57,251 модератора (добровольцев, которые просматривают и добавляют сайты в каталог), но это не совсем правильная цифра. На самом деле у них нет столько модераторов, даже близко к этому. Это число — общее количество модераторов с момента старта проекта. Большинство из них больше не работают. Существенная часть тех, которые еще являются модераторами, неактивны или редко проявляют активность. Так что число модераторов, активно рассматривающих и добавляющих сайты, относительно мало.

С другой стороны, в очереди на рассмотрение стоит множество сайтов. Каждый модератор отвечает только за свой раздел (категорию). Некоторые модераторы имеют дело с маленькими разделами и малым числом заявок и соответственно могут справиться очень быстро. Другие просто ошеломлены горой нерассмотренных сайтов, и шансы пробраться через них в ближайшем будущем невелики. Но огромные завалы и относительно низкое число активных модераторов — не единственные причины затянувшегося процесса регистрации сайта. Во многих случаях причиной задержки является ошибка человека, предоставившего заявку на размещение.

Представьте как кто-то подает заявку на внесение сайта в категорию, которая является близкой по его содержанию, но сайт на самом деле принадлежит к другой категории. Что случится? Заявка ожидает в очереди категории, на которую представлена заявка. Рано или поздно наступает ее очередь, и модератор находит, что сайт принадлежит к другой категории. Этот модератор не может редактировать другую категорию, так что заявка будет передана к другой категории и добавлена в очередь. Заявка не пойдет вне очереди из-за того только, что уже ждала в другой. В конечном счете наступит снова ее черед и она будет рассмотрена заново. Это — простая последовательность событий, когда сайт представлен к неправильной категории. На практике, тем не менее, часто случается по-иному.

Когда первый модератор рассматривает сайт, часто в прошествии долгого времени после подачи заявки, и находит, что он не принадлежит в категории, что он (она) может подумать? «Если Вы не побеспокоились найти правильную категорию для сайта, не буду этого делать и я». Так что сайт часто отсылается к категории, которая является более близкой, но совсем не обязательно к нужной. Новый модератор в конечном счете добирается до него и посылает его к более соответствующей категории — возможно на этот раз к нужной, а может и нет. Задержки прибавляются только из-за того, что вебмастер, подавший заявку на внесение сайта, не уделил достаточно времени на выбор нужной категории.

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

Почему некоторые сайты получают отказ?

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

Другая причина отказа — из-за заявки. Если Title (заголовок) и Description (описание), заполняемые при регистрации не соответствуют рекомендациям DMOZ, то некоторые модераторы склонны считать так: «если Вы не уделяете небольшое время на это, почему же я должен беспокоиться и переписывать это за Вас?», и отклоняют заявку. Лично, я нахожу трудным поверить, что модераторы сделали бы это, но я слышал о таких случаях. Так что читайте и следуйте рекомендациям при заявке сайта. Описание предназначено для того, чтобы дать людям понять, что может быть найдено на сайте, а не для раскрутки.

Людей не уведомляют об отклонении их сайтов, и многие думают, что их заявки все еще ожидают своей очереди, хотя на самом деле они уже отклонены. Есть только один способ узнать состояние заявки — заставить кого-то на той стороне сообщить это Вам. К счастью, есть место, где Вы можете сделать это. Это — Open Directory Public Forum, который поддерживается некоторыми модераторами. Они помогают в выяснении состояния дел в процессе внесения сайта. Если сайт был отклонен, они сообщат вам и скорее всего укажут причину. Иногда модераторы могут даже рассмотреть сильно просроченную заявку, но только если определенная категория не имеет модератора, или он не подает никаких признаков выполнения своих обязанностей на протяжении значительного времени.

О модераторах DMOZ

Хотя я упомянул ранее, что активных модераторов не так много как указано на главной странице DMOZ, но большинство тех, которые являются активными, очень энергичны. Они хотят добавлять сайты с уникальным содержанием и стараются улучшить каталог; фактически, они напоминают мне колонию муравьев, занятых вокруг и непосредственно в муравейнике (каталоге), возводя его по крупинкам. Вопреки мнению некоторых людей, они заботятся о добавлении новых сайтов, несмотря на сложности, возникающие в процессе работы.

06.11.2003

Комментарии: (0) | Интернет и Сети | 2006-06-04

Dmoz.org - Открытый каталог

Ура! Наш проект принят в общемировой каталог Dmoz.org. Причём нам не пришлось ждать несколько месяцев, а всего две недели. Про каталог можно прочесть здесь, мы добавлены вот в эту ветку каталога.

Комментарии: (0) | Новости сайта | 2006-06-04

Система учета трафика в считанные минуты

Система учета трафика в считанные минуты

Оригинал статьи в журнале Xakep

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

Chillin

Возьмем самый распространенный случай, когда в твой подъезд/универ/офис заведен кабель от прова, выделен статический IP-адрес, а в роли маршрутизатора выступает старенький комп с двумя сетевухами и установленной FreeBSD 5.х. Что касается фряхи, то она у нас (для остроты ощущений) будет не совсем обычной. Мы откажемся от использования штатных файрволов ipfw2/ipfilter и прикрутим OpenBSD.шный pf, по фичам и возможностям не имеющий себе равных среди свободно распространяемых брандмауэров.

Ядра - чистый изумруд

Наличие поддержки интерфейса обратной петли (loopback), сети Ethernet и фильтров пакетов Беркли обязательно:

device loop

device ether

device bpf

Следующим шагом будет объявление директивой options переменных PFIL_HOOKS и RANDOM_IP_ID (генерируем случайное значение в поле ID IP-пакета вместо того, чтобы каждый раз увеличивать его на единицу). Только так мы получим практически полноценную поддержку packet filter нашим ядром:

options PFIL_HOOKS

options RANDOM_IP_ID

Поддержка практически полноценная, так как ALTQ и работа с протоколом IPv6 пока находится в стадии бета-тестирования, но не волнуйся: ни то ни другое нам не понадобится. С помощью утилиты config производим синтаксический анализ конфигурационного файла ядра и создаем компиляционный каталог со всеми необходимыми заголовочными файлами:

# config MIDIAN

Ненадолго отвлекаемся от ядерных экспериментов и устанавливаем packet filter из портов:

# cd /usr/ports/security/pf

# make install clean

Далее переходим в директорию с сырцами и не спешим, так как дедовский метод сборки ядра (make clean && make depend && make && make install) для пятой ветки уже не подходит:

# cd /usr/src

# make buildkernel KERNCONF=MIDIAN

# make installkernel KERNCONF=MIDIAN

Ставим на автомат

В отличие от большинства файрволов, packet filter не использует систему Syslog и регистрирует все события с помощью собственного журнального демона pflogd. Отслеживаемые на псевдоустройстве /dev/pf пакеты перенаправляются на сетевой интерфейс pflog0, откуда, попав в компетенцию pflogd, в двоичном формате tcpdump методично записываются в файл /var/log/pflog.

В конфиге /etc/rc.conf следующими записями разрешаем автоматическую загрузку pf и pflogd при старте системы (последней директивой pf_conf задается путь к файлу с правилами fw):

# vi /etc/rc.conf

pf_enable="YES"

pf_logd="YES"

pf_conf="/usr/local/etc/pf.conf"

Но этого недостаточно, так как по умолчанию фряшные системные файлы ничего не знают о директивах pf_*, поэтому придется подготовить init-скрипт, содержащий всю необходимую информацию о специальных переменных и модулях pf. К счастью, кодить нам не придется, все уже сделано до нас:

# mv /usr/local/etc/rc.d/pf.sh.sample /usr/local/etc/rc.d/pf.sh

Создать универсальный набор рулесетов файрвола, ввиду специфики условий работы, не представляется возможным, поэтому опишу только общую часть, которая затрагивает систему NAT и редирект http-трафика:

# vi /usr/local/etc/pf.conf

// внешний сетевой интерфейс

ext_if="fxp0"

// внутренний сетевой интерфейс

int_if="fxp1"

// в таблицы радикса заносим айпишники клиентов и доверенные подсети

table persist file "/usr/local/etc/nat.conf"

table { 192.168.5.0/24, 192.168.7.0/24 }

// NAT.им юзверей (производим трансляцию адресов)

nat on $ext_if from to any -> $ext_if

// заворачиваем на проксик все клиентские http-запросы

rdr on $int_if inet proto tcp from to ! port \

{ 80, 8080, 8101 } -> 127.0.0.1 port 3128

Предлагаю дальнейшую разработку правил firewall.а возложить на твои мужественные/женственные плечи и перейти непосредственно к нашим клиентам, страстно жаждущим получить доступ в Сеть:

# vi /usr/local/etc/nat.conf

192.168.5.2/32

192.168.5.3/32

192.168.5.9/32

Теперь с помощью механизма sysctl включаем перенаправление IPv4-пакетов между сетевыми интерфейсами (скажу по секрету: сетевые подсистемы Linux и BSD спроектированы так, что форвардинг должен работать по дефолту, однако такое поведение запрещено рабочими документами RFC, именно поэтому нам приходится ручками ковырять sysctl):

# vi /etc/sysctl.conf

net.inet.ip.forwarding=1

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

# reboot

Считаем трафик, не отходя от кассы

Коллекция портов FreeBSD . настоящая панацея для ленивого юниксоида. Заботливые разработчики подготавливают правила сборки программ, размещая рядом тщательно протестированные diff.чики, конфиги и скрипты. Отказаться от таких удобств было бы просто преступлением:

# cd /usr/ports/net/ipfm

# make install clean

# cd /usr/ports/www/apache13

# make install clean

# mkdir /usr/local/www/data/traffic

Этими нехитрыми командами мы поставили саму считалку трафика и web-сервер Apache. Для отображения пользовательской статистики воспользуемся встроенным средством апача, а именно опцией Indexes директивы Options (листинг каталога при отсутствии index.html).

Но об этом чуть позже, а пока конфигурим его величество ipfm:

# vi /usr/local/etc/ipfm.conf

// определяем внутренний сетевой интерфейс

DEVICE fxp1

// не учитываем локальный трафик

LOG 192.168.5.0/255.255.255.0 NOT WITH 192.168.0.0/255.255.0.0

// задаем имя журнального файла в формате год/месяц_прописью/число

FILENAME "/var/log/ipfm/%Y/%B/%d"

// сбрасываем данные из буферов каждые полчаса

DUMP EVERY 30 minutes

// никогда не очищаем статистику, за нас это делает cron

CLEAR NEVER

// не преобразовываем IP-адреса в доменные имена
// не будем переходить в неразборчивый режим

NOPROMISC

Далее утилитой crontab вызываем текстовый редактор (тот, что определен в переменной окружения $EDITOR) для постановки следующих команд на исполнение в заданное время:

# crontab .e

5,35 * * * * cp .p .R /var/log/ipfm/* /usr/local/www/data/traffic

30 7 1 * * kill .s HUP `cat /var/run/ipfm.pid`

Таким образом, всякий раз при наступлении пятой и тридцать пятой минуты будет происходить рекурсивное копирование каталогов с полученной от ipfm статистикой в директорию, доступную апачу. Сам web-сервер Apache можно вообще не конфигурировать, нас вполне устроят настройки по умолчанию. Хотя особо педантичные товарищи могут проверить, установлена ли опция Indexes для корневого каталога /usr/local/www/data:

# egrep -n 'data|Indexes' /usr/local/etc/apache/httpd.conf

378:

387:Options Indexes FollowSymLinks MultiViews

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

# /usr/local/sbin/ipfm -c /usr/local/etc/ipfm.conf -p /var/run/ipfm.pid

# /usr/local/sbin/apachectl start

Теперь, чтобы посмотреть статистику, достаточно в браузере набрать ip.address.http.server/traffic/.

Подсчитал? Теперь сэкономь!

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

% wget www.squid-cache.org/Versions/v2/2.5/squid-2.5.STABLE4-

YEARMONTHDAY.tar.gz

% tar zxvf squid-2.5.STABLE4-YEARMONTHDAY.tar.gz

% cd squid-2.5.STABLE4-YEARMONTHDAY

После выполнения этой стандартной процедуры начинаем выяснять, с какими параметрами нам нужно скомпилировать кальмара (не советую здесь баловаться с флажками оптимизации, так как squid беспечно работает с памятью, выделяемой под хранимые объекты, sigh):

% ./configure --help | more

% ./configure --prefix=/usr/local/squid --sysconfdir=/etc/squid

--enable-storeio="ufs diskd" --enable-poll --enable-pf-transparent

--disable-ident-lookups --enable-removal-policies="lru heap"

--disable-wccp --enable-err-language=Russian-koi8-r

В данном случае ключевым аргументом сценария configure является параметр.enable-pf-transparent. Именно он дает нам возможность насладиться прелестями прозрачного проксирования. Поясню для тех, кто не в курсе: с помощью прозрачного проксирования для клиентских хостов создается иллюзия прямого соединения с www-узлами интернета (клиентские браузеры не нужно настраивать специальным образом, что очень удобно при наличии в сети большого числа машин), так как все пакеты, в адресах назначения которых содержится 80/tcp порт, будут автоматически перенаправляться squid.у на 3128/tcp порт. С этим разобрались, теперь давай от теории вернемся к созидательной практике, тем более что configure подкинул нам повод для размышлений:

WARNING: Cannot find necessary PF header file

Transparent Proxy support WILL NOT be enabled

Однако не все так просто, как могло показаться на первый взгляд.

Попробуем с этим разобраться:

% grep pf config.log

configure:3843: checking for net/pfvar.h

configure:3849:23: net/pfvar.h: No such file or directory

Как видно из сообщения об ошибке, сценарий configure в директории /usr/include/net не смог найти необходимый для успешной компиляции заголовочный файл pfvar.h. Что ж, придется ему помочь:

# ln -s /usr/local/include/pf/net/pfvar.h /usr/include/net/pfvar.h

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

PF Transparent Proxy enabled

Вот теперь можно переходить к самой компиляции кальмара:

% gmake

И, убедившись в отсутствии ошибок при сборке, инсталлируем:

# gmake install

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

# ln -s /usr/local/squid/var/logs /var/log/squid

Игры с кальмаром

Ниже перечислю только первостепенные параметры кэша. Более подробную инфу по настройке squid.а ты найдешь в многочисленных руководствах на сайте squid.opennet.ru.

# vi /etc/squid/squid.conf

// указываем адрес, на котором squid будет слушать клиентские

запросы

http_port 127.0.0.1:3128

// выделяем под кэш требуемый объем оперативки и дискового

пространства (в данном случае 1 Gb)

cache_mem 128 MB

cache_dir diskd /usr/local/squid/var/cache 1024 16 256 Q1=72 Q2=64

// не ленимся вести журналы работы

cache_access_log /usr/local/squid/var/logs/access.log

cache_log /usr/local/squid/var/logs/cache.log

cache_store_log none

// снижаем привилегии

cache_effective_user squid

cache_effective_group squid

// работаем в режиме транспарентной прокси

httpd_accel_host virtual

httpd_accel_port 80

httpd_accel_with_proxy on

httpd_accel_uses_host_header on

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

# pw groupadd squid -g 3128

# pw useradd squid -u 3128 -c "squid caching-proxy pseudo user"

-g squid -d /usr/local/squid -s /sbin/nologin

Назначаем корректные права доступа для кэша, директории с журнальными файлами, а также для специального псевдоустройства, позволяющего программам (скажем, pfctl) контролировать поведение packet filter через системные вызовы ioctl(2):

# chown squid:squid /usr/local/squid/var/cache

# chown squid:squid /usr/local/squid/var/logs

# chgrp squid /dev/pf

# chmod g+rw /dev/pf

Создаем кэш прокси-сервера, иначе говоря, обнуляем структуру каталогов:

# /usr/local/squid/sbin/squid -z

2004/01/30 17:24:28| Creating Swap Directories

# /usr/local/squid/sbin/squid

Альтернативным вариантом будет запуск кальмара с аргументами: ?-D> для пропуска DNS-теста (помогает при модемном соединении либо при неверно настроенном сервере имен) и ?-Y> для более быстрого восстановления после сбоев:

# /usr/local/squid/sbin/squid .DY

Вуаля. Транспарентный проксик созрел и готов принимать наши запросы:

# netstat -na --inet | grep 3128

tcp4 0 0 127.0.0.1.3128 *.* LISTEN

Разбор полетов

Да, все шустро и безглючно воркает, но если ты взглянешь в /var/log/squid, то, скорее всего, тебе станет дурно: за какие-то пару часов работы сквид произведет на свет вагон и маленькую тележку журнальных записей о www-соединениях в неудобочитаемом виде (конечно, все зависит от количества клиентов и интенсивности подключений). Чтобы разобрать эту кашу, никакие калькуляции в уме/в столбик не помогут. Поэтому воспользуемся sarg.ом - одной из самых популярных на сегодняшний день программ для построения детальных html-отчетов на основе лог-файлов squid.а. И здесь нас выручает дерево портов:

# cd /usr/ports/www/sarg

# make install clean

Большинство параметров sarg.а можно оставить без изменений, перечислю только те, на которые стоит обратить особое внимание:

# vi /usr/local/etc/sarg/sarg.conf

// абсолютный путь до лог-файла squid

access_log /usr/local/squid/var/logs/access.log

// директория, куда будут помещаться html-отчеты

output_dir /usr/local/www/data/reports

// не учитываем локальный www-трафик

exclude_hosts 192.168.5.0

// создаем отметки времени в европейском формате

date_format e

// для экономии места перезаписываем отчеты

overwrite_report yes

И, наконец, через crontab передаем демону cron новые задания: каждое первое число месяца производить ротацию логов сквида и ежечасно обрабатывать логи sarg.ом (если ты считаешь, что запускать такие задания от имени суперпользователя несколько рискованно, то используй команду crontab .u username):

# crontab -e

0 8 1 * * /usr/local/squid/sbin/squid -k rotate

0 * * * * /usr/local/bin/sarg -f /usr/local/etc/sarg/sarg.conf

Chillout

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

Таблицы радикса

Таблицы радикса (radix tables) - это именованные массивы, предназначенные для хранения IP-адресов и целых подсетей. Таблицы очень удобно использовать, когда нужно оперировать большими диапазонами адресов. К примеру, немедленно блокируем все соединения с айпишниками, зарезервированными для внутреннего использования (см. RFC 1918):

table const { 10/8, 172.16/12, 192.168/16 }

block in log quick on $ext_if inet from to any

block in log quick on $ext_if inet from any to

Приручаем VPN

Для того чтобы клиенты могли выходить в инет, используя виртуальные частные сети, нужно с помощью packet filter разрешить исходящие соединения по протоколу gre:

pass out on $ext_if inet proto tcp from any to any flags S/SA keep state

pass out on $ext_if inet proto { udp, icmp, gre } all keep state

Интересные тулзы

pftop (www.eee.metu.edu.tr/~canacar/pftop/) . утилита для мониторинга работы pf в реальном времени.

pfstat (www.benzedrine.cx/pfstat.html) . утилита для сбора статистики pf и построения красивых графиков с использованием библиотеки gd.

hatchet (www.dixongroup.net/hatchet/) . анализатор лог-файлов pf.

INFO

В данном примере fxp0 . это внешний сетевой интерфейс, имеющий выделенный статический IP-адрес, а fxp1 . внутренний интерфейс с айпишником из диапазона адресов класса С (fxp - это драйвер семейства сетевых карт Intel EtherExpress 100).

DANGER

Если в роли шлюза выступает маломощный компьютер, то для более быстрой обработки данных при настройке ipfm не задавай сортировку логов и используй опции NORESOLVE, NOPROMISC.

WWW

pf4freebsd.love2party.net/

robert.cheramy.net/ipfm/

solarflux.org/pf/

www.openbsd.org/faq/pf/index.html

www.aei.ca/~pmatulis/pub/obsd_pf.html

Деликатный сивисап

Грамотно синхронизировать дерево портов и исходный код FreeBSD нам поможет система cvsup. Фича заключается в том, что достаточно всего один раз получить полный набор исходных текстов, а затем с помощью cvsup мержить только произошедшие изменения. Создаем конфигурационный файл, содержащий всю информацию, необходимую для обновления системы. Здесь мы выбираем ближайший миррор, указываем месторасположение сырцов, задаем релизный тег, а также, помимо сырцов, обновляем и коллекцию портов:

Конфиг ~/cvs-supfile

*default host=cvsup5.ru.FreeBSD.org

*default base=/usr

*default prefix=/usr

*default release=cvs tag=RELENG_5_1

*default delete use-rel-suffix

*default compress

src-all

ports-all tag=.

Теперь проапдейтиться можно следующим образом:

# /usr/local/bin/cvsup -g -L 2 ~/cvs-supfile

Подробнее об используемых параметрах cvsup:

-g . не используем графическую версию сивисапа;

-L 2 . устанавливаем степень журналирования событий.

Автор: Andrey Matveev

Комментарии: (0) | Linux | 2006-06-03

Инсталляция и настройка ZyXEL OMNI ADSL USB под ОС Linux

Инсталляция и настройка ZyXEL OMNI ADSL USB под ОС Linux

Итак, начнем. Первое:

Сбор сведений о модеме

90% секретной информации находится в открытых исходниках.
У меня имелся настроенный доступ в Интернет под Windows XP. Была получена следующая информация:

Модем в Windows XP (System Info) определялся как Alcatel Telecom DinaMiTe modem, c PID = 0xa5a5 и VID =0x06b9.
В системе он представлен в виде сетевой карты с названием (RFC1483 mode). Т.е. Драйвер модема моделирует сетевую карту:
TCP/IP настроен на использование статического IP адреса. Забыл картинку сделать. Но тут надо подключить воображение. У Вас все получиться.
IP адрес, маска подсети и ip адрес шлюза получены. Адреса DNS серверов записаны.
Различные параметры относящиеся к модему записаны в текстовый файл.
Файлы firmware (Fw-usb.bin, init-usb.bin) на всякий случай загружены.
Все сложено на USB flash drive. Все готово к dive into Linux.
Перезагрузка. Lilu. Linux. Bash. root. rm -rf / :-)
Поехали.
Исходная конфигурация

Компьютер с usb портами. Да, ничего специального не требуется, просто c usb портами.
Вновь установленная система Mandrake 10 Offical Discovery с ядром 2.6.3-7mdk. Именно с этим ядром, мы же не хотим парится.

Установка требуемых rpm пакетов

Для нашего простого случая (RFC1483 routed) требуется не так много библиотек и все они идут в поставке Mandrake 10, вот повезло.

Если ставим бинарный rpm (только скомпилированные драйвер и скрипты) то требуются только следующие пакеты:

libusb0.1_4-0.1.7-1mdk.rpm - библиотека доступа к USB устройствам
libpcap0-0.8.1-1mdk.rpm - packet capture библиотека
liblinux-atm1-2.4.1-3mdk.rpm - библиотеки поддержки ATM в Linux
linux-atm-2.4.1-3mdk.prm - поддержка ATM в Linux

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

kernel-source-2.6.3-7mdk.rpm или исходные коды ядер серии 2.6.
libusb0.1_4-devel-0.1.7-1mdk.rpm - заголовочные файлы для разработки
liblinux-atm1-devel-2.4.1-3mdk.rpm - файлы разработчика Linux ATM API

Как найти библиотеки? Запускаем менеджер rpmdrake. В поле поиска задаем сокращенные названия: kernel-source или libusb и т.д.
Если не находите, посмотрите, может они уже установлены. Для этого запустите режим удаления пакетов, но не удаляйте, что Вы прямо как маленькие.
А да забыл, делать все вышенабитое надо с бюджетом root"a, не экономьте, дело стоящее.

Установка пакета amedyn_spb (специальная редакция для питерчан).

Получаем rpm пакет драйвера с моей уютной домашней странички: .http://www.dzhi.sp.ru/drivers/amedyn_spb-2004-08-01.k2.6.3-7mdk.i686.rpm Эх, хорошо иметь домик .в деревне.. Если проблемы с типом процессора, скажите, перекомпилю, просто не помню пересобирал ли я ядро.
Настраиваем в менеджере источников программ (rpmdrake), путь к месту где деньги лежат (будут лежать все скачанные rpms).
Все готово к установке. Устанавливаем, указав группировать пакеты по источнику и выбрав наше место. Выбираем файл. Ставим.
Редактируем файл /etc/amedyn. Вносим в него свой IP-адрес, маску подсети, IP-адрес шлюза. Никаких пробелов после знака "равно", будьте внимательны, из-за одного символа на полтора миллиарда попала одна европейская ракета.
Редактируем файл /etc/resolv.conf. Вносим в него адреса первичного и вторичного DNS.
Все. Перезагружаемся. Oops. Не надо, мы в Linuxе. Надо стартовать сервис. Здесь как и у Ильи Муромца два пути: первый запустить сервис, второй запустить скрипт.
Почему некто Муромец выбрал запуск скрипта?
Скрипт amstart.sh - стартует загрузку драйвера и поднятие сетевого интерфейса atm0.
Скрипт amstop.sh - с двух раз?
Потому что, в глючных системах, надо контролировать каждый шаг, а скрипт позволяет делать это лучше, сервис оставим на потом, когда все будет работать как часы.

# amstart.sh

Если google не пингуется, то что делать смотрим Замеченные проблемы. Это раздел полнится глюками.
А если пингуется, что делать и кто виноват? Моч.. Смотрим вопросы.

Информация о существующем драйвере Amedyn версии от 29.10.2003

Данный драйвер был переделан автором(не мной, мозгов не хватит, пока) из драйвера для модема Alcatel Speedtouch, который построен на чипсете Alcatel Telecom DinaMiTe, на котором построен мой(да, находящийся в собственности под оперативным управлением по доверенности) Zyxel.
С некоторых пор драйвер для speedtouch включен в поставку ядра linux. Надо бы сделать патч для Zyxel, но этих Zyxel-ов так много разновидностей, что нужен репозитарий, с кучей товарищей, которые будут беречь каждую народную копейку. Вот бы еще исходник firmware бы где взять. Можно было бы опутать dslем всю эту ужасно-огромную бывшую верхнюю вольту, хотя правда за оптоволокном в каждый дом.

История об установке драйвера amedyn и его конфигурировании

Скачиваем драйвер с сайта автора (см. ссылки). Благодарим судьбу, что есть люди, которые делают правильные и нужные вещи.
Распаковка архива в каталог /usr/src, следование процедуре компиляции-установки, настройка параметров и отсутствие результата.
Начинаем разбираться глубже. Читаем форум, волосы дыбом.
Итак, метод плаг и прай не работает, надо что еще. Впадаем в депрессию, ну как так можно делать продукты без акцизной марки, это же просто вредительство.
Заходим рутом и выполняем команду:

#mount /dev/brain /mnt/head -t system_analysis
#cd /mnt/head
#sysanald -b

Проверяем все ли работает нормально:

#ps -ax | grep sysanald

Видим запущенный процесс. Здесь надо отметить, что не всегда процесс запуска столь успешен, как в нашем случае. В таких ситуациях, помогает только помощь эксперта, см. в конце статьи рекламу.
Ставим задачу: Поиск неисправности в многокомпонентной системе.
Исходная посылка: Firmware и процесс загрузки работают правильно, драйвер тоже, опыт предыдущей системы.
Проверяем исходную посылку. Замечаем, при компиляции драйвера, выдается странное предупреждение. Ок, драйвер на заметку.
Выполняем скрипты по отдельности.

#amload.sh

Выполнен успешно. Firmware загружено. С точки зрения опыта заложенного в программу amload, все ok. Делаем вывод о работоспособности firmware и процесса загрузки.

#modprobe amedyn

Ничего не сообщил. Смотрим список загруженных модулей:

#lsmod

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

#tail -f /var/log/messages

Теперь мы видим последние сообщения на стандартном логгере.

Смотрим там строчки содержащие строку xdslusb. И видим, что есть какая-то проблема, вывалились внутренности, не транспортабелен, в морг значит в морг.

Ок, проблемы с ваучером. Ставим драйвер на заметку.

#amnetup.sh

Отвалился, в моем частном случае, с сообщением "No route to host". Ставим на заметку.

Что-то не работает. На заметке у нас драйвер и amnetup.sh. Странно, драйвер раньше работал, правда с другим ядром. Проблема скорее всего во взаимодействии драйвера и нового ядра. Как ее фиксить, на данном этапе не представляю.

Смотрим где остановился amnetup.sh. Для этого смотрим исходник скрипта. Ок, падает на команде atmarp -s $GATEWAY 0.$VPI.$VCI. Что за команда, что делает, не представляю.

Итак, драйвер или amnetup.sh. Вначале грузится драйвер. Начнем с драйвера.
Идем на форум, читаем труды. Просто сказано - идем, на самом деле, это гиммор, для тех перцев которые не продублировали свои системы и не любят работать с соломкой.
Чтение "шескпира" в оригинале дает массу информации, об исключениях при монтировании /dev/brain.
Делаем просто, отсекаем инфу связанную с неверно сконфигурированными ядрами, не поставленными библиотеками, отключенным usb, мозгом, ногами и руками и пр. Надежда только на генетически модифицированные продукты и на ее величество генетический алгоритм.
Выясняется, что драйвер у кого-то работает, у кого-то нет, на одних яйцах идет, на других - нет. Да-а блин, имеется пипл в наше время.
Информация которая заинтересовывает - драйвер является переделанным из драйвера для модема Alcatel Speedtouch и переделка заключается в укачивании, копировании модуля speedtch.c, изменении идентификаторов модема, а также еще то, что драйвер Speedtouch есть в ядре.
Качаем, отправляем с дублирующего процессора, по беспроводной связи, с помощью openOBEX протокола скачанный файл, распаковка, выполнение шаманской инструкции, компиляция, проблемы и no results.
Странно, проверяю:

#mount

/dev/brain смонтирован.

Ага, вот sysanald process suspended. Что такое, suspended. Читаем LONGMAN Guide to English Usage. Точного соответствия не найдено, но есть похожее, ну знаете как у нас в русском, слово - suspence. Смысл: suspence is mental uncertainty: a novel of suspence. Да вместо одно непонятного слова, еще несколько. Знаете, как у Хаббарда, если слово непонятно, надо его понять.
После некоторого времени попыток, вспоминаю, пора бы уже записывать, что в ядре идет драйвер, смекаю, если компилируется ядро, то компилируется и драйвер. Захожу в каталог (или папку) /usr/src/linux-2.6.3-7mdk/drivers/usb/misc/. Вижу файл speedtch.c. Цепляюсь зубами и не отпускаю, пока не зайду в папку /usr/src/amedyn/module/. Да, с терминологией проблемы, надо бы внести в повестку следующей думы. Отпускаю, уже не дышит. Переименовываю в xdslusb.c, предварительно перетащив в корзину старый, до чего же линукс дошел, до мусорного ведра на столе. Правлю идентификаторы VENDORID и PRODUCTID, указываю своего модема.
Делаю make. Падает. На каком- то модуле br..., еще там что-то.
Ну что делать, давно хотел изучить устройство Makefile.
Смотрю, все четко разбито на разделы, более менее понятно. Делаю еще раз make. Смотрю вывод результата. Определяю что мой модуль компилируются, а падает этот br. Выясняю что за киса. Нужен только для протокола моста (RFC 1483/2684 bridged). Забавно, вне контекста, фраза протокол моста не понимается. Нам не надо шоко, выкидываем, правя Makefile. Не с первого раза, но скомпилировались. И вроде никаких предупреждений. Ну еще раз для надежности делаем очистку: make clean, дистилляцию make uninstall. Снова make. Свят,свят.
Запускаем:

#amstart.sh

Что-то ругается про crc32, но пишет что запускается драйвер в нормальном режиме. А потом падает, да все в том же месте amnetup.sh.

Жалкая попытка пинга www.google.com, в надежде что все само рассосется. Не рассосется, халявы не будет, я понял еще не так давно. Как сказал Эдисон, если бы люди предпринимали при каждой проблеме, в три раза больше усилий, то все проблемы были бы разрешены. Ну, это вольный пересказ слов того дядьки, кто лампочку зафигачил на 1001 шаге. Степ бай степ анд you ин.
Что за crc32? Форум, поиск. Результат - вроде не нужен драйверу в ядрах 2.6. Комментируем.
Правда все равно падает в amnetup.sh
Опять консоль с хвостом логгера. Изучаю, как работает плаг анд плай. Отключаю модем и подключаю, смотрю лог. Вроде проблем не замечено. Видны сообщения "Usb disconnect..",
"usbcore: registered new driver xdslusb". Вроде система видит драйвер и нет больших ошибок, правда маленькие есть всегда.
lsmod докладывает о наличии модуля ядра amedyn, это наш добрый драйвер.
Теперь анализирую стартовый скрипт amload.sh. Вижу, что пытается снести usb подсистему, потом драйвер, до основания, а затем, на новом чистом месте запустить загрузку firmware.
Ну что, понятно. Вначале загрузка firmware, потом драйвер, потом запуск amnetup.sh в нашем случае, с другими протоколами-случаями разбирайтесь сами, мы же в свободной стране. Америка, Америка. Не забудьте встать и приложить руку.
Перехожу к amnetup.sh.
Запускаю. Загружаются всякие товарищи из подземелья. И первая проблемное сообщение приходит от atmarpd.
Опять чего-то не хватает, а именно "no signaling daemon". Это что, типа регулировщика на перекрестке?
Достает разбираться, откладываю. Перевожу проблему в фоновый режим подсознания. Утро вечером и т.п.
На свежую голову запускаю процесс сверки подобия параметров из Windows и linux.
Четко проверяю цифры. IP-IP, Маска-Маска, Шлюз - отличие. В винде стоит, какой-то не понятный шлюз, в поддержке сказали, что шлюз должен быть мой IP адрес с последним октетом установленным в единицу. Ну ладно. Верю на слово. Проверяю. Правлю /etc/amedyn.
Стартую amstart.sh. Оп. пишет amnetup.sh succeseful. Ого-го.
Дрожащими руками набираю ping www.rambler.ru. Ничего. Знаете, есть такой смайлик, так вот, фэйс выглядел не лучше.
Анализ лога. Опять регулировщик отсутствует, спит на посту что-ли. "no signaling dieman"
Да, нынешнего уровня понимания устройства Linux, явно не достаточно. Да, но это был второй учебный заход. А надо 3 как минимум. Это еще нас учил великий товарищ Чейто. Под альтернативной коммерческой ОС, гиммора не меньше, попробуйте настроить спаривание двух зубастых голубозадых с собственными драйвами. Трах с лицензией обеспечен, как и удовлетворение от хорошо сделанной работы. Они бы еще парсер отечественного законодательства на уровне чипов реализовали, ироды.
Продолжаю, нахожу 2 причины: Неверный шлюз (как оно работало в Win, не знаю, но понимаю, что много лишнего мне продали в довесок) и видимо неверные настройки параметров качества сервиса (qos). Есть отличия в цифрах sdu и т.п.
Делаю чтение документации cat mans > /dev/brain, несколько иным способом: man:/atmarp в konqueror. Eror - это от слова error? Помянем калькулятор с ЕГОГ. Да чтобы работало, нужно установить man страницы.
Далее, анализ информации из настройки windows, на предмет этого qos. Все на уровне совпадения неизвестных слов, ubr, aal5. Любимый max_sdu который отличается от своего одноименца из win.
Составляем набор параметров в строку и правим amnetup.sh в части параметров atmarp
Запуск. Пинг. Заработало. Милый, добрый Интернет пингуется, как много в этом слове.

# ifconfig

atm0 Link encap:UNSPEC HWaddr 00-00-20-F4-FF-BF-1E-00-00-00-00-00-00-00-00-00
inet addr:195.xxx.xxx.xxx Mask:255.255.255.0
UP RUNNING MTU:9180 Metric:1
RX packets:1547 errors:0 dropped:0 overruns:0 frame:0
TX packets:1686 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:184084 (9.7 Kb) TX bytes:540059 (7.4 Kb)

# route

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
195.xxx.xxx.0 * 255.255.255.0 U 0 0 0 atm0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default xxx.xxx.xxxx.xx 0.0.0.0 UG 0 0 0 atm0
#

Все на месте.
Смотрим, что имеется в подсистеме ATM:

# cd /proc/net/atm/
# ls
arp devices pvc svc vc xdslusb:0
# cat arp
IPitf TypeEncp Idle IP address ATM address
atm0 PVC LLC 11 xxx.xxx.xxx.1 0.1.32

# cat devices

Itf Type ESI/"MAC"addr AAL(TX,err,RX,err,drop) ... [refcnt]
0 xdslusb 00a0c55bfb80 0 ( 0 0 0 0 0 ) 5 ( 204 0 236 0 0 ) [2]

# cat pvc

Itf VPI VCI AAL RX(PCR,Class) TX(PCR,Class)
0 1 32 5 0 UBR 0 UBR CLIP, Itf:atm0, Encap:LLC/SNAP

# cat svc

Itf VPI VCI State Remote
999 0 0 CONNECTED

# cat vc

Address Itf VPI VCI Fam Flags Reply Send buffer Recv buffer [refcnt]

cbcXXX00 0 1 32 PVC 2047 0 0/ 110592 0/ 110592 [2]
cbXXXaX0 999 0 0 SVC 0102 0 0/ 110592 0/ 110592 [2]

# cat xdslusb:0

DynaMiTe USB Modem (usb-0000:00:07.3-2)
MAC: 00:a0:c5:xx:xx:80
AAL5: tx 213 ( 0 err ), rx 245 ( 0 err, 0 drop )
Line up, firmware loaded

#

Чтобы понять, что значат все эти термины, надо почитать документацию по АТМ. Все не так страшно.
YANI. Даже в Интернет можно не ходить. Howto идут в поставке. Все в одном. И это правильная концепция, для нас безлошадных на информационной супер магистрали.
Проверяем последовательность запуска, убираем не нужное, сводим все к простой процедуре.
Все Инет работает.
Теперь надо сделать что-то, что-бы потом не парится с этой проблемой еще раз, хотя придется, но уже меньше.
Цель: изготовить rpm пакет, для себя и для друзей.
Как изготовить rpm рассказывать? Ну это было достаточно быстро. Нашел инструкцию, почитал, сделал. Эта операция скоро вкомпилируется в мозги.
Результат готовый rpm-файл (см. ссылки). Данные rpm файл рассчитан на использование с ядром 2.6.3-7mdk идущем в поставке Mandrake 10 Offical Discovery. Данное ядро уже настроено на поддержку ATM и всех прочих вещей нужных для этого модема. Так что plug and play. Теперь ловим бочку дегтя. Не совсем плаг анд плай, смотрим Замеченные проблемы.

Информация об архитектуре драйвера amedyn

Данный драйвер моделирует сетевую ATM карту в подсистеме ATM ядра Linux. Т.е. для вышележащих приложений появляется (raw) ATM устройство. Ну а usb, так можно pci, isa или еще что-нибудь.

Настраиваем plug&play

Желание достичь качественного результата ведет меня дальше.
Начинаю разбираться с настройкой горячего подключения.
Ставим цель, что мне хочется достичь: Мозговой штурм приводит к четырем способам работы с модемом. Далее сценарии по возрастанию сложности конфигурирования.
Сценарий 1. Компьютер выключен, модем подключен, телефонная линия подключена.
Включение компьютера. Загрузка драйвера и автоматическое конфигурирование сетевого интерфейса. Работа в Интернет. Выключение компьютера.
Это простой сценарий, включающий в себя последовательную настройку драйвера и сети.
Не включает в себя режим горячего подключения и конфигурирования. Не позволяет на ходу менять сетевые подключения.
Он реализуется существующим драйвером и скриптами.
Для запуска сервиса при загрузке:
В Mandrake 10 надо запустить Центр управления Mandrake 10 зайти в раздел Система->Сервисы
Отметить сервис amedyn_spb стартовать при загрузке. Все. Интернет должен быть доступен.

Сценарий 2. Компьютер выключен, модем не подсоединен, телефонная линия подключена.

Включение компьютера. Загрузка системы. Подключение модема. Автоматическая загрузка и инициализация драйвера. Автоматическая настройка сетевого интерфейса. Работа в Интернет. Отключение модема. Автоматическая остановка сетевого интерфейса. Автоматическая выгрузка драйвера. Продолжение работы в системе. Выключение компьютера. Требуется настроить подсистему usb-agent. Займусь, потом напишу.

Сценарий 3. Отличается от Сценария 1 и 2, тем что подключение и отключение телефонной линии, должно сопровождаться корректным автоматическим конфигурированием сетевого интерфейса и уведомлением пользователя (и журнала syslog) о наличии/отсутствии физического подключения. Пока не работает, видимо решается на уровне драйвера. На сайте появилась новая утилита, надо посмотреть, люди работают.

Сценарий 4. Отличается от Сценария 2, тем что автоматически корректно подключаются, конфигурируются и отключаются все службы и сервисы завязанные на сетевой интерфейс модема, например расшаренное(shared) интернет-соединение, подключенные клиенты и пр. Т.е. происходит уведомление всех клиентов об отключении интерфейса. Употребляемый термин "корректно" подразумевает, что приложение, служба, сервис, обрабатывает все нестандартные ситуации, а не зависает. К примеру, в сценарии 3 при отключении телефонной линии драйвер модема зависает, уведомления к клиентам не приходят, ситуация обрабатывается некорректно.
Поле не паханное. Есть где развернуться.

Замеченные проблемы

Проблема с перезапуском службы amedyn_spb. Выдается сообщение: connection time out, Причина ниже, в проблеме 2.
Инициализация (загрузка firmware) возможно только 1 раз при подключении. Повторная инициализация командой amload приводит к ошибке. Лечится отключением модема на 30 секунд. Также см. Проблема 3.
Команда ifconfig не распознает тип atm, в результате многие программы настройки сети не умеют работать с данным типом сетевого интерфейса, в том числе конфигуратор сети Mandrake 10.
Работоспособность только при одном подключенном ADSL модеме. В драйвере есть код, который берет первый попавшийся под руку модем и загружает в него firmware.
При долгом отсоединении сетевого интерфейса (по команде amnetdown.sh) в течении ночи, последующее поднятие интерфейса (amnetup.sh) завершается на вызове amioctl с результатом -1. Решается только отсоединением модема секунд на 30 и повторным подсоединением и выполнением команды amstart.sh.
Не пингуется IP-адрес шлюза. Это особенность данной серии модемов. В Win аналогично. Сказали в поддержке, звонил ночью, люди работают.
Дистрибутивы не имеют понятия о пользователях, которые не любят копаться в ядре.
Имеются предупреждения при компиляции драйвера amedyn_spb под ядро 2.6.3-7mdk. У меня на работоспособность они не влияют. При компиляции под ядро 2.6.7 надо проделать процедуру замены файла драйвера, либо попросить меня, выложу.
Сообщение .broken pine. можно игнорировать когда все работает. Если же не работает загрузка, то надо разбираться, на форуме что-то было про это.
Много проблем. Но они постепенно решаются. Через год все будет хорошо. Харашо. Все будет харашо я это знааю.

Заключение в виде краткого списка ToDo

Короче, надо бы драйвер переделать и включить в ядро. Желающие? Правда ядро опухнет скоро.
Еще надо бы сделать локализацию сообщений. Разберусь как-нибудь.
Изготовить исходник в формате rpm, удовлетворяющий стандарту пакетов с исходниками.

Ссылки
Адрес сайта с драйвером amedyn: http://sourceforge.net/projects/zyxel630-11
Адрес сайта с драйвером amedyn_spb: http://www.dzhi.sp.ru/drivers/amedyn_spb-2004-08-01.k2.6.3-7mdk.i686.rpm
Адрес сайта с исходником драйвера amedyn_spb: http://www.dzhi.sp.ru/drivers/amedyn_spb.tar.gz

ПО использованное при создании данной статьи
Mandrake 10 . дистрибутив.
Amedyn . open source драйвер модема Zyxel 630-11.
Rpmdrake . прелестная утилита настройки Mandrake 10.
Konqueror . интегрированный браузер, с поддержкой ftp, для закачки на домашнюю страницу, просмотра созданной страницы.

Автор: Kernel-msk

Комментарии: (0) | Linux | 2006-06-03


Страница 10 из 51Первая«78910111213 »Последняя