From: Eje Gustafsson (macahan_at_fament.com)
Date: Mon 10 Mar 2003 - 03:41:47 GMT
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
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
Eje Gustafsson mailto:MacAhan_at_fament.com
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> 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> 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]