Как заставить pppd автоматически пытаться установить соединение при разъединении коннекта?

собрал ядро с поддержкой smp максимальное число процессоров 2 и улучшение шедулера в сторону hyperthreading. Поднял на нём firebird, а теперь тестю производительнось через обращение к firebird по сети. Смотрю через gkrellm - cpu0 - нагружается на 100% а cpu1 - практически не нагружается(редкие всплески). В чём трабла?

есть такая опция в настройке ядра. Всё понятно - нужна например для поддержки других подсистем ядра, например selinux, или использоваться независимо. С SELinux всё понятно, а что конкретно в ядро добавляет эта опция - нет. Кинте линк плз - чёт ничего немогу найти.

есть где скачать?

Немогу найти консольный проигрыватель mp3 типа m3 blaster, с эквалайзером. Может кто посоветует?

А почему всё таки заголовки в /usr/include/{linux,asm} должны соответствовать тем с которыми компилировалась glibc? Как компилируемые программы могут пострадать от этого? Например использую я printf() - функция реализована в glibc, gcc использует файл /usr/include/stdio.h, glibc выполняет эту функцию, используя системные вызовы. - вроде бы всё акейна. Теперь беру какую либо функцию из /usr/include/linux - теперь моя программа откомпилится с системным вызовом, который выполнит ядро в обход glibc. При чём тут glibc...

Что-то никак в толк не возму.

у меня есть два ip X и Y. И есть скрипт запускайщийся раз в минуту, который поправляет статический роутинг, по следующей схеме: если шлюз для Y доступен, то сделать Y маршрутом по умолчанию, а X только для нескольких сетей. Если Y не доступен, то все пакеты посылать через X. - Всё работает хорошо. Теперь настроил sendmail, MX в dns указывает на X. Письма ходят до тех пор пока выключен маршрут Y. Только включаешь шлюз для Y и через минуту почта уже не приходит. Шлюз для Y - это спутниковый терминал, с частным ip. Поэтому входящих соединений для Y нет.

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

Заранее спасибо.

На сервере работает uucp'шная почта. Надо сделать почту по smtp, и оставить uucp. В sendmail.mc есть такие строки

MAILER(local) MAILER(smtp) MAILER(uucp)

Означает ли это что sendmail попытается сначала отослать почту через smtp, но если не сможет то через uucp?

присматриваюсь к системам подсчёта траффика, пока остановился на netacct. Но он плохо работает со squid и вот почему. Если использовать прозрачный прокси то всё работает, но если на клиентской машине прописать "использовать прокси" и указать ip:80 (для http, ftp и др) из набора бесплатных сетей, то netacct покажет, что весь трафик поступал от ip:80, то есть мягко говоря соврёт. Использовать отдельные анализаторы логов сквида не хотелось бы - потому как не сквидовый трафик не учитывается. И вот чего-то ничего в голову умного не приходит.

Может кто-чего подскажет?

Есть гейтвей (внутренний адрес 192.168.0.1)с запущенным sendmail. Почта из внехи на него приходит и если непосредственно с него отправяеть - отправяется. Но если посылать с клиентской машины (например opera'ой) - то сервер возвращает ошибку "Recipient error [550 5.7.1 <"адрес"@mail.ru>... Relaying denied. IP name lookup failed [192.168.0.3]]"

Вот содержание access:

root@celeron:/etc/mail# cat /etc/mail/access 192.168.0. RELAY

Долго уже гуглю но пока ничего не нашёл.

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

Есть настроенный sendmail через uucp. uucp работает нормально и кладёт письма в очередь /var/spool/clientmqueue и не приходят на локальные ящики(/var/mail/xxx). Перезагружаюсь - тогда приходят и очередь очищается. Что с этим делать?

Есть какая нибудь замена для дисциплины обработки очереди tbf. Она всем хороша но скорость всего до 1mbit/s.

i=2 IP_2="192.168.0.37"

echo ...

Что нужно поставить в echo для вывода 192.168.0.37 ?

Здравствуйте. Примерно с месяц назад я спрашивал как заставить внутренние машины прозрачно (насильно :)) ходить через внешний прокси сервер (т.е. внешний по отношению к шлюзу, через который ходят внутренние машины). В конце концов остановился на такой схеме: запустил transproxy, которая слушала 100 порт, и [как я раньше думал] заворачивала все пришедшие на него пакеты в обёртку пригодную для прокси, в которой адрес назначения = адресу прокси. Роль этой обёртки - доставить пакет до прокси. Когда пакет доходит до прокси, она выбрасывает обёртку и посылает оригинальный пакет. Например: посылаем пакет из внутренней сети (dest=ip_google.ru:80). Iptables на шлюзе редиректит с 80 на 100 порт. Transproxy ловит пакет на 100 порту, заворачивает его в обёртку (dest=ip_ext_proxy:80(dest=ip_google.ru:80)). Пакет без проблем доходит до прокси, которая снимает обёртку и посылает (dest=ip_google.ru:80). [/как я раньше думал]. А вчера пришлось перенастроить фаерволл, и с удивлением обнаружил что если использовать такие правила дла внутренних машин:

