Re: chroot bind?

[Nicholas Lee]

Sorry missed your response, just picked it up now from the web archive.

> Are you working with bind 8.X or 9.X?

Jaldhar H. Vyas mentioned he has something working with 8.2.3.  I was
only thinking myself with bind8.

As Jaldhar also mentioned, bind9 isn't something I trust yet. Even in a
chroot.


Personally I see no need to replace the bind package.  In fact with the
use of alternatives on /etc/init.d/bind it should be pretty easy to mix
them in together.

Here are some issues though:

i) /chrootlocation/dev/log and syslod.  No generic simply way to
automatically add this log socket to syslog set it listens too.

ii) named-xfer is the only binary required in /chrootlocation/, how to
deal with the base bind package upgrading and this binary changing?

iii) I've sent a message to the FHS mailing.  I guess we'll see what
comes up. 8)  Whatever the case I specific its not easy to find a
generic mechanism to deal with chroots, particular since they are often
applications specific. 


Nicholas

Re: chroot bind?

[Nicholas Lee]

On Sun, Apr 22, 2001 at 07:27:56PM -0800, Ethan Benson wrote:


> put into a chroot is named and named-xfer, apparently named is not
> actually necessary.  

Which was my point.  Glad we got that settle. ;)


> /etc/init.d/sysklogd is a conffile, sysklogd cannot change it without
> the admin's permission.  as for how this package changes it i don't
> know, there is no policy compliant way to do it other then a message
> to the admin saying if they want bind to log they have to fix the
> initscript themselves.  

Hmm. Which means there is never going to be any default easy way of
installing bind-chroot and just having it work.


Nicholas

Re: Suggestion to change how bugs get closed

[Anthony Towns]

On Mon, Apr 23, 2001 at 03:11:41AM +0200, Adrian Bunk wrote:
> When a package was only uploaded to stable the bugs aren't closed but
> tagged "woody" instead. When the package goes into testing the bugs get
> closed.

You're cordially invited to work on enhancing the BTS to make this sort of
thing actually workable. Note that what you propose, at least in the context
of the current BTS, takes us back to a much much worse situation than before
we were able to close bugs in the changelog.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)


pgp4O9NWWXuSn.pgp
Description: PGP signature

Re: chroot bind?

[Ethan Benson]

[ i do read the list so i don't need a CC ]

On Mon, Apr 23, 2001 at 03:12:59PM +1200, Nicholas Lee wrote:
> On Sun, Apr 22, 2001 at 04:54:42PM -0800, Ethan Benson wrote:
> > 
> > fine, no disagreement here, what im pointing out is that with at least
> > bind 8 (someone mentioned bind 9 works differently) its not open to
> > debate, you either have bind binaries in the chroot jail or bind
> > doesn't work.  
> 
> No, only named-xfer.  

thats my point, named-xfer IS a bind binary, and it must live in the
chroot jail or bind8 breaks.  

> With ndc you just go say: /usr/sbin/ncd -c /var/named/var/run/ndc 

i have never said ncd needed to be there.  the only binaries i ever
put into a chroot is named and named-xfer, apparently named is not
actually necessary.  

> > so long as your chroot jail isn't setup wrong (ie chown -R
> > named.named) i don't really see any risk here.  
> 
> Maybe, but if there is no need for binaries to be in the chroot, why put
> them there.

if you have to you have to (named-xfer).  

> True, but its not the default and the local syslog might not even be
> listening.

yes it is the default.  bind logs to /dev/log.  the fact that you
chroot and the /dev/log its logging to is now /var/named/dev/log is
not relevant to bind.  

> > SYSLOGD="-a /var/named/dev/log"
> 
> Yeah, but is secure-bind (or bind-chroot) allowed to reach and change
> this variable?  Plus can it be sure that sysklogd doesn't reach out and
> change it?

/etc/init.d/sysklogd is a conffile, sysklogd cannot change it without
the admin's permission.  as for how this package changes it i don't
know, there is no policy compliant way to do it other then a message
to the admin saying if they want bind to log they have to fix the
initscript themselves.  

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgpAU68R56mdE.pgp
Description: PGP signature

Re: chroot bind?

[Nicholas Lee]

On Sun, Apr 22, 2001 at 09:36:23PM -0400, Jaldhar H. Vyas wrote:
> 
> Ethan mentioned the method but it cannot be automated which is why I left
> it up to the admin.

Maybe there should be a discussion as to the possibility of a mechanism
to handle this.


Nicholas

Re: chroot bind?

[Nicholas Lee]

On Sun, Apr 22, 2001 at 09:25:14PM -0400, Jaldhar H. Vyas wrote:
> Because I was following the instructions at
> http://www.psionic.com/papers/dns/linux-dns which suggests named and
> named-xfer should go there.  I decided to throw the rest in there too. :-)

This is wrong.

> 
> But if we don't need them there we should definitely take them out.

Both bind4 (default) and bind8 (from ports) in Openbsd have only
named-xfer in /var/named/.


> Because it is a non-standard /var directory, I thought it would be helpful
> to name it after the package it belonged to.

True, but as Ethan says "is not really secure, only better."   Its not a
biggie though.

Nicholas

Re: chroot bind?

[Nicholas Lee]

On Sun, Apr 22, 2001 at 09:43:52PM -0400, Jaldhar H. Vyas wrote:
> 
> So change it to more-secure-bind then :-)  Or /var/named, whatever is
> thought best.


I guess we'' see what the FHS says.   Tho I have no experience with how
quick these guys are.


> Btw, Bdale (Debian Bind maintainer) suggested that if we can get this
> working properly so it can build as an optional package from the standard
> bind source package, he would include it.  He also suggested we use bind 9
> as a base not 8.


Interesting.  I'll have a look into that.   With regards to bind 9, not
sure I trust it yet, even less than bind8 in a chroot.   I assume the
mechanism to chroot is the same in bind9 as in bind8 so it should be
pretty much the same.


Nicholas

Re: chroot bind?

[Nicholas Lee]

On Sun, Apr 22, 2001 at 04:54:42PM -0800, Ethan Benson wrote:
> 
> fine, no disagreement here, what im pointing out is that with at least
> bind 8 (someone mentioned bind 9 works differently) its not open to
> debate, you either have bind binaries in the chroot jail or bind
> doesn't work.  

No, only named-xfer.  

With ndc you just go say: /usr/sbin/ncd -c /var/named/var/run/ndc 


> so long as your chroot jail isn't setup wrong (ie chown -R
> named.named) i don't really see any risk here.  

Maybe, but if there is no need for binaries to be in the chroot, why put
them there.


> read the README.Debian that goes with bind, its not going to happen,
> its also never going to run non-root by default.  i happen to disagree
> with that stance but the maintainer has spoken.  

Hmm, I agree with you. The only point I could make is that in a
caching/forwarder situation with dynamical interfaces doesn't sound much
like a server.  Given that 127.0.0.1 seems like the only useful and
secure interface for a machine in that situation.  

> only way to do that is editing the sysklogd initscript to add the -a
> /var/named/dev/log switch.  editing this script opens a whole new can
> of policy worms unfortunatly.  


Yeah thats why I asked if there was a generic mechanism.  One package is
not allow to touch another packages files.  


> 
> it already does.  

True, but its not the default and the local syslog might not even be
listening.


> 
> sort of:
> 
> # Options for start/restart the daemons
> #   For remote UDP logging use SYSLOGD="-r"
> #
> SYSLOGD=""
> 
> change that to:
> 
> SYSLOGD="-a /var/named/dev/log"


Yeah, but is secure-bind (or bind-chroot) allowed to reach and change
this variable?  Plus can it be sure that sysklogd doesn't reach out and
change it?


> as a sidenote i think this /var/secure-bind name is lame, it doesn't
> follow any conventions and frankly its naive to think that just
> because bind is chrooted and running as root that its now fully
> secure.  more secure yes, a panacea no.  

I'd have to agree here.

Nicholas

new imlib packages uploaded

[Ossama Othman]

Hi,

I just uploaded a new set of imlib packages linked against xlibs
4.0.2-13.  Again, sorry about the mix-up.

-Ossama
-- 
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068  70E6 5EB7 5E71 F7A3 94A8

busted imlib packages

[Ossama Othman]

Hi,

As many have pointed out, the imlib packages I uploaded are depended
on pre-release debs of X.  My apologies.  My sources.list still had
Branden's apt site listed in it.  I'll upload a new set of imlib
packages right now.

-Ossama
-- 
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068  70E6 5EB7 5E71 F7A3 94A8

Re: Dual CPU compilation.

[Craig Sanders]

On Sun, Apr 22, 2001 at 10:15:28PM -0400, Simon Law wrote:
> I'm the lucky new owner of a dual Pentium Pro system.  It seems,
> however, that compiling stuff just doesn't use my extra CPU.  I know I
> can compile with 'make -j 2' to use the second processor; but I don't
> know how to convince kernel-package and dpkg-deb (apt-get source) to
> do that for me.  Any tips?

this question belongs on debian-user, not debian-devel.

type:

export MAKE='make -j3' 

before running make-kpkg.

note that the kernel is known to have problems compiling reliably when
you use make -j. this won't be fixed until Keith Owens and others have
got their fixed kernel build system into the kernel tree - that won't
happen until 2.5.x i believe.

i've successfully compiled several kernels using -j3, but it's not
something i'd want to rely on at the moment.

craig

--
craig sanders <[EMAIL PROTECTED]>

  GnuPG Key: 1024D/CD5626F0 
Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57  52C3 EC32 6810 CD56 26F0

Dual CPU compilation.

[Simon Law]

Hello,

I'm the lucky new owner of a dual Pentium Pro system.  It seems,
however, that compiling stuff just doesn't use my extra CPU.  I know I
can compile with 'make -j 2' to use the second processor; but I don't
know how to convince kernel-package and dpkg-deb (apt-get source) to
do that for me.  Any tips?

Thanks,
Simon

Re: Suggestion to change how bugs get closed

[Ben Collins]

