lug-bg: Re: lug-bg: Странен проблем
- Original Message - From: "Spas Pavlov" <[EMAIL PROTECTED]> To: Sent: Thursday, September 28, 2006 3:18 PM Subject: Re: lug-bg: Странен проблем On Thursday 28 September 2006 14:38, Ivan Ivanov wrote: - Original Message - From: "Spas Pavlov" <[EMAIL PROTECTED]> To: Sent: Thursday, September 28, 2006 2:00 PM Subject: Re: lug-bg: Странен проблем > On Thursday 28 September 2006 12:50, Ivan Ivanov wrote: >> > ПП: Сложи за тест 3com цената им е около 30-40$ и виж дали ще се >> > оправи ако ли не , помисли за ъпгрейд :), но мисля , че само за >> > рутиране не трябва да имаш никакви проблеми с такива машини и такива >> > скорости. >> >> Смених мрежовите карти на едната машина(с intel) но проблема си >> остана... Моля за идеи ... :-) > > Здравейте, > > "Connection tracking" да е ??? > За него трябва да имаш съобщения из syslog. > > Спас Павлов По логовете няма нищо нередно.. Най-лесно се познава дали е от connections tracking, като пуснеш пинг (да мине през машината) връща нещо от сорта: ping: sendmsg: Operation not permitted... Друга идея: пусни tcpdump и гледай за пакети, на които src И dst (src && dst ) адреси не са твои. В тази връзка имаш ли VLAN интерфейси? Спас Павлов ping: sendmsg: Operation not permitted... не дава и не излизат адреси които да не са мои. няма VLAN интерфейси
Re: lug-bg: Странен проблем
On Thursday 28 September 2006 14:38, Ivan Ivanov wrote: > - Original Message - > From: "Spas Pavlov" <[EMAIL PROTECTED]> > To: > Sent: Thursday, September 28, 2006 2:00 PM > Subject: Re: lug-bg: Странен проблем > > > On Thursday 28 September 2006 12:50, Ivan Ivanov wrote: > >> > ПП: Сложи за тест 3com цената им е около 30-40$ и виж дали ще се > >> > оправи ако ли не , помисли за ъпгрейд :), но мисля , че само за > >> > рутиране не трябва да имаш никакви проблеми с такива машини и такива > >> > скорости. > >> > >> Смених мрежовите карти на едната машина(с intel) но проблема си > >> остана... Моля за идеи ... :-) > > > > Здравейте, > > > > "Connection tracking" да е ??? > > За него трябва да имаш съобщения из syslog. > > > > Спас Павлов > > По логовете няма нищо нередно.. Най-лесно се познава дали е от connections tracking, като пуснеш пинг (да мине през машината) връща нещо от сорта: ping: sendmsg: Operation not permitted... Друга идея: пусни tcpdump и гледай за пакети, на които src И dst (src && dst ) адреси не са твои. В тази връзка имаш ли VLAN интерфейси? Спас Павлов
lug-bg: Re: lug-bg: Странен проблем
- Original Message - From: "Spas Pavlov" <[EMAIL PROTECTED]> To: Sent: Thursday, September 28, 2006 2:00 PM Subject: Re: lug-bg: Странен проблем On Thursday 28 September 2006 12:50, Ivan Ivanov wrote: > ПП: Сложи за тест 3com цената им е около 30-40$ и виж дали ще се оправи > ако ли не , помисли за ъпгрейд :), но мисля , че само за рутиране не > трябва да имаш никакви проблеми с такива машини и такива скорости. Смених мрежовите карти на едната машина(с intel) но проблема си остана... Моля за идеи ... :-) Здравейте, "Connection tracking" да е ??? За него трябва да имаш съобщения из syslog. Спас Павлов По логовете няма нищо нередно..
Re: lug-bg: Странен проблем
On Thursday 28 September 2006 12:50, Ivan Ivanov wrote: > > ПП: Сложи за тест 3com цената им е около 30-40$ и виж дали ще се оправи > > ако ли не , помисли за ъпгрейд :), но мисля , че само за рутиране не > > трябва да имаш никакви проблеми с такива машини и такива скорости. > > Смених мрежовите карти на едната машина(с intel) но проблема си остана... > Моля за идеи ... :-) Здравейте, "Connection tracking" да е ??? За него трябва да имаш съобщения из syslog. Спас Павлов
lug-bg: Re: lug-bg: Re: lug-bg: Странен проблем
Ivan Ivanov wrote: Здравейте, От скоро наблюдавам следният проблем при 2 рутиращи машини: При повишаване на трафика машината започва да се товари и се появява загуба на пакети. Става предимно при upload. Процесора се товари от softirqd. Едната машина е с ядро 2.6.8 а другата с 2.4.26. Машините са напълно различни като хардуер, освен може би мрежовите карти които са Realtek. На едната машина сменях мрежовите карти, сложих Kingston но проблема си остана. Някои има ли някаква идея от къде може да идва този проблем? Какви са машите е добре да се знае ( дали имат hypertreiding ми е по скоро въпроса ). Добре е да смениш ланките с нещо по добро . Това което бих ти предложил е или 3com или Intel ( лично предпочитам интел ). И все пак какъв трафик минава през тях. Забравих да питам дали тези машини само рутират или правят и нещо друго ( NAT , шейпъри или някой други iptables правила ). Но мисля че основния ти проблем са самите ланки. Другото което може да тестваш е SMP affinity ето линк с малко инфо за него. http://bcr2.uwaterloo.ca/~brecht/servers/apic/SMP-affinity.txt ПП: Сложи за тест 3com цената им е около 30-40$ и виж дали ще се оправи ако ли не , помисли за ъпгрейд :), но мисля , че само за рутиране не трябва да имаш никакви проблеми с такива машини и такива скорости. Смених мрежовите карти на едната машина(с intel) но проблема си остана... Моля за идеи ... :-)
lug-bg: Re: lug-bg: Странен проблем
Забравих да питам дали тези машини само рутират или правят и нещо друго ( NAT , шейпъри или някой други iptables правила ). Но мисля че основния ти проблем са самите ланки. Другото което може да тестваш е SMP affinity ето линк с малко инфо за него. http://bcr2.uwaterloo.ca/~brecht/servers/apic/SMP-affinity.txt ПП: Сложи за тест 3com цената им е около 30-40$ и виж дали ще се оправи ако ли не , помисли за ъпгрейд :), но мисля , че само за рутиране не трябва да имаш никакви проблеми с такива машини и такива скорости. На едната машина се прави маскиране, на другата не. и на двете работят шейпъри, има и доста iptables правила. SMP affinity - мога да си поиграя с него но само на двупроцесорната машина. В момента прекомпилирам кърнела и ще пробвам с Intel-ски ланки. Ако не се оправи пак ще пиша. Благодаря за съдействието.
Re: lug-bg: Re: lug-bg: Странен проблем
Ivan Ivanov wrote: Няма hypertreiding, първата машина е Kayak, 2 процесора по 550, Втората е с един процесор AMD XP 1800+ трафика при първата е около 30 Mbit,а при втората 20 Mbit. - Original Message - From: "Георги Генов" <[EMAIL PROTECTED]> To: Sent: Tuesday, September 26, 2006 11:05 AM Subject: Re: lug-bg: Странен проблем Ivan Ivanov wrote: Здравейте, От скоро наблюдавам следният проблем при 2 рутиращи машини: При повишаване на трафика машината започва да се товари и се появява загуба на пакети. Става предимно при upload. Процесора се товари от softirqd. Едната машина е с ядро 2.6.8 а другата с 2.4.26. Машините са напълно различни като хардуер, освен може би мрежовите карти които са Realtek. На едната машина сменях мрежовите карти, сложих Kingston но проблема си остана. Някои има ли някаква идея от къде може да идва този проблем? Какви са машите е добре да се знае ( дали имат hypertreiding ми е по скоро въпроса ). Добре е да смениш ланките с нещо по добро . Това което бих ти предложил е или 3com или Intel ( лично предпочитам интел ). И все пак какъв трафик минава през тях. Забравих да питам дали тези машини само рутират или правят и нещо друго ( NAT , шейпъри или някой други iptables правила ). Но мисля че основния ти проблем са самите ланки. Другото което може да тестваш е SMP affinity ето линк с малко инфо за него. http://bcr2.uwaterloo.ca/~brecht/servers/apic/SMP-affinity.txt ПП: Сложи за тест 3com цената им е около 30-40$ и виж дали ще се оправи ако ли не , помисли за ъпгрейд :), но мисля , че само за рутиране не трябва да имаш никакви проблеми с такива машини и такива скорости. begin:vcard fn:George Genov n:Genov;George adr:;;;Veliko Tyrnovo;;5000;Bulgaria email;internet:[EMAIL PROTECTED] tel;work:062/60-30-71 tel;cell:0888/644622 x-mozilla-html:FALSE url:http://www.magibg.com version:2.1 end:vcard
lug-bg: Re: lug-bg: Странен проблем
Няма hypertreiding, първата машина е Kayak, 2 процесора по 550, Втората е с един процесор AMD XP 1800+ трафика при първата е около 30 Mbit,а при втората 20 Mbit. - Original Message - From: "Георги Генов" <[EMAIL PROTECTED]> To: Sent: Tuesday, September 26, 2006 11:05 AM Subject: Re: lug-bg: Странен проблем Ivan Ivanov wrote: Здравейте, От скоро наблюдавам следният проблем при 2 рутиращи машини: При повишаване на трафика машината започва да се товари и се появява загуба на пакети. Става предимно при upload. Процесора се товари от softirqd. Едната машина е с ядро 2.6.8 а другата с 2.4.26. Машините са напълно различни като хардуер, освен може би мрежовите карти които са Realtek. На едната машина сменях мрежовите карти, сложих Kingston но проблема си остана. Някои има ли някаква идея от къде може да идва този проблем? Какви са машите е добре да се знае ( дали имат hypertreiding ми е по скоро въпроса ). Добре е да смениш ланките с нещо по добро . Това което бих ти предложил е или 3com или Intel ( лично предпочитам интел ). И все пак какъв трафик минава през тях.
Re: lug-bg: Странен проблем с апаче
Благодаря на всички които отговориха, внасям малко яснота и допълнителни данни и ви очаквам пак :) >W май беше статус paging (man ps), може би поради това, че още не е уточнен >статуса на кънекшъна, но пък всички процеси да са в това състояние май вече >става подозрително. Мой пропуск, че не съм уточнил че става въпрос за /server-status на апачето,а не за ps, т.е "W" състояние си е "Sending Reply" според него. >Това наистина прилича на tcp syn attack, само, че тук си съкратил малко от >тези съобщения "client stopped connection" и има още неща освен rvputs, >rwrite Прегледах пак логовете, има и Send timed out, ето примерен отрязък: [Mon Dec 27 07:47:37 2004] [info] [client x.y.z.133] (104)Connection reset by peer: client stopped connection before rwrite completed [Mon Dec 27 07:47:38 2004] [info] [client x.y.z.60] (104)Connection reset by peer: client stopped connection before rwrite completed [Mon Dec 27 07:47:41 2004] [info] [client x.y.z.179] send timed out [Mon Dec 27 07:47:41 2004] [info] [client x.y.z.179] client stopped connection before rvputs completed [Mon Dec 27 07:47:46 2004] [info] [client x.y.z..137] send timed out [Mon Dec 27 07:47:46 2004] [info] [client x.y.z.137] client stopped connection before rvputs completed [Mon Dec 27 07:47:46 2004] [info] [client x.y.z.60] send timed out [Mon Dec 27 07:47:46 2004] [info] [client x.y.z.60] client stopped connection before rvputs completed [Mon Dec 27 07:47:46 2004] [info] [client x.y.z.225] (104)Connection reset by peer: client stopped connection before rwrite completed [Mon Dec 27 07:47:49 2004] [info] [client x.y.z.109] send timed out >Наблюдавай за връзки в наполовина-отворено (half-open) състояние с: >netstat -n -p TCP | grep SYN_RECV >даже може да го зациклиш да блъска във някой файл... На мен това ми беше една от първите идеи, точно това и направих, огледах резултантното файлче, SYN_RECV бяха около 200 , но трябва да се има в предвид че: при нормална работа има около 100 такива ( т.е. сървъра си е натоварен); syncoocies защитата ми е активна; нямаше много повтарящи се ip-та. >Разгледай малко tcp flags с: >tcpdump -i $IFACE 'tcp[tcpflags] & (tcp-syn ) != 0 ' -vvv >или >tcpdump -i $IFACE 'tcp[tcpflags] & (tcp-fin | tcp-syn | tcp-rst | tcp-push | >tcp-ack | tcp-urg) != 0 ' -vvv Това не съм го правил но трябва да се има в предвид че филтрирам някои шитс и меря количеството на филтрираните: #PROTECTION /sbin/iptables -A INPUT -i eth0 -p tcp ! --syn -m state --state NEW -j b_block #disallow packets frequently used by port-scanners # All of the bits are cleared /sbin/iptables -A INPUT -p tcp --tcp-flags ALL NONE -j b_block # SYN and FIN are both set /sbin/iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j b_block # SYN and RST are both set /sbin/iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j b_block # FIN and RST are both set /sbin/iptables -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j b_block # FIN is the only bit set, without the expected accompanying ACK /sbin/iptables -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j b_block # PSH is the only bit set, without the expected accompanying ACK /sbin/iptables -A INPUT -p tcp --tcp-flags ACK,PSH PSH -j b_block # URG is the only bit set, without the expected accompanying ACK /sbin/iptables -A INPUT -p tcp --tcp-flags ACK,URG URG -j b_block /sbin/iptables -A INPUT -p tcp --tcp-flags SYN,RST,ACK SYN -j flood_prot /sbin/iptables -A INPUT -i eth0 -p icmp --icmp-type timestamp-request -j b_block ..и по време на кризисните периоди нямаше голямо увеличение на блокираните пакети b_block, нито съм имал логнати активации на флууд протекшъна. >2) tcp_max_syn_backlog задава колко на брой tcp връзки в наполовина отворено >състояние се допускат в backlog queue. >sysctl -w net.ipv4.tcp_max_syn_backlog=1024 Да евентуално мога да го намаля до 400 сега е 1024 3) tcp_syn_retries имаше ли в 2.4 ? ако има дай му 5-10. и въобще разгледай стойностите на променливите /proc/sys/net/ipv4/tcp* за нещо интересно. cat /proc/sys/net/ipv4/tcp_retries1 3 cat /proc/sys/net/ipv4/tcp_retries2 15 Смъкнал съм и някои други таймаутс и ретрайс.Увеличил съм и паметта за TCP/IP стека. Ето и топа от времето на проблема: 08:06:20 up 50 days, 13:25, 2 users, load average: 370.48, 363.99, 356.72 637 processes: 635 sleeping, 1 running, 1 zombie, 0 stopped CPU0 states: 3.1% user 2.2% system0.0% nice 0.0% iowait 94.0% idle CPU1 states: 2.3% user 1.0% system0.0% nice 0.0% iowait 96.0% idle CPU2 states: 4.2% user 0.4% system0.0% nice 0.0% iowait 94.3% idle CPU3 states: 1.1% user 3.1% system0.0% nice 0.0% iowait 95.1% idle Mem: 5030532k av, 464k used, 381644k free, 0k shrd,1052k buff 1415204k actv, 1174416k in_d, 44920k in_c Swap: 530136k av, 0k used, 530136k free 2749728k cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
Re: lug-bg: Странен проблем с апаче
Georgi Genov wrote: и порчети малко инфо за syncookies! Ето ти инфо: http://www.physnet.uni-hamburg.de/physnet/security/vulnerability/synk4.html Ето ти я и гадорийката където ги прави тези неща: http://www.hoobie.net/security/exploits/hacking/synk4.c -- Georgi Genov [EMAIL PROTECTED] A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers). http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
Re: lug-bg: Странен проблем с апаче
On Monday 27 December 2004 15:00, Hristo Chernev wrote: > Понеже нищо повече не ми ражда главата, ще се допитам до вас за проблема, > който не ме остави да спя. > > Двупроцесорна машинка с Xeon-и, много памет - 5ГБ, scsi u160 диск. На нея - > 2.4 кернел smp bigmem(redhat9), 1.3.31 апач с 4.3.9 php, qmail , bind > 9.2.1.16 (rh). Има и малък firewall с iptables 1.2.7а.2.(rh) > > Както си работеше безпроблемно 2 месеца така тая нощ се появи 3 пъти > проблема, като двата пъти изчезна след около половин час и работи нормално > 2 часа, но третия си остана в такова - ни живо, ни умряло състояние: > > http услугата на апаче не отговаря или много бавно отговаря, apaчe > процесите sa na max и са всички във 'W' състояние - Sending Reply, в лога W май беше статус paging (man ps), може би поради това, че още не е уточнен статуса на кънекшъна, но пък всички процеси да са в това състояние май вече става подозрително. > на системата нищо, на екрана нищо,в ерор лога на апача има много от тези и > все от различни IP-ta: > client stopped connection before rvputs completed > client stopped connection before rwrite completed Това наистина прилича на tcp syn attack, само, че тук си съкратил малко от тези съобщения "client stopped connection" и има още неща освен rvputs, rwrite Наблюдавай за връзки в наполовина-отворено (half-open) състояние с: netstat -n -p TCP | grep SYN_RECV даже може да го зациклиш да блъска във някой файл... Разгледай малко tcp flags с: tcpdump -i $IFACE 'tcp[tcpflags] & (tcp-syn ) != 0 ' -vvv или tcpdump -i $IFACE 'tcp[tcpflags] & (tcp-fin | tcp-syn | tcp-rst | tcp-push | tcp-ack | tcp-urg) != 0 ' -vvv обаче това е интересно да се види по време на атаката. Евентуални действия: 1) вдигаш tcp syncookies на 1 както беше казано, ако не помага, то не боли. 2) tcp_max_syn_backlog задава колко на брой tcp връзки в наполовина отворено състояние се допускат в backlog queue. sysctl -w net.ipv4.tcp_max_syn_backlog=1024 3) tcp_syn_retries имаше ли в 2.4 ? ако има дай му 5-10. и въобще разгледай стойностите на променливите /proc/sys/net/ipv4/tcp* за нещо интересно. 2 и 3 по-скоро ги провери и ги остави както, ако пак има грижа, може да ги понамалиш малко... инспектирането на syslog и messages за странни неща около часовете когато се е наблюдавало това явление е силно препоръчително. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers). http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
Re: lug-bg: Странен проблем с апаче
Georgi Genov wrote: Danail Petrov wrote: Hristo Chernev wrote: Понеже нищо повече не ми ражда главата, ще се допитам до вас за проблема, който не ме остави да спя. Двупроцесорна машинка с Xeon-и, много памет - 5ГБ, scsi u160 диск. На нея - 2.4 кернел smp bigmem(redhat9), 1.3.31 апач с 4.3.9 php, qmail , bind 9.2.1.16 (rh). Има и малък firewall с iptables 1.2.7а.2.(rh) Както си работеше безпроблемно 2 месеца така тая нощ се появи 3 пъти проблема, като двата пъти изчезна след около половин час и работи нормално 2 часа, но третия си остана в такова - ни живо, ни умряло състояние: http услугата на апаче не отговаря или много бавно отговаря, apaчe процесите sa na max и са всички във 'W' състояние - Sending Reply, в лога на системата нищо, на екрана нищо,в ерор лога на апача има много от тези и все от различни IP-ta: client stopped connection before rvputs completed client stopped connection before rwrite completed Трафика намалял на 1/3 и като обем и като бр. пакети Другите услуги ( те не товарят кой знае колко по принцип - сигурно <1% ), нормално си работеха, в шела си беше пъргава машинката .. Подобно ми се е получавало като се скапе нещо базата с която се свързва ( на друга машина), но този път базата си беше ок. Памет има предостатъчно свободна load average >300 vmstat: cat /proc/sys/net/ipv4/tcp_syncookies ако ти върне 1 значи проблема е на друго място, а ако пък не върне 1 то добави този ред: echo 1 > /proc/sys/net/ipv4/tcp_syncookies във файла rc.local а ако искаш и да не рестартираш го изпълни като root и порчети малко инфо за syncookies! Според мен проблема не е това , също така е хубаво кернел параметрите да бъдат подавани със `sysctl' , и да се записват в /etc/sysctl.conf :) echo 'net.ipv4.tcp_syncookies = 1' >> /etc/sysctl.conf BR, Danail Petrov A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers). http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
Re: lug-bg: Странен проблем с апаче
Danail Petrov wrote: Hristo Chernev wrote: Понеже нищо повече не ми ражда главата, ще се допитам до вас за проблема, който не ме остави да спя. Двупроцесорна машинка с Xeon-и, много памет - 5ГБ, scsi u160 диск. На нея - 2.4 кернел smp bigmem(redhat9), 1.3.31 апач с 4.3.9 php, qmail , bind 9.2.1.16 (rh). Има и малък firewall с iptables 1.2.7а.2.(rh) Както си работеше безпроблемно 2 месеца така тая нощ се появи 3 пъти проблема, като двата пъти изчезна след около половин час и работи нормално 2 часа, но третия си остана в такова - ни живо, ни умряло състояние: http услугата на апаче не отговаря или много бавно отговаря, apaчe процесите sa na max и са всички във 'W' състояние - Sending Reply, в лога на системата нищо, на екрана нищо,в ерор лога на апача има много от тези и все от различни IP-ta: client stopped connection before rvputs completed client stopped connection before rwrite completed Трафика намалял на 1/3 и като обем и като бр. пакети Другите услуги ( те не товарят кой знае колко по принцип - сигурно <1% ), нормално си работеха, в шела си беше пъргава машинката .. Подобно ми се е получавало като се скапе нещо базата с която се свързва ( на друга машина), но този път базата си беше ок. Памет има предостатъчно свободна load average >300 vmstat: cat /proc/sys/net/ipv4/tcp_syncookies ако ти върне 1 значи проблема е на друго място, а ако пък не върне 1 то добави този ред: echo 1 > /proc/sys/net/ipv4/tcp_syncookies във файла rc.local а ако искаш и да не рестартираш го изпълни като root и порчети малко инфо за syncookies! -- The complicated problems have simple and easy for understanding bad answers. Georgi Genov [EMAIL PROTECTED] A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers). http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
Re: lug-bg: Странен проблем с апаче
В access loga виждам нормална активност, не виждам нищо фрапиращо, в error лога съм казал какво се вижда, а netstat-а показва неща от вида ( също струва ми се нормални ): tcp0 0 k.l.m.n:80 0.0.0.0:* LISTEN 2858/httpd tcp0315 k.l.m.n:80 x.y.z.193:10126 FIN_WAIT1 3023/httpd tcp0 0 k.l.m.n:80 x.y.z.123:1027ESTABLISHED 3000/httpd tcp0 0 k.l.m.n:80 x.y.z.211:16793FIN_WAIT2 2971/httpd tcp0 0 k.l.m.n:80 x.y.z.70:4494 ESTABLISHED 2986/httpd tcp0 0 k.l.m.n:80 x.y.z.89:2940 ESTABLISHED 3009/httpd tcp0348 k.l.m.n:80 x.y.z.142:3888FIN_WAIT1 2979/httpd tcp0 0 k.l.m.n:80 x.y.z.207:1549 ESTABLISHED 2965/httpd tcp0 0 k.l.m.n:80 x.y.z.49:1168 ESTABLISHED 2989/httpd tcp0 0 k.l.m.n:80 x.y.z.120:1421FIN_WAIT2 18772/httpd Няма много връзки от едно и също IP, нито прекалено много в SYN_RECV... -- Христо Чернев - Всичко е по-бързо и сигурно с БТК ADSL! http://www.telecom.bg/adsl/ A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers). http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
Re: lug-bg: Странен проблем с апаче
Hristo Chernev wrote: Понеже нищо повече не ми ражда главата, ще се допитам до вас за проблема, който не ме остави да спя. Двупроцесорна машинка с Xeon-и, много памет - 5ГБ, scsi u160 диск. На нея - 2.4 кернел smp bigmem(redhat9), 1.3.31 апач с 4.3.9 php, qmail , bind 9.2.1.16 (rh). Има и малък firewall с iptables 1.2.7а.2.(rh) Както си работеше безпроблемно 2 месеца така тая нощ се появи 3 пъти проблема, като двата пъти изчезна след около половин час и работи нормално 2 часа, но третия си остана в такова - ни живо, ни умряло състояние: http услугата на апаче не отговаря или много бавно отговаря, apaчe процесите sa na max и са всички във 'W' състояние - Sending Reply, в лога на системата нищо, на екрана нищо,в ерор лога на апача има много от тези и все от различни IP-ta: client stopped connection before rvputs completed client stopped connection before rwrite completed Трафика намалял на 1/3 и като обем и като бр. пакети Другите услуги ( те не товарят кой знае колко по принцип - сигурно <1% ), нормално си работеха, в шела си беше пъргава машинката .. Подобно ми се е получавало като се скапе нещо базата с която се свързва ( на друга машина), но този път базата си беше ок. Памет има предостатъчно свободна load average >300 vmstat: procs memory swap io system cpu r b w swpd free buff cache si sobibo incs us sy id 0 378 0 0 381592 1136 274912800 0 12 0 1 1 2 0 383 0 0 377752 1076 274925200 1905 136 798 2422 5 4 92 0 384 0 0 377072 1084 274979200 2405 111 846 2240 4 2 94 0 373 0 0 377512 1020 274975200 383084 1072 2903 6 2 92 0 365 0 0 381656 1032 274982400 386267 1078 2714 6 2 92 0 369 0 0 380012 1068 274986000 243071 889 2216 6 4 90 1 375 0 0 377256 1064 274937600 1885 114 911 2790 3 3 93 Тази висока стойност на 'b'-то (обикновенно е около 0)... доколкото знам това са процеси чакащи за I/O (диск), но на диска имаше достатъчно място, а и записът беше безпроблемен. След рестарт на апаха, ония отново придоби същия вид,а след ребоот се оправи ...но докога ли и какво да предприема следвашия път ( замирисва на уиндоус ако взема да рестартирам през ден ).. Ще се радвам ако споделите какви идеи ви хрумват! -- Христо Чернев - Влезте в играта на HYUNDAI! Спечелете “Ready to work’ компютър HYUNDAI от играта! Регистрирайте се тук: http://www.hyundai.bg A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers). http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html А netstat -nta | grep 80 какво казва? A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers). http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
Re: lug-bg: Странен проблем с апаче
Hristo Chernev wrote: Понеже нищо повече не ми ражда главата, ще се допитам до вас за проблема, който не ме остави да спя. Двупроцесорна машинка с Xeon-и, много памет - 5ГБ, scsi u160 диск. На нея - 2.4 кернел smp bigmem(redhat9), 1.3.31 апач с 4.3.9 php, qmail , bind 9.2.1.16 (rh). Има и малък firewall с iptables 1.2.7а.2.(rh) Както си работеше безпроблемно 2 месеца така тая нощ се появи 3 пъти проблема, като двата пъти изчезна след около половин час и работи нормално 2 часа, но третия си остана в такова - ни живо, ни умряло състояние: http услугата на апаче не отговаря или много бавно отговаря, apaчe процесите sa na max и са всички във 'W' състояние - Sending Reply, в лога на системата нищо, на екрана нищо,в ерор лога на апача има много от тези и все от различни IP-ta: client stopped connection before rvputs completed client stopped connection before rwrite completed Трафика намалял на 1/3 и като обем и като бр. пакети Другите услуги ( те не товарят кой знае колко по принцип - сигурно <1% ), нормално си работеха, в шела си беше пъргава машинката .. Подобно ми се е получавало като се скапе нещо базата с която се свързва ( на друга машина), но този път базата си беше ок. Памет има предостатъчно свободна load average >300 vmstat: procs memory swap io system cpu r b w swpd free buff cache si sobibo incs us sy id 0 378 0 0 381592 1136 274912800 0 12 0 1 1 2 0 383 0 0 377752 1076 274925200 1905 136 798 2422 5 4 92 0 384 0 0 377072 1084 274979200 2405 111 846 2240 4 2 94 0 373 0 0 377512 1020 274975200 383084 1072 2903 6 2 92 0 365 0 0 381656 1032 274982400 386267 1078 2714 6 2 92 0 369 0 0 380012 1068 274986000 243071 889 2216 6 4 90 1 375 0 0 377256 1064 274937600 1885 114 911 2790 3 3 93 Тази висока стойност на 'b'-то (обикновенно е около 0)... доколкото знам това са процеси чакащи за I/O (диск), но на диска имаше достатъчно място, а и записът беше безпроблемен. След рестарт на апаха, ония отново придоби същия вид,а след ребоот се оправи ...но докога ли и какво да предприема следвашия път ( замирисва на уиндоус ако взема да рестартирам през ден ).. Ще се радвам ако споделите какви идеи ви хрумват! -- Христо Чернев А в access и error лога какво пише? -- 'Can death be sleep, when life is but a dream' --John Keats /* waiting... dreaming... wishing... */ signature.asc Description: OpenPGP digital signature
Re: lug-bg: Странен проблем с iptables
Благодаря за мненията! Всъщност проблема възниква когато препращам пакетите от OUTPUT веригата към LOCAL_NET_IN_OUT: iptables -t filter -A OUTPUT -m mark --mark 1 -j LOCAL_NET_IN_OUT като махна този ред всичко се оправя (между другото в първото писмо съм писал на едното място марка 1, а на другото 15, но имам предвид един и същ номер). В крайна сметка всичко си следва логиката по отношение на OUTPUT веригата. Явно ще трябва да приложа друг вариант :). Поздрави: Илия Линдов A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers). http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
Re: lug-bg: Странен проблем с iptables
При мене командата ти работи, тоест проблема не е в нея. Най вероятно нямаш поддръжка на проверката за мак адреси. Пробвай заредиш: modprobe ipt_mac Или си прекомпилирай ядрото с включен MAC address match support. A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers). http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
Re: lug-bg: Странен проблем с iptables
Здрасти! от packet filtering how-to: - mac За да използвате този модул трябва задължително да укажете -m mac или -match mac . Той се използва за сравняване на Ethernet (или MAC) адреса на изпращача на входящите па кети, и следователно е приложим САМО за пакети преминаващи през ! !! PREROUTING и INPUT веригите. Той предоставя само една опция: --mac-source може да бъде последвана от ! , и ethernet адреса в шестнайстичен вид разделен с : , например macsource 00:60:08:91:CC:B7 . # mac адресите съвпаднат iptables -t filter -A LOCAL_NET_IN_OUT -s 192.168.2.25 -m mac --mac-source 00:01:02:03:04:05 -j ACCEPT Странното е, че аз като пробвах мога да добавиа --m mac в която си поискам верига. Не знам обаче дали по някяква причина iptables не се усеща, че има проблем и въпреки, че правилото е добавено може и да не работи. А като пуснах твоиа скрипт действително се поиави грешката. Явно някое от предишните правила я предизвиква. В същото време в /var/log/mssages плюе Mar 26 19:35:01 debian kernel: ipt_mac: only valid for PRE_ROUTING, LOCAL_IN or FORWARD. Това поведение не мога за сега да си го обясня. Поздрави, Радо A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers). http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
