Kernel 2.6.8 again / How THNIC serves .TH

First, new software releases: X11 R 6.8.0, gcc 3.4.2, and cdrtool 2.01

It seems that the new kernel (>= 2.6.8) still breaks user applications. The thing is that they tightened security of some of the commands within the kernel. Programs that were able to run by suid may not run properly unless you run it as root. AFAIK, these programs include cdrecords, k3b, and some dvd tools. I had reported the problem and solution for cdrecord some days ago, it was not it. Some people need to patch k3b too. The patch was suggested by Linus himself. MrChoke reported that k3b patched would allow root to write CD/DVD, non-root users still do not get any luck. So, for the next release of TLE, which is expected to use kernel >= 2.6.8, you may need to be root to burn CD/DVD.

Man, there are so many patches released to workaround the problem of kernel >= 2.6.8 and cdrecord (and k3b). Some of them just comment out parts of the code. It works, but the side effect is that it unlocks some limitations and would allow you to overwrite the firmware of your CD/DVD burner – gotta be careful ! This is why, as a package maintainer, I do not accept any patch easily. I want to know how the patch solve the problem. For this particular case, it tooks me days to read those patches, review, decide which ones should apply, and test them before actually build the binary packages.

me: I am using kernel 2.6.8.1-ck4. The kernel allows to burn CDs by just suid, without applying any patches to user programs (i.e., k3b, and cdrecord). The ck4 (and the later 2.6.8.1 ck tree) modifies SCSI command filters inside the kernel. Of course, this modification sacrifices levels of kernel security. I think it is, more or less, as secure as 2.6.7. It should be okay at least for desktop installation.

(เอ่อ .. ช่วงนี้กำลังเขียนธีสิส คิดอะไรเป็นภาษาอังกฤษจนลืมตัว พิมพ์ blog มาครึ่งนึงเป็นภาษาอังกฤษหมด .. เลยตามเลยละกัน .. – -‘)

For kitty.in.th, I’m still on building the backup site. My repository has been transferred to two servers: Belldandy in Ratchaburi, and Skuld at Khonkaen. A name server has been setup at each site. DNS records have been written so that the query to Ratchaburi would get answers of IP of Belldandy, and the query to Khonkaen would get those of Skuld. I expect Belldandy to primarily serve services of kitty.in.th. If she is off for one hour (TTL of the domain), all traffic to kitty.in.th would be redirected to her younger sister, Skuld, at Khonkaen automatically. Cool eh ? :)

Anyway, after set this up, I’ve seen quite a number of users had been redirected to Skuld even Belldandy was still up and fully operational. I think this is about DNS, so I asked Parkpoom, the manager of THNIC, about how the network of name servers of THNIC actually works. He explained that for a single .th domain, you need at least two name servers – logically labeled as primary and secondary name server. The RFC suggested that queries will go to ALL servers in round-robin fashion. However, he said the ISC/BIND software would check RTT to all name servers of the domain, and let the smallest RTT one to answer the query. So, it does not mean that the primary name server will always answer the queries, the secondary servers(s) may answer the queries too. In other words, the concept of primary/secondary name server is NOT for selecting the server to answer a query. (note: the primary/secondary thing is to synchronize DNS records among those servers of the domain).

So, I gotta reconfigure the name servers again. Skuld should be a secondary name server, providing the same DNS records as the primary. And if Belldandy is off, Skuld will be reconfigured to answer different DNS records so that traffic to kitty.in.th will be redirected to Khonkaen.