On Mon, Apr 23, 2001 at 03:11:41AM +0200, Adrian Bunk wrote:
> Hi,
> 
> I think we have a new problem with the closing of bugs since there is
> testing: Currently, bugs get closed when a package goes into unstable.
> When we'll freeze testing we'll have to check whether the packages that
> closed the bugs made it into testing or not. This isn't very good. As a
> solution I suggest the following:
> 
> When a package was only uploaded to stable the bugs aren't closed but
> tagged "woody" instead. When the package goes into testing the bugs get
> closed.

Your case is wrong. What if the bug didn't exist in woody, and only in
stable?

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: chroot bind?

[Jaldhar H. Vyas]

On Sun, 22 Apr 2001, Ethan Benson wrote:

> as a sidenote i think this /var/secure-bind name is lame, it doesn't
> follow any conventions and frankly its naive to think that just
> because bind is chrooted and running as root that its now fully
> secure.  more secure yes, a panacea no.
>

So change it to more-secure-bind then :-)  Or /var/named, whatever is
thought best.

Btw, Bdale (Debian Bind maintainer) suggested that if we can get this
working properly so it can build as an optional package from the standard
bind source package, he would include it.  He also suggested we use bind 9
as a base not 8.


-- 
Jaldhar H. Vyas <[EMAIL PROTECTED]>

Re: chroot bind?

[Jaldhar H. Vyas]

On Mon, 23 Apr 2001, Nicholas Lee wrote:

>
> Which brings up an interesting point.  Doesn't seem to be provision in
> secure-bind for syslog.
>
>
> In fact a quick test of the binary deb should its not loggin properly.
> I guess there might be two ways to fixing this:
>
> i)  get secure-bind to log to syslog via a network socket.
>
> ii) install /dev/log in /var/secure-bind/dev/log and get syslogd to add
> the following flag: '-a /var/secure-bind/dev/log'.
>
>

I thought I put a note about this in README.Debian?  I guess not.  Anyway,
secure-bind will log to syslog if you follow the steps you mentioned
above.


> Which leds to a futher question, is there a generic mechanism in
> debian's default syslog (sysklogd) to tell it to listen on other
> log devices?
>

Ethan mentioned the method but it cannot be automated which is why I left
it up to the admin.

-- 
Jaldhar H. Vyas <[EMAIL PROTECTED]>

Re: kernel-{image,headers} package bloat

[esoR ocsirF]

On Sun, Apr 22, 2001 at 09:59:42PM +1000, Craig Sanders wrote:
> >
> > I compile my own kernels, and have for a long time. But it's a pain to
> 
> in that case, a far better solution is a package containing a bunch
> of pre-generated kernel .config files, plus a menu script to copy
> 
> call it kernel-helper and make it depend on kernel-package.
> 
> problem solved.

OK, this all seems very fun and all but wouldn't making the kernel
recompile an automatic process solve the whole kit'n'kabootle?

I haven't tried this but 
http://sourceforge.net/projects/kautoconfigure/

looks seriously promising, especially as I read somewhere that it may be
included into 2.5.x and future kernels

If this has been considered and discarded for reasons I don't know about
please disregard this message ;)
-- 
Frisco Rose "By any other name, I would smell the same"
EOU Student Physics Instructor  and Nice guy

Physics Mathematics Computer Science

foo = [, quark., strange., charm., quasar., galaxy., \
physics., cs[0-17]., scijou.]
[EMAIL PROTECTED]   where 0 <= n < 10
[EMAIL PROTECTED]   [EMAIL PROTECTED]   ...

Re: chroot bind?

[Jaldhar H. Vyas]

On Sun, 22 Apr 2001 [EMAIL PROTECTED] wrote:

>
>
> Just two questions:
>
> i) Is there any reason why you decided to include the named binaries in
> the chroot?
>

Because I was following the instructions at
http://www.psionic.com/papers/dns/linux-dns which suggests named and
named-xfer should go there.  I decided to throw the rest in there too. :-)

But if we don't need them there we should definitely take them out.

>
>
> ii)  Is there a particular reason to use /var/secure-bind rather than
> say /var/named which seems to be some what of an informal default.
>


Because it is a non-standard /var directory, I thought it would be helpful
to name it after the package it belonged to.


-- 
Jaldhar H. Vyas <[EMAIL PROTECTED]>

Re: chroot bind?

[Jaldhar H. Vyas]

On Sat, 21 Apr 2001, Ethan Benson wrote:

> seriously though, it makes alot more sense for your chroot package to
> build a chroot jail, maybe do something about the config files, and
> then just divert the /etc/init.d/bind script elsewhere and replace it
> with one that installs the bind binaries into the chroot and then
> starts bind from there.  this way you need not include any bind
> binaries in your package so your package won't need to be updated
> every time bind gets a security update.  instead the mainline bind
> package would be updated by the security team, it would upgrade
> /usr/sbin/named* and run /etc/init.d/bind restart in its postinst,
> when that happens your initscript would copy the new updated binaries
> into the chroot and restart them.
>

I see.

> if your package is a complete fork of the mainline package the
> security team now has two bind packages to fix instead of one.  given
> how busy they tend to be i think its prudent to avoid creating more
> work for them unecessarily.
>

Good point.

> also your initscript should update certain things in the chroot at
> every start anyway, things like /etc/localtime so the logs have
> correct timestamps and the admin doesn't have to remember to update
> two /etc/localtimes if the default timezone should need to be
> changed.  libc is another that needs to be updated in the chroot jail.
>
>

Aargh!  I've just realized that with /etc/localtime only being copied at
debianization time, all users of my package effectively have America/New
York as their timezone.  So some kind of script will be necessary in any
case so we might as well go all the way.

As for libc, I compiled the libraries statically.  The idea was that
eventually they would be compiled with stackguard or something for a
little extra protection against buffer overflows (this doesn't give 100%
protection I know.) but I never got around to implementing that.


-- 
Jaldhar H. Vyas <[EMAIL PROTECTED]>

Suggestion to change how bugs get closed

[Adrian Bunk]

Hi,

I think we have a new problem with the closing of bugs since there is
testing: Currently, bugs get closed when a package goes into unstable.
When we'll freeze testing we'll have to check whether the packages that
closed the bugs made it into testing or not. This isn't very good. As a
solution I suggest the following:

When a package was only uploaded to stable the bugs aren't closed but
tagged "woody" instead. When the package goes into testing the bugs get
closed.

cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Re: chroot bind?

[Ethan Benson]

On Mon, Apr 23, 2001 at 11:07:03AM +1200, Nicholas Lee wrote:
> 
> Note: I'm not subscribed to -devel at the moment, and probably not for a
> while since its unlikely I have time to read the volume.  Please CC:

then please add:

lists debian-devel@lists.debian.org 

to your ~/.muttrc so your Mail-Followup-To header will be properly setup.

>  Ethan Benson <[EMAIL PROTECTED]>  mentioned:
> > the way i do it is the initscript replaces the binaries in the chroot
> > jail before starting them, this way the mainline bind package can
> > get upgraded to fix a security hole and the chroot is upgraded
> > automatically.  the binaries in the chroot jail are only writable by
> > root, and of course named does not run as root.  (chrooted named
> > running as root is completely pointless).  
> 
> 
> See I disagree here,  I think whatever the case less binaries should
> be in a chroot rather than more.

fine, no disagreement here, what im pointing out is that with at least
bind 8 (someone mentioned bind 9 works differently) its not open to
debate, you either have bind binaries in the chroot jail or bind
doesn't work.  

the initscript should still copy /etc/localtime over but that isn't an
executable binary so its beside the point.  

> Why depend on a known potential problem (chrooting binary in its own
> chroot enviroment) when you can just have it outside.  Of course this
> risk is quite small I'd say, but better safe than sorry.

so long as your chroot jail isn't setup wrong (ie chown -R
named.named) i don't really see any risk here.  

> In fact named-xfer only gets updated when bind gets updated, so there is
> only a need to copy it across when that happens.  Of course just a
> matter of figuring out how to do that. 

well if its that big a deal compare md5sums, if they differ update it,
if not leave it.  since the binary is small its really not a big deal
to replace it every time.  

> Might be nice to have it as the default for bind. ;)

read the README.Debian that goes with bind, its not going to happen,
its also never going to run non-root by default.  i happen to disagree
with that stance but the maintainer has spoken.  


> Which brings up an interesting point.  Doesn't seem to be provision in
> secure-bind for syslog.  

only way to do that is editing the sysklogd initscript to add the -a
/var/named/dev/log switch.  editing this script opens a whole new can
of policy worms unfortunatly.  

> In fact a quick test of the binary deb should its not loggin properly.
> I guess there might be two ways to fixing this:
> 
> i)  get secure-bind to log to syslog via a network socket.

it already does.  

> ii) install /dev/log in /var/secure-bind/dev/log and get syslogd to add
> the following flag: '-a /var/secure-bind/dev/log'.

yup, thats what you have to do, though i remember reading there are
other ways to do it, i think the extra /dev/log socket is simplest.  

> Which leds to a futher question, is there a generic mechanism in
> debian's default syslog (sysklogd) to tell it to listen on other 
> log devices?  

sort of:

# Options for start/restart the daemons
#   For remote UDP logging use SYSLOGD="-r"
#
SYSLOGD=""

change that to:

SYSLOGD="-a /var/named/dev/log"

as a sidenote i think this /var/secure-bind name is lame, it doesn't
follow any conventions and frankly its naive to think that just
because bind is chrooted and running as root that its now fully
secure.  more secure yes, a panacea no.  

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgpefueiK5Fdc.pgp
Description: PGP signature

Re: kernel-{image,headers} package bloat

[Adam Heath]

The old way, we had one kernel, optimized for the lowest denonimation of ia32
machine.  Ie, i386.  We then modified the drivers that were compiled into the
kernel.

Now, using an initrd, we no longer need to compile different variations of
drivers and modules into and out of the kernel.  We can compile almost
everything as a module, and use the initrd to insert the required drivers at
boot time.

Everyone agrees that using an initrd, allows us to reduce the number of kernel
images, and thereby, reduce the load on mirrors, cds, and boot floppy workers.
However, by increasing the number of kernel images(which specific cpu
optimization does), will not help them in any regard.

This supposed initrd, that contains the modules to be inserted, has to have
modules that match the kernel being booted.  This means they have to be
optimized for the same type of cpu.  To continue further, this means we can't
use a generic initrd, but one that is either created dynamically, at
installation time, built from the generic base initrd, and the specific set of
matching modules, or, use a prebuilt one, that matches the particular kernel
that has been choosen.

