from:"Oleg Frolkov"


Evgeny Yugov пишет:

Здравствуйте.

А поподробнее можно?

У меня есть 2 сервера:

1) XEN 3.1.2, 4 VM, почтовый траффик (порядка 300 клиентов)
2) XEN 3.2, 3 VM, телефония в основном

даже при регулярном dist-upgrade замерзаний не заметил...

Шлюз по умолчанию на твоем dom0 смотрит в сторону роутера который на 
этой-же машине в domU
или в сторону внешнего роутера? Так вот сделай виртуальную машинку чисто 
роутер и поставь

шлюзом по умолчанию в dom0 - думаю неприятно удивишься.

Первый раз я с этим столкнулся когда использовал Debian/etch i686 
установленный на P3(64Bit)-3.2Ghz.


Сейчас я столкнулся на Debian/lenny i686 установленной на AMD64 (Правда 
с ядром от etch, птому как в lenny пока нет ядра xen работающего в dom0)


Есть еще Intel Core Quad с установленным Debian/lenny amd64 - опять-же с 
ядром от /etch. Там смоделировал такую-же ситуацию
- результат тот-же но более странный. Сейчас попробую как-то внятно 
отразить. Сеть у меня бриджевая, правда
некоторыми трюками удалось без всяких модификаций скриптов заставить 
дефолтные скрипты работать так как
хочется, а не так как в идеологии xen. Идеология по умолчанию 
предусматривает переименование физического
интерфейса и в моем случае (использование VLAN) это ведет к 
неработоспособной сети.


Решается это дело так:

-/etc/network/interfaces
auto eth0
iface eth0 inet manual

auto br-eth0
iface br-eth0 inet manual

auto vlan100
iface vlan100 inet static
   vlan_raw_device br-eth0
   address 192.168.1.4
   netmask 255.255.255.0
   gateway 192.168.1.1


Соответственно все виртуальные интерфейсы цепляются к br-eth0

--/etc/xen/xend-config.sxp
(network-script network-dummy) - Это чтобы скрипт инициализации бриджа 
не перекурочивал сеть
(vif-script vif-bridge) - Это чтобы виртуальные интерфейсы цеплялись к 
бриджу указанному в конфиге

 виртуальной машины.

Если указать
(network-script network-bridge) - то при старте xend скрипты пытаются 
переименовать
основной интерфейс и отрывают от него VLANы.. а назад естественно не 
прикручивают из

за своей убогости.

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

то возможно все будет нормально, но конфигурация сильно усложнится.

--/etc/xen/vm.cfg
vif  = [ 'mac=00:16:3e:XX:YY:ZZ, bridge=br-eth0' ]


В общем-то вот так у меня все и устроено.

Первый виртуальный сервер lenny/686
 |Dom0-vs|VLAN100|192.168.1.4|--+
WAN - (WW.XX.YY.ZZ)|VLAN99|DomU-gw|VLAN100|192.168.1.1|--+
 |DomU-fs|VLAN100|192.168.1.5|--+
|
|
Второй виртуальный сервер lenny/amd64|
| 
   |Dom0-vs2|VLAN101|192.168.2.103+

+192.168.1.100|VLAN101|DomU-gw2|VLAN101|192.168.2.1|-+

|
Третий комп. |

+192.168.1.113|VLAN100|Pentium-200|


В общем-то в VLAN100 все роутят на 192.168.1.1
в VLAN101 соответственно на 192.168.2.1

В итоге беру Dom0 на втором сервере, тупо делаю:

scp debian.iso [EMAIL PROTECTED]: (ok)
scp debian.iso [EMAIL PROTECTED]: (ok)
scp debian.iso [EMAIL PROTECTED]: (ok)
scp debian.iso [EMAIL PROTECTED]: (ok)

Далее в обратку:

scp [EMAIL PROTECTED]:debian.iso . (ok)
scp [EMAIL PROTECTED]:debian.iso . (ok)
scp [EMAIL PROTECTED]:debian.iso . (ok)
scp [EMAIL PROTECTED]:debian.iso . (stall)
scp [EMAIL PROTECTED]:debian.iso . (stall)

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

Когда забираю с отдельно стоящей машины - тоже все нормально.

Эта аномалия меня уже утомила. пока в dom0 указал в качестве шлюза 
отдельную машинку (Pentium-200/64RAM)которая у меня занимается почтой 
(тот домен с  котрого сейчас пишу но это не дело
птому что винт на этой машинке утомил жужжать и хотелось от нее 
избавиться занеся в виртуальную

только пока не получается, иначе сеть опять отсыхать будет :(

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


Какие будут мысли? Попробуйте повторить ну или рассказать/показать 
ваши конфиги.




Олег.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Генератор правил фай рвола


Alexey Boyko пишет:

Monday 02 June 2008 08:56:17 Oleg Frolkov написав:

  

[axed]

Тоже им пользуюсь с давних пор, но ищу замену. Он хорош, но только как
препроцессор для генерации
скрипта iptables, а хочется порой чего-то более гибкого. Например надо
еще добавить правил - в случае с
ferm это полный рестарт файрволла который например в моем случае -
требует переинициализации всех
правил которые добавлены не с помощью ferm (у меня при поднятии ppp
интерфейсов приписываются
дополнительные строчки для NAT в зависимости от адресов с которыми
поднимается ppp, 



у ferm есть @include 'файл';

Как на счёт добавления правил не сразу в iptabes, а в дополнительный файл
с правилами ferm, а потом рестарт ferm ?


  
Нет, ну если сделать кучу подпорок то можно и с ferm извратиться. 
т.е. самому написать исходный скрипт,
и сделать в каждой из дефолтных цепочек INPUT, FORWARD, OUTPUT переход 
например на INPUT-FERM,
FORWARD-FERM,OUTPUT-FERM и их перегружать ferm_ом в принципе надо 
подумать. потому как
другие варианты (типа include) немного не то он все объявленные 
цепочки тупо чистит и впрочем правильно делает.


Олег.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Ctrl+Alt+F*


Grey Fenrir пишет:

В Mon, 2 Jun 2008 16:04:25 +0400
Алексей пишет:

  

Здравствуйте.

Не работают сочетания Ctrl+Alt+F1(F2, F3...) в  Debian lenny + Gnome
2.22.1 (все пакеты в актуальных версиях)
Пожалуйста, подскажите, как вернуть системе способность переключаться
между консолями? Спасибо.

От гнома не зависит, у меня тот же глюк на одной из систем под KDE. 
На другой установлено всё то же самое но переключалка работает. %/


--
Grey Fenrir


  

Что у вас в /etc/X11/xorg.conf в районе:

   Option  XkbVariant,

? Если не просто запятая а что-то еще, то попробуйте оставить только 
запятую.


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

что решило, кажется именно XkbVariant.


Олег.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Помогите настроит ь часы

Юрий Илюшко пишет:

Доброго времени суток.
После долгих попыток определиться между Windows и Debian, остановился на
последней. Но возникла маленькая проблема, решение которой пока не могу найти.

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

На всякий случай.
Установлен: Debian GNU/Linux 4.0 'etch' I386. (gnome, установлены только пакеты
по умолчанию для рабочего стола)
Часовой пояс: европа/рига

Или подскажите где искать информацию по этой, и возможно другим проблеме.

Для начала перегрузись. Посмотри время в BIOS.
Потом загрузись в Linux

Посмотри время командой #date
затем #date -u
- Пришли сюда результат биос и команд.

Как уже правильно советовали - сюда содержимое /etc/default/rcS

Можно еще содержимое /etc/adjtime

запусти команду tzconfig и убедись что все параметры правильные.

Скорее всего у тебя в /etc/default/rcS
UTC=yes

Соответственно система считает что в BIOS время в UTC и прибавляет еще
количество часов

равное разницы вашего времени с UTC.

Олег.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Помогите настроит ь часы


Nicholas пишет:

Oleg Frolkov wrote:
Соответственно система считает что в BIOS время в UTC и прибавляет 
еще количество часов


При исталяции Debian спрашивается как время в биосе настроено - 
локальное или универсальное - если есть еще win то лучше ставить 
локальное, что бы одинаковое было в обоих операционках. Если есть 
только linux то лучше выбрать универсальное в биосе, а в локале будет 
актуальная.


К сожалению, забыл как вернуться к этому меню после инталяции  -
dpkg-reconfigure... (не locales, нe tzdata, что то вроде base... может 
кто-то помнит ? )





Так поставь в /etc/default/rcS вместо UTC=yes UTC=no и перезагрузись.

Олег.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Генератор правил фай рвола

2008-06-01 Пенетрантность Oleg Frolkov


Alexey Boyko пишет:

Saturday 31 May 2008 00:09:14 Alexander GQ Gerasiov написав:

  

Господа, а чем сейчас модно генерировать правила файрвола?
Понятно, что можно руками писать, но как-то слишком уж объемно
получается. Можно (и сейчас так и сделано), в шелл скрипте пяток
функций задать, чтобы правила попроще вылядели, но нет ли чего хорошего
готового? И чтобы нат знало/умело. Shorewall?



apt-get install ferm

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


пример файла с правилами :
  

[axed]

Тоже им пользуюсь с давних пор, но ищу замену. Он хорош, но только как 
препроцессор для генерации
скрипта iptables, а хочется порой чего-то более гибкого. Например надо 
еще добавить правил - в случае с
ferm это полный рестарт файрволла который например в моем случае - 
требует переинициализации всех
правил которые добавлены не с помощью ferm (у меня при поднятии ppp 
интерфейсов приписываются
дополнительные строчки для NAT в зависимости от адресов с которыми 
поднимается ppp, т.е после рестарта ferm - имеем сломанный NAT на ppp 
интерфейсах.) вот и хотелось-бы файрволл который умеет добавить/удалить 
конкретные блоки правил а не рестартовать iptables очищая все цепочки.


Олег.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Замерзание бриджей в XE N

2008-05-30 Пенетрантность Oleg Frolkov

Блин... всю голову сломал и не первый раз уже проявляется.

Есть dom0 на котором пускается domU
в domU сделан роутер. Из dom0 в domU экспортируется br-eth0
и
там и там поднимаются VLAN. Предположим
VLAN100 - WAN
VLAN101 - LAN

В dom0 есть интерфейс VLAN101 - через него он роутит пакеты на domU
чтобы попасть в интернет.

Проблемы начинаются когда в dom0 качаю что-то из интернета, тем-же самым
wget.
Скачивается 100-500Kb и все встает в одну позу. при этом из dom0 я
локалку пингую а
из domU не пингую ни локалку ни dom0 ни глобал. Пакеты в интерфейс из
domU уходят а в

dom0 не приходят через некоторое время просирается и работает.

Если открывать странички по несколько килобайт то все нормально.

Если качать с машин в локальной сети то такой проблемы не возникает.

Может кто с этим сталкивался и знает откуда ноги растут?

Олег.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: XFS and ReiserFS

2008-04-24 Пенетрантность Oleg Frolkov


Sydoruk Yaroslav пишет:

On Wed, Apr 23, 2008 at 06:17:43PM +0300, Rodion Brodetsky wrote:
  

Доброго времени суток достопочтенный All!
Пишу письмо в эту рассылку не ради флейма, а ради интереса и разъяснения
одной проблемы. Меня заинтересовала файловая система XFS. Сам я вот уже
5 с лишним лет использую ReiserFS, но как-то наткнулся на одну статейку
(возможно она не очень объективно освещает проблему) и в ней XFS во
многих тестах показала себя куда лучше, чем остальные файловые системы.
Хочется узнать мнение читателей этой рассылки об этой файловой системе.
Кто с ней сталкивался, кто работал, как она проявила себя в повседневной
работе и как она по сравнению с ReiserFS ? Уточню что область работы ФС,
в моём случае - это обычный домашний компьютер и как следствие файлы и
задачи будут самые разнообразные.



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



  
Я xfs уже лет 5 пользую, ни каких нареканий, очень надежна. Практически 
все дизастеры лечатся
ее утилитами, ну а от потери данных записываемых в момент выключения 
электропитания никто не застрахован.


Есть у xfs один большой минус из-за которого я потихоньку с нее 
переползаю. xfs не поддерживает
квоты если систему с ней запустить в XEN. В вариантах с XEN пользую jfs 
- оказалось весьма шустрее
xfs (по субъективным ощущениям) - у меня тупо скопированный и запущенный 
внутри XEN web сервер
стал гораздо шустрее отзываться, уж не знаю толи из-за XEN толи из-за 
JFS толи просто из-за того что

при копировании все само дефрагментировалось :)

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



Oleg.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Клиент для Виндового te rminal сервера.

2008-04-24 Пенетрантность Oleg Frolkov


Приветствую Олл.

Порекомендуйте плиз клиент (желательно репозиторный) удобный для 
использования в Гноме.
Еще подскажите можно-ли вылечить косяки в клавиатуре? Сейчас использую 
Клиент Терминального Сервера
(tsclient) но с раскладкой клавиатуры полная [censored] в русском режиме 
нет точки и прямого слэша, в английском просто нет прямого слэша. 
работает только слэш на дополнительной цифровой клавиатуре.


Хелп! А то на виндовую машину ходить совсем неудобно, хотелось-бы 
одинаковой клавиатуры везде.



Oleg.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Debian кластер

2008-04-08 Пенетрантность Oleg Frolkov


Evgeny Yugov пишет:

Здравствуйте.

Что-то типа:

heartbeat-2
redhat-cluster
drbd8
ocfs

PS Держите в курсе экспериментов ;-)

chaos пишет:

Доброго времени суток уважаемые.

Собственно возникло желание поиграться с кластерами, для 
распараллеливания вычислений и т.д. Посему и вопрос, что по этим 
самым кластерам интересного имеется в официальном репозитории. Может 
кто что посоветует, кауда копать.
Особых требований нет, интересно на данный момент то что есть именно 
в репозитории.
То что в инете полно всего и всё это можно ставить и пробовать это 
понятно, интересует так сказать debian way.


Заранее благодарен.


Или я что-то не понимаю, или где тут параллельные вычисления? Тут разве 
только пакеты относящиеся к HA (High Availability)



Олег.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: kvm vs xen network

2008-03-24 Пенетрантность Oleg Frolkov


Maxim Tyurin пишет:

Nicholas writes:

  

Maxim Tyurin wrote:



У меня сквида в зен. В нее еще филиалы лезут. Работает нормально.

  

Или проще - активно используемый ftp сервер на виртуальной машине ?


Достаточно активно используемый NFS ничего не теряет.
  

Спасибо.

А вы пробовали шейпить под виртуальной машиной ? iptables не глючит в
linux под xen ? Есть какие-нибудь подводные камни ?



  
У меня роутило и шейпило 10 Mbit в боевом режиме. особых косяков 
замечено небыло. Загрузка правда

была достаточно маленькая, в среднем 2Mbit.


Олег.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Засада с сетью

2008-03-19 Пенетрантность Oleg Frolkov

Yuri Kozlov пишет:

18.03.08, Oleg Frolkov[EMAIL PROTECTED] написал(а):

Проблема номер 2: Ранее забив на разборки с Marvell Yukon я просто взял
и ткнул в PCI слот карточку Realtek 8169S. Все нормально
запахало пока я не попер машинку в другое место и соответственно не
включил машинку в другой Гигабитный Коммутатор
Был Planet WGSW-24010 Стал Planet GSW-1602SF. На другом коммутаторе эта
карточка договаривается на 10Mbit/Half Duplex.

То есть не договариваются. Бывает. Выставьте вручную на
обоих сторонах.

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

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

У меня-же вообще конфигурация не описанная даже в факах по xen. Я бридж
цепляю к eth интерфейсу а внутри VM уже на внутренний
eth навешиваю VLAN-ы. В итоге сразу резко снимаются ограничения по
количеству интерфейсов внутри VM и упрощается настройка.

В каждую машину передается только 1 интерфейс.

Олег.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Засада с сетью

2008-03-19 Пенетрантность Oleg Frolkov

Pavel Ammosov пишет:

On Tue, Mar 18, 2008 at 08:34:08PM +0300, Oleg Frolkov wrote:

Проблема номер 2: Ранее забив на разборки с Marvell Yukon я просто взял
и ткнул в PCI слот карточку Realtek 8169S. Все нормально

[..]

Какие будут советы?

Выбросить какашки и поставить Intel PRO/1000 на PCIe.

Ага... мне жить с этим серваком недолго осталось... обещают 2 Хьюлета
прислать - не знаю какие там будут косяки.
В общем-то скачал сырцы с реалтека и нашел какой-то патч для sky2.
Собрал реалтек но пока не пробовал, взял скрипты
из реалтековского драйвера, тупо в них поменял r8169 на sky2 и в каталог
сырцов положил вместо r8169.c/h sky2.c/h
пропатченный руками на авось патч вставать добром не захотел -
пришлось по ходу смотреть что там и править руками
максимально приближенно к патчу одной функции какой-то не нашлось -
пришлось ее тупо удалить. В общем-то на авось
пропатчил, собрал, загрузил - пока вот пару часов полет нормальный,
посмотрим как будет себя вести дальше.

Пробовал собрать драйвер из ядра 2.6.24 - с ходу не получилось :( - на
досуге посмотрю, напильником попилю).

Олег.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

openbsd-inetd vs xinetd

2008-03-19 Пенетрантность Oleg Frolkov


Хай Олл.

При установке debian/etch по умолчанию ставится openbsd-inetd, но в 
репозитарии естественно есть и xinetd.
Кто знает почему в Debian используется более старый inetd вместо xinetd 
используемого в большинстве новых
дистрибутивов и если я поставлю xinetd вместо openbsd-inetd - каков риск 
неправильных апдейтов конфигов?


Ведь насколько я понимаю при установке некоторых сервисов запускаемых из 
inetd они вписываются в конфиг но
чаще всего остаются отключенными. Получается что инсталляционные скрипты 
таких пакетов должны понимать и тот

и другой вариант конфигов?


Олег.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Измеритель скорости

2008-03-14 Пенетрантность Oleg Frolkov


lamazavra пишет:
Мне нужно, чтоб пользователи ADSL могли проверить скорость в пределах 
локальной сети.

Grey Fenrir wrote:

В Fri, 14 Mar 2008 10:33:05 +0600
lamazavra [EMAIL PROTECTED] пишет:


А есть ли в природе какие-нить измерители скорости типа speedtest.net ?
мне энти спидтесты выдают результаты с разбросом на несколько 
порядков, так что я на них плотно забил.


Можно без Флеша, главное чтоб показывали хотябы приближенно точные 
результаты.
взять образ дебиан wget'ом с любого официального зеркала. секунд 
через 20-30 всё будет понятно.











iperf

http://system-administrators.info/?p=552


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

GIS

2008-03-13 Пенетрантность Oleg Frolkov


Хай Олл.

Есть что-нибудь вменяемое для Linux для задач картографии? Вернее даже 
для задач GIS. Хочется например надергать битмапов из гугля, привязать 
их к координатам и рисовать объекты поверх этого битмапа с возможностью 
последующего экспорта куда-нибудь. В частности
надо рисовать трассы кабелей, причем как на карте так и например на 
сканированных планах зданий и желательно чтобы это все как-то
можно было удобно интегрировать типа здание на карте а на нем ссылка 
позволяющая открыть планы этого здания.


Может кто что видел/пользовал? Или кроме губозакаточной машинки мне 
ничего не поможет? :)


