Kernel Traffic
Latest | Archives | People | Topics
Wine
Latest | Archives | People | Topics
GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Debian Traffic #19 For 18 Jan 2001

Editor: Zack Brown

By Prashanth MundkurSteve Robbins  and  Zack Brown

Debian Home Page | Weekly News | Social Contract | Constitution | Policy Manual | Developer's Reference | Documentation Project | debian-devel Archives

Table Of Contents

Introduction

Want to help write KC Debian? See the KC Authorship page the KC Debian homepage, and the Thread Summary FAQ. Send any questions to the KCDevel mailing list.

1. man Surprise

3 Jan 2001 - 9 Jan 2001 (28 posts) Archive Link: "our broken man package"

Summary By Steve Robbins

People: Joey HessEthan BensonBranden Robinson

Joey Hess pointed out several ways in which Debian's man system can surprise you.

  1. Invoking man -l foo.1 will fail if the current directory is not searchable by user man.
  2. Invoking man with PAGER set will fail for root if the PAGER is not accessible as user man.
  3. Invoking man as root can fail if TMP is set to a directory not accessible as user man.

All of these surprises stem from the fact that man is a wrapper that invokes a set-UID program, running as user man. Concludes Joey, " I have never seen an explination of why this wrapper program makes man run as user man. If it just ran it as group man, everything would be ok. As bug #42128 suggests, /var/catman/ could be writable by group man, rather than user man. " Ethan Benson pointed out " the problem with this is you end up with the catman files owned by whatever user reads whatever man page. personally as a sysadmin i don't want users gaining write permission to files in any more places under /var then there already is (ahem texmf). i am not certain if there is potential security threats to users being able to write bogus catman files, perhaps via groff tricks there is. IMO a setgid man with a group writable /var/catman is not any better then a mode 1777 /var/catman. (which is what slackware does btw) OpenBSD took another tack on this problem and just did away with cached man pages altogether. (no suid or sgid man) "

The discussion then moved on to the relative merits of three approaches. The simplest approach is to do no caching of formatted pages at all. Another possibility is to split man into a small, auditable set-UID rendering/caching program and a separate page-lookup/pager that invokes the renderer. A third suggestion is to do the caching in a cron job (caching recently-accessed pages, for example) rather than when a user invokes man. No concensus was reached.

In reply to Joey's initial message, Branden Robinson threatened to forcibly adopt the packages man-db and groff.

Both it and groff are maintained by a person who just doesn't seem to give a damn.

Let this serve as notice that I plan to take over these packages by force in one (1) week if substantially improved versions of these packages are not uploaded in the interim.

I will repackage them from scratch. I looked at groff (as did rcw), and the package appears to have been assembled by a lunatic[1]

[1] That, or it's just doing a bunch of things that were very clever by Debian packaging standards of 1993 but hopelessly archaic now.

2. Bind 9.X package status

4 Jan 2001 - 8 Jan 2001 (12 posts) Archive Link: "BIND 9.X package status"

Summary By Prashanth Mundkur

People: Bdale GarbeeNate Duehr

Bdale Garbee made this announcement:

As the BIND package maintainer, I indicated many months ago my intention to package BIND 9.X for Debian.

Unfortunately, the BIND 9.0.0 and 9.0.1 releases contained sources for required elements that were not compliant with the DFSG, and so would at best have been made available in non-US/non-free. After the firestorm that resulted from my putting the 8.X BIND bits in non-free, I decided to try and get the problem resolved before packaging BIND 9.X.

As a result of discussion with key contacts at the ISC, this issue has been completely resolved for the upcoming BIND 9.1.0 release, currently in beta. I have done quite a bit of work on packages in preparation for this release, and will be ready to upload shortly after 9.1.0 is finally released. Note that unless we change Debian crypto code policy in the meantime, bind9 will show up in non-US since it includes required crypto-based authentication components. The ISC happily makes this available for export from the US, so I'm sure we could too... but until the DPL and FTP admins indicate it is ok to do so, I will direct the packages to non-US.

Getting this right has two major components that are worth my commenting on here. First, the package 'bind' will continue to be 8.X to avoid violating the principle of least astonishment for our users, and there will be a new 'bind9' package and friends delivering 9.X. For new installs, the dns server task package will install bind9 packages. Second, the 'dnsutils' package which is priority standard and delivers various DNS related client progrems is being restructured both so that I can deliver pristine upstream BIND 9.X sources into the archive, and so that future updates to the independent components are easier.

Bdale went on to describe the structure of his new packages.

Nate Duehr helpfully summarized some additional information and his experiences with BIND:

At this point in their development cycles I wouldn't call BIND 9 an upgrade for BIND 8. In fact if you read the history file at isc.org, BIND 9 is a complete re-write. Hardly an 8 to 9 upgrade.

I think Bdale's plan is a good one, but there may be some breakage if ISC doesn't release a BIND 9 that fully supports the BIND 8 style zone files. Up until the latest Beta release of BIND 9, it didn't even understand $GENERATE statements!

Those who can live without the features they left behind in BIND 8 and didn't implement, and especially those who want the new features in BIND 9 are encouraged to switch.

BIND 8 and BIND 9 are still not quite the same nameserver yet, however.