Now, it doesn't take a genius, to see how this will cascade.  For each
optimization of a kernel, there will be a full kernel-image.deb.  Then, for
the boot disks, there will be the individual kernel, and the modules to match
it(this is a doubling of space).  So, for all the numbers given in this
thread(whatever their value), you have to double them.

Now, my gut instinct says that, as of this moment in time, no one has
addressed the building of this initrd, to use at boot time, AFTER
installation.  Yes, we may have an installation initrd, but, in almost all
circles, that is going to be different that what is used after the system is
installed.  Has this boot time initrd been constructed?  Do we know how we are
going to do that?

The best way to handle all this, is to train users how to compile a kernel,
or, let them pick the optimization they want, and we compile the kernel for
them.  We could even use a double boot technique, to make sure it works.  The
new kernel is installed, added to lilo, but not made the default.  System
reboots, and the user picks the new kernel.  IF the kernel works, we switch
the default.

Re: kernel-{image,headers} package bloat

[zhaoway]

> this actually *helps* new users.

Why?

I can see your suggestion help mirrors (The trade-off is
questionable.) But I can't see why it could help users.

I certainly don't think that make users (even make the task easier) to
compile a kernel can do help to most of the users (That is *not* a
task they should be bothered at all.) And I certainly disagree that
they who don't want compile a kernel don't belong to our user base.

-- 
http://dim.sourceforge.net ... Debian Chinese Input Method
http://njlug.sourceforge.net  NanJing GNU/Linux User Group
http://cdlinux.sourceforge.net ... Debian running on Live! CDs
http://people.debian.org/~zw .. XEmacs Screenshots

Re: chroot bind?

[Nicholas Lee]

Note: I'm not subscribed to -devel at the moment, and probably not for a
while since its unlikely I have time to read the volume.  Please CC:

 Ethan Benson <[EMAIL PROTECTED]>  mentioned:


> you have to have at least named-xfer.  

Of course, but.

> yes there is. 

Only named-xfer.


> the way i do it is the initscript replaces the binaries in the chroot
> jail before starting them, this way the mainline bind package can
> get upgraded to fix a security hole and the chroot is upgraded
> automatically.  the binaries in the chroot jail are only writable by
> root, and of course named does not run as root.  (chrooted named
> running as root is completely pointless).  


See I disagree here,  I think whatever the case less binaries should
be in a chroot rather than more.


Why depend on a known potential problem (chrooting binary in its own
chroot enviroment) when you can just have it outside.  Of course this
risk is quite small I'd say, but better safe than sorry.

In fact named-xfer only gets updated when bind gets updated, so there is
only a need to copy it across when that happens.  Of course just a
matter of figuring out how to do that. 



> it certainly would be useful to have some standard setup for this kind
> of thing.


Might be nice to have it as the default for bind. ;)


Yotam Rubin <[EMAIL PROTECTED]> wrote:

> I disagree. A lot of the vulnerability scanners out there determine whether
> a host is susceptible to a certain bug by looking at its version.bind record


I agree here, but this might be a better way of de-versioning bind.

// Don't reveal BIND version
version "";


As for debug, this should be sufficent for any local admin. (From
/var/log/daemon)

Apr 23 10:30:42 woodcut named[18186]: starting (/etc/bind/named.conf).  named 
8.2.3-REL-NOESW Sat Jan 27 01:46:37 MST 2001 [EMAIL 
PROTECTED]:/home/bdale/debian/bind-8.2.3/src/bin/named



Which brings up an interesting point.  Doesn't seem to be provision in
secure-bind for syslog.  


In fact a quick test of the binary deb should its not loggin properly.
I guess there might be two ways to fixing this:

i)  get secure-bind to log to syslog via a network socket.

ii) install /dev/log in /var/secure-bind/dev/log and get syslogd to add
the following flag: '-a /var/secure-bind/dev/log'.


Which leds to a futher question, is there a generic mechanism in
debian's default syslog (sysklogd) to tell it to listen on other 
log devices?  



Nicholas

Re: kernel-{image,headers} package bloat

[zhaoway]

> I agree that it is not too hard to compile your own kernel.
> I never use Debian's standard kernel-image packages (except on
> my 68K Mac, where it takes too long to recompile).

Hey, hey, it's for you! Do you guys really expect all Debian users ==
Debian develoepers? What about k12 users? What about, say Donald
E. Knuth? Do you really think that trivial cubersome kernel compiling
ability is necessary for all to enjoy? They may just have no time,
they may have no interests! Please don't even try to educate(??) them
on this, OK?

That said. If you guys are really into Craig's kernel-helper idea, go
ahead with it. It yes could help you and me. But it still would make
nonsense to many and they may still be in favor of pre-compiled,
optimized (maybe trivially or whatever I left this to Herbert to
decide) binary kernel.

If you argue this for bloat, now look on XEmacs, just for
example. There could be a single xemacs-mule-canna-wnn instead of
xemacs-nomule, xemacs-mule, and xemacs-mule-canna-wnn. Right? Wrong! 
Becasue if we could do all users a favour, then why not? Isn't this
the whole point of Debian?

(But I agree the number of kernel packages for now is tunable, which
Herbert seems be doing.)

-- 
http://dim.sourceforge.net ... Debian Chinese Input Method
http://njlug.sourceforge.net  NanJing GNU/Linux User Group
http://cdlinux.sourceforge.net ... Debian running on Live! CDs
http://people.debian.org/~zw .. XEmacs Screenshots

Re: kernel-{image,headers} package bloat

[Craig Sanders]

On Sun, Apr 22, 2001 at 03:36:02PM -0700, Aaron Lehmann wrote:
> On Mon, Apr 23, 2001 at 08:33:43AM +1000, Craig Sanders wrote:
> > is there such a thing as cross-compilation for the kernel?
> 
> Yes - porting to new architectures would be nearly impossible
> otherwise.

yep, true...but is it deep kernel hacker wizardry or is it accessible to
mere mortals :)


> kernel-package even supports cross-compilation IIRC.

cool, i didn't know thatdon't actually have any need for it. i was
just curious.

craig

--
craig sanders <[EMAIL PROTECTED]>

  GnuPG Key: 1024D/CD5626F0 
Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57  52C3 EC32 6810 CD56 26F0

Re: kernel-{image,headers} package bloat

[Aaron Lehmann]

On Mon, Apr 23, 2001 at 08:33:43AM +1000, Craig Sanders wrote:
> is there such a thing as cross-compilation for the kernel?

Yes - porting to new architectures would be nearly impossible
otherwise.

kernel-package even supports cross-compilation IIRC.

Re: kernel-{image,headers} package bloat

[Craig Sanders]

On Mon, Apr 23, 2001 at 08:00:50AM +1000, Hamish Moffatt wrote:
> I do that too; what's the oldconfig step needed for though? I just
> jump straight to menuconfig and it always seems OK.

i find it easier to deal with new config questions. it uses your old
answers as input for any questions, and only prompts you to input
answers to new questions.

> I agree that it is not too hard to compile your own kernel.  I never
> use Debian's standard kernel-image packages (except on my 68K Mac,
> where it takes too long to recompile).

is there such a thing as cross-compilation for the kernel?

craig

--
craig sanders <[EMAIL PROTECTED]>

  GnuPG Key: 1024D/CD5626F0 
Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57  52C3 EC32 6810 CD56 26F0

Re: kernel-{image,headers} package bloat

[Craig Sanders]

On Sun, Apr 22, 2001 at 10:23:04PM +1000, Herbert Xu wrote:
> > in that case, a far better solution is a package containing a bunch
> > of pre-generated kernel .config files, plus a menu script to copy
> > [...]
> > that would be one package, taking maybe a few hundred kilobytes total.
> > call it kernel-helper and make it depend on kernel-package.
> 
> But why not take this one step further, let's just distribute what's
> in build-essential and let the users compile the rest.  Let's
> rewind the clock back to times when men were men, and they compiled
> everything on their own box :)

how is that "taking it one step further"?

what i suggested was providing tools and documentation to assist users
in building their own custom kernels, rather than providing a bloated
number of still-generic kernels.

this actually *helps* new users. what you want to do doesn't help at
all, in fact it causes harm.


craig

--
craig sanders <[EMAIL PROTECTED]>

  GnuPG Key: 1024D/CD5626F0 
Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57  52C3 EC32 6810 CD56 26F0

Re: kernel-{image,headers} package bloat

[Craig Sanders]

On Sun, Apr 22, 2001 at 10:16:36PM +1000, Herbert Xu wrote:
> We clearly disagree, so let's leave it at that.

no.

> > just as you stated you'd be filing bug-reports to get 2.2.17 kernel
> > image removed from the archive, i'll be filing "package should not
> > exist" bugs against all the excess kernel-image bugs.
>
> Go ahead, I'll close them as soon as they're filed.

and i'll open them again or file new ones.

what you are doing is broken.



> And what does this have to do with our discussion?

it's about as relevant as the rest of your digression on initrd and
modules.

craig

--
craig sanders <[EMAIL PROTECTED]>

  GnuPG Key: 1024D/CD5626F0 
Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57  52C3 EC32 6810 CD56 26F0

Re: kernel-{image,headers} package bloat

[Ethan Benson]

On Sun, Apr 22, 2001 at 01:00:02PM +, Andreas Metzler wrote:
> What *is* the difference between eg. kernel-headers-2.4.3-686 and
> kernel-headers-2.4.3-k6?

not much:

[EMAIL PROTECTED] eb]$ diff -rq /usr/local/src/linux-2.2.19/include 
/usr/src/kernel-headers-2.2.19/include
Only in /usr/src/kernel-headers-2.2.19/include: asm # symlink to asm-$arch
Only in /usr/src/kernel-headers-2.2.19/include: config # directory: 2.2MB
Only in /usr/src/kernel-headers-2.2.19/include/linux: autoconf.h
Only in /usr/src/kernel-headers-2.2.19/include/linux: compile.h
Only in /usr/src/kernel-headers-2.2.19/include/linux: modules
Only in /usr/src/kernel-headers-2.2.19/include/linux: modversions.h
Only in /usr/src/kernel-headers-2.2.19/include/linux: version.h

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgpdltxGcorGG.pgp
Description: PGP signature