Олег.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: шифрование

2008-03-09 Пенетрантность Oleg Frolkov

Dmitry E. Oboukhov пишет:

Не совсем понятна задача. если это
раздел для бэкапов то почему-бы просто не
шифровать бэкап
(ну например с помощью fsbackup) с помощью gnupg
открытым ключем? И раздел не надо будет
шифровать
и бэкапы будут пакованные ну и можно
полные/инкрементальные со всеми
вытекающими..

эмм

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

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

В общем-то man gnupg.
в случае если это пароль, то бакап ключа не нужен - в голове
очень надежно хранится информация :)

а в случае если это ключ, то возникает вопрос где его хранить
а хранить значит и бакапить итп :)

а с точки зрения удобства запуска/останова системы было бы удобно
если одно смонтировали (ввели пароль) второе смонтировать на автомате

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

Далее ты задавал вопросы про хостинг и закрытие данных от их рутов.
Никто не мешает например в том-же
xen дать виртуальной машине 2 блочных устройства. Одно из них открытое и
на нем система а второе устройство
администратор виртуального сервера может использовать как хочет - хочет
пусть туда шифрованную ФС помещает.
Если сисадмины хостера не имеют рутовых прав в виртуальной системе то
попасть в стсиему они не смогут. В принципе
это полноценная виртуальная машина и сила ее защиты целиком в твоих
руках, с той оговоркой что админы хостера имеют
физический доступ - для чего им надо как минимум остановить машину и
перезагрузить ее или в синглмоде или подмонтировать
контейнер. Но важные данные-то у нас на шиырованном диске так что
это им ничего не даст.

Олег.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: шифрование

2008-03-07 Пенетрантность Oleg Frolkov

Dmitry E. Oboukhov пишет:

имеется шифрованный (AES256, но это непринципиально - всегда можно
изменить) раздел.

монтируется руками с вводом пароля.

далее есть необходимость создания второго шифрованного раздела.

хочется тут не вводить еще раз пароли а использовать тот же.

как решение:
скрипт монтирует сперва один раздел, потом берет с него ключ и монтирует
с ключем второй раздел

но тут возникает проблема бакапа этого ключа итп

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

Не совсем понятна задача. если это раздел для бэкапов то почему-бы
просто не шифровать бэкап
(ну например с помощью fsbackup) с помощью gnupg открытым ключем? И
раздел не надо будет шифровать
и бэкапы будут пакованные ну и можно полные/инкрементальные со всеми
вытекающими..

Олег.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Debian etch, xen, живая миграция .

2008-03-06 Пенетрантность Oleg Frolkov


Хай Олл!

Кто-нибудь игрался с живой миграцией доменов XEN в etch? Или может знает 
требования?


Поставил из бэкпортов drbd8 - для возможности работы Master/Master, 
сконфигурил поддержку
миграции в XEN, даю задание мигрировать - домен уезжает на destination, 
там трапается и перезагружается.



Машинки конечно на 2х хостах разной архитектуры - возможно из-за этого, 
хотя по идее xen предоставляет
виртуализацию и это не должно мешать. Первая машина на древнем 
Athlon 2.4 вторая на P4/3.0G на обоих

машинах стоят 32битные ядра.

Есть у кого какие мысли?

Олег.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Странности работы сети в etch/xen

2008-03-04 Пенетрантность Oleg Frolkov

Хай Олл.

У меня начала странно себя вести сеть в виртуальных машинах имею
следующую структуру (пример)

192.168.1.1 - router (vr)
192.168.1.4 - XEN Dom0 (vs)
192.168.1.10 - Рабочий комп (w)
192.168.1.11 - Тестовый комп (t)

Все это крутится на etch апдейченном вчера. Косяки правда начались еще
до апдейта.

Роутер имеет кучу VLAN между которыми роутит, снимает статистику, и.т.д.
В общем-то реальная структура гораздо сложнее - это 9 виртуальных
серверов до недавнего времени замечательно работавших на одной машине. В
общем-то изначально я тронул только
drbd проапдейтившись до drbd8 из бэкпортов чтобы попробовать
конфигурацию master/master и живую миграцию - впрочем живая
миграция не прокатила - виртуальный сервер мигрирует и трапается на
удаленном хосте перезагружаясь, возможно что из-за
разницы архитектур хост-машин P4 и AMD Athlon 2.4. Сеть в виртуальные
машины идет через бридж повешенный на eth0 (br-eth0)

Ну теперь вернемся к нашим баранам.

С тестовой машины пингую:
192.168.1.11 - 192.168.1.4 - Потерь нет (получается цепочка
t-switch-vs_eth0)
192.168.1.11 - 192.168.1.1 - Теряю пакеты время от времени. Получается
t-switch-vs-vr

Параллельно на рабочей машине цепляюсь ssh к роутеру, запускаю screen и
tcpdump -ni eth0

Пакеты ПЕРЕСТАЮТ теряться. первым предположением было что из-за
включения promisc режима
на интерфейсе, но простой детач screen-а (tcpdump остается работать) и
пакеты начинают опять теряться.

т.е. получаем парадоксальную ситуацию - нагружаем интерфейс роутера
трафиком - ситуация улучшается.
Непонятно одно в принципе-то у него и так интерфейс не простаивает,
в среднем поток порядка 10Mbit

там бегает.

