Странно ми се вижда, че няма никакъв пристигнал пакет на eth0, в смисъл, че и аз съм към LAN-ка и определено пристига доста паразитен трафик - broadcast, разни ентусиасти, дето се пробват да ми налучкат паролата на ssh-a, вируси... та се посъбират получени пакети, даже и без активност от моя страна, а при теб показва RX packets:0 Тази стойност дали се променя с времето?
Каква е картата?
А дистрибуцията?
Някакви странни записи относно картата в логовете?
Безболезнен вариант да пробваш с друга карта?

[Цитат]

Цитат (poisoner @ Дек. 28 2005,21:44)

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

А защо ти е парола, като можеш да се аутентифицираш с двойка ключове?

Да разбирам ли, че няма интернет на този компютър?
И че проблема е в ping към хостове от 10.0.0.0/8?

Няма указан defaut gateway, така че друга мрежа този компютър няма как да достигне. Ако пингваш хостовете по име, евентуално би било проблем, ако днс сървъра е извън тази мрежа...
Вместо iptables-save, дай резултата от iptables -L
Дай и командата с която пингваш другия компютьр
След като пробваш да пингнеш другия хост, дай едно arp -a и виж дали там има запис за него, това би означавало проблем с firewall-a

Успех!

Интересен би бил и резултата от
route -n
като добавка към IP и netmask

[@gandonov]

@gandonov
Ами аз пробвах синхронизация, това, което мога да кажа е, че се получи и проблеми не забелязах, независимо кой от двата диска съм махнал. Имаше обаче една подробност - след като единия диск бъде откачен, на следващото му закачане се налагаше да добавям "на ръка" дяловете, които участват в масива. За 2x120GB hdd синхронизацията отнема около 3 часа, като през това време системата си работи, нямах подходящо натоварване за да засека нарушена производителност. Според данните от /proc/mdstat синхронизиртането беше орязано на 10000KBps, така че основното ограничение не е от дискове/шина/процесор.

@hary
Честито! Иначе и аз имам една забележка - хич не е зле /boot да си е отделен дял в началото на диска. Моите предпочитания поне са такива, човек все може да жертва 80-100 MB за да спи спокойно като сложи нов кернел по-късно. '>

Просто декларацията на dport е с --dport, а не -dport

Няма да ти навреди, ако поне малко почетеш по темата, сляпото преписване на команди няма да ти е от кой-знае каква полза.

Успех!

Ами ограничение върху обема има... поне в postfix... ограничението се дефинира от администратора '> аз поне не се сещам за друго ограничение, освен от файловата система... при ext3 e 4TB '>
Аз ползвам Postfix+CyrusIMAP+amavis+clamav+spamassassin с MySQL backend за паролите, но мисля, че за теб може да се окаже по-подходящ LDAP... наскоро излезе Fedora Directory Server, мисля, че тука на сайта беше анонсиран че във възможностите му влиза и синхронизация с Windows LDAP, което би трябвало да ти позволи да си ползваш акаунти от активната директория, не съм тествал, не зная подробности. От всички споменати по-горе, само Windows LDAP не е под GPL '>
ClamAV ми е изпуснал 1 вирус за 6 месеца откак работи (може и късмет да е), а всичкото това върви върху Fedora, която смятам да го заменя със Scientific Linux заради прекалено късия живот на версиите, докато SL се билдва от сорсовете на RedHat Enterprise Linux и има доста по-продължителен reselase time. RHEL, също като SLES е платен, но дериватите му като Scientific Linux са под GPL

Във всеки случай каквото и да избереш - приятно четене. '>

Ами аз си реших въпроса с еднакви дискове, правиш си raid-a, после копираш на "втория" MBR-a от "първия" и си готов... пардон - СЪМ готов, при мен тръгна, не съм сигурен дали това е  верния начин. Нямам идея и доколко е безопасно начинанието - тогава работех с чисто нови дискове и нямах притеснения от загуба на данни.
Резултата от това е, че който и от двата физически диска да отпадне, другия е в състочние да "запали" сам.

За swap-a обаче не виждам смисъла - не знам там да има и байт информация дето да си струва раид-ването, по-добре раздели групата и си имай 2 пъти повече swap '>

Това би трябвало да може да се получи с подходяща маска (umask) и вдигнат SGID-bit на директорията. Може би ще трябва рекурсивно... не съм борил много темата, просто попаднах на това свойство на SGID-бита за директория - всички файлове в нея наследяват групата, остава маската да кара файловете да са с права rwrw-- примерно, т.е. еднакви за user и group.
Според мен можеш да съобразиш юзерите и групите в дистрибуциите, под които споменаваш, че ще се монтира дяла... само това дето го пишеш - да е независимо от същинските разрешения... не го виждам да стане, т.е ако ставаше щеше да е доста притеснително откъм сигурност на файловата система.

Успех!

Добре де, дай да започнем от там какво се случва при опит за resolve. Аз поне не разбрах какво се случва - намира ли сървъра, сървъра намира ли отговор...
Дай изхода от
dig hostname.my.dom

И друг интересен въпрос ми се завъртя из вакуума в главата - сигурно ли е, че порта е отворен през firewall-a? '>

Успех!

Специално за yum е описано в:
man yum.conf
Иначе имаше някаква променлива, която се експортваше (мисля при по-старите версии - имам спомен за FC1), но нямам спомен за точното име.

ами гледам, че става така:

iptables -A INPUT -m helper --helper ftp-2221

но резултата ми е неизвестен '>

никаква промяна ли не настъпи с "modprobe ip_conntrack_ftp"?

[Примерен код]

Зареждането на ip_conntrack_ftp не помага ли?
A това чудо, наречено helper?
виж какво пише в man-a за него:

Примерен код

helper        This module matches packets related to a specific conntrack-helper.        --helper string               Matches packets related to the specified conntrack-helper.               string  can  be  "ftp"  for packets related to a ftp-session on               default port.  For other ports append -portnr to the value, ie.               "ftp-2121".               Same rules apply for other conntrack-helpers.

И виж дали ако свалиш firewall-a на "клиента" няма да се променят нещата, не е казано, че само сървъра прецаква нещата.

ами може и да няма смисъл от такава опция, трябва да се пробва, просто data-connection почти винаги е на порт с 1 по-малък от този на control connection, при vsftpd това явно не е задължително, та затова си има опция, при proftpd може да си фиксиран порта
netstat ще ти свърши работа в случая

Ами не точно: във vsftpd.conf указах, че искам фиксиран порт за data-connection и кой е този порт, при мен е от нерпивелигированите - 2120 в случая, просто с 21 и 20 имах проблем с един Вин - имаше firewall, a човека на него твърдеше, че няма и отказваше да коригира каквото и да е, оказа се, че като минах на "горни портове" (след 1023) нещата си станаха, изглежда win-a преживява по-лесно връзка от непривелигирован порт, отколкото от привелигирован.  '>