Re: Architecture question

[Hamish Moffatt]

On Sun, Apr 22, 2001 at 01:24:43PM -0500, Taral wrote:
> I'm packaging acl2, which can take several hours to compile on a PPro
> 200. Would it be reasonable to exclude certain architectures as too
> slow? (acl2 is a theorem prover.)

eg your PPro 200? :-)


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Bug#94912: ITP: garlic -- free molecular visualization program

[zhaoway]

Package: wnpp
Severity: wishlist

Garlic, a free molecular visualization program written for unix and
unix clones. Garlic was written by Damir Zucic, at the University of
Osijek.

The latest version of garlic may be found at:
http://pref.etfos.hr/garlic

-- 
http://dim.sourceforge.net ... Debian Chinese Input Method
http://njlug.sourceforge.net  NanJing GNU/Linux User Group
http://cdlinux.sourceforge.net ... Debian running on Live! CDs
http://people.debian.org/~zw .. XEmacs Screenshots

Bug#94911: O: drscheme -- lost interests and don't use it anymore

[zhaoway]

Package: wnpp
Severity: normal

drscheme has quite some porting related bugs. and the upstream is
moving fast to v200.

i hereby orphan this package for i didn't use it for a long time. and
i have to get more time work on other tasks which i have more
interests. (for now at least. ;)

thanks,
-- 
http://dim.sourceforge.net ... Debian Chinese Input Method
http://njlug.sourceforge.net  NanJing GNU/Linux User Group
http://cdlinux.sourceforge.net ... Debian running on Live! CDs
http://people.debian.org/~zw .. XEmacs Screenshots

Re: kernel-{image,headers} package bloat

[Hamish Moffatt]

On Sun, Apr 22, 2001 at 09:59:42PM +1000, Craig Sanders wrote:
> btw, if you've been compiling your own kernels for a long time then you
> probably do somthing similar to what i do - copy in the .config from the
> previous version and run "make oldconfig" before "make menuconfig" and
> make-kpkg. i've been doing this for years and it's a great way to manage
> kernels. i even make copies of the .config files which are specific to
> particular machines.

I do that too; what's the oldconfig step needed for though? I just
jump straight to menuconfig and it always seems OK.

I agree that it is not too hard to compile your own kernel.
I never use Debian's standard kernel-image packages (except on
my 68K Mac, where it takes too long to recompile).

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: kernel-{image,headers} package bloat

[David Spreen]

Hi there,
On Mon, Apr 23, 2001 at 07:38:18AM +1000, Herbert Xu wrote:
> I think you've missed the point.  We're not talking about what is going
> to be the standard kernel image for woody.  We're discussing the way the
> kernel images are constructed on i386, which happens to only apply to
> 2.4 at the moment.

Hmm, no, but if had read th P.S. you would have seen...

so long...

David
-- 
  __  _  | David "netzwurm" Spreen  Kiel, Germany
 / _|___  ___| |__  __ _ _ _ | http://www.netzwurm.cc/  [EMAIL PROTECTED]
|  _/ _ \/ _ \ '_ \/ _` | '_|| gnupg key (on keyservers):   C8B6823A
|_| \___/\___/_.__/\__,_|_|  | CellPhone:   +49 173 3874061

Re: kernel-{image,headers} package bloat

[Herbert Xu]

Steve M. Robbins <[EMAIL PROTECTED]> wrote:

> Independent of whether or not Xu uploads a dozen pre-compiled kernels,
> it would be nice to have their configs readily available.  I would
> appreciate an easy way of seeing what tweaks are recommended to
> optimize for an i686 machine.

They already are:

apt-get source kernel-image-2.4.3-i386
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: kernel-{image,headers} package bloat

[Herbert Xu]

Andreas Metzler <[EMAIL PROTECTED]> wrote:

> Are these *really* necessary? Who does need them, people who compile

Yes.  By all module builders, especially those outside Debian.

> external kernel-modules (alsa, lm-sensors, ...)? Can't these
> people simply install kernel-source, extract it to /tmp and set $KSRC?

You can't build-depend on a source package.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: kernel-{image,headers} package bloat

[Herbert Xu]

David Spreen <[EMAIL PROTECTED]> wrote:
> On Sun, Apr 22, 2001 at 10:16:36PM +1000, Herbert Xu wrote:
>> With the latest release, it's now down to about 80MB.  In any case, we
>> never release with more than one old kernel, nor with experimental kernels,
>> so that would be 1 x 2.2.x, and at most 2 x 2.4.x.

> This sucks. Hopefully not only in my opinion. But, see, I don't agree with 
> you if you concentrate on 2.4.x kernels until 2.4.10 or better .15 is
> released. I felt like on an horror trip when I saw potato released with
> an prerelaese of a stable kernel. And please, don't use a 2.4.x kernel
> for wood as the standard kernel-image.

I think you've missed the point.  We're not talking about what is going
to be the standard kernel image for woody.  We're discussing the way the
kernel images are constructed on i386, which happens to only apply to
2.4 at the moment.

The kernel on the boot floppies is still 2.2 at the moment.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: ITP: dopewars

[David Nusinow]

On 22 Apr 2001 20:22:10 +0200, Leon Breedt wrote:
> Hi,
> 
> DopeWars is a kickarse curses based game that supports
> multiplayer, its under the GPL and can be found at:
> 
> http://bellatrix.pcl.ox.ac.uk/~ben/dopewars/
> 
> If no one objects, I'll package it.
> 

Sweet! I'm kind of surprised no one packaged it sooner. I'm glad it's on its 
way though.

- David Nusinow
   [EMAIL PROTECTED]

Re: chroot bind?

[Marco d'Itri]

On Apr 22, Ethan Benson <[EMAIL PROTECTED]> wrote:

 >> i) Is there any reason why you decided to include the named binaries in
 >> the chroot?  
 >you have to have at least named-xfer.  
Not with BIND 9. Another reason to use BIND 9.

-- 
ciao,
Marco

Re: kernel-{image,headers} package bloat

[Aaron Lehmann]

On Sun, Apr 22, 2001 at 02:47:36PM +0200, Roland Mas wrote:
> Nonono, we should automate it as much as possible.  I envision a
> global Makefile somewhere, and a ports/ directory, and a
> make-world.sh, and...  And then Debian GNU/BSD!  Yay!

I've been spending a lot of time starting to design a ports system
based on dpkg-dev and apt. It would be a "personal autobuilder" that
would be similar in function to apt-get but would compile packages
with customized options and optimizations.

Re: kernel-{image,headers} package bloat

[Aaron Lehmann]

On Sun, Apr 22, 2001 at 09:44:01PM +1000, Craig Sanders wrote:
> just as you stated you'd be filing bug-reports to get 2.2.17 kernel
> image removed from the archive, i'll be filing "package should not
> exist" bugs against all the excess kernel-image bugs.

Alternatively, you could bring it up with the technical committee.

Re: XFree 4.0.3 used by some debian developers and their sid packages depend on it (but not available)

[Branden Robinson]

ALL RIGHT, YOU JACKASSES, STOP COMPILING AGAINST UNRELEASED PACKAGES.

Everyone else, please file serious bugs against any packages you find doing
this.  "Cannot build from source" is exactly what they are, and that's a
release critical bug.

4.0.3-1 will be out when it's ready, which will hopefully be soon.

On Sun, Apr 22, 2001 at 08:05:51PM +0200, Adel Belhouane wrote:
>   I send this e-mail to you because I think you're the person most
> able to talk about this to debian developer.
> 
>   Some debian developers create packages depending on xlibs 4.0.3,
> but it's not available in sid without including for example a deb line
> pointing to your packages. I already made one or two bug reports in the
> past when the very same happened with packages depending on non-available
> xlibs 4.0.1 but I didn't get any positive answer.
> 
>   Would you mind putting a warning on your X Strike Force page
> telling debian developers to be careful about that, or do you think that
> since I'm using the unstable distribution I shouldn't find this abnormal
> and handle it myself (personnally I can, maybe not some others)? I won't
> protest if so, I'd just like to be told.
> 
> Thanks in advance.
> 
> list of such packages:
> 
> merlin-clock
> freetype-tools
> freetype2-demos
> wmsysmon
> netmaze
> ssh-askpass-gnome
> 
> Adel Belhouane <[EMAIL PROTECTED]>

-- 
G. Branden Robinson |   Men use thought only to justify their
Debian GNU/Linux|   wrong doings, and speech only to conceal
[EMAIL PROTECTED]  |   their thoughts.
http://www.debian.org/~branden/ |   -- Voltaire


pgpZud4keMutF.pgp
Description: PGP signature

Re: Architecture question

[Ben Collins]

On Sun, Apr 22, 2001 at 08:31:55PM +0200, Wichert Akkerman wrote:
> Previously Taral wrote:
> > I'm packaging acl2, which can take several hours to compile on a PPro
> > 200. Would it be reasonable to exclude certain architectures as too
> > slow? (acl2 is a theorem prover.)
> 
> No.

Argeed. Lots of packages take several hours to build, even on fairly
recent systems. Let the porter decide what to exclude in this case.

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: Architecture question

[Philip Blundell]

>I'm packaging acl2, which can take several hours to compile on a PPro
>200. Would it be reasonable to exclude certain architectures as too
>slow? (acl2 is a theorem prover.)

No.  The porters can make up their own minds about whether it's worth 
compiling for their architecture.  We already have packages like XFree86 that 
take over a day to compile on slower platforms.

p.

Re: Architecture question

[Wichert Akkerman]

Previously Taral wrote:
> I'm packaging acl2, which can take several hours to compile on a PPro
> 200. Would it be reasonable to exclude certain architectures as too
> slow? (acl2 is a theorem prover.)

No.

Wichert.

-- 
   
 / Generally uninteresting signature - ignore at your convenience  \
| [EMAIL PROTECTED]  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Architecture question

[Taral]

I'm packaging acl2, which can take several hours to compile on a PPro
200. Would it be reasonable to exclude certain architectures as too
slow? (acl2 is a theorem prover.)