В общем-то какой-то подземный стук. может у кого будут
предположения? А то я уже какой час туплю и не
пойму где сломалось :( - сначала подумал что комп не справляется
снагрузкой и перераспределил
виртуальные между двумя компами. В общем-то сам роутер был и на одной и
на другой, железо совершенно
разное а ситуация одинаковая (вплоть до ethernet порта, на одном 100Mbit
на другом 1Gbit), так что боюсь проблема
софтверная и пока не вижу решения, запустил вот workaround-ом tcpdump и
он хлещет кушая ресурсы процов

как на роутере так и на рабочем компе.

Олег.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

(Решено) Re: Странн ости работы сети в etch /xen

2008-03-04 Пенетрантность Oleg Frolkov

Eugene Berdnikov пишет:

On Tue, Mar 04, 2008 at 04:23:10PM +0300, Oleg Frolkov wrote:

Параллельно на рабочей машине цепляюсь ssh к роутеру, запускаю screen и
tcpdump -ni eth0

Промиск можно поставить принудительно через /sbin/ip или ifconfig.

на другом 1Gbit), так что боюсь проблема
софтверная и пока не вижу решения, запустил вот workaround-ом tcpdump и
он хлещет кушая ресурсы процов

как на роутере так и на рабочем компе.

Возможно, поломан arp. Сравните tcpdump arp or icmp с обеих сторон.

Сорри, всем отбой. все оказалось проще.. серв не при чем, нашел
уже в сети урода - надо еще кого-нибудь
к нему заслать посмотреть как он так умудрился сделать. смысл в том что
малая часть broadcast трафика уходящего в его порт разворачивается и
топает назад портя ARP таблицы свитчей. Вот и получалась лотерея - если
чей-то бродкаст возвращался - свитчи разворачивали таблицы и его трафик
шел в тот порт пока он очередным пакетом не поворачивал на себя, странно
только что проблема не локализовалась в одном VLAN и проявлялась в
других. по идее за пределы VLAN в котором она возникла она не должна
была выходить. В общем-то конечно ethernet технология задница.

Кстати в принципе можно и автоматическую диагностику подобных вещей
делать, может кто знает реализацию?
Или такого еще не реализовывали? Теоретически если регулярно опрашивать
свитчи по SNMP и следить за изменениями
таблиц соответствия MAC адресов и портов - вполне можно сразу находить
направление с которого идет эта фигня.

Олег.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: А что есть для упроще ния скриптования шейпинга ?

2008-02-21 Пенетрантность Oleg Frolkov


Michael Ter-Sahakian пишет:

MasterShaper может шайпить и на одном интерфейсе. только надо
пропатчить ядро для поддержки IMQ. http://www.linuximq.net/


  
Так мне наоборот надо что-то многоинтерфейсное, ну и сомневаюсь что 
MasterShaper сможет например отобразить
количество очередей больше 20, там у него в отображалке все достаточно 
примитивно сделано а мне если придется
реализовывать безлимит для абонентов надо будет много очередей. 
Пользовал я его, но в варианте генератора базового
скрипта а потом экспортил скрипт, правил для нескольких интерфейсов и 
запускал. В итоге Его использовал как гуй для
создания примитивов и моделирования приоритизации/подсчета общего 
диапазона и для мониторинга а правила каждый
раз правил ручками (он у меня стоял на компе в котором был и внешний 
интернет и 3 пиринговых линка с соседними
провайдерами). Кстати сейчас не помню в чем был косяк, но в варианте 
iptables он вообще кривой скрипт генерил - пришлось

переходить на вариант с tc.

Кстати в новой версии обещают многоинтерфейсность и использование 
Intermediate Functional Block (IFB) который соперничает с

IMQ и якобы уже включен в ядра 2.6.17.

Олег.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

А что есть для упрощени я скриптования шейпинга?

2008-02-19 Пенетрантность Oleg Frolkov


Хай Олл.

Подскажите, есть что нибудь упрощающее написание скриптов для шейпинга?

А то например для IPTABLES я пока использую ferm а для шейпинга пока не 
нашел ничего.
Неужели все ручками прописывают? Есть конечно примитивные скрипты для 
конечного
пользователя, а вот для более-менее серьезного распределения трафика так 
и не нашел...


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

Олег.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Аналог unnumbered в Linux


Степан Голосунов пишет:

Oleg Frolkov [EMAIL PROTECTED] wrote:
  
Видел в конфигах цисок достаточно забавный твик - задание VLANа как 
unnumbered и соответственно на него  не вешается IP адрес
и пришедший трафик в соседний VLAN (с соседним ip адресом) фактически 
роутится отражаясь соответственно в netflow. Таким образом получаем 
возможность в каждый VLAN высунуть всего 1 адрес. поставить фильтр на 
этот адрес и позволять приходить ему только с этого vlan
и уходить только в этот vlan. т.е. существенно экономим ip адреса нежели 
делать подсетки с маской /31


Есть варианты реализации такой схемы на Linux кроме как сделать бридж, 
назначить ему адрес и цеплять к нему VLAN интерфейсы без

адресов?



Что нибудь такое?

iface eth0.123 inet manual
up ip link set up dev eth0.123
up ip route add to 10.0.0.123 dev eth0.123
down ip route del to 10.0.0.123 dev eth0.123


  

Не катит.
# ifconfig vlan1006
vlan1006  Link encap:Ethernet  HWaddr 00:16:3E:02:F3:37
 BROADCAST MULTICAST  MTU:1500  Metric:1
 RX packets:0 errors:0 dropped:0 overruns:0 frame:0
 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0
 RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)


# ip route add to 10.200.200.200 dev vlan1006
RTNETLINK answers: No such device

В общем-то вот так

Олег.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Простейшая аутентифи кация в домашней сети

HoverHell пишет:

Провайдера выбирать не из чего, управляемые свичи тоже достаточно излишни.
openvpn/ppp излишни потому что 1. дополнительная нагрузка процессора
(особенно сервера), 2. лишний интерфейс+софт на каждом компьютере.
(Хотя тут остро выступают мои предпочтения).
Насчёт привязки IP+MAC уточню: не нравится стабильный вариант такой
привязки. Т.е. привязывать к IP на премя существования
аутенифицирующего соединения - и есть то, что интересует. Т.е. вроде
упомянутого мной выше варианта samba аутенификации (к которому я могу
ещё упомянуть аналогичную ssh аутенификацию...)

--
--HoverHell (ICQ#174520, XMPP/GTalk here, GPG 30E202CB).
И еще в догонку собственно настройка VPN сервера на основе pptp с
шифрованием это правка пары строк в паре конфигов
(для Debian etch) не понимаю проблем. при этом у меня тут при
висящих 40 соединениях процессор P4-3000 практически совсем
не грузится учитывая что эта машина и биллинг и роутер и NAT и VPN
сервер и www и шейпер и DNS сервер. В общем-то для
виртуальной машины VPN сервера максимум загрузки процессора показываемый
на графиках - всего порядка 3% при загрузке

интерфейса порядка 2Mbit...

Олег.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Простейшая аутентифи кация в домашней сети

HoverHell пишет:

--
--HoverHell (ICQ#174520, XMPP/GTalk here, GPG 30E202CB).
Нет, ну как вариант видел у NetUP следующий момент - пользователь идет
на определенный сервер (в клинических случаях порт 80 или 443
редиректится на этот сервер для всех кто не прописан в iptables явно)
оттуда грузится небольшой апплетик (реализовать я так думаю можно и на
javascript и на java ну или тупо refresh-ем, хотя не уверен - не силен в
этом) там пользователь видит логин/pass и вводит. Апплетик авторизуется
на сервере и в результате авторизации в iptables прописываются строки
для конкретного ip. Страничка авторизации каждые X секунд рефрешится
(ну или еще какой механизм, зависит от апплета) тем самым посылая некое
подобие keepalive. Если определенное время запрос keepalive

не поступил - удаляем ip из iptables тем самым отрубая интернет.

т.е. пока страничка авторизации у пользователя открыта - интернет есть,
как только закрыл - интернета лишили.

Олег.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Аналог unnumbered в Linux


Степан Голосунов пишет:

Oleg Frolkov [EMAIL PROTECTED] wrote:
  

Степан Голосунов пишет:


Oleg Frolkov [EMAIL PROTECTED] wrote:
  
Видел в конфигах цисок достаточно забавный твик - задание VLANа как 
unnumbered и соответственно на него  не вешается IP адрес
и пришедший трафик в соседний VLAN (с соседним ip адресом) фактически 
роутится отражаясь соответственно в netflow. Таким образом получаем 
возможность в каждый VLAN высунуть всего 1 адрес. поставить фильтр на 
этот адрес и позволять приходить ему только с этого vlan
и уходить только в этот vlan. т.е. существенно экономим ip адреса нежели 
делать подсетки с маской /31


Есть варианты реализации такой схемы на Linux кроме как сделать бридж, 
назначить ему адрес и цеплять к нему VLAN интерфейсы без

адресов?



Что нибудь такое?

iface eth0.123 inet manual
up ip link set up dev eth0.123
up ip route add to 10.0.0.123 dev eth0.123
down ip route del to 10.0.0.123 dev eth0.123


  
  

Не катит.
# ifconfig vlan1006
vlan1006  Link encap:Ethernet  HWaddr 00:16:3E:02:F3:37
 BROADCAST MULTICAST  MTU:1500  Metric:1



А где UP?

  

 RX packets:0 errors:0 dropped:0 overruns:0 frame:0
 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0
 RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)


# ip route add to 10.200.200.200 dev vlan1006
RTNETLINK answers: No such device



Перед этим интерыейс должен быть не только создан, но и поднят.


  

#ifconfig vlan1006 up
#ifconfig vlan1006
vlan1006  Link encap:Ethernet  HWaddr 00:16:3E:02:F3:37
 inet6 addr: fe80::216:3eff:fe02:f337/64 Scope:Link
 UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:0 errors:0 dropped:0 overruns:0 frame:0
 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0
 RX bytes:0 (0.0 b)  TX bytes:270 (270.0 b)

# ip route add to 10.200.200.200 dev vlan1006
RTNETLINK answers: No such device


В общем-то те-же яйца. может конечно я еще где-то ступил


Олег.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Простейшая аутент ификация в домашней с ети

Stanislav Kruchinin пишет:

Oleg Frolkov wrote:
И еще в догонку собственно настройка VPN сервера на основе pptp с
шифрованием это правка пары строк в паре конфигов
(для Debian etch) не понимаю проблем. при этом у меня тут при
висящих 40 соединениях процессор P4-3000 практически совсем
не грузится учитывая что эта машина и биллинг и роутер и NAT и VPN
сервер и www и шейпер и DNS сервер. В общем-то для
виртуальной машины VPN сервера максимум загрузки процессора
показываемый на графиках - всего порядка 3% при загрузке

интерфейса порядка 2Mbit...

PPTP использует уязвимый алгоритм аутентификации. Кроме того, такое
VPN-решение плохо масштабируется. Было бы забавно посмотреть на вашу
виртуальную машину при количестве сессий около 3 тысяч и 100 Мбитном
внешнем канале. Если уж делать VPN, то на основе L2TP и на уровне
ядра, чем-то типа FreeBSD + mpd + netgraph.

MSCHAPv2 - Сильно уязвимый?
Ну мне тоже было-бы забавно посмотреть, но пока такой возможности нет -
а что касается масштабирования то по идее никто не
мешает при возрастающих нагрузках выделить отдельный VPN сервер/сервера
как на основе линукса так и на основе более
специфичных железок. Балансировать нагрузку тоже наверное можно разными
способами - думаю соответствующие решения есть.
Да и на крайний случай можно сбалансировать каким-нибудь source
routing-ом от внутренних клиентов к разным ppp серверам.

Олег.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Косяки с роутинго м ppp при подключении к ак клиент.

2008-01-17 Пенетрантность Oleg Frolkov


chindi пишет:

On Tue, 15 Jan 2008 20:14:28 +0300
Oleg Frolkov [EMAIL PROTECTED] wrote:
  

 А если подумать, то станет ясно, что идиот здесь админ vpn-сервера,
 выдавший такой адрес серверной стороне туннеля. И то, что винда
 содержит костыль-предохранитель от короткого замыкания -- это
 не аргумент за то, что такая конфигурация правильна.
  
Хорошо. я идиот. Какая конфигурация правильна? Выдать совершенно 
левый ip?


Например, у нас пользователям по PPTP выдаются адреса из сети
10.1.0.0/16, и адрес серверной стороны туннеля соотв. 10.1.0.1.


  

А теперь контрольный вопрос: Какой IP у самого VPN сервера?

Олег.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Аналог unnumbered в Linux

2008-01-17 Пенетрантность Oleg Frolkov


Хай Олл!


Видел в конфигах цисок достаточно забавный твик - задание VLANа как 
unnumbered и соответственно на него  не вешается IP адрес
и пришедший трафик в соседний VLAN (с соседним ip адресом) фактически 
роутится отражаясь соответственно в netflow. Таким образом получаем 
возможность в каждый VLAN высунуть всего 1 адрес. поставить фильтр на 
этот адрес и позволять приходить ему только с этого vlan
и уходить только в этот vlan. т.е. существенно экономим ip адреса нежели 
делать подсетки с маской /31


Есть варианты реализации такой схемы на Linux кроме как сделать бридж, 
назначить ему адрес и цеплять к нему VLAN интерфейсы без

адресов?

Просто я в XEN развлекаюсь с подобными извращениями а бриджи внутри XEN 
себя ведут как-то очень странно.



Олег.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Косяк с фрагмента цией пакетов в ppp и ра змером MTU/MRU. (pppd, pptpd, ppp oe, mtu, mru, mss, fragment)


Andrey Lyubimets пишет:
В общем-то речь про очередной косяк ppp :) - с которым многие мучаются и 
когда заходит речь про очередной косяк ррр - в первую очередь ищите 
кривые руки.
Ну возможно, значит я не совсем правильно понял суть проблемы. Факт в 
том, что почему-то при использовании CISCO as5350
подобной вещи не наблюдалось (не знаю уж как они это обходят) а при 
настройке VPN сервера на Linux получил такую проблему.



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