BIND 9.1.0 fixes the most grevious problem with migration for many people which was that BIND 9.0.1 did not understand $GENERATE statements in zone files at all.

In BIND 9.1.0's doc/misc/migration file:

"BIND 9 is designed to be mostly upwards compatible with BIND 8, but there is still a number of caveats you should be aware of when upgrading an existing BIND 8 installation to use BIND 9."

You can see the docs in the source for the specifics, but it's not ready to use as a drop-in replacement yet. It does have a huge number of NEW features, but some old features are lagging behind.

Plopping BIND 9 binaries in over BIND 8 zone files was almost guaranteed to break something in all but the most "plain vanilla" configurations until the (still Beta) release of BIND 9.1.0.

Currently there are four major BIND's in the wild that folks might be using if they're keeping up-to-date:

BIND 8.2.2-P7 (what's in Debian) -- OFFICIAL RELEASE ON BIND 8 PLATFORM

BIND 8.2.3-T9B - has a few new features on old codebase and mostly NT build bugfixes, but some general bugfixes too.

BIND 9.0.1 (bugfixes) -- OFFICIAL RELEASE BIND 9 PLATFORM

BIND 9.1.0b2 - second Beta of BIND 9 platform (first to have $GENERATE)

There are a LOT of changes, and I'm still playing around with BIND 9 on a non-production server to see what all is different, but it's definitely not going to be a smooth upgrade path right now unless BIND 9.2 finishes up most/all of the leftover stuff that's not implemented.

ISC has not been very public about their plans for full backward compatibility (although they appear to be striving towards it) nor have I seen a release plan for when they will have that done -- and stop support for BIND 8. But right now they're running both versions (and releases) in parallel.

I should clarify that by "public" I mean their web pages. There have been some comments made by developers in the bind-isc mailing list, but their web pages are falling behind again. (They don't have history notes past BIND 8.2.2-P5 in the "Highlights of BIND 8.x" section yet.

In addition many commercial products and other free software (some packaged for Debian, some not yet) expect all the BIND 8 zone file features to be working. Especially software that generates zone files automatically from databases. (Many of which actually leverage the special statements available from the BIND 8 zone parsing engine and cheat heavily.)

3. tar option mini-saga

5 Jan 2001 - 10 Jan 2001 (49 posts) Archive Link: "tar -I incompatibility"

Summary By Prashanth Mundkur

People: Goswin BrederlowScott EllisBdale Garbee

Goswin Brederlow sparked a long discussion when he noted that

the Author of tar changed the --bzip option again. This time its even worse than the last time, since -I is still a valid option but with a totally different meaning.

This totally changes the behaviour of tar and I would consider that a critical bug, since backup software does break horribly with the new semantic.

Any good reason not to whack the author with a 50 pound unix manual and revert the changes?

Scott Ellis objected: "Of course the -I option to tar was completely non-standard. The changelog explains why it changed, to be consistant with Solaris tar. I'd prefer portability and consistancy any day, it shouldn't take that long to change any custom scripts you have. I always use long options for nonstandard commands when building scripts anyway :)"

From subsequent discussion, it appears that the current GNU tar in Debian is from the unstable tar tree, since the last stable tar is buggy and unmaintained.

In a later thread, a happy conclusion was reached between Paul Eggert, the tar maintainer, and Bdale, the Debian maintainer:

4. Upcoming Events In Germany

5 Jan 2001 - 7 Jan 2001 (5 posts) Archive Link: "Upcoming Events in Germany"

Summary By Zack Brown

People: Martin Schulze

Martin Schulze announced:

I have received a whole bunch of notifications for conferences and exhibitions in Germany next year. I would love Debian to be present at each of them, with both, a booth and a talk. This should not be too difficult since there are about 70 Developers in Germany with half as much new applicants.

If you are interested in running a Debian booth or giving a talk at one or more conferences, please coordinate with events@debian.org so we can add that information to the events pages at http://www.debian.org/events/

Please find the Call for Papers at one of the links given for each event.

March 10-11 3. Chemnitzer Linux-Tag
http://www.tu-chemnitz.de/linux/tag/
http://www.infodrom.ffis.de/Debian/events/CLT3/
May 4-6 3. Braunschweiger Linux-Tage
http://braunschweiger.linuxtage.de/
http://www.infodrom.ffis.de/Debian/events/BLT3/
May 18-19 Magdeburger Linuxtage
http://www.mdlug.de/index.php3/linuxtag2001/
May 19-20 Berliner Linux Infotage
http://www.belug.org/infotage/
July 5-8 LinuxTag 2001, Stuttgart
http://www.linuxtag.org/
http://www.infodrom.ffis.de/Debian/events/LinuxTag2001/

As far as I know, there are NO entrance fees for any of these events. So if you don't want to run a booth or give a talk but are interested

in some other talks or the exhibition, you are invited to come around and attend.

There are three more events where we would require some people running a booth. It's the commercial Linux Expo Roadshow organized by Sky Events. Please check out http://www.linuxexporoadshow.com/ and http://www.debian.org/events/2001/0426-linuxexpo-moscow for details.

For these events in eastern Europe there is no Debian booth yet but there could be if people want to organize it. So if you are interested, please get in touch with me.

April 23 Praha
April 24 Budapest
April 25 Warsaw
April 26-28 Moscow (Peter Novodvorsky could use some help)

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.