-- 
Taral <[EMAIL PROTECTED]>
Please use PGP/GPG encryption to send me mail.
"Any technology, no matter how primitive, is magic to those who don't
understand it." -- Florence Ambrose


pgp46rC9K5soW.pgp
Description: PGP signature

Location of chroot environments (was: chroot bind?)

[Marc Haber]

On Sat, 21 Apr 2001 10:39:02 -0400 (EDT), "Jaldhar H. Vyas"
<[EMAIL PROTECTED]> wrote:
>On 21 Apr 2001, Bdale Garbee wrote:
>> I have no great inspirations about where to park chroot's, either.  I don't
>> think it is well handled, if at all, by current policy.  The buildd machines
>> I've looked at mostly use /chroot, but that means nothing.
>
>I just put it in /var/secure-bind.

I tend to put play chroots under my home directory, and chroots for
production daemons under /var/chroot.

A pity that the FHS doesn't comment on that.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber  |   " Questions are the | Mailadresse im Header
Karlsruhe, Germany  | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

ITP: dopewars

[Leon Breedt]

Hi,

DopeWars is a kickarse curses based game that supports
multiplayer, its under the GPL and can be found at:

http://bellatrix.pcl.ox.ac.uk/~ben/dopewars/

If no one objects, I'll package it.

Cheers,

Leon.

-- 
[EMAIL PROTECTED]
http://neverborn.org

ITP: fam (but not a developer yet)

[Michel Salim]

fam, the File Alteration Monitor from SGI, will be used by both E 0.17
and the upcoming Nautilus 1.0.3 / 1.2, whatever they will finally call
it.

http://oss.sgi.com/projects/fam

Guess I'll take a stab at this. Will post the URL when done - I don't
intend to jumpstart anything, just avoiding duplication of efforts :)


-- 
Michèl Alexandre Salim

Re: chroot bind?

[Yotam Rubin]

On Sun, Apr 22, 2001 at 06:23:43PM +0200, Marco d'Itri wrote:
> On Apr 21, Yotam Rubin <[EMAIL PROTECTED]> wrote:
> 
>  >We could harden the default configuration with the following directives:
>  >
>  >version 'Not available';
> This does not harden anything and just makes debugging harder.
> Don't dare putting something like this in the default configuration of a
> debian package.

I disagree. A lot of the vulnerability scanners out there determine whether
a host is susceptible to a certain bug by looking at its version.bind record.
If a bug were to be discovered in 8.2.3, conventional script kiddie methods
will not properly function. Obviously, it does not provide full 'protection',
but it will render a lot of scanners out there useless.
Debugging? When in debugging does one check one's version.bind? 

Regards, Yotam Rubin

> 
> -- 
> ciao,
> Marco
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 


pgpRsyDdbO8BA.pgp
Description: PGP signature

Re: chroot bind?

[Marco d'Itri]

On Apr 21, Yotam Rubin <[EMAIL PROTECTED]> wrote:

 >We could harden the default configuration with the following directives:
 >
 >  version 'Not available';
This does not harden anything and just makes debugging harder.
Don't dare putting something like this in the default configuration of a
debian package.

-- 
ciao,
Marco

Re: FYI: dh_upx compresses i386 executables

[Radovan Garabik]

On Sat, Apr 21, 2001 at 11:50:44AM -0700, John H. Robinson, IV wrote:
> On Sat, Apr 21, 2001 at 11:41:56AM -0700, Alexander Hvostov wrote:
> > On Sat, 21 Apr 2001 11:40:15 -0700 "John H. Robinson, IV" wrote:
> > 
> > > however, on something like boot-floppies, this might be a
> > > goddess-send.
> > 
> > What about filesystem-level compression?
> 
> http://www.netspace.net.au/~reiter/e2compr/intro.html :
> 
>   I wouldn't use e2compr on a ``production'' machine (where
>   neither faults nor delays are tolerated).
> 

I would say the same about 2.4 kernel :-)

> i would have to say no to that. 
> 
> if there were indication that it was ready to stabalize and be ready for
> prime time, then add it to unstable and wait for bugreports (make it an
> option, of course).

I've run it for years (well, almost 2 :-)) on a heavily loaded
production server without any problems whatsoever...


-- 
 ---
| Radovan Garabik http://melkor.dnp.fmph.uniba.sk/~garabik/ |
| __..--^^^--..__garabik @ melkor.dnp.fmph.uniba.sk |
 ---
Antivirus alert: file .signature infected by signature virus.
Hi! I'm a signature virus! Copy me into your signature file to help me spread!

Re: Recovering dpkg database

[Taral]

On Sat, Apr 21, 2001 at 10:49:20PM -0700, Joseph Carter wrote:
> From then on (sorry, I know of no other way) you will simply have to get a
> list of installed packages (dpkg --get-selections, you can use cut or sed
> and grep or something to cut the list down to just the ones you want) and
> feed the result to apt-get install..  If you do it cleverly, you can do it
> on one cmdline.

Actually, dpkg is likely not to want to install them. Answer:

apt-get clean
apt-get -d install `dpkg --get-selections | awk '$2 == "install" { print
$1 }'`
dpkg -i /var/cache/apt/archives/*.deb

This will force a reinstall. You just have to hope that upgraded
packages don't break on you.

-- 
Taral <[EMAIL PROTECTED]>
Please use PGP/GPG encryption to send me mail.
"Any technology, no matter how primitive, is magic to those who don't
understand it." -- Florence Ambrose


pgpUiPIQN4ikb.pgp
Description: PGP signature

Re: kernel-{image,headers} package bloat

[Andreas Metzler]

Herbert Xu <[EMAIL PROTECTED]> wrote:
[snip]
>> P.S. Is a seperate kernel-headers package really necessary for
>> every CPU type? What are the differences between the headers in,
>> say kernel-headers-2.4.3-686 and kernel-headers-2.4.3-686-smp?
>> Or kernel-headers-2.4.3-k6 and kernel-headers-2.4.3-k7? I was not
>> aware that a different set of headers was made for every chip type!

> It's got nothing to do with CPU type.  The individual kernel-headers exist
> for the benefit of module builders.

Hello!
Are these *really* necessary? Who does need them, people who compile
external kernel-modules (alsa, lm-sensors, ...)? Can't these
people simply install kernel-source, extract it to /tmp and set $KSRC?
What *is* the difference between eg. kernel-headers-2.4.3-686 and
kernel-headers-2.4.3-k6?

kernel-image-version-$cpu is really nice, but these
kernel-headers--* are bigger and _seem_ to be a real waste of
space/bandwith.
   cu andreas
-- 
Uptime: 10 seconds  load average: 0.00, 0.00, 0.00
vim:ls=2:stl=***\ Sing\ a\ song.\ ***

Re: FYI: dh_upx compresses i386 executables

[Itai Zukerman]

On Sun, 22 Apr 2001 06:02:30 -0800, Ethan Benson wrote:
> On Sun, Apr 22, 2001 at 09:00:13AM -0400, Itai Zukerman wrote:
> > If not, I suggest a debhelper command to add the necessary code to
> > the postinst.  Packages that use this should, of course, depend on the
> > binary-compressing package, which would provide the one-time question
> 
> why should they depend on it?  if its not installed that should imply
> that the admin does not want compressed binaries.  

OK, I believe doc-base and install-docs is handled this way.

Then, later you could install the compressing package and run
dpkg-reconfigure on those packages that you want compressed?

-itai

Re: kernel-{image,headers} package bloat

[John H. Robinson, IV]

On Sun, Apr 22, 2001 at 02:47:36PM +0200, Roland Mas wrote:
> Herbert Xu (2001-04-22 22:23:04 +1000) :
> > Craig Sanders <[EMAIL PROTECTED]> wrote:
> > 
> > > that would be one package, taking maybe a few hundred kilobytes
> > > total.  call it kernel-helper and make it depend on
> > > kernel-package.  problem solved.
> > 
> > But why not take this one step further, let's just distribute what's
> > in build-essential and let the users compile the rest.  Let's rewind
> > the clock back to times when men were men, and they compiled
> > everything on their own box :)
> 
> Nonono, we should automate it as much as possible.  I envision a
> global Makefile somewhere, and a ports/ directory, and a
> make-world.sh, and...  And then Debian GNU/BSD!  Yay!

or convince linus that the SunOS way is the one true way. edit a file
in /etc (call it linux.rc) that has the kernel tweaks. next boot, the
kernel recompiles itself.

whadayasay?

-john

Re: kernel-{image,headers} package bloat

[Nathan E Norman]

On Sun, Apr 22, 2001 at 10:23:04PM +1000, Herbert Xu wrote:
> Craig Sanders <[EMAIL PROTECTED]> wrote:
> 
> > in that case, a far better solution is a package containing a bunch
> > of pre-generated kernel .config files, plus a menu script to copy
> > your choice to the right subdirectory (e.g. /usr/local/src/linux or
> > wherever)...then run "make menuconfig" or "make xconfig" to let you
> > tweak the .config before compiling.
> 
> > that would be one package, taking maybe a few hundred kilobytes total.
> 
> > call it kernel-helper and make it depend on kernel-package.
> 
> > problem solved.
> 
> But why not take this one step further, let's just distribute what's
> in build-essential and let the users compile the rest.  Let's rewind
> the clock back to times when men were men, and they compiled everything
> on their own box :)

Well, this is foolish.

Craig is arguing for one (or a few) kernel packages rather than a
multitude of them.  It's difficult to install debian if there's not at
least one kernel-image package, eh?

Your hypthetical is calling for distributing zero packages, in which
case we no longer have a distribution.  Some people prefer that
approach, but they probably aren't using debian at all.

-- 
Nathan Norman - Staff Engineer | A good plan today is better
Micromuse Ltd. | than a perfect plan tomorrow.
mailto:[EMAIL PROTECTED]   |   -- Patton


pgpx8rHF5wqod.pgp
Description: PGP signature

Re: kernel-{image,headers} package bloat

[Nathan E Norman]

On Sun, Apr 22, 2001 at 09:59:42PM +1000, Craig Sanders wrote:
> On Sun, Apr 22, 2001 at 12:09:12AM -0500, David Starner wrote:
> > On Sat, Apr 21, 2001 at 09:28:02PM -0500, Rahul Jain wrote:
> > > Unless you care about performace. Which is the main reason to use
> > > different packages for each CPU type.
> >
> > I compile my own kernels, and have for a long time. But it's a pain to
> > go through all the poorly-documented options and takes quite a while
> > to select those options and actually build a kernel. And then there's
> > the times I have to go back and recompile because I left out my mouse
> > drivers, or ide-scsi, or vfat. It's entirely rational to want to pick
> > up the 10% improvement from hitting the right button in dselect and
> > not worry about the 20% from recompiling the kernel.
> 
> in that case, a far better solution is a package containing a bunch
> of pre-generated kernel .config files, plus a menu script to copy
> your choice to the right subdirectory (e.g. /usr/local/src/linux or
> wherever)...then run "make menuconfig" or "make xconfig" to let you
> tweak the .config before compiling.
> 
> that would be one package, taking maybe a few hundred kilobytes total.
> 
> call it kernel-helper and make it depend on kernel-package.
> 
> problem solved.

This is an excellent idea.  Herbert, please consider it.  I really
don't think that we need several hunder megabytes worth of kernels in
the distribution ...

-- 
Nathan Norman - Staff Engineer | A good plan today is better
Micromuse Ltd. | than a perfect plan tomorrow.
mailto:[EMAIL PROTECTED]   |   -- Patton


pgpbcCH4XZ4IM.pgp
Description: PGP signature

Re: kernel-{image,headers} package bloat

[Steve M. Robbins]

On Sun, Apr 22, 2001 at 09:59:42PM +1000, Craig Sanders wrote:
> On Sun, Apr 22, 2001 at 12:09:12AM -0500, David Starner wrote:
> > On Sat, Apr 21, 2001 at 09:28:02PM -0500, Rahul Jain wrote:
> > > Unless you care about performace. Which is the main reason to use
> > > different packages for each CPU type.
> >
> > I compile my own kernels, and have for a long time. But it's a pain to
> > go through all the poorly-documented options and takes quite a while
> > to select those options and actually build a kernel. And then there's
> > the times I have to go back and recompile because I left out my mouse
> > drivers, or ide-scsi, or vfat. It's entirely rational to want to pick
> > up the 10% improvement from hitting the right button in dselect and
> > not worry about the 20% from recompiling the kernel.
> 
> in that case, a far better solution is a package containing a bunch
> of pre-generated kernel .config files, plus a menu script to copy
> your choice to the right subdirectory (e.g. /usr/local/src/linux or
> wherever)...then run "make menuconfig" or "make xconfig" to let you
> tweak the .config before compiling.
> 
> that would be one package, taking maybe a few hundred kilobytes total.
> 
> call it kernel-helper and make it depend on kernel-package.
> 
> problem solved.

That sounds like a neat idea.

Independent of whether or not Xu uploads a dozen pre-compiled kernels,
it would be nice to have their configs readily available.  I would
appreciate an easy way of seeing what tweaks are recommended to
optimize for an i686 machine.

-Steve

Re: FYI: dh_upx compresses i386 executables

[Ethan Benson]

On Sun, Apr 22, 2001 at 09:00:13AM -0400, Itai Zukerman wrote:
> 
> If not, I suggest a debhelper command to add the necessary code to
> the postinst.  Packages that use this should, of course, depend on the
> binary-compressing package, which would provide the one-time question

why should they depend on it?  if its not installed that should imply
that the admin does not want compressed binaries.  

> you want.  The postinst code would call the compression routines,
> which might not do anything, depending on how the compressing package
> was configured (i.e., it wouldn't call the compressing code directly,
> but through a wrapper).

makes sense

> Any objections?

see above

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgp84tJynUGQt.pgp
Description: PGP signature

Re: kernel-{image,headers} package bloat

[David Spreen]

On Sun, Apr 22, 2001 at 10:16:36PM +1000, Herbert Xu wrote:
> With the latest release, it's now down to about 80MB.  In any case, we
> never release with more than one old kernel, nor with experimental kernels,
> so that would be 1 x 2.2.x, and at most 2 x 2.4.x.

This sucks. Hopefully not only in my opinion. But, see, I don't agree with 
you if you concentrate on 2.4.x kernels until 2.4.10 or better .15 is
released. I felt like on an horror trip when I saw potato released with
an prerelaese of a stable kernel. And please, don't use a 2.4.x kernel
for wood as the standard kernel-image.

But this thread's discussion ducks. It will point to nothing, if noone will
suggest a solution. What's about the kernel images to be pseudopackages
with special configs depending on patches and kernelsource to build a 
kernel live when installing it?

so long...

David
-- 
  __  _  | David "netzwurm" Spreen  Kiel, Germany
 / _|___  ___| |__  __ _ _ _ | http://www.netzwurm.cc/  [EMAIL PROTECTED]
|  _/ _ \/ _ \ '_ \/ _` | '_|| gnupg key (on keyservers):   C8B6823A
|_| \___/\___/_.__/\__,_|_|  | CellPhone:   +49 173 3874061

Re: FYI: dh_upx compresses i386 executables

[Itai Zukerman]

On Sun, 22 Apr 2001 00:57:54 +0200, <[EMAIL PROTECTED]> wrote:
> On Sunday 22 April 2001 00:45, Itai Zukerman wrote:
> > Why not compress the binaries in the postinst, maybe after asking the
> > admin for permission?
> 
> Well, if I had to answer "no" to compression for binary in every new package 
> I installed, I'd go nuts rather soon. If, however, it was made the 
> responsibility of the system somehow, packagers needn't worry of it at all, 
> users only had to answer once, and whoever had to implement had to do the 
> work, and nobody had to duplicate it, allowing him to feel nice about himself.

Yes, dpkg needs some way to define hooks, things to be run against
every installed package.  That should take care of compressed binaries
and purging locales & documentation.  Maybe dpkg already has such a
thing.

If not, I suggest a debhelper command to add the necessary code to
the postinst.  Packages that use this should, of course, depend on the
binary-compressing package, which would provide the one-time question
you want.  The postinst code would call the compression routines,
which might not do anything, depending on how the compressing package
was configured (i.e., it wouldn't call the compressing code directly,
but through a wrapper).

Any objections?

-itai

Re: kernel-{image,headers} package bloat

[Roland Mas]

Herbert Xu (2001-04-22 22:23:04 +1000) :

> Craig Sanders <[EMAIL PROTECTED]> wrote:
> 
> > that would be one package, taking maybe a few hundred kilobytes total.
> 
> > call it kernel-helper and make it depend on kernel-package.
> 
> > problem solved.
> 
> But why not take this one step further, let's just distribute what's
> in build-essential and let the users compile the rest.  Let's rewind
> the clock back to times when men were men, and they compiled
> everything on their own box :)

Nonono, we should automate it as much as possible.  I envision a
global Makefile somewhere, and a ports/ directory, and a
make-world.sh, and...  And then Debian GNU/BSD!  Yay!

  Seriously though, I think Craig's idea of a kernel-helper is cool.

Roland.
-- 
Roland Mas

Plus on en fout, plus y'en a du riz.
  -- Proverbe chinois.

Re: Cryptic messages from installers

[Santiago Vila]

On Sat, 21 Apr 2001, Antti-Juhani Kaijanaho wrote:

> On 20010419T170915+0200, Santiago Vila wrote:
> > On 18 Apr 2001, James Troup wrote:
> > > making broken assumptions based on random things like the signature on
> > > the file.
> >
> > "A gpg signature is a random thing" --Debian gnupg maintainer.
> >
> > Great quote! :-)
>
> Except that it's not a quote (don't agree with me? show me where he
> used those exact words).

Of course it is not a quote, hence the ":-)".

But this does not change what he said:

"[...] based on random things like the signature on the file."

Being a gpg signature the deliberate and internally consistent thing
it is, the only context I can think of it to be "random" is the
statistical distribution of the characters in its base64 enconding.

Re: kernel-{image,headers} package bloat

[Wichert Akkerman]

Previously Roland Mas wrote:
>   Call me stupid if you like, but I think "all goes into modules"
> won't work.

It does if you use initrd.

Wichert.

-- 
   
 / Generally uninteresting signature - ignore at your convenience  \
| [EMAIL PROTECTED]  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: kernel-{image,headers} package bloat

[Roland Mas]

Herbert Xu (2001-04-22 14:15:50 +1000) :

> Yes you should.  But then most people would be happy to have all of
> the above as modules.

I used to put plenty of things in modules.  I even put ext2 in a
module, three or four times.  Wham, kernel panic at boot.  Okay, I
thought I wouldn't do the same error again.  I haven't, for three
years.

  Then one day I compiled IDE as a module.  Boom again!

  Call me stupid if you like, but I think "all goes into modules"
won't work.

Roland.
-- 
Roland Mas

Mou ichido !  Hayaku !  Ookii koede !
  -- Atsuko Sasaki

Re: kernel-{image,headers} package bloat

[Herbert Xu]

Craig Sanders <[EMAIL PROTECTED]> wrote:

> in that case, a far better solution is a package containing a bunch
> of pre-generated kernel .config files, plus a menu script to copy
> your choice to the right subdirectory (e.g. /usr/local/src/linux or
> wherever)...then run "make menuconfig" or "make xconfig" to let you
> tweak the .config before compiling.

> that would be one package, taking maybe a few hundred kilobytes total.

> call it kernel-helper and make it depend on kernel-package.

> problem solved.

But why not take this one step further, let's just distribute what's
in build-essential and let the users compile the rest.  Let's rewind
the clock back to times when men were men, and they compiled everything
on their own box :)
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: kernel-{image,headers} package bloat

[Herbert Xu]

On Sun, Apr 22, 2001 at 09:44:01PM +1000, Craig Sanders wrote:
> 
> i disagree with you primarily because the cost of having so many
> kernel-image packages is too high.

That is your opinion, and I disagree with it.

> that cost is over 100MB per kernel version, that's several hundred MB
> with several kernel versions available (1 or 2 x 2.2.x kernels and 1 or
> 2 x 2.4.x kernels, possibly a 2.5.x kernel as well)

With the latest release, it's now down to about 80MB.  In any case, we
never release with more than one old kernel, nor with experimental kernels,
so that would be 1 x 2.2.x, and at most 2 x 2.4.x.

> that means extra bandwidth consumed to sync each and every mirror
> site...repeated every time a kernel-image is added to or upgraded in
> the archive. that could easily run into several gigabytes per month
> PER mirror...and dozens of gigabytes extra per month for master and
> ftp.debian.org to feed all the mirrors.

That I am afraid is hyperbole.  Even if I were on steroids, I just don't
see myself making more than 4 uploads per month, that's what 320MB?

> it also means more space consumed on the CD-ROM - several hundred MB
> extra wasted on kernel images in the release will mean at least one
> extra CD-ROM. that means a more expensive release, and more difficult
> and time-consuming to produce.

As I said before, someone will need to look into the problem of CDs and
in particular of being able to not include everything in the distribution
on CDs.  This is merely a manifestation of a greater problem.

> it also means more gigabytes of bandwidth used by people mirroring the
> ISO images.

I think you exaggerate too much.

> the benefit of having all those extra kernel-image packages around is
> soemwhere been non-existant and negligible...but the cost is enormous.

We clearly disagree, so let's leave it at that.

> just as you stated you'd be filing bug-reports to get 2.2.17 kernel
> image removed from the archive, i'll be filing "package should not
> exist" bugs against all the excess kernel-image bugs.

Go ahead, I'll close them as soon as they're filed.

> > Most are.  In my opinioin, there isn't anything that is particular
> > important to most people which haven't been modularised yet.
> 
> you seem to think that optimisations for specific ia32 sub-architectures
> are important enough to package...

How does this relate to what I said?

> there's good reason to worry about kernel modules now that there are
> known hax0r stealth modules which exist purely to hide the fact that a
> system has been compromised.

And what does this have to do with our discussion?
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: kernel-{image,headers} package bloat

[Craig Sanders]

On Sun, Apr 22, 2001 at 12:09:12AM -0500, David Starner wrote:
> On Sat, Apr 21, 2001 at 09:28:02PM -0500, Rahul Jain wrote:
> > Unless you care about performace. Which is the main reason to use
> > different packages for each CPU type.
>
> I compile my own kernels, and have for a long time. But it's a pain to
> go through all the poorly-documented options and takes quite a while
> to select those options and actually build a kernel. And then there's
> the times I have to go back and recompile because I left out my mouse
> drivers, or ide-scsi, or vfat. It's entirely rational to want to pick
> up the 10% improvement from hitting the right button in dselect and
> not worry about the 20% from recompiling the kernel.

in that case, a far better solution is a package containing a bunch
of pre-generated kernel .config files, plus a menu script to copy
your choice to the right subdirectory (e.g. /usr/local/src/linux or
wherever)...then run "make menuconfig" or "make xconfig" to let you
tweak the .config before compiling.

that would be one package, taking maybe a few hundred kilobytes total.

call it kernel-helper and make it depend on kernel-package.

problem solved.


btw, if you've been compiling your own kernels for a long time then you
probably do somthing similar to what i do - copy in the .config from the
previous version and run "make oldconfig" before "make menuconfig" and
make-kpkg. i've been doing this for years and it's a great way to manage
kernels. i even make copies of the .config files which are specific to
particular machines.

for example, if i want to compile 2.4.2 for a machine called foobar
and i have a previously saved .config for 2.2.17 for that machine
then i copy it into /usr/local/src/linux, run "make oldconfig", "make
menuconfig", and then build the kernel with make-kpkg...and finally copy
it to the right machine with scp.

similar, if machine barfoo is very similar to machine foobar then i
might use foobar's .config as the base for creating barfoo's .config.


perhaps doing this is not completely obvious to new users. in that
case, we should be teaching them that this kind of thing is possible,
educating our users to make effective use of the existing tools.

we have good tools for managing kernel .config files and kernel
versions. kernel-package is an outstanding piece of work...manoj has
done some lots of other cool work too, but this by itself is more than
enough to earn a great deal of respect.

if users don't know that this exists or don't realise how useful it is,
then that can be solved with education.

craig

--
craig sanders <[EMAIL PROTECTED]>

  GnuPG Key: 1024D/CD5626F0 
Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57  52C3 EC32 6810 CD56 26F0

Re: kernel-{image,headers} package bloat

[Craig Sanders]

On Sun, Apr 22, 2001 at 01:38:42PM +1000, Herbert Xu wrote:
> > if the user needs a more specific kernel (e.g. with SMP or compiled
> > for a P2 or a K6 or whatever) then they can use manoj's excellent
> > kernel-package (one of debian's best features, IMO) to build a
> > custom kernel.
>
> This is exactly our disagreement.  My position is that it is well
> within our capabilities to make this unnecessary.  And you disagree
> with that which is fine with me.

i disagree with you primarily because the cost of having so many
kernel-image packages is too high.

that cost is over 100MB per kernel version, that's several hundred MB
with several kernel versions available (1 or 2 x 2.2.x kernels and 1 or
2 x 2.4.x kernels, possibly a 2.5.x kernel as well)

that means extra bandwidth consumed to sync each and every mirror
site...repeated every time a kernel-image is added to or upgraded in
the archive. that could easily run into several gigabytes per month
PER mirror...and dozens of gigabytes extra per month for master and
ftp.debian.org to feed all the mirrors.

there's also an economic cost too, of course. some places in the
world have much cheaper bandwidth than Australia, some have much more
expensive bandwidth, but here in Australia, a GB costs about $AUD200 (~=
$USD100) to download. that's at $0.20/MB, an average price for Australia
- some people pay more than that (as much as $0.35/MB), some pay less
(as little as $0.07/MB)...so the price per GB ranges from $AUD70 to $AUD350.


it also means more space consumed on the CD-ROM - several hundred MB
extra wasted on kernel images in the release will mean at least one
extra CD-ROM. that means a more expensive release, and more difficult
and time-consuming to produce.

it also means more gigabytes of bandwidth used by people mirroring the
ISO images.


the benefit of having all those extra kernel-image packages around is
soemwhere been non-existant and negligible...but the cost is enormous.

it's just plain wrong, and it should not happen.

just as you stated you'd be filing bug-reports to get 2.2.17 kernel
image removed from the archive, i'll be filing "package should not
exist" bugs against all the excess kernel-image bugs.

the correct thing to do is to encourage and educate our users about
compiling their own kernel. if it's "too hard" then we should try to
make it easier.

why pander to ignorance when ignorance is a curable affliction? it's
much better to cure it through education than to support and encourage
it.

what you want to do is detrimental in the long run - it serves to
perpetuate the myth that compiling kernels is extremely difficult, and
encourages laziness and ignorance on the part of the user.


> Most are.  In my opinioin, there isn't anything that is particular
> important to most people which haven't been modularised yet.

you seem to think that optimisations for specific ia32 sub-architectures
are important enough to package...

> > 2. it is, in general, *far* better to run a kernel which is specific to
> > your exact hardware and your exact requirements than to use a generic
> > kernel with a bunch of options you don't use and don't care about
> > compiled in.
> 
> IMHO, with the current 2.4.* setup, the difference between compiling your
> own and using the preexisting one is so minimal that most people will be
> able to use the precompiled one rather than building their own.

there's good reason to worry about kernel modules now that there are
known hax0r stealth modules which exist purely to hide the fact that a
system has been compromised.

craig

--
craig sanders <[EMAIL PROTECTED]>

  GnuPG Key: 1024D/CD5626F0 
Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57  52C3 EC32 6810 CD56 26F0

Re: chroot bind?

[Ethan Benson]

On Sun, Apr 22, 2001 at 08:50:45PM +1200, [EMAIL PROTECTED] wrote:
> 
> 
> Just two questions:
> 
> i) Is there any reason why you decided to include the named binaries in
> the chroot?  

you have to have at least named-xfer.  

> There is no need for them to be there, since named does the chroot
> internal.  In fact this might represent a security hole.

yes there is.  

> Consider some manages to break named and get access to the chroot
> enviroment.  The manage to upload a trojaned vesion of the named binary
> somehow.  The server boots and the system is wide open.  

not if you setup the chroot jail with correct permissions.  ie NOT
chown -R named.named /var/named.  the ONLY part of the chroot jail
that should be writable by named is var/tmp and var/cache/bind (and i
think var/run has to be too).  everything else including the config
files, and binaries/libraries and the directories they live in should
be owned by root and readonly to all others.

> This _might_ create a false sense of security.  

chroot isn't a panacea but it certainly is an improvment.  

> 
> If chroot chroot ;) was used (from an external location to the chroot) or
> named was called say from '/use/sbin/named -t /var/secure-bind' then of
> course this is not an issue.  Since the binary that creates the chroot
> is not in the chroot itself.

the way i do it is the initscript replaces the binaries in the chroot
jail before starting them, this way the mainline bind package can
get upgraded to fix a security hole and the chroot is upgraded
automatically.  the binaries in the chroot jail are only writable by
root, and of course named does not run as root.  (chrooted named
running as root is completely pointless).  

> ii)  Is there a particular reason to use /var/secure-bind rather than
> say /var/named which seems to be some what of an informal default.
> 
> I'm going to ask on the FHS mailing list about their thoughts on chroot
> enviroments and how it might fit in FHS policy.

it certainly would be useful to have some standard setup for this kind
of thing.  

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgpXvyZAIuYo1.pgp
Description: PGP signature

Re: kernel-{image,headers} package bloat

[Herbert Xu]

Michael Banck <[EMAIL PROTECTED]> wrote:

> Fair enough. But what about the difference between machine-dependant
> optimisation? Perhaps the difference between i386 and PIII is so minimal

Please read the earlier messages in this thread.  This has already been
covered.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Update release management

[Michel Salim]

Hello,

I apologise if this is considered off-topic - might be barking up the
wrong tree in the wrong forest here - but bringing up an old issue here
of release frequency, once the transition to using package pools and the
new debian-installer is done, would it be reasonable to expect Debian
releases more often - say, once every quarter like FreeBSD already does?

The comparison with FreeBSD is rather apt as both are community projects
working on whole OSes, although FreeBSD has a principal sponsor (BSDi,
then WindRiver) and positions itself more commercially than does Debian
(selling official CDs) and thus perhaps having more to benefit from
frequent releases?

That asides, with the avalanches of release in the last few days (RH
7.1, Mdk 8.0, FreeBSD 4.3) leading me to think about the future of
Debian - note that last week also sees the update of the Unofficial
Debian CD sets (by Attila Nagy - many thanks!), one sets to ponder
certain points of matter:

- it should be easier maintaining the new modular installer in-between
releases (considering the present one looks very much similar to
FreeBSD's spartan interface, and *that* installer has not changed in
ages it seems, it would be nice if our next installer can be that
dependable)

- Package pools allowing easy roll-out of custom-made mini-distributions

Take the two together and certain possibilities arise:
1. Frequent releases made possible for the benefit of people without
blazing-fast connection
2. This frequent release should allow Debian to generate more revenue
3. A sort of package rating system, allowing a core nucleus of important
libraries and programs to coalesce. Since these packages are those most
likely to change and thus most noticeable when they become out of date,
having frequent releases would help, and doing so would be easier with
less packages to concentrate bug-fixing on
4. Inter-release update CDs could be issued ala Microsoft's Service
Packs with updated packages only - so it might depend on previous
release CDs. Should be simple enough to automate, does not even need an
installer.


I am sure all these points have been raised before, or even seem obvious
and if anyone think this posting is a waste of time and space, my
apologies. Just thought to appease my curiousity about Debian's future
plans since I am in the process of joining it.

Warm regards,

-- 
Michèl Alexandre Salim

Re: kernel-{image,headers} package bloat

[Michael Banck]

On Sun, Apr 22, 2001 at 01:38:42PM +1000, Herbert Xu wrote:
 
> IMHO, with the current 2.4.* setup, the difference between compiling your
> own and using the preexisting one is so minimal that most people will be
> able to use the precompiled one rather than building their own.

Fair enough. But what about the difference between machine-dependant
optimisation? Perhaps the difference between i386 and PIII is so minimal
that most people will be able to use the precompiled i386-image? At
least those were the rumours I heard some time ago.
Did someone investigate this?

Gnome keyboard shortcuts stopped working

[Dr. Guenter Bechly]

Hello,

I am running Sid (daily updated) and currently have a problem with Gnome:
Before I could access the programm menus with the keyboard shortcuts
(Alt + undelined_character). This worked with all Gnome apps under
any window manager. It still works with KDE apps, but since a few
days the Gnome apps only show the underlined_character in the menues
in grey (inactive) color and the shortcuts no longer work.
Anybody else experiencing the same problem, or knowing what's the
reason for this behaviour?

Best wishes,
Guenter

-- 
Linux: Who needs GATES in a world without fences?

Re: chroot bind?

[nic]

Just two questions:

i) Is there any reason why you decided to include the named binaries in
the chroot?  

There is no need for them to be there, since named does the chroot
internal.  In fact this might represent a security hole.

Consider some manages to break named and get access to the chroot
enviroment.  The manage to upload a trojaned vesion of the named binary
somehow.  The server boots and the system is wide open.  

This _might_ create a false sense of security.  


If chroot chroot ;) was used (from an external location to the chroot) or
named was called say from '/use/sbin/named -t /var/secure-bind' then of
course this is not an issue.  Since the binary that creates the chroot
is not in the chroot itself.



ii)  Is there a particular reason to use /var/secure-bind rather than
say /var/named which seems to be some what of an informal default.

I'm going to ask on the FHS mailing list about their thoughts on chroot
enviroments and how it might fit in FHS policy.



Nicholas

Re: kernel-{image,headers} package bloat

[David Starner]

On Sun, Apr 22, 2001 at 12:37:16AM -0500, Rahul Jain wrote:
> use the distro kernels' config as a starting point.

Which wins me how much, over just starting from the defaults? You 
still have to go over all the options, and wait for the kernel to
compile. It's still a lot easier to break stuff manually configuring
your kernel instead of going apt-get install kernel-2.8.88-i686.  

-- 
David Starner - [EMAIL PROTECTED]
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: FYI: dh_upx compresses i386 executables

[Richard Braakman]

On Sat, Apr 21, 2001 at 07:42:00PM -0300, Carlos Laviola wrote:
> There is: just upx -d it. (you can even run md5sum before and after
> compression/decompression to find out for yourself that the decompressed file
> is the same as before.)

Will upx -d work on a binary that was compressed with an older version
of upx?  The code I've seen doesn't seem to care much about that, so
I wonder if the author considers it a design requirement at all.

Richard Braakman

Re: Fix for: libdb3 and gnome

[Christian Marillat]

 "WWT" == Wesley W Terpstra <[EMAIL PROTECTED]> writes:

[...]

WWT> Anyways, here's the easy fix. In configure.in find:

[...]

WWT> Anyways, you have a fix that works now. Please try it yourself and let me
WWT> know whether or not it works out. Oh, I had to tweak all the Build-Depends
WWT> too.

This doesn't work.

Christain

Re: kernel-{image,headers} package bloat

[zhaoway]

> > > I should build my own kernel, right?
> > 
> > Sure, you're a computer geek. But remember we don't expect our
> > users to be all computer elites. No, they're no dummies. Think
> > about scientists, etc. who just simply don't have that much enough
> > time sometimes to make oneself be familiar with kernel
> > compiling. And why bother? (Ie. in most cases.)
> 
> If they're not into madly trying to get the configuration perfect
> when it comes to the kernel, why install an optimized version at
> all?

Because they are there. :)

Ie. If we can do our users a favor.. (And if the trade off of bloating
package pool is okay enough. In this case, I agree with Herbert.)

-- 
http://dim.sourceforge.net ... Debian Chinese Input Method
http://njlug.sourceforge.net  NanJing GNU/Linux User Group
http://cdlinux.sourceforge.net ... Debian running on Live! CDs
http://people.debian.org/~zw .. XEmacs Screenshots

Re: Recovering dpkg database

[Joseph Carter]

On Sun, Apr 22, 2001 at 12:07:37AM +0200, Klaus Reimer wrote:
> My harddisk containing /var has crashed (and I am a fool without a backup). I 
> was able to recover /var/lib/dpkg/status but all other files in /var/lib/dpkg 
> except some files from /var/lib/dpkg/info are gone. Is there any way to 
> reconstruct all other files and directories (alternatives, info, diversions) 
> without reinstalling all packages?

The fact that you were able to recover status is an amazing feat in and of
itself.  It greatly simplifies matters as you at least know what is
installed.

First thing you must do in order to fix dpkg is this:

# apt-get update
# apt-cache dumpavail > avail
# dpkg --update-avail avail

You'll also need to recreate the dpkg directory structure, the contents
file on the archive will help you do that.

From then on (sorry, I know of no other way) you will simply have to get a
list of installed packages (dpkg --get-selections, you can use cut or sed
and grep or something to cut the list down to just the ones you want) and
feed the result to apt-get install..  If you do it cleverly, you can do it
on one cmdline.

Expect that you'll have to rerun it a few times.  The popularity of apt
has caused many maintainers to become lax in their dependencies since apt
will usually figure it out if you rerun it a few times.  The whole point
of apt's resolver was to make that no longer necessary, but that's another
rant for another week.

You literally must reinstall the packages to rebuild the database or apt
will not know what files are installed (rebuildable with the contents file
and a good script or two) or the pre and post scripts, debconf
information, etc..


Just in case you need it said:  BACKUP BACKUP BACKUP!  I have ... uh, 1082
packages installed here personally and together they total enough space
that rebuilding the database by reinstalling the packages would be a very
painful experience.  In fact, it happened once (thank you ext2 and DRI, I
much appreciated that..) and as the system was recently installed I had no
backup yet.  It took me all night on a DSL line, so I pity anyone with
just a modem.

-- 
Joseph Carter <[EMAIL PROTECTED]>Free software developer

The less you know about computers the more you want Microsoft!
-- Microsoft ad campaign, circa 1996

(Proof that Microsoft's advertising _isn't_ dishonest!)



pgpu6GEOZQrME.pgp
Description: PGP signature

Re: kernel-{image,headers} package bloat

[Rahul Jain]

On Sun, Apr 22, 2001 at 12:09:12AM -0500, David Starner wrote:
> On Sat, Apr 21, 2001 at 09:28:02PM -0500, Rahul Jain wrote:
> > Unless you care about performace. Which is the main reason to use different
> > packages for each CPU type.
> 
> I compile my own kernels, and have for a long time. But it's a pain
> to go through all the poorly-documented options and takes quite a
> while to select those options and actually build a kernel. And then
> there's the times I have to go back and recompile because I left out
> my mouse drivers, or ide-scsi, or vfat. It's entirely rational to
> want to pick up the 10% improvement from hitting the right button in
> dselect and not worry about the 20% from recompiling the kernel. 

use the distro kernels' config as a starting point.

-- 
-> -/-   - Rahul Jain -   -\- <-
-> -\- http://linux.rice.edu/~rahul -=- mailto:[EMAIL PROTECTED] -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--||--||-|--|-|-|-|
   Version 11.423.999.220020101.23.50110101.042
   (c)1996-2000, All rights reserved. Disclaimer available upon request.

Re: kernel-{image,headers} package bloat

[David Starner]

On Sat, Apr 21, 2001 at 09:28:02PM -0500, Rahul Jain wrote:
> Unless you care about performace. Which is the main reason to use different
> packages for each CPU type.

I compile my own kernels, and have for a long time. But it's a pain
to go through all the poorly-documented options and takes quite a
while to select those options and actually build a kernel. And then
there's the times I have to go back and recompile because I left out
my mouse drivers, or ide-scsi, or vfat. It's entirely rational to
want to pick up the 10% improvement from hitting the right button in
dselect and not worry about the 20% from recompiling the kernel. 

For a comparison: Remember the libc-i686 packages? I had them
installed when they were available. I can compile my own libc - it
probably wouldn't take more than 10 minutes to find the right switch
to frob, and then compiling time. But I haven't, even for a speed-up
that maybe as big as what the kernel will give you, and I would
reckon that most of the other people that had the libc-i[56]86
packages installed haven't either. It's analogous to the kernel
problem. 

-- 
David Starner - [EMAIL PROTECTED]
Pointless website: http://dvdeug.dhis.org
(K) 3141 All Rights Reversed