может кому пригодится.)

Path MTU Discovery Black Hole
проблеме этой уже 10 лет -- http://www.znep.com/~marcs/mtu/

по русски об этом тоже не раз писали, например --
http://www.opennet.ru/base/net/pppoe_mtu.txt.html
Да, да, да и я на русском прочитал когда задал поиск по словам linux 
mtu mss clamp но когда не работает не сразу подберешь

нужные слова для поиска.


В общем если на Debian etch 4.0 сделаете vpn сервер, то выяснится что 
некоторые сайты при подключении по такому соединению не
открываются в принципе из-за маленького размера MTU/MRU и 
соответственно попыткой фрагментировать пакеты. Однако некоторые
сайты отдают пакеты с флагом dont fragment (ну например yandex) и эта 
фрагментация обламывается. в результате расследования выяснилось
было бы неплохо расследовать кто режет icmp пакеты - вы сами или ваш 
провайдер?
Насколько я понимаю icmp пакеты могут резаться на всем пути до например 
того-же яндекса и не только его, как вариант - на это может влиять NAT и 
выяснять кто что где режет - дело неблагодарное. Так что лучше костыль, 
с ним пока особых проблем не вижу.
что какой-бы MRU/MTU не выставляли в конфиге - pppd договаривается с 
виндовыми машинами (Linux не пробовал тогда) на меньший размер
(не помню на вскидку какой) и первым моим решением было добавить в 
/etc/ppp/ip-up.d скрипт которы с помощью ifconfig изменял-бы MTU/MRU
на уже поднятом ppp интерфейсе. Это помогло но было в принципе криво, 
дальнейшие раскопки привели к вот такому решению:



это тоже криво - проблема на уровне IP, а решение на TCP, но
на безрыбье и рак- рыба, если нет возможности настучать по башке 
наглухо закрывшему  icmp админу.





Насколько я понял из той ссылки что указали Вы - проблема в том что 
участок pptp имеет самый маленький MTU а протокол TCP при
инициации соединения (ну или при увеличения окна) не узнает об этом - 
соответственно пересылая большие фреймы которые не проходят

через pptp соединение, или я не так понял?.


Олег.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Косяки с роутинго м ppp при подключении к ак клиент.


Andrey Lyubimets пишет:

Oleg Frolkov пишет:

Eugene Berdnikov пишет:

On Mon, Jan 14, 2008 at 07:21:21PM +0300, Oleg Frolkov wrote:
 
роутинг на ip адрес предъявленный с той стороны прописывается на 
ppp10 ну и defaultroute естественно прописывается туда-же.


Если адрес ppp сервера не из локальной сети - получаем завертывание 
gre пакетов в дефолтроут и соответственно неработу ppp интерфейса.



 Во-первых, следует поставить маршрут до vpn-сервера ручками.
  
Не маленький, знаю - но это идеологически неверно в случае когда 
адрес получили с помощью dhcp.
наверное, было бы идеологически верно маршрут до впн-сервера получать 
по dhcp. А?
Хех... и такое возможно, но я рассматриваю ситуацию с позиции КОНЕЧНОГО 
пользователя которому надо
соединяться не только с VPN сервером провайдера, но и в том числе через 
установленное соединение с сервером
провайдера инициировать еще одно соединение - но уже со своим VPN 
сервером (тем-же корпоративным

сервером организации).

Я понимаю Вашу позицию со свиным рылом в калашный ряд, но не могу ее 
разделить. Если в виндах что-то работает криво
- то я так и скажу криво, если в Линуксе что-то работает криво - это и 
надо называть КРИВО а не (не так как в виндах).


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




Еще более усугубляет положение выдача удаленным vpn сервером в 
качестве удаленного адреса
ppp интерфейса того-же адреса на какой и цепляемся vpn (что в 
общем-то естественно если у VPN сервера единственный

интерфейс)


 Не в этом ничего естественного. Это нелепость.
  
Возможно что и нелепость, но в принципе не мешает функционированию 
системы.

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

если тут кто-то не подскажет.

так и напиши - хочу как в винде и точка! чего воду лить?

Винда делает все логически верно, так что не стоит передергивать.

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

ткнет носом в нужном направлении.


почему самостоятельно прописать в конфиге маршрут - идеологически 
неправильно, но если за тебя это делает ОченьУмнаяПрограмма - то всё 
нормально?

Не должен pppd делать больше чем ему предписано в конфиге!
Вот ему не предписано создавать маршрут до ремотного ip адреса 
полученного в результате согласования параметров, однако он

зачем-то его прописывает? Хотя по Вашим словам не должен.



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

+1, и cisco не забудьте
Проблемы создают все, и у любой проблемы есть 2 варианта решения: 1 - 
исправить, 2 - сделать костыль.
Чаще всего используется второй вариант, потому как пинать того кто 
должен исправить порой бывает
слишком долго, и от этого никуда не денешься ни в мире WINDOWS ни в мире 
Linux. Даже если напишешь
патч - его приложат когда совсем припрет а до тех пор будут пользоваться 
костылями.
  
При чем тут косяки MS? В данном случае я хожу с линукса на линукс. А 
вот в варианте с MS на линукс
подобных проблем не возникает, потому что там не настолько накосячили 
чтобы заворачивать трафик

vpn сервера в туннель.

В общем-то если не получу инфы о том что я не прав и подсказок как 
эту проблему решить изящно - придется править
скрипты.. Хотя вообще крайне странно что в stable дистрибутиве 
положены скрипты которые ПРИНЦИПИАЛЬНО

какой скрипт конкретно имеется ввиду?
Ну видимо все-таки не скрипты, а ppp обладает неким искусственным не 
достаточно интеллектом.
Чтобы прописать роутинг до ip полученного на ремотной стороне у него 
интеллекта хватает, а для
того чтобы перед этим прописать роутинг до VPN сервера - ему интеллекта 
не хватает.
неправильно поднимают ppp соединение и в большинстве случаев ppp из 
коробки неработоспособен без плясок с бубном.


Надеюсь что я не прав.

Олег.

В общем-то в лоб я проблему решил убрав defaultroute и 
replacedefaultroute из конфига /etc/ppp/provider/xxx

Добавив туда ipparam [EMAIL PROTECTED]
и добавив следующие скрипты:
/etc/ppp/ip-up.d/0vpnroute

#!/bin/sh
# Adjust routing
case $PPP_IPPARAM in
 [EMAIL PROTECTED])
   GW=`route -n|grep ^0\.0\.0\.0|awk '{print $2}'`
   route del $PPP_REMOTE dev $PPP_IFACE
   route add -host $PPP_REMOTE gw $GW
   route add default dev $PPP_IFACE
;;
 [EMAIL PROTECTED])
;;
 *)
 echo No PPP_IPPARAM defined
;;
esac


/etc/ppp/ip-down.d/0vpnroute

Re: Косяки с роутинго м ppp при подключении к ак клиент.

Eugene Berdnikov пишет:

[axed]

наверное, было бы идеологически верно маршрут до впн-сервера получать по
dhcp. А?

dhcp у кого? У провайдера а VPN мне нужен не только провайдерский но и
мой корпоративный.

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

но они этого не делают.

2 Frolkov: Зарубите себе на носу: Вам никто ничего не должен.

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

Вы решили поставить меня на место? Любая программа с обозначенным
функционалом -
должна этот функционал выполнять. Программа ДОЛЖНА работать, а если она
не работает
значит она ГЛЮКАВА и точка. Мне никто ничего не должен, но надо просто
признать что

ЕСТЬ ГЛЮКИ а не вправлять мне мозги на тему никто не должен.

Не надо с обсуждения проблемы переходить на обсуждение людей, я Вас не
собираюсь

заставлять что-то для меня программировать.

Возможно что и нелепость, но в принципе не мешает функционированию системы.

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

Советы купить винду приберегите для других людей, а лучше вообще для
себя. Люди на этом форуме делятся на тех
кто помогает (кинув порой одну строчку по которой можно выгуглить
решение) и тех кто крутой перец и все остальные
у него годны только для того чтобы поставить винду и не париться. Мне
кажется стремиться во вторую категорию не стоит,

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

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

Олег.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Косяки с роутинго м ppp при подключении к ак клиент.


Max Dmitrichenko пишет:


Хех... и такое возможно, но я рассматриваю ситуацию с позиции КОНЕЧНОГО 
пользователя которому надо
соединяться не только с VPN сервером провайдера, но и в том числе через 
установленное соединение с сервером
провайдера инициировать еще одно соединение - но уже со своим VPN 
сервером (тем-же корпоративным

сервером организации).


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

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


Я думаю, что даже винда, не обладает таким интелектом, просто ты как-то не так
сконфигурил ppp и у тебя от этого все беды. Как говорили выше, проблемы ppp суть
проблемы кривых рук.
  
Как раз винда-то и обладает, и если в любой винде сказать #route print - 
то можно увидеть что она активно
пользуется метриками, а если поднимаешь VPN соединение она увеличивает 
на 1 метрику у дефолтного
маршрута а метрику нового маршрута выставляет=1. Вдобавок винда создает 
прямой маршрут с маской /32
до VPN сервера с которым начинает соединение. В принципе любое другое 
поведение не имеет смысла.
Если мы не хотим обрубить сук на котором сидим то первым делом надо 
выяснить адрес шлюза и прописать на него

прямой роутинг до того VPN сервера с которым СЕЙЧАС_НАЧНЕМ соединяться.
  
Вода льется в надежде на просветление или на то что какому-либо умному 
человеку это надоест и он ткнет носом в нужном направлении.


Нарисуй пожалуйста схему стенда со связями и адресами. А то лично я ничего не 
понимаю
в топологии твоих туннелей с твоих слов. Поэтому ткнуть носом точно не могу.
  
Да что понимать? В исходном сообщении есть стартовые условия. Получили 
адрес по DHCP (не суть важно
откуда, смысл в том что сеть настроена автоматически и крайне не 
хотелось-бы ручного вмешательства).
т.е. в предельно упрощенном варианте имеем маршрут для своей сети 
смотрящий в интерфейс и дефолтный

маршрут смотрящий на шлюз.

Далее предположим:
Поднимаем VPN соединение с опцией defaultroute
Получаем: после поднятия интерфейса создается прямой маршрут на адрес 
представленный с той стороны и заворачивается
в ppp, в случае если предъявленный адрес = адресу с которым соединялись 
получаем роутинг пакетов для ppp сервера в туннель.
с defaultroute тоже косяк он просто не создается в принципе, потому 
что есть уже маршрут по умолчанию, хотя собственно
никто не мешает pppd завести второй маршрут по умолчанию. Я в этом свете 
вообще не понимаю зачем нужна директива defaultroute