iptables -t nat -A PREROUTING -s 192.168.0.5\ -p tcp -m multiport --dports 80 -j DNAT --to-destination $PROX_IP

iptables -t nat -A POSTROUTING -s 192.168.0.5 -j SNAT --to-source $EXT_IP

,где $PROX_IP, и $EXT_IP, это ip адреса внешней прокси и ip сетевухи в мир на моём шлюзе соответственно, то всё замечательно ходит через внешнюю проксю, даже если в броузере, не выставлять галочку "использовать прокси сервер 192.168.0.1:80", и не используя transproxy. Ну и соответственно возникает вопрос: Как это может работать? Я думал что DNAT - это когда мы посылаем пакет например dest=ip_google.ru, а DNAT меняет dest=на_что_нибудь_другое. Если так, то с вышеуказанными првилами iptables, должно происходить вот что: dest=ip_google_ru меняется на $PROX_IP пакет доходит до прокси, а она приняв его, снимает обёртку(которой нет), и не знает что с ним делать. Информация о том что пакет должен дойти до google.ru осталась на машине которая выполняет DNAT.

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

Посидел поразминался с iptables многое понял. Одно мне не очень понятно, объясните кто-нибудь. Пишем правило например такое:

iptables -t nat -A OUTPUT -p tcp -dport 80 -j REDIRECT --to-port 100

Пакет должен после прохождения цепочки OUTPUT таблицы nat попасть опять на ту же самую машину. Что это значит? Каковы будут поля адреса источника/приёмника, порт получателя, каким будет считаться входной интерфейс, пойдёт ли этот пакет снова на цепочку INPUT. Мне не понятно почему при таком правиле браузер на этой же машине ходит в инет?

Нашёл TransparetProxy-howto. В нем описывается как настроить прозрачный прокси с локальным Squid (как я понял это прокся). А дальше есть такие строки:

6. Transparent Proxy to a Remote Box

Now, the question naturally arises, if we can do all this nifty stuff redirecting HTTP connections to local ports, could we do the same thing but to a remote box (e.g., the machine with squid running is not the same machine as iptables is running on). The answer is yes....

Первый споссоб, такой:

iptables -t nat -A PREROUTING -i eth0 -s ! squid-box -p tcp --dport 80 -j DNAT --to squid-box:3128

iptables -t nat -A POSTROUTING -o eth0 -s local-network -d squid-box -j SNAT --to iptables-box

iptables -A FORWARD -s local-network -d squid-box -i eth0 -o eth0 -p tcp --dport 3128 -j ACCEPT

Где squid-box - ip адрес удалённой прокси, local-network - это локальная сеть для которой мы являемся шлюзом, а iptables-box - это ip нашегно шлюза-фаервола.

И я что-то неочень понимаю, как оно работает. Вот например как я понимаю первую запись: у всех пакетов которые приходят на eth0, на 80-й порт tcp соединения, имеют адрес отправителя не = ip(squid-box), необходимо перед решением о роутинге поменять адрес получателя на ip(sqid-box):3128.

И как это так? Например оправляю я запрос на (google.ru) из локалки. Фаервол принимает запрос проверяет: пришёл на eth0, адрес источника - не ip(squid-box), порт 80. Пакт правилу удовлетворяет => надо поменять ip(google.ru) на ip(squid-box). Squid-box (прокся) пакет получит, но откуда она узнает куда его отправлять дальше? Вобщем я чего-то не понимаю, объясните пожалуйста.

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

Есть два компа, один (linux) с внешкой, в нём стоит 2 сетевухи. У одной сетевухи адрес 192.168.0.1 у другой реальный ip. Первый комп отлично работает шлюзом для второго. Но вот появился третий комп - для него тоже нужен интернет. Хочу обойтись без хаба, те в первый комп добавил третью сетевуху. А вот как всё это дело разрулить (роутить :) ) ... Обязательно ли чтобы все три сетевухи были в разных сетях или нет? (если да то я знаю что делать). Может можно просто назначить двум внутренним сетевухам один ip (ну ща вы меня запинете ;)) - и всё само заработает?

вобщем под ядром 2.4.29, включенным со слакой 10.1 - скорость харда

/dev/hda:
 Timing cached reads:   756 MB in  2.00 seconds = 378.00 MB/sec
 Timing buffered disk reads:  166 MB in  3.01 seconds =  55.15 MB/sec
  
вот что выводит hdparm /dev/hda:
  
/dev/hda:
 multcount    = 16 (on)
 IO_support   =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    =  8 (on)
 geometry     = 9729/255/63, sectors = 80026361856, start = 0

         
а под скомпиленым ядром 2.6.11.12:

/dev/hda:
 Timing cached reads:   692 MB in  2.00 seconds = 345.53 MB/sec
 Timing buffered disk reads:   92 MB in  3.02 seconds =  30.42 MB/sec

bash-3.00# hdparm /dev/hda1

 multcount    = 16 (on)
 IO_support   =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    =  8 (on)
 geometry     = 16383/255/63, sectors = 10487199744, start = 63


Те почти в 2 раза скорость во втором случае меньше из-за чего?