Hello Sam, Alright. sigh. I hate life with computers sometimes. The first tests turned out that I had 2 named services fighting so that was why I saw slow responds in my first tests and it started working better later (one of the servers had timed out and given up) while the remaining server had failed to bind to 127.0.0.1 because of the other server running. So it was entirely all issues with named that had nothing to do with the ctx patch. So you can safely just ignore that e-mail.
As far as I been able to tell DNS is working great on my test machine Linux 2.4.20-ac2-ctx16 #3 Sun Mar 9 18:42:16 CST 2003 i686 GNU/Linux This using vserver-0.22-1.i386.rpm on a RedHat 8.0 master The vserver is also a RH 8 system using BIND 9.2.1 both caching DNS is functioning as well as static dns server. I configured up a domain on the DNS server local requests work nicely from inside the vserver and remote request for both that domain as well other domains work just fine from my remote workstation. As far as I can tell there are no issues with named. When doing requests from the remote server responds get back from the RIGHT ip (the vservers) and has the right mac address. If I ask for a domain that this dns server do not answer authorative for then it will go out to the root servers and find out who is the dns server for that domain in question. All the time it's utilizing Protocol: UDP (0x11) correct header checksum and always correct source address. Is there something I'm missing or not getting here ? To me it looks like I will be able to start using this patched kernel on my production machine. I will if I get a chance tomorrow try this kernel. I have 2 vservers that are running active dns servers so if there is any issues that I missed so far I will for sure find out tomorrow. Best regards, Eje Gustafsson mailto:[EMAIL PROTECTED] The Family Entertainment Network http://www.fament.com Phone : 620-231-7777 Fax : 620-231-4066 - Your Full Time Professionals - eBay UserID : macahan -- SV> Well, if anyone can help debug the DNS problem with the ctx patch for the SV> -ac kernel; SV> http://vilain.net/linux/ctx/patch-2.4.20-ac2-ctx16.gz SV> Find out exactly what isn't working to stop DNS from working, give me an SV> exact description (eg, UDP packets to 127.0.0.1 don't get through), SV> potentially isolating the problem to whether it affects localhost only, SV> external packets, etc ... SV> There was a small piece where the merge wasn't quite straightforward in the SV> 2.4.21-pre4-ac6 patch that I did, that was in the UDP code. So if someone SV> can verify whether the problem exists in the 2.4.20-ac2-ctx16 patch and SV> nail it down to an exact functional cause (ie, using strace, netstat, SV> tcpdump) ... I'm sure everyone here with the crash problem would be SV> grateful. SV> This kernel uses a completely different scheduler, so is guaranteed not to SV> have the same scheduling bug. SV> I've just been too busy of late to set up a test environment, vserver isn't SV> what i'm making money off any more... SV> Sam. SV> On Mon, 10 Mar 2003 07:53, Eje Gustafsson wrote: >> Ok. Here we go. Crashed again. Got me another 48 hours of run time. >> Just curious is ctx-14 or ctx-13 more stable then 16 and 15 ? >> If I understand it right earlier version then 15 do not have >> functional udp stack ? So doing snmp calls from inside one vserver >> will not work at all if I go with anything prior to 15 ? >> How does this work for named ? It's using UDP ? Are you not able >> to run named in a vserver in < ctx-15 ? >> I'm NOT a kernel programer. Been ages since I did any C/C++ programing >> at all. I not done anything but php/perl/mysql/html coding for the >> last 2 or so years. SV> What are you, a man or a mouse ? :-) --- [This E-mail scanned for viruses by Declude Virus]