если она не добавляет маршрута если есть уже маршрут по умолчанию.

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

его запись, однако факт остается фактом - метрика = 0 со всеми вытекающими.

Можно конечно поднимать с опциями defaultroute replacedefaultroute - но 
тогда теряем старый роутинг по умолчанию и не можем его

достать из скрипта в /etc/ppp/ip-up.d

В общем-то как я писал выше - запретил я pppd менять маршруты и делаю 
это сам.
Хотя конечно маршрут для ip выданного на том конце ppp все-таки он 
вкрячивает - приходится
его удалять. В принципе для таких случаев в pppd должна быть проверка 
типа if remote_ipvpn_ip route add 

но видимо этого нет, ну да ладно.


почему самостоятельно прописать в конфиге маршрут - идеологически 
неправильно, но если за тебя это делает ОченьУмнаяПрограмма - то всё 
нормально?

Не должен pppd делать больше чем ему предписано в конфиге!
  
Вот ему не предписано создавать маршрут до ремотного ip адреса 
полученного в результате согласования параметров, однако он

зачем-то его прописывает? Хотя по Вашим словам не должен.


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

Re: Косяки с роутинго м ppp при подключении к ак клиент.

Eugene Berdnikov пишет:

On Tue, Jan 15, 2008 at 05:39:42PM +0300, Oleg Frolkov wrote:

Andrey Lyubimets пишет:

почему самостоятельно прописать в конфиге маршрут - идеологически
неправильно, но если за тебя это делает ОченьУмнаяПрограмма - то всё
нормально?

Не должен pppd делать больше чем ему предписано в конфиге!

Вот ему не предписано создавать маршрут до ремотного ip адреса

Это не регулируется конфигом pppd. Pppd лишь конфигурит интерфейс,
а маршрут при этом создаёт ядро.

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

создать маршрут до vpn сервера, это решило-бы проблему.

полученного в результате согласования параметров, однако он
зачем-то его прописывает? Хотя по Вашим словам не должен.

В результате работы pppd появляется явный маршрут до remoteip,
и перебивает маршрут на vpn-сервер, а Вы устраиваете из-за этого
типично чайницкий свист. Вместо того, чтобы подумать головой.

Да ладно... это не единственная проблема :) Есть еще косячекс если
не прописать

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

все равно не обойтись до тех пор пока не поправят pppd/pptp.

А если подумать, то станет ясно, что идиот здесь админ vpn-сервера,
выдавший такой адрес серверной стороне туннеля. И то, что винда
содержит костыль-предохранитель от короткого замыкания -- это
не аргумент за то, что такая конфигурация правильна.
Хорошо. я идиот. Какая конфигурация правильна? Выдать совершенно
левый ip?
Или выделить пул реальных IP и раздавать vpn серверам для фиктивных
интерфейсов?

Моим аргументом является то что выделенный мною белый ip не может пересечься
ни с чьей внутренней сетью, если-же я буду выдавать что-то типа 10.0.0.1
то теоретически
в какой-то конфигурации я из чужой сети с роутером имеющим тот-же адрес
не смогу
соединиться со своим VPN сервером. Любой придуманный экзотический ip из
серой сети
может применяться где-то еще, хотя конечно вероятность стремится к нулю,
а лишних реальныех ip
всегда не хватает, потому и пользую тот единственный который есть у VPN
сервера.

Олег.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Косяки с роутингом ppp при подключении как клиен т.


Stanislav Kogut пишет:
15.01.08, *Alexey Boyko* [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] написал(а):


В сообщении от вівторок, 15-січ-2008 Eugene Berdnikov написал(a):

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

Эта, а какой нужно выдать ИП серверной стороне туннеля, чтобы
опция defaultroute в конфиге pppd не перебивала маршрут до
pptp-сервера?


--
JID: alexey#boyko,km,ua


Вообще-то любой, если вы не забыли про то что такое default route, как 
он обрабатывается и когда.
Ну предположим опять-же получил адрес по dhcp, соответственно в таблице 
маршрутизации два маршрута.

10.0.0.0/24 -10.0.0.1
0.0.0.0/0.0.0.0 - 10.0.0.1

Соединяюсь с vpn сервером 1.2.3.4

Если установлен параметр defaultroute и не установлен 
replacedefaultroute то маршрут по умолчанию остается прежним -

соответственно vpn сервер видим, а вот внешний мир не видим.

Если установить и defaultroute и replacedefaultroute - то получаем 
маршрут по умолчанию на ppp интерфейс и теряем маршрут до

vpn сервера, т.е. без костылей все так-же неработоспособно.

В чем разница? Все равно надо докладывать костыли, так хоть в дистре 
доклали-бы, а то вообще смех дистрибутив не
выполняет в общем-то штатную и нужную очень многим функцию без костылей, 
и если в случае статичной машины
самый простой костыль - прописать в /etc/network/interfaces роутинг до 
впн сервера/серверов то в случае с ноутом имеем
постоянный геморрой с правкой этого самого файла в зависимости от места 
подключения. А если еще провайдер поменяет
параметры сети - то опять геморрой. Если я этот геморрой решу - то 
человек которому настроили Linux на ноутбуке вполне

может наткнутся на ситуацию вчера работало а сегодня не работает
.
Олег.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Косяки с роутинго м ppp при подключении к ак клиент.


Eugene Berdnikov пишет:

On Tue, Jan 15, 2008 at 06:04:20PM +0300, Oleg Frolkov wrote:
  
 Pppd РАБОТАЕТ, и делает то, что ему сказано. Точка.

 А то, что результат Вам не нравится -- это другой вопрос.
  

Да, если ему дать костыли - он работает, я не спорю.

Мне никто ничего не должен, но надо просто признать что
ЕСТЬ ГЛЮКИ а не вправлять мне мозги на тему никто не должен.



 Надо научиться отличать глюки в СВОЕЙ голове от глюков софта и
 тараканов в голове софтописателей.

 Вы пока что никаких содержательных аргументов против линуксовых
 алгоритмов не привели. У винды проблем нет -- это не аргумент.
  
Алгоритм - заменить defaultroute не прописав при этом шлюз до VPN 
сервера Вы считаете

правильным?

В общем-то работающий алгоритм достаточно прост: взяли defaultroute, 
зароутили на него
VPN сервер, соединились с VPN сервером, поменяли defaultroute и так 
можно сколь угодно

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



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

 Вы неправы в том, что не задумываетесь, как в классической модели
 маршрутизации ядро должно выбрать маршрут на remoteip, который
 один и тот же для vpn-сервера и серверного конца туннеля.
 Задумайтесь.
 Проблема именно здесь. А затем задумайтесь над тем, какого хрена
 винда этой модели не следует, и как с этим жить, если предугадать
 её недокументированное поведение невозможно.

 С клиентами под MacOS и BeOS тоже всё нормально с этим vpn-сервером? :)
  


Не знаю, но в таком случае хотя-бы костыль получается не слишком 
громоздким, потому что адрес
VPN сервера скрипт может узнать из переменной $PPP_REMOTE, а вот в 
случае если выдавать адрес
отличный от адреса сервера - взять ip самого сервера изнутри скрипта в 
/etc/ppp/ip-up.d неоткуда. и даже
если его передавать в $PPP_IPPARAM в виде символьного адреса - то надо 
будет исключить defaultroute и
replacedefaultroute тогда его можно будет отрезолвить и поднять 
интерфейс как надо, но вот досада. возвращать
назад надо будет тоже скриптом, и в этом скрипте неоткуда взять адрес 
старого шлюза.


В общем-то я пока не нашел универсального гибкого решения. Заплаток 
можно сколько угодно сделать
но моей целью является придумывания такого способа - чтобы не 
приходилось впредь менять содержимое
каких либо скриптов, а для этого имя vpn сервера должно быть именем а не 
адресом и информация не должна
браться из каких-либо файлов отличных от /etc/ppp/peers/provider. Ну и 
еще оно должно позволять поднимать
несколько ppp интерфейсов как с изменением defaultroute так и без его 
изменения.


Пока никто готового решения не предложил ;)
Все норовят чайником обозвать :)
Те несколько решений которые пытался реализовать - не покрывают те или 
иные потребности.
Все было-бы проще, если-бы pppd добавлял defaultroute к уже 
существующему - но он почему-то это не делает

- только перезаписывает если указано replacedefaultroute :(


Олег.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Косяки с роутинго м ppp при подключении к ак клиент.


Eugene Berdnikov пишет:

On Tue, Jan 15, 2008 at 08:14:28PM +0300, Oleg Frolkov wrote:
  
Или выделить пул реальных IP и раздавать vpn серверам для фиктивных 
интерфейсов?

Моим аргументом является то что выделенный мною белый ip не может пересечься
ни с чьей внутренней сетью, если-же я буду выдавать что-то типа 10.0.0.1 
то теоретически
в какой-то конфигурации я из чужой сети с роутером имеющим тот-же адрес 
не смогу
соединиться со своим VPN сервером.  Любой придуманный экзотический ip из 
серой сети

может применяться где-то еще,



 Да, это проблема, и принципиально неразрешимая с IPv4.
 Но практически она решается уходом с начала адресного диапазона
 куда-то вглубь, где вероятность пересечься с другой организацией
 ничтожно мала.
  
В принципе ладно - выделил я еще один белый ip - но плучил другую 
проблему, все равно
без костылей pppd маршрут делает неправильно, а с костылями я не могу - 
они вызываются уже после удаления
defaultroute или с defaultroute приходится работать самому - что 
приводит к невозможности регулировать тип
соединения (устанавливать на него defaultroute или нет) в конфиге pppd 
для конкретного vpn сервера..


Мало того что если выдаваемый той стороне адрес не равен адрсу сервера 
(у правильного админа) то получить
в костыле ip VPN сервера из его символьного адреса невозможно - потому 
что в момент передачи управления костылю

defaultroute уже снесен и резолвинг не работает.

В общем-то вот такие вот шахматы. куда не пойдешь - мат в 1 ход :)

 Принципиальные проблемы существуют. Даже в винде, сюрприз.
 Вот яркий пример: винда считает список dns'ов параметром интерфейса,
 если на ней поднять vpn, то возникнет новый туннельный интерфейс,
 на котором можно прописать свои dns'ы. В случае pptp, и для цисковких
 клиентов, и для openvpn, и для некоторых других vpn-нов сервер умеет
 список dns'ов оправить клиенту, а винда умеет их принять и прописать.

 А теперь, внимание, вопрос. Какой dns будет использоваться?
 Вопрос не праздный, потому что домен lan.company.tld, может
 быть не виден из интернета, и если спросить сначала интернетовский
 dns, то резолвер получит NXdomain и дальше искать НЕ ПОЙДЁТ.
 Как быть? Ставить приоритетным тот dns, который на туннельном
 интерфейсе? Ага, так поступают многие vpn-клиенты, причём это обычно
 никак не регулируется. Но теперь надо вспомнить, что у нас есть
 не только та локалка, которая доступна через vpn, но и своя,
 в которую торчит физический интерфейс. И в своей локалке тоже
 может быть свой локальный dns, очень-очень нужный для локальной почты,
 web-прокси и ещё тыщи вещей. Винда этот вопрос решить не может,
 точнее, костылей для него в винде пока нет.
  
Если я правильно понял Вашу проблему - то надо пойти в свойства VPN 
соединения -
Сеть-TCPIP-Использовать следующие адреса для DNS серверов и там 
указать ваши локальные DNS и при желании

адреса DNS серверов выдаваемых автоматически VPN сервером.
В итоге после поднятия этого интерфейса получите нужный список и нужный 
порядок DNS серверов.


Хотя конечно это не решит общей проблемы, винда все равно не пойдет к 
другому серверу если получила ответ
от первого. А разве поведение Линукса в этом плане отличается? Тут тоже 
вроде как общий список для резолвинга.


Еще есть наверное шанс получить нужное поведение если поставить под 
винду какой-либо локальный DNS сервер, настроить его

на нужное поведение  а резолвинг завернуть на него.

Впрочем это уже совсем оффтопик пошел.

Олег.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Косяки с роутинго м ppp при подключении к ак клиент.


Eugene Berdnikov пишет:

On Tue, Jan 15, 2008 at 09:37:15PM +0300, Oleg Frolkov wrote:
  


 Можно дописать нужную фунциональность к линуксовому pptp-клиенту,
 снабдив его интеллектом круче виндового. Исходники открыты.
  


