Помогите!
Для подсчета трафика используется цель ACC iptables (http://zzz.corg.ru/u/Members/dmitry/nf2).
Все было замечательно, пока не поставили маршрутизатор на VIA Eden (http://www.via-c3.ru/products/motherboard/via_epia_mini-itx.shtml).
cat /proc/cpuinfo
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 7
model name : VIA Samuel 2
stepping : 3
cpu MHz : 599.903
cache size : 64 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu de tsc msr cx8 mtrr pge mmx 3dnow
bogomips : 1196.03

И все, считает совершенно неправильно!
Причем, если посмотреть счетчики iptables, то все верно:
4144 3202K ACC all -- eth0 * 0.0.0.0/0 0.0.0.0/0 MARK set 0x2
А в том, что выдает стандартная прога ipacc - нет ничего похожего.

Пробовал перекомпилировать модуль ipt_ACC и под i386 и под VIA С3 (ядро 2.4.18, варианты оптимизации) - результат одинаков.

Что может быть не так? Что можно поправить в исходниках?
Почему?! На этой же машине все остальное (iptables, named, ppptp, pppd) работает идеально.

Купили винт Seagateовский SATA на 200G. Подрубили к Линуху. Линух говорит, что размер винта 137438952960 bytes. BIOS честно сообщает, что 200G.
Слышал про ограничение в 128гиг, что рекомендуют переходить на ядра 2.6.x.
Правда ли, что проблема решается только в ядрах 2.6.x?
Существует ли патч для 2.4.x?
Где вообще можно прочитать про эту проблему?

Что-то последнюю неделю пошла мода у пользователей прописывать IP-адрес шлюза. В результате вся сеть лишается Инета.
Как с этим можно бороться?
В качестве шлюза выступает Debian-Linux.
arp -s на каждом клиенте не годится, ибо их (клиентов) порядка сотни.

Остро стоит вопрос о том, что лучше купить в качестве маршрутизатора, чтобы раздавать Интернет множеству клиентов: какую-нибудь (говорю так, потому что к сожалению не имею никакого опыта общения с подобными животными) Киску или хороший мощный писишник, куда поставить Линух.
В связи с этим очень интересует мнение уважаемых коллег как по поводу одних, так и по поводу других.
Существуют ли задачи, которые легко решает Cisco, но невозможно решить на Linux и наоборот?
Как ведут себя и те и другие, если "терминировать" придется десятки сетей с десятками машин в каждой?
и проч. и проч.

Пытаюсь поднять ntpd, чтобы множество других машин могли подстраивать свои часы по нему с помощью ntpdate.
Делаю ntpdate -dv xx.xx.xx.xx
выдает:
...
transmit(xx.xx.xx.xx)
receive(xx.xx.xx.xx)
...
stratum 16, precision -17, leap 11, trust 000
refid [0.0.0.0], delay 0.02609, dispersion 0.00000
3 Mar 16:13:10 ntpdate[10795]: no server suitable for synchronization found

Меня смущает, почему stratum = 16 и refid = 0.0.0.0.
В конфигах сервер, по которому надо синхронизироваться прописан. Более того, при пять минут назад наш ntpd успешно ответил, указав stratum = 3 и refid указывающий на его сервер. А теперь вдруг перестал, хотя конфы не менялись, и дальше ни в какую.
Отчего это может быть?
У меня подозрения, что ntpd просто не хочет выдавать инфу, пока сам не синхронизировался с другим сервером, который refid.

Надо, чтобы sendmail принимал почту со всего мира (FEATURE(promiscuous_relay) ?), но только ДЛЯ определенных доменов и релеил ее на smart host (FEATURE(`nullclient', myrelay.xx.yy)).
В каком файле и что прописать, чтобы письма НА определенные домены relayились, а остальные rejectились?

Организуем доступ к Интернет.
Раньше на каждого клинта стоял свой маршрутизатор, который собирал статистику, натил и проч. Один линуховый роутер на, максимум, 50 клиентских машин.
Теперь появилась возможность соединить всех этих разрозненных клиентов в "единую" сеть через VLANы и раздавать Интернет из единого центра.
Интуитивно ощущается, что нагрузка на этот центральный маршрутиатор будет нехилая (500 - 1000 клиентских машин). Понятно, что лучше привлечь какую-нибудь Cisco. Только вот опыта работы с ними нет.

Если маршрутизатор будет на Линухе, каковы будут особенности настройки ядра, какие требования к железу, как это можно оценить?

Сабж для нескольких локальных сетей.
Кто что посоветует?
ircd-RU не предлагать.

Хочу сделать сабж, чтобы можно было определить отсутствие связи и прочие проблемы, произошедшие с ssh.
Однонаправленный вариант работает нормально ($proga на сервере получает данные):
$pid = open(RECV, "| -");
$SIG{ALRM} = sub { die "whoops, program pipe broke" };
if($pid)
{
print RECV "blablabla" || die ("Can't send data!\n");
close(RECV) || die ("SSH exited $?");
exit 0;
}
else
{#child
($EUID, $EGID) = ($UID, $GID);
exec("/usr/bin/ssh $user\@$server $proga 2>/dev/null") || die "can't exec program: $!";
}
Самый страшный двунаправленный вариант, который придумался - вот такой (данные получает шелл пользователя $user):
pipe(PR, CW);
pipe(CR, PW);
$pid = fork();
$SIG{ALRM} = sub { dielog("ssh pipe broke"); };
if ($pid)
{#parent
close PR; close PW;
print CW "blablabla" || dielog("can't send data");
close(CW) || dielog("ssh exited $?");
close(CR) || dielog("ssh exited $?") ;
waitpid($pid,0);
exit 0;
}
else
{#child
dielog("cannot fork: $!") unless defined $pid;
close CR; close CW;
open(STDOUT,">&PW"); close PW;
open(STDIN,"<&PR"); close PR;
($EUID, $EGID) = ($UID, $GID);
my $server = "$ssh $user\@server 2>/dev/null";
exec($server) || dielog("can't exec $server: $!");
}
Вот этот вариант успешно завершается даже при попытке послать данные на несуществующий сервер (левый ip-шник).
Что я делаю не так? Существует ли более элегантное решение? Мне важно, чтобы скрипт прерывался при любых проблемах со связью.

Пытаемся получать интернет через спутник и раздавать его юзверям.
Тестовая конфигурация такая: есть выделенка, интерфейс eth0, поднимаем через нее VPN канал (с помощью pptp), интерфейс ppp0, через который идут запросы наружу. Есть DVB карточка Pent@Net, интерфейс pentanet0, через который приходят ответы. На машинке работает squid, таким образом юзвери, работающие через проксю - получают интернет через спутник.
С маршрутизацией вроде разобрались. В перспективе хотелось бы избавиться от VPN туннеля. Но речь не об этом.
Хочется firewallом прикрыть все дырки. В стандартном варианте все решается таким образом:
iptables -P INPUT DROP #все закрываем
iptables -A INPUT -p ALL -m state --state ESTABLISHED,RELATED -j ACCEPT #разрешаем ответы на запросы squid
iptables -A INPUT -p tcp --dport 3128 -j ACCEPT #разрешаем запросы юзверей к squid
iptables -P OUTPUT ACCEPT #не будем параноиками
Прошу обратить внимание на вторую строчку. squid, как клиент, обращается к внешним серверам с, в общем случае неизвестно какого, порта. И, чтобы, не открывая лишних портов, разрешить получать данные с них, эта строчка необходима.
Но, в случае со спутником, запросы уходят с одного интерфейса, а ответы приходят на другой. И трассировка соединений не работает!
Можно ли как-то заставить модуль ip_conntrack игнорировать интерфесы, с которых идут пакеты? Или возможно ли какое-то более элегантное решение? Или все-таки придется писать iptables -A INPUT -i pentanet0 -j ACCEPT ?

Тупой но интересный вопрос. И клиенту надо срочно ответить. Помогите!
Каким образом можно запустить (выполнить) php-скрипт из командной строки и, в частности, по cron'у?
Можно ли это как-то сделать по образу и подобию perl? Или самый честный способ - сформировать http-запрос хотя бы lynx'ом?

Проблемка такая. Стоит на Debian 3.0 (2.4.18) apache 1.3.27rusPL30.17, к нему прикручены mod_ssl-2.8.14-1.3.27 и php-4.2.1, также запущен MySQL 3.23.49. Открываем из MSEI 5.5 или 6.0 через https соединение некий php-скрипт, который делает маленький запрос к базе и в результате получаем "Невозможно отобразить страницу". Если несколько раз нажать F5 - то страничка может и появится. Если же заходить на тот же php через просто http - все OK. Причем с тем же MSIE под NT я такого не видел ни разу! А машина под 9x в той же сети - ругается. У клиентов через пару хопов - вообще не работает.
В чем грабли? В винде поганой?

В машине стоит три одинаковые сетевухи на чипе Davicom. Для них загружается один на всех модуль dmfe. Необходимо одну их сетевух перевести в 10Мб. Задача решается передачей модулю параметра mode=0. Но, если в /etc/modules.conf приписать options dmfe mode=0, то в 10Мб переключатся все три сетевухи, а этого нам не надо. Как передать различные параметры разным экземплярам модуля? Ось - Debian 3 (2.14.18).