Да этого наверное и не надо надо просто поправить /usr/bin/pon - но 
вот беда в том,
что при очередном apt-get dist-upgrade это может запросто затереться 
хотелось сделать

Debian-Way - поменять в таком месте которое не касается при апдейте системы.

Олег.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Множество ppp интер фейсов - как-бы разрул ить при падении?

Max Dmitrichenko пишет:

On Sunday 13 January 2008 00:24, Oleg Frolkov wrote:

И что это даст кроме передачи дополнительного праметра скриптам
поднятия/опускания?

А слабо по этому параметру определять, что за интерфейс у тебя поднят?

Этот параметр имеет такой же смысл как и label у раздела на жестком диске.
Можно юзать /dev/sda2, можно label:usrlocal. Тебе что наглядней? Мне второе.

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

попробовать.

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

этот софт.

Олег.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Множество ppp интер фейсов - как-бы разрул ить при падении?


Alexei Kopendakov пишет:
Уже звучало, использовать в конфиге unit  это именно то, что судя по 
треду Вы хотите.



--
С уважением
Алексей Копендаков
Инженер-программист
Полоцкая ТЭЦ 

Вот огромное спасибо за наводку, дальше сам выгуглю :)

Олег.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Косяки с роутингом ppp п ри подключении как клиент .


Хай Олл.

Речь пойдет о Debian etch 4.0/386 поставленном с диска.

Решил и тут засетапить очередную машинку, поставился, получил ip по dhcp 
и соответственно defaultroute. Затем поставил pptp-linux
и сделал файлик /etc/ppp/provider (листинг приведу ниже), далее говорю 
#pon и наблюдаю следующую картину:
роутинг на ip адрес предъявленный с той стороны прописывается на ppp10 
ну и defaultroute естественно прописывается туда-же.


Если адрес ppp сервера не из локальной сети - получаем завертывание gre 
пакетов в дефолтроут и соответственно
неработу ppp интерфейса. Еще более усугубляет положение выдача удаленным 
vpn сервером в качестве удаленного адреса
ppp интерфейса того-же адреса на какой и цепляемся vpn (что в общем-то 
естественно если у VPN сервера единственный

интерфейс)

Пока спас положение вписыванием строчки: up route add vpn.xx.xx gw 
localgateway но в общем-то учитывая то что
ip адрес получается по dhcp и предполагается что комп (ноут) будет 
цепляться из разных локаций - придется эту строчку

регулярно править в зависимости от локации.

ВНИМАНИЕ ВОПРОС! Как это разрулить идеологически правильно? По идее 
роутинг на VPN сервер должен прописываться

туда - куда смотрел старый дефолтроут скриптом устанавливающим соединение.

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

вот и хочется понять - это я что-то не понимаю или это косяк в дистре?

/etc/ppp/provider
--
pty pptp vpn.xxx.xx --nolaunchpppd
name user
remotename server
file /etc/ppp/options.pptp
defaultroute
replacedefaultroute
ipparam [EMAIL PROTECTED]
noipdefault
hide-password
persist
maxfail 0
unit 10


Олег.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Система билинга


San_Sanych пишет:

Ky6uk пишет:

Встал вопрос о поднятии и настройке билинговой системы.
Условия:
- Локальной сети, состоящей из 1к машин необходимо предоставлять доступ
в интернет через прокси-сервер.
- На каждую машину требуется выделять определенное количество
интернет-трафика в сутки.
- Для доступа в интернет необходима предварительная проверка на
достоверность пользователя (связка ip+mac с дополнительной авторизацией
в билинге). Если достоверность пользователя подтверждена и имеется
неиспользованный трафик - разрешить доступ в интернет.
- Детализация использования трафика.


Какую наиболее удачную связку при данных условиях можно использовать?



я в свое время присматривался к этому:
http://code.google.com/p/cakebilling/

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

а например если он хоть и копейки но сколько-то стоит?


Олег.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Косяки с роутинго м ppp при подключении к ак клиент.

Eugene Berdnikov пишет:

On Mon, Jan 14, 2008 at 07:21:21PM +0300, Oleg Frolkov wrote:

роутинг на ip адрес предъявленный с той стороны прописывается на ppp10
ну и defaultroute естественно прописывается туда-же.

Если адрес ppp сервера не из локальной сети - получаем завертывание gre
пакетов в дефолтроут и соответственно неработу ppp интерфейса.

Во-первых, следует поставить маршрут до vpn-сервера ручками.

Не маленький, знаю - но это идеологически неверно в случае когда адрес
получили с помощью dhcp.

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

но они этого не делают.

Еще более усугубляет положение выдача удаленным
vpn сервером в качестве удаленного адреса
ppp интерфейса того-же адреса на какой и цепляемся vpn (что в общем-то
естественно если у VPN сервера единственный

интерфейс)

Не в этом ничего естественного. Это нелепость.

Возможно что и нелепость, но в принципе не мешает функционированию системы.

Однако адрес типа pointopoint можно в ip-up разобрать на localip:remoteip,
удалить его с интерфейса, и потом поднять другой, типа localip/localmask,
при этом явный маршрут на remoteip не поднимется. Маска в протоколе ppp
не передаётся, но ifconfig может придумать её сам. :)

В принципе можно вообще назначить /0 с высокой метрикой, главное, чтобы
явный маршрут на remoteip не прошёл через интерфейс ppp.

Зачем все эти сложности? В принципе если в дистре это косяк то придется
править скрипты на
предмет выяснения defaultroute перед изменением маршрутизации и
заворачивать роутинг на VPN

сервер в сторону указанного там шлюза.

Пока спас положение вписыванием строчки: up route add vpn.xx.xx gw
localgateway но в общем-то учитывая то что
ip адрес получается по dhcp и предполагается что комп (ноут) будет
цепляться из разных локаций - придется эту строчку

регулярно править в зависимости от локации.

Зависит от того самого выбора, о котором писалось выше.
Если с выбором проблемы -- пишите рекламации в ip-up, ip-down...

Вот цель моего поста выяснить - писать мне рекламации или может я
неправильно готовлю ppp

ВНИМАНИЕ ВОПРОС! Как это разрулить идеологически правильно? По идее
роутинг на VPN сервер должен прописываться

туда - куда смотрел старый дефолтроут скриптом устанавливающим соединение.

В общем-то винда кушает все без проблем, а тут такой косяк.

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

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

vpn сервера в туннель.

В общем-то если не получу инфы о том что я не прав и подсказок как эту
проблему решить изящно - придется править
скрипты.. Хотя вообще крайне странно что в stable дистрибутиве
положены скрипты которые ПРИНЦИПИАЛЬНО
неправильно поднимают ppp соединение и в большинстве случаев ppp из
коробки неработоспособен без плясок с бубном.

Надеюсь что я не прав.

Олег.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Множество ppp интер фейсов - как-бы разрул ить при падении?


Alexei Kopendakov пишет:
Уже звучало, использовать в конфиге unit  это именно то, что судя по 
треду Вы хотите.



--
С уважением
Алексей Копендаков
Инженер-программист
Полоцкая ТЭЦ 
Спасибо! Это то что надо. Но это только для исходящих соединений и если 
планируются входящие соединения - то аплинк

интерфейсы придется уводить в область старших чисел.

Может-быть есть подобное решение для входящих соединений? Например чтобы 
pppd создавал ppp10 и  выше.


Олег.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Косяк с фрагментацией пакетов в ppp и размером MTU/M RU. (pppd, pptpd, pppoe, mtu, mru, mss, fragmen t)


Хай Олл.

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

может кому пригодится.)

В общем если на Debian etch 4.0 сделаете vpn сервер, то выяснится что 
некоторые сайты при подключении по такому соединению не
открываются в принципе из-за маленького размера MTU/MRU и соответственно 
попыткой фрагментировать пакеты. Однако некоторые
сайты отдают пакеты с флагом dont fragment (ну например yandex) и эта 
фрагментация обламывается. в результате расследования выяснилось
что какой-бы MRU/MTU не выставляли в конфиге - pppd договаривается с 
виндовыми машинами (Linux не пробовал тогда) на меньший размер
(не помню на вскидку какой) и первым моим решением было добавить в 
/etc/ppp/ip-up.d скрипт которы с помощью ifconfig изменял-бы MTU/MRU
на уже поднятом ppp интерфейсе. Это помогло но было в принципе криво, 
дальнейшие раскопки привели к вот такому решению:


/sbin/iptables -A FORWARD -i ppp+ -p tcp -m tcp --tcp-flags SYN,RST SYN 
-m tcpmss --mss 1301:65535 -j TCPMSS --set-mss 1300
/sbin/iptables -A FORWARD -o ppp+ -p tcp -m tcp --tcp-flags SYN,RST SYN 
-m tcpmss --mss 1301:65535 -j TCPMSS --set-mss 1300


Это решение позволило расслабиться, но однажды на своей домашней машине 
на которой я настраивал pppoe с помощью pppoeconf
обнаружилось более другое решение (хотя оно приводит в итоге к большему 
количеству правил при большом

количестве ppp интерфейсов)

/etc/init.d/ip-up.d/0clampmss

#!/bin/sh
# Enable MSS clamping (autogenerated by pppoeconf)

iptables -t mangle -o $PPP_IFACE --insert FORWARD 1 -p tcp --tcp-flags 
SYN,RST SYN -m tcpmss --mss 1400:1536 -j TCPMSS --clamp-mss-to-pmtu




/etc/init.d/ip-down.d/0clampmss

#!/bin/sh
# Disable MSS clamping (autogenerated by pppoeconf)

iptables -t mangle -L -n -v --line-numbers | grep 
TCPMSS.*$PPP_IFACE.*clamp | cut -f1 -d   | xargs -n1 -r iptables -t 
mangle -D FORWARD



Как видно проблема решается немного разными способами, и я пока 
затрудняюсь ответить какой из способов более правильный
(как в плане архитектуры решения так и в плане самого принципа - в одном 
месте mss выставляется фиксированным, в другом как

я понял он выставляется равным mtu)

Вот в общем-то, может кому пригодится. Проблема опять-же из разряда - 
косяк из коробки.



Олег.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Множество ppp интер фейсов - как-бы разрул ить при падении?

2008-01-12 Пенетрантность Oleg Frolkov

[EMAIL PROTECTED] пишет:

On Fri, 11 Jan 2008, Oleg Frolkov wrote:

Хай Олл.

Подскажите как идеологически правильно разрулить ситуацию с
множеством ppp соединений. Есть соединение к провайдеру, статический
прямой ip они не хотят делать - интерфейс поднимается по pppoe. Но по
ходу на этой машине еще и постоянно висит туннель до другой машины.
В итоге когда падает ppp0 падает и ppp1 и каким-то образом они порой
взлетают в обратном порядке.. чего очень не хотелось-бы да и
вообще есть мысли и на этой машинке поднять VPN сервер чтобы можно
было ходить на нее и оказываться в домашней сети... но вот с какой
стороны не подумаю - получается какой-то сплошной геморрой. :( -
3 ppp интерфейса после падения могут взлететь в абсолютно произвольном

порядке, да к тому-же еще и открутиться от каких-либо сервисов.

Олег.

man pppd на предмет ipparam string.

Ю.

И что это даст кроме передачи дополнительного праметра скриптам
поднятия/опускания? Интерфейсы все равно могут взлететь
в произвольном порядке и вместо ppp0 для основного соединения вполне
можно получить ppp2, и соответственно в скриптах
поднятия/опускания придется прописывать/удалять правила для файрволла -
т.е. при их изменении надо будет сначала править файрволл
а потом еще скрипты up/down. В идеале хотелось-бы что-то типа того чтобы
для каждого исходящего соединения можно было прописать

статический pppX а для входящих указать например ppp10-100.

Олег.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Множество ppp интерфейс ов - как-бы разрулить при п адении?

2008-01-11 Пенетрантность Oleg Frolkov


Хай Олл.


Подскажите как идеологически правильно разрулить ситуацию с множеством 
ppp соединений. Есть соединение к провайдеру, статический прямой ip они 
не хотят делать - интерфейс поднимается по pppoe. Но по ходу на этой 
машине еще и постоянно висит туннель до другой машины.
В итоге когда падает ppp0 падает и ppp1 и каким-то образом они порой 
взлетают в обратном порядке.. чего очень не хотелось-бы да и вообще 
есть мысли и на этой машинке поднять VPN сервер чтобы можно было ходить 
на нее и оказываться в домашней сети... но вот с какой стороны не 
подумаю - получается какой-то сплошной геморрой. :( - 3 ppp 
интерфейса после падения могут взлететь в абсолютно произвольном

порядке, да к тому-же еще и открутиться от каких-либо сервисов.

Олег.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: OT: DVB И XEN

2007-12-28 Пенетрантность Oleg Frolkov


DamirX пишет:

On Thursday 27 December 2007 20:38, Oleg Frolkov wrote:
  

Комп собственно слабоватенький конечно: AMD AthlonXP 2.5 но занимался он
только раздачей 20 радиостанций в сеть
(юникастом)



позвольте поинтересоваться, с целью расширения кругозора так сказать.

юникастом - значит один слушатель - один исходящий поток с сервера
если да, то почему так?
сколько всего слушателей?

--
DamirX
  


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

начинает лажать и штормить сеть.

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

щелкало..

Oleg.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

DVB И XEN

2007-12-27 Пенетрантность Oleg Frolkov


Хай Олл.


Решил тут стримовый DVB комп заточить под XEN чтобы зря не простаивал, 
железо срочно стало нужно.
Комп собственно слабоватенький конечно: AMD AthlonXP 2.5 но занимался он 
только раздачей 20 радиостанций в сеть
(юникастом), впихнул туда 2G памяти, поставил Debian etch 4.0, как люблю 
- с xen,evms,drbd :) - Все как-бы взлетело без
проблем, сэкспортировал DVB карточку в DomU, пересобрали v4linux, vlc, 
запустили... и тут обнаружилось что при прослушивании

слышны более-менее регулярные щелчки  :(

при этом судя по #xm top этот домен ест всего порядка 1.5-2.5% процессора.

может кто проходил уже это и знает как можно победить?


Олег.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Помощь по EVMS

2007-12-26 Пенетрантность Oleg Frolkov


Роман Кисилев пишет:

Здравствуйте ALL!
Суть проблемы в следующем - есть raid5 порезаный LVM2

/dev/md0:
   Version : 00.90.03
 Creation Time : Tue Jun 26 16:17:34 2007
Raid Level : raid5
Array Size : 215045760 (205.08 GiB 220.21 GB)
   Device Size : 71681920 (68.36 GiB 73.40 GB)
  Raid Devices : 4
 Total Devices : 4
Preferred Minor : 0
   Persistence : Superblock is persistent

   Update Time : Wed Dec 26 08:45:57 2007
 State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
 Spare Devices : 0

Layout : left-symmetric
Chunk Size : 64K

  UUID : c33a88a1:48351638:3cc40b63:6b4dbe63
Events : 0.120

   Number   Major   Minor   RaidDevice State
  0   8   330  active sync   /dev/sdc1
  1   8   491  active sync   /dev/sdd1
  2   8   652  active sync   /dev/sde1
  3   8   173  active sync   /dev/sdb1


при запуске EVMS вываливается вот такая лажа

device-mapper: table: 253:6: linear: dm-linear: Device lookup failed
device-mapper: ioctl: error adding target to table

несолько десятков раз и ВСЁ!

Может кто сталкивался, подскажите пожалуйста в какую сторону копать.


Посмотри как указан root в конфиге grub, скорее всего при апдейте ядра 
grub-update поменял строчку root=
и соответственно если при старте корень указан как /dev/dm/. или как 
там еще то происходит конфликт

между dm и evms.

Выше в конфиге grub посмотри закоментаренные строчки типа kopts и 
xenopts (точно не помню) в которых прописаны шаблоны


из которых grub-update формирует строчки для найденных ядер, поменяй в 
шаблоне root= на строчку для evms, по идее после этой
операции grub-update вызывающийся каждый раз при апдейте ядра должен 
делать правильные строчки. То-же относится и ко всем
остальным модификациям параметров ядра - которые слетают каждый раз при 
апдейте ядра. Все модификации надо делать
там - в закомментаренных строчках. Я так лишался не раз всяких 
параметров, сейчас поправил там и вроде все как надо стало

но ядро пока не обновлял.

Олег.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: системный мониторинг в графиках

2007-12-13 Пенетрантность Oleg Frolkov


Max V. Kotov пишет:



  
В прошлом году решали, чем мониторить оборудование, пробовал zabbix 
(тогда ещё 1.1). Наилучшую производительность он показал в связка с 
Postgresql нежели с MySQL. Но, всё же остановились на cacti
Spine (cactid) отличается некоторой нестабильностью, но решает текущие 
задачи мониторинга (по крайней мере у нас) + я использую бесплатную 
версию zenoss.





Вот кстати о zenoss - можно где-то найти пакет собранный под Debian etch 
или грамотное хауту по интеграции его в etch?
А то как-бы смотрю что оно базируется на zope а версия идущая с zenoss и 
версия в etch разные крайний раз когда я пытался его прикрутить
у меня не получилось, а то есть желание посмотреть на этот самый zenoss 
и сравнить с zabbix.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: APC suxx

Dmitrii Varvashenia пишет:

08.12.07, Alexey Lobanov[EMAIL PROTECTED] написал(а):

08.12.2007 13:59, Dmitrii Varvashenia пишет:

А вы пробовали подключать это чудо к более другому системному блоку?

А смысл? Мне же надо не репутацию APC поддержать, а надёжно работающую
систему сделать.

:)
Мне как-то попадалась нагрузка, которая вырубала упс при уходе на
батарейку. На более другом аналогичном системнике он (упс) работал. И
до сих пор интересно, что-же это таки было.
PS: Мои упсы были какие-то совсем левые и ни разу не apc

Есть мысль... что блок питания у этого системника хитрый сглаживает
меандр
который APC Back выдает вместо синуса на выходе В итоге это
сглаживание приводит
к дополнительной нагрузке на ИБП и тот срубается от этого
осинусивания его честного

квадрата на выходе :)

т.е. у блока питания фильтр помех по входу.

Oleg.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: системный мониторинг в графиках

Alexander Vlasov пишет:

У него коллектор от крона запускается? 8/
Построить графики дело несложное. rrdtool имеет встроенный механизм, в
конце концов google charts api можно использовать.
Душа просит коллектора -- причем демонообразного по возможности, чтоб

крон не насиловать, и расширяемого (чтоб свои плагины писать). Сейчас
мне требуются по крайней мере три типа источников данных: snmp, ipmi
sensors, http с разбором по шаблону.
Может кто-то подскажет что? Сейчас использую cacti. Недоволен тем что он
много тянет, странной организацией конфигов и ненадежным демоном cactid.

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

вызывается тулзень которая кладет нужный счетчик в базу zabbix.

Oleg

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: chkconfig


Покотиленко Костик пишет:

В Пнд, 10/12/2007 в 19:02 +0300, Denis Klykvin пишет:
  

Alexander Vlasov [EMAIL PROTECTED] writes:



Подскажите, пожалуйста, каким образом в debian отключаются сервисы на
определённых runlevel? Есть что-то типа chkconfig --level 35 samba off ?


update-rc.d
  

Ага, оно.
Спасибо



есть ещё sysv-rc-conf - оно с интерфейсом, но тормознутое.

  

А есть еще rcconf - тоже с интерфейсом.

Oleg



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Как правильно прописат ь интерфейс без IP адреса?


Приветствую.

Подскажите правильный синтаксис интерфейса без ip адреса.
Часто бывает надо - например для интерфейсов на которые будет 
навешиваться VLAN или BRIDGING или BONDING
Если просто прописать address 0.0.0.0 и netmask 0.0.0.0 то в принципе 
прокатывает но при загрузке
система ругается что не есть гуд... ну и еще в некоторых вариантах таки 
не создает интерфейс
(встречался когда лепил из двух ethernet интерфейсов без адреса 
транковый интерфейс (bond) без адреса чтобы
на него уже в свою очередь навесить бридж без адреса а на этот бридж 
VLAN-ы без адреса :)) и что самое примечательное таки на

VLANы еще один бридж но уже с адресом :)

Если спросите про обилие бриджей.. для XENа это, он-же в нормальном 
состоянии только к бриджам линкуется :( и в зависимости
от конфигурации или к интерфейсу где ходят тэгированные фреймы, или к 
интерфейсу где ходят нетегированные - если например

запускаешь XEN домен с виндой и нужно ему обеспечить нетегированный VLAN.

Самое интересное что у меня это все работает практически в продакшн... 
правда прослойку bond пришлось исключить неустойчиво оно

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

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


Oleg.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: системный монитор инг в графиках


Andrey Nikitin пишет:

Для полной картины скажите про cacti, кто пользует.
Общую оценку в сравнении с mrtg и другими.

  
Может я не умею его готовить, но лично мне cacti не понравился именно 
тем что кроме как рисовать картинки он
собственно ничего не умеет а кто тебе на сотовый пришлет СМС о том 
что например диск скоро закончится?
Или о том что какой-то важный тебе процесс на машинке отсутствует в 
списке задач?


Oleg.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: системный мониторинг в графиках


Kirill A. Korinskiy пишет:

Oleg Frolkov - Andrey Nikitin  @ Wed, 05 Dec 2007 21:21:56 +0300:

[skip]

знаешь, можно тоже самое на базе mrtg сделать. Что куда более приятно + умеет
snmp интерфейс.

  

А кто сказал что zabbix его не имеет?


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: системный монитор инг в графиках


Andrey Nikitin пишет:

Подскажите пожалуйста наиболее простое в настройке средство
для ведения журнала мониторинга системы (CPU:LA,usage; IO:disk,net; mem ...)
с генерацией HTML с графиками.

  

zabbix :)
не самое простое но пригодится и на будущее. В принципе это злая 
серьезная система мониторинга. Есть в репозитарии,
но я брал с офф сайта и пересобирал, та что в репозитарии у меня падала 
часто но я как истинный извращенец ее гонял под
postgresql а не под mysql потому что планировалась большая загрузка 
В общем-то поддерживает кучу вещей для нужд
мониторинга, сриди которых есть и так называемый zabbix agent как в 
варианте для linux так и в варианте для windows.
Собственно на той машине которую надо мониторить ставится только агент а 
данные со всех агентов собираются на
zabbix_server. zabbix это не только голимый графопостроитель но и можно 
на основании данных пришедших с устройства
активировать триггеры активация которых как присутствует в логах так и 
позволяет выслать оповещение. например если

мало места на диске или еще что.

Почему я советую zabbix? да потому что достаточно один раз разобраться и 
настроить и потом можно мониторить много
чего начиная от собственной машины и заканчивая например скоростью 
трансфера страничек с ya.ru :) В некоторых случаях
(типа одной машины дома) эта штука явно overpowered но с другой для 
опроса одной машины она и памяти/процессора много

не съест а в будующем может пригодиться :)

Oleg.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: системный мониторинг в графиках


Kirill A. Korinskiy пишет:

Alexander Krayniuk - debian-russian@lists.debian.org  @ Wed, 05 Dec 2007 
21:53:22 +0200:

 AK Вообще-то zabbix очень даже умеет snmp. И сравнивать zabbix и mrtg не
 AK стоит, это разного полета птицы. В течение 4 лет использую zabbix для
 AK мониторинга десятков удаленных серверов (linux, freebsd, windows). В
 AK процессе эксплуатации нарекания были, не без этого, но в целом очень
 AK доволен этой системой мониторинга.

 AK http://zabbix.com

Я на zabbix смотрел косо. Признаюсь.

На досуге посмотрю повнимательнее, и, быть может, мигрирую с mrtg.

Спасибо.

  


А я вот на досуге хочу посмотреть zenoss. меня интересует не только 
мониторинг серверов, но и сеть-бы отмониторить
по человечески, а тут zabbix все-таки не совсем катит. Есть ньюансы 
в создании хостов для опроса по snmp (если привязываешь
темплейт к узлу то штатными средствами нельзя поменять у этого узла 
community а если отвязываешь темплейт - то потом если какие
изменения в темплейте - так это-же надо будет опять геморроиться чтобы 
эти изменения до всех узлов донести.. хотелось-бы чтобы
community для хостов отдельно прописывался. Хотя конечно в этой части 
решаемо в плане SQL скрипта. Еще есть такое дело, что
после забивания пары десятков свитчей в мониторинг SNMP счетчиков (база 
postgress) - стало кушать много процессора (процессор
начал кушать postgres из-за того что zabbix вовсю пользуется 
транзакциями, причем очень часто и postgres постоянно занят тем что
коммитит изменения) а изменение периода опроса с 60 секунд например до 5 
минут выявило что за 5 минут счетчики на гигабитных интерфейсах вполне 
даже переполняются и графики рисуют лажу. Ну и карты сетей там 
достаточно убого создаются/отрисовываются да и странички с графиками 
тоже имеют свои минусы - начиная от того что прорисовываются во время их 
создания - что достаточно сильно нервирует. потому что 
прорисовывается это все долго и добавив каждый график для например 24 
портового коммутатора - приходится ждать прорисовки по 2 раза на каждый 
порт - 1раз после выбора типа поля, а второй когда его добавишь.


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


А то так получается что в сети например из десяти 24-портовых свитчей 
(собственно это и не слишком большая сеть) для привязки
графика к порту надо выбрать график из списка с 240 пунктами. а 
например 50 коммутаторов из 1200 пунктов в общем-то это

не радует

В общем из того что на примете разве что zenoss может и покатит, но надо 
смотреть а с ходу я его поставить не смог.


Так что для меня пока вопрос системы мониторинга так и остался открытым, 
хочется чего-то уникального чтобы умело ВСЕ,
хотя конечно понимаю что это малореально :)  - хотя-бы найти что-то 
умеющее многое и чтобы можно было допиливать
в этом отношении zabbix как изделие написанное на C требует достаточных 
знаний и средств для допиливания, а zenoss
написанный на python возможно более податлив напильнику - хотя могут 
возникнуть вопросы производительности.


Oleg.

P.S. Сорри за флуд, но может кому пригодится :)


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: глупый вопрос про RAID


Timur S. Sattarov пишет:

Timur S. Sattarov wrote:
  

Добрый день, All.


Насколько я понимаю - объединение дисков в RAID1 должно увеличить
скорость чтения с получившегося блочного устройства или я ошибаюсь ?
Может чего подкрутить надо ?


Прошу прощения, спутал RAID1(redundancy) и RAID0. Вопрос снимается

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

hdparm  -i /dev/sda

/dev/sda:

 Model=ST3120026AS , FwRev=8.05,
SerialNo=3JT3RP2B   
 Config={ HardSect NotMFM HdSw15uSec Fixed DTR10Mbs RotSpdTol.5% }

 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=234375000
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: ATA/ATAPI-6 T13 1410D revision 2:  ATA/ATAPI-1
ATA/ATAPI-2 ATA/ATAPI-3 ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6

смущает отсутствие звездочки напротив какого либо udma режима.

/dev/sda:
 Timing O_DIRECT cached reads:88 MB in  2.03 seconds =  43.39 MB/sec
 Timing O_DIRECT disk reads:  142 MB in  3.01 seconds =  47.12 MB/sec

Скорость чтения из кэша ниже чем с самого винта.

При этом информацию от SMART я получить не могу:

# smartctl  --all /dev/sda
smartctl version 5.36 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

Device: ATA  ST3120026AS  Version: 8.05
Serial number: 3JT3RP2B   
Device type: disk

Device does not support SMART


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



  
А может все упирается в PCI шину которая максимум может прокачать 
порядка 100Mb со всех девайсов сразу?




Oleg.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: kernel: Disabling IRQ...

Alexey Lobanov пишет:

Hi all.

Есть старый двухпроцессорный сервер. Зависал без видимой причины он
давно, поменять железо я хотел ещё в 2004 году. Но так и не поменял,
уволился. После меня - тоже не поменяли :-)

После апгрейда ядра с 2.4.25 на 2.6.23 стало совсем плохо. При большой
нагрузке на сеть (Intel Ethernet Pro 100) или на IDE диски (карточки с
CMD 648, CMD 649) через несколько минут ядро отключает прерывание
нагруженного PCI устройства, примерно так:

Nov 26 11:52:29 woody kernel: irq 17: nobody cared (try booting with
the irqpoll option)

Nov 26 11:52:29 woody kernel: Disabling IRQ #17

В данном случае это пострадал IDE-контроллер CMD-649, повод - 5 минут
активного копирования с диска на диск. Далее, естественно,

Nov 26 11:52:49 woody kernel: hdk: dma_timer_expiry: dma status ==
0x24 - и половина дисковой подсистемы умерла.

Упомянутый параметр загрузки irqpoll не меняет в поведении системы
абсолютно ничего. Равно как ничего (кроме номеров прерываний) не
меняют irqfixup, nosmp, noacpi.

Говорить noapic не пробовал, но он вроде как входит в nosmp - SMP
mode deactivated, forcing use of dummy APIC emulation.

Чипсет там странный. Broadcom он же ServerWorks CNB20LE.

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

А.Л.

Вообще-то если пишешь что отключает разные устройства то надо приводить
все примеры. В данном случае похоже что проблемыы с
DMA у контроллера HDD. Постарайся средствами BIOS или тусованием плат
разнести DMA контроллер на отдельное прерывание.

Вообще неплохо-бы еще сюда cat /proc/interrupts - Чтобы видно было что
там у тебя творится.

Oleg.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Xen и bridge. Надо ли?


Peter Teslenko пишет:

Привет, коллеги.

Надо ли в dom0 прописывать бридж в /etc/network/interfaces ?

А то у меня вроде и так работает...

[EMAIL PROTECTED]:~$ cat /etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.1.210
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1
# dns-* options are implemented by the resolvconf package, if 
installed

dns-nameservers 192.168.1.2
dns-search mcbfa.local

[EMAIL PROTECTED]:~$ ip a
1: lo: LOOPBACK,UP,1 mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: peth0: BROADCAST,NOARP,UP,1 mtu 1500 qdisc pfifo_fast qlen 1000
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
inet6 fe80::fcff::feff:/64 scope link
   valid_lft forever preferred_lft forever
3: eth1: BROADCAST,MULTICAST mtu 1500 qdisc noop qlen 1000
link/ether 00:30:48:35:3d:b9 brd ff:ff:ff:ff:ff:ff
4: sit0: NOARP mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
5: vif0.0: BROADCAST,NOARP,UP,1 mtu 1500 qdisc noqueue
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
inet6 fe80::fcff::feff:/64 scope link
   valid_lft forever preferred_lft forever
6: eth0: BROADCAST,MULTICAST,UP,1 mtu 1500 qdisc noqueue
link/ether 00:30:48:35:3d:b8 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.210/24 brd 192.168.1.255 scope global eth0
inet6 fe80::230:48ff:fe35:3db8/64 scope link
   valid_lft forever preferred_lft forever
7: vif0.1: BROADCAST,MULTICAST mtu 1500 qdisc noop
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
8: veth1: BROADCAST,MULTICAST mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
9: vif0.2: BROADCAST,MULTICAST mtu 1500 qdisc noop
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
10: veth2: BROADCAST,MULTICAST mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
11: vif0.3: BROADCAST,MULTICAST mtu 1500 qdisc noop
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
12: veth3: BROADCAST,MULTICAST mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
13: xenbr0: BROADCAST,NOARP,UP,1 mtu 1500 qdisc noqueue
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
inet6 fe80::200:ff:fe00:0/64 scope link
   valid_lft forever preferred_lft forever
16: vif3.0: BROADCAST,NOARP,UP,1 mtu 1500 qdisc noqueue
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
inet6 fe80::fcff::feff:/64 scope link
   valid_lft forever preferred_lft forever

[EMAIL PROTECTED]:~$ ip r
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.210
default via 192.168.1.1 dev eth0

А это вот первый domU

[EMAIL PROTECTED]:~$ ip a
1: lo: LOOPBACK,UP,1 mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth0: BROADCAST,MULTICAST,UP,1 mtu 1500 qdisc pfifo_fast qlen 
1000

link/ether 00:16:3e:64:b6:eb brd ff:ff:ff:ff:ff:ff
inet 192.168.1.215/24 brd 192.168.1.255 scope global eth0
inet6 fe80::216:3eff:fe64:b6eb/64 scope link
   valid_lft forever preferred_lft forever
3: sit0: NOARP mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0

[EMAIL PROTECTED]:~$ ip r
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.215
default via 192.168.1.1 dev eth0



И каково-же содержимое /etc/xen/xend-config.sxp в строках:
(network-script
(vif-script

?

Вообще можно конечно и без бриджа - если настраивать dom0 как роутер.
Хотя может я и не прав.

Oleg


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: kernel: Disabling IRQ...


Alexey Lobanov пишет:

Hi,

28.11.2007 12:04, Oleg Frolkov пишет:


  

Вообще-то если пишешь что отключает разные устройства то надо приводить
все примеры.



Скорее, это означает, что виноваты не устройства, а система. И
перечислять примеры бестолку.

  
Тем не менее телепатов тут нет, диагноз можно поставить только видя как 
можно больше симптомов.



Я же писал, что ничего (кроме номеров прерываний) не
меняют irqfixup, nosmp, noacpi.
  

Я не понял... это опции ядра или опции биоса?
noapic пробовал? Не noacpi а именно noapic.

А основной режим smp+apic сам всё разносит.

  
Основной режим это что? Каким образом осуществляется переключение 
основной/дополнительный?

Вообще неплохо-бы еще сюда cat /proc/interrupts - Чтобы видно было что
там у тебя творится.



[EMAIL PROTECTED]:~# cat /proc/interrupts
   CPU0   CPU1
  0: 61  0   IO-APIC-edge  timer
  1:  4  4   IO-APIC-edge  i8042
  3:  44728  45264   IO-APIC-edge  serial
  7:  0  0   IO-APIC-edge  parport0
  8:   61246284   61249572   IO-APIC-fasteoi   rtc
 10: 40 57   IO-APIC-fasteoi   ohci_hcd:usb1
 12:   7265   7480   IO-APIC-edge  i8042
 14:   1761   1855   IO-APIC-edge  ide2
 16:  11443  11594   IO-APIC-fasteoi   ide0
 17:   1722   1670   IO-APIC-fasteoi   ide4
 18:110 82   IO-APIC-fasteoi   serial
 19:   3101   2788   IO-APIC-fasteoi   eth0
 31:493494   IO-APIC-fasteoi   acpi
NMI:  0  0
LOC: 143906 144292
ERR:  0
MIS:  0

  
Если я не туплю то 0-15 Это основной контроллер прерываний, 16 - выше 
это APIC.



Отваливались:

irq 16 RAID bus controller: Silicon Image, Inc. SiI 0649 Ultra ATA/100
PCI to ATA Host Controller

irq 17 RAID bus controller: Silicon Image, Inc. PCI0648

irq 19 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100]

А.Л.

  

Отваливалось все что на APIC.

Возможные варианты лечения:
1. Обновить BIOS чтобы пофиксить ошибки программирования APIC. Мне 
помогало на многих материнках на которых

ядро 2.6 вообще не грузилось без noapic.

2. Отключить apic в BIOS - тогда все должно рассаживаться в пределах 
0-15 прерываний.


3. Отключить APIC при загрузке ядра


Других вариантов вроде-бы нет

Oleg.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Разделы или диски? (Re : soft-raid1)

Maxim Kudelya пишет:

Oleg Frolkov wrote:

Alexander Vlasov пишет:

У нд, 2007-11-25 у 23:02 +0300, Alexey Lobanov пише:

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

Начиная с 2.6 partitionable md поддерживается.
Но тем не менее инсталлятор debian этого не умеет (или не хочет)

Ни какого геморроя со сдвиганием партиций, е.т.с. и если назвал
раздел root или repair то он будет
адресоваться как /dev/evms/root или /dev/evms/repair вне зависимости
от того на каком он физическом винте..

Также как и в LVM.
В чем конкретно преимущество EVMS перед LVM по вашему опыту
использования EVMS?

Так собственно evms это скорее надстройка над RAID, LVM. LVM2. Кроме
интерфейса командной строки имеет приятный
GUI как для X так и для ncurses. Мне удобно что за счет метаданных evms
я могу загрузиться в LiveCD и получить собранный

RAID/LVM2 с моей системой.

Далее. не много работал с LVM2 но насколько я понял адреса томов
выглядят как /dev/mapper/volume/name и если я захочу тот-же
root перенести на другой volume - то придется править конфиги. В случае
с evms корень у меня живет в /dev/evms/root и пофигу на

каком он физическом/логическом томе/группе томов.

Oleg.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Разделы или диски ? (Re: soft-raid1)