Re: Disappearing task-* packages!
On Tue, Sep 25, 2001 at 01:04:12PM -0500, Taral wrote: All the task-* packages seem to be missing from the main Packages file! Where did they go? the dumpster. P.S. If this was announced, perhaps the announcement should have gone to the debian-devel-announce list? its been discussed in various places. task- packages are a ugly kludge that have been replaced by a proper implementation: the Task: feild of the control file, the new tasksel uses this now instead of task- packages. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpKbCLNHL3z4.pgp Description: PGP signature
Re: XFS Kernel image packaging
On Tue, Sep 25, 2001 at 10:23:34PM -0700, David wrote: At this time being, there's no official XFS kernel images nor patches in Debian, however there is xfsprogs as far as I know in Woody Sid. I am willing to work on an XFS kernel floppy boot disk, but it would be pointless cine a kernel image with XFS is bloated by about 300K if I'm not mistaken, at least the ones on some of the machines I put XFS into. There are Reiserfs images avaiable however. I certainly would like to get a hold of some XFS based install disks if anyone ever has done any with success. fwiw current cvs boot-floppies (and 3.0.14) support XFS (as well as ext2, ext3, and reiserfs). if you boot with a kernel capable of any of these filesystems and have the corresponding mkfs utility on the root disk the filesystem will be offered as an option. if you were insane enough to get a kernel supporting all of ext2, ext3, xfs, and reiserfs and had all the mkfs utils you would be offered a choice between all 4. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpirMoQI66kv.pgp Description: PGP signature
Re: Mounts with fs type 'none'
On Wed, Sep 26, 2001 at 06:15:34PM -0500, Steve Greenland wrote: I've a request to have checksecurity skip searching filesystems with type 'none' (not device 'none'). A brief check leads me to believe that these are result of mount --bind, which means that the mount in question correct, mount --bind is just a shortcut for: mount -t none -o bind /somewhere /some/where/else -- Ethan Benson http://www.alaska.net/~erbenson/ pgpJ94Db6avqu.pgp Description: PGP signature
Re: Mounts with fs type 'none'
On Wed, Sep 26, 2001 at 06:53:54PM -0500, Steve Greenland wrote: Thanks. Does anything else use '-t none'? i don't know, not that i know of, but i wouldn't rule it out in the future given `none' is pretty generic. (And why does mount(8) document '--bind' but not '-t none' or '-o bind'?) i don't know that either.. i prefer the latter since its standard usage of mount, it also makes it more clear that something like this in /etc/fstab will (and does) work as expected: /tmp/var/tmpnonebind0 0 -- Ethan Benson http://www.alaska.net/~erbenson/ pgpUDvD8DPNqK.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On Sat, Sep 22, 2001 at 05:39:20PM +0200, Bernhard R. Link wrote: * Richard Atterer [EMAIL PROTECTED] [010922 16:26]: One idea: In a configuration file, the user lists those daemons he wants to run chrooted. init.d scripts that support it read this information and act on it, copying the required files to a chroot before starting the daemon there. (The config file should probably not be read directly, instead the init.d script should call a small query script. That way, file format changes are possible.) Help, please no. More supports for chroots may be nice. But not this way! init.d-scripts calling scripts, that parse global config files is ugly and one of the many points to make people switch from Suse or Redhat to debian. very much agreed. And why should there be an global config file for all daemons? Beeing chrooted is an quite personal thing for every package. Why should an daemon that run chroot (and there are not that many, that can can be run there) parse a file which is of no interest for him but for the other daemons? yes the proper way is usually /etc/default/package which has config variables for the initscript, such as CHROOT=yes -- Ethan Benson http://www.alaska.net/~erbenson/ pgpMr4lCrK712.pgp Description: PGP signature
Re: Purposely broken/uninstallable packages in archive
On Thu, Sep 20, 2001 at 09:58:16AM -0400, Norbert Veber wrote: If its not to be installed, it should not be in the archive. This is like going to a restaurant and being told not to eat a certain dish under any circumstances because you'll get food poisoning.. :) Clearly these pacakges are 'data' files, and should be treated as such. They could just as easily be .tar files (or any format, including .deb) inside of an INSTALLABLE .deb.. do you want boot-floppies or not? because that won't work with boot-floppies. until the next release after woody when debian-installer may become viable you have to live with these -bf packages as they currently exist. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpxi2U3XK3cG.pgp Description: PGP signature
Re: Purposely broken/uninstallable packages in archive
On Wed, Sep 19, 2001 at 11:01:24AM -0400, Norbert Veber wrote: packages such as diskless-image-secure, diskless-image-simple, xfsprogs-bf, e2fsprogs-bf should automatically qualify for grave or even critical bugs for breaking your system if installed. read the description for xfsprogs-bf and e2fsprogs-bf, your NOT SUPPOSED to install them. we need them for boot-floppies. with at least the -bf packages the user has to explicity type `yes please wreck my system' or something like that into apt before it will proceed, if they are that determined to shoot thier own foot, let them. -- Ethan Benson http://www.alaska.net/~erbenson/ pgp6ddkqrcUEp.pgp Description: PGP signature
Re: unable to stat `./usr/share/man/man3/qcanvas.3qt.gz' (which I was about to install): Value too large for defined data type
On Mon, Sep 10, 2001 at 10:37:48PM -0700, Karl M. Hegbloom wrote: [EMAIL PROTECTED]:~ % ls -l /usr/share/man/man3/qcanvas.3qt.gz -rw-r--r--1 root root 16787680395758934842 Aug 23 11:14 /usr/share/man/man3/qcanvas.3qt.gz Wow, huh!? WTF? [EMAIL PROTECTED]:~ % df -h /usr/share/man/man3/ FilesystemSize Used Avail Use% Mounted on /dev/hda3 27G 20G 7.6G 72% / mount shows: /dev/hda3 on / type reiserfs (rw) might i suggest XFS, or even ext2. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpnnN9ntDbmw.pgp Description: PGP signature
Re: root rm: Permission denied (Was: unable to stat `./usr/share/man/man3/qcanvas.3qt.gz')
On Tue, Sep 11, 2001 at 01:24:56PM +0200, Tille, Andreas wrote: On Tue, 11 Sep 2001, Wichert Akkerman wrote: Corrupted filesystem, unlink that file and try again. Hmmm, I have also a relict of older ReiserFS (from 2.4.4 or so) on my HD (I´m so happy that I didn´t used it on a critical box and perhaps never will do so ...): /var/lug# whoami root /var/lug# unlink postgres.log.7.gz unlink: unlinking `postgres.log.7.gz': Permission denied /var/lug# rm -f postgres.log.7.gz rm: cannot remove `postgres.log.7.gz': Permission denied i would suggest the immutable flag, but AFAIK reiserfs has no such thing. thats the only time ive ever seen root denied permission to do such things (other then /proc..). sure someone isn't playing a joke on you and replaced /bin/su with fakeroot ;-) -- Ethan Benson http://www.alaska.net/~erbenson/ pgpvrUpfPtgc8.pgp Description: PGP signature
Re: reopening ECN bugreport/netbase
On Wed, Sep 05, 2001 at 04:32:42PM +0200, Tomas Pospisek wrote: ) then it's the kernel-image package that needs to make sure it's runing in a sane environment. So *please* can we add something like: if ! grep /proc/sys/net/ipv4/tcp_ecn /etc/sysctl.conf /dev/null; then echo sys/net/ipv4/tcp_ecn=0 /etc/sysctl.conf fi to the kernel-image-2.4.x postinst. no you cannot. that is a policy violation and will get a severity serious bug report to have it removed if its ever added. /etc/sysctl.conf is a conffile belonging to procps NO package may modify it in maintainer scripts. since sysctl will produce errors at boot if this is added to the default sysctl.conf that is not acceptable either. furthermore if you simply installed a 2.4 kernel but decided not to boot it, or decided to go back to 2.2 you start getting errors at boot again. since aj won't add anything to netbase the admin will simply have to turn off ecn themselves. thats the only option. -- Ethan Benson http://www.alaska.net/~erbenson/ pgprCsGk5u9zP.pgp Description: PGP signature
Re: reopening ECN bugreport/netbase
On Wed, Sep 05, 2001 at 06:02:10PM +0200, T.Pospisek's MailLists wrote: So since netbase does not want to be the proper place, a better fix/workaround (I'm sincerely trying hard not to be ironic!) would be to use debconf with a default value of 0 and to inform/ask the user about it when installing a new kernel. and store/implement it where? /etc/sysctl.conf is unacceptable as its a conffile belonging to procps. and personally i don't want /etc/sysctl.conf to become another debconf [mis]managed config file. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpWnoX2DI0RN.pgp Description: PGP signature
Re: Bug#111158: Kernel 2.4.5+ network timeouts
On Tue, Sep 04, 2001 at 11:59:25AM +0200, Francesco P. Lovergine wrote: Ok, after some times with /proc/sys/net/ipv4/tcp_ecn set to 0, it worked. Anyway I strongly suggest to modify this setting ASAP in procps. Moreover this is required only for kernel 2.4.5+ (why? if its to be set anywhere it should be in netbase NOT procps. if you put it in /etc/sysctl.conf every default debian system will output an error on boot: error: 'net/ipv4/tcp_ecn' is an unknown key remember the default kernel in woody is 2.2, not 2.4. there should be a new option added to /etc/network/options just like the current syncookies option. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpdcJlLCjCrr.pgp Description: PGP signature
Re: How many people need locales?
On Mon, Sep 03, 2001 at 12:55:53PM +0200, Jean-Marc Chaton wrote: - It is clumsy to have to answer : No, keep the modified version each time the package is updated. that only happens if the file in the package has changed from the installed version of the package. that is if etc/locale.gen in locales 2.2.4-1 is the same as the one in 2.2.4-2 you will NOT be asked to replace your modified /etc/locale.gen. that leaves the question to: how often is the default locale.gen file altered in locales? i would guess not all that often, therefore your not going to be asked about it very often. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpaj56BYr3S8.pgp Description: PGP signature
Re: sysctl should disable ECN by default
On Sun, Sep 02, 2001 at 05:56:45PM +0200, Goswin Brederlow wrote: I think that should be refiled against kernel-image-2.4.x. Those, since they have the flag enabled, should warn about it and turn it off in /etc/sysctl.conf upon first install (not on update, so you can delete the option). Or just ask via debconf. no package is permitted to modify /etc/sysctl.conf. its a conffile belonging to procps, anything (except the admin) modifying it should receive a severity serious bug report. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpNGXvwRWTuS.pgp Description: PGP signature
Re: [FLAME WARNING] Linux Standards Base and Debian
On Wed, May 09, 2001 at 12:26:35PM +0200, Marcus Brinkmann wrote: I think it makes more sense for the LSB to define an intersection of required features, and use only that for their stuff. Then other people can easily implement this minimal interface or convert to/from it. The LSB doesn't need the full power of a complex packaging system, and it is unlikely they would get it right without really using it. i don't think it doesn't really makes any sense for them to comment on packaging systems anyway. the only reason i can see (and has been mentioned) for it is proprietary developers. i personally think proprietary stuff should just go in /opt. proprietary devs almost invariably horribly ignore the FHS or anything resembling *nix filesystem standards anyway.. so i say hell with it tell them to put all thier junk in /opt/prog and perhaps require a wrapper script suitable for installation in /usr/local/bin that properly runs the software. if they did this packaging systems don't even enter into it, the developer just ships a tar.gz to be unpacked in /opt, simple. or better yet, don't use non-free software ;-) IMNSHO, it should be up to the distribution makers to do packaging, not upstream as its usually not thier specialty and thus they often end up making a crappy package. standard or not i think this will always be the case. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpOxtWHvUj1l.pgp Description: PGP signature
Re: [FLAME WARNING] Linux Standards Base and Debian
On Wed, May 09, 2001 at 01:08:21PM -0400, Albert den Haan wrote: The LSB's LCD (Lowest Common Denominator) is working on a simple package system that is the *intersection* of capabilities the major ones in current use. Yes the RPM V3 [1] package archive file format is being used (as *.lsb files), but to handle data dpkg both requires and will not choke on. [snip] [1] Note that this archive file format is understood by both the rpm V3 and V4 programs. may i suggest you use a more generic format? .debs are nothing more then an ar archive containing a couple gzipped tarballs. they can extracted on virtually any system, regardless of OS even. this is a tremendous advantage IMO, both because for example slackware need not put rpm into thier distro, and more importantly for recovery purposes. it can be a life saver to be able to quickly extract a package on a badly hosed system. (lets say a bout of filesystem corruption wipes out /bin/rpm) and yes i have had this type of thing happen before. debian's human readable and editable package database, and open and standard ar+tar+gzip package format saved me from a reinstall. this choice of using the rpm binary format should be reconsidered IMNSHO. i don't really care whether you use the debian ar+tar+gzip, or just plain .tar.gz, just use something i can extract *anywhere* with the most basic and standard tools, without having to go and compile rpm or some rpm archive extracter. -- Ethan Benson http://www.alaska.net/~erbenson/ pgp2X5SmAI0vs.pgp Description: PGP signature
Re: [FLAME WARNING] Linux Standards Base and Debian
On Wed, May 09, 2001 at 05:47:00PM -0500, Sam TH wrote: On Wed, May 09, 2001 at 02:14:20PM -0800, Ethan Benson wrote: this choice of using the rpm binary format should be reconsidered IMNSHO. i don't really care whether you use the debian ar+tar+gzip, or just plain .tar.gz, just use something i can extract *anywhere* with the most basic and standard tools, without having to go and compile rpm or some rpm archive extracter. RPM is just a cpio archive. Or at least that was my impression. So GNU cpio should work just fine. people love to say that, but it simply isn't true. i have never been able to use cpio to extract an rpm except by putting the rpm through rpm2cpio first. ar tar and gzip are extractable EVERYWHERE, even non-GNU systems. -- Ethan Benson http://www.alaska.net/~erbenson/ pgp6SFVJ3zkcS.pgp Description: PGP signature
Re: [FLAME WARNING] Linux Standards Base and Debian
On Wed, May 09, 2001 at 06:32:14PM -0400, Timothy H. Keitt wrote: Its been a while, but if I remember correctly, RPMs are in cpio format. no there not, they are in a goofed up customized cpio format that cpio no longer recognizes. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpSK7KOzXcqF.pgp Description: PGP signature
Re: [FLAME WARNING] Linux Standards Base and Debian
On Wed, May 09, 2001 at 05:44:17PM -0500, Steve Langasek wrote: On Wed, 9 May 2001, Timothy H. Keitt wrote: Its been a while, but if I remember correctly, RPMs are in cpio format. $ cpio -idv -F gnocatan-client-0.6.1-2.alpha.rpm cpio: warning: skipped 61098 bytes of junk cpio: warning: archive header has reverse byte-order cpio: [binary garbage output snipped]: unknown file type cpio: premature end of file ... apparently not... exactly RPMs are in fact based on the cpio format, but I think they stick their own header on the front of the file -- the only way I've ever seen cpio handle the contents of an RPM is after passing the RPM through the rpm2cpio utility. a few weeks ago i was chatting with a yellowdog employee who for some reason needed to extract a .rpm raw rather then via rpm. he could extract normal cpio files just fine, but no matter what could not get the rpm extracted. i kept telling him the `rpm is cpio' thing just isn't true but he still felt the need to fsck around with it and reread all the cpio docs for over an hour until he finally took my word for it and used rpm2cpio. based on cpio is a far cry from BEING a cpio archive. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpKEg8ZiZOog.pgp Description: PGP signature
Re: Does BTS clean old bugs?
On Sun, May 06, 2001 at 03:00:56PM +0300, Eray Ozkural (exa) wrote: On the bts web interface, it's written that closed bugs are cleaned up after a period of inactivity. Are they permanently erased? I'd prefer that a complete history of all bugs is preserved. they are archived. thats what the `search archived bugs' option in the search page is for. it would be quite a mess if bugs were listed on packages for eternity after they are closed. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpIaPrppsOaj.pgp Description: PGP signature
Re: chroot bind?
On Wed, May 02, 2001 at 04:52:23PM +1200, Nicholas Lee wrote: Note though that in the mailing list there has been a little dis-content about /svr vs /var, etc etc. So it might not finalise for 2.2. Anyway, given the wording of FHS 2.2 S3.17 I figure /svr/domain would be a FHS-complinate location for a chroot domain server. this would be somewhat annoying since / is small and contained on many systems, adding /svr means either an extra partition, or symlinking it somewhere else. i can see why there is dis-content (or was there some other complaint?). /var/svr would make more sense IMO. / has enough already. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpzKTBOmogXj.pgp Description: PGP signature
Re: debbugs can now send bug mails to someone different than the maintainer
On Mon, Apr 30, 2001 at 02:36:21AM -0400, Matt Zimmerman wrote: Unless, of course, you can do your filtering on the mail server, as I do. and how many isps allow this? -- Ethan Benson http://www.alaska.net/~erbenson/ pgpnnXUWcAbZ4.pgp Description: PGP signature
Re: updating of /etc/rc?.d
On Mon, Apr 23, 2001 at 11:56:45PM -0700, Erik Hollensbe wrote: I was wondering how possible it would be to considering adding to the policy that a single runlevel's symlinks be left out of updating from packages. After running an update of 200+ packages or so, all the rc?.d directories are re-polluted with symlinks i've destroyed. This is a big problem on my workstation, where I may only want mysqld up for a few hours while I check something, for example. if you leave at least one symlink in at least one runlevel, even if its a K link in runlevel 0 or 6 update-rc.d will refuse to add any new links. policy requires the use of update-rc.d so packages can't add any links so long as you leave at least one. if you find a package that does otherwise thats a bug. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpraRgfTyidx.pgp Description: PGP signature
Re: FYI: dh_upx compresses i386 executables
On Tue, Apr 24, 2001 at 01:14:36PM +0100, Colin Watson wrote: Ethan Benson [EMAIL PROTECTED] wrote: On Sun, Apr 22, 2001 at 09:00:13AM -0400, Itai Zukerman wrote: 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 Not if UPX were to be an option for all binaries. Having to add stuff to every package's postinst is evil (see /usr/doc, although that was necessary). ok, then have the upx package ask if the admin wants to compress /* it seems there is only a few ways to do this: 1) add crap to postinst. -- evil 2) packages just compress at build time -- beyond evil, don't even think about it. 3) add all the questions/compression tasks to the upx package itself. option 3 seems to be the only semi sane/non-evil way. -- Ethan Benson who personally finds the idea of upx hideous. http://www.alaska.net/~erbenson/ pgp5C4lPHa5tw.pgp Description: PGP signature
Re: FYI: dh_upx compresses i386 executables
On Tue, Apr 24, 2001 at 09:14:41AM -0400, Itai Zukerman wrote: It seems to me that each maintainer should make the decision of whether she wants UPX to apply to any of her binaries. And the easiest way to do that, IMO, is to have her add [ -x install-upx ] install-upx /usr/bin/foo /usr/bin/bar to her postinst or fine dh_upx to her rules. /usr/doc was evil for a number of reasons other than NO! this would absolutly suck. that leaves the admin in the position to have to rebuild the package or fsck with decompression every time the package is upgraded to get a fulltime normal non-upx binary if they don't want this crap. You seem to want *all* binaries compressed. I'm suggesting that some binaries are best left uncompressed, and that that would be the maintainer's decision. and more importantly the admins' decision. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpBUqqTYemzA.pgp Description: PGP signature
Re: kernel-{image,headers} package bloat
On Mon, Apr 23, 2001 at 06:27:30AM +, Andreas Metzler wrote: [...] 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 Hello! This seems to scream to me to simply split the common files out to a new package. kernel-headers-2.4.2-common Am I missing something? tia, cu andreas that was my first thought, then i realized, how do you know whats different? you can't keep a static list of files/directories to grab since its almost certain to change with new kernels. i suppose you could modifiy make-kpkg to save an ls -R or something to a file and compare afterwords but that seems gross and perhaps unreliable. its just not as trivial as it sounds i don't think. -- Ethan Benson http://www.alaska.net/~erbenson/ pgp474GbYTWez.pgp Description: PGP signature
Re: chroot bind?
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: FYI: dh_upx compresses i386 executables
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
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: chroot bind?
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: chroot bind?
[ 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: What to do about /etc/debian_version
On Sat, Jan 06, 2001 at 01:49:59PM +0100, Marco d'Itri wrote: On Jan 06, Joey Hess [EMAIL PROTECTED] wrote: [EMAIL PROTECTED]:/tmpmount -o loop foo 1 Why don't we just patch mount to use /var/run/mtab? I don't know about any other program which modifies it. because /var is not always on the same partition as / -- Ethan Benson http://www.alaska.net/~erbenson/ pgpCm5HRdFdRO.pgp Description: PGP signature
Re: bugs + rant + constructive criticism (long)
On Thu, Jan 04, 2001 at 12:41:24AM -0500, Adam McKenna wrote: as for including other's in the Mail-Followup-To mutt only does this if those users had used `lists' instead of `subscribe' indicating they WANT to be CCed. There must be a bug in it somewhere, then, because I often see people getting added to Mail-Followup-To that shouldn't be there. In fact, I personally have been added to Mail-Followup-To by other Mutt users, and I don't use the lists command at all. in that case there would be something funny going on, here is my theory: you post to list, you M-F-To: is set to only the list someone (Mr-Broken) with broken mailer uses reply-to-all which CCs you anyway ignoring M-F-To. mutt user uses list-reply to Mr-Broken's post, mutt sees you were CCed and assumes you should be included since there is no M-F-To header. mutt then sets the M-F-To header to include you for the benifit of later list-replies. if this is the case the solution is fixing broken mailers, many of them are Free software so why have patches to support M-F-To not been made? -- Ethan Benson http://www.alaska.net/~erbenson/ pgpqtpqwUSa94.pgp Description: PGP signature
Re: bugs + rant + constructive criticism (long)
On Thu, Jan 04, 2001 at 01:18:40AM -0500, Adam McKenna wrote: if this is the case the solution is fixing broken mailers, many of them are Free software so why have patches to support M-F-To not been made? I'd like to see someone convince that M-F-To fix Pine. But I doubt you'll have an easy time getting Crispin to apply a patch. He won't even implement maildir, for christ sake, and patches for that have been around for over 2 years now. pine is a lost cause anyway. i was thinking of GNUs which seems to be the other big offender of ignorage of M-F-To. (i am not sure if it respects Mail-Copies-To: never i just started adding that.) btw is it Mail-Copies-To: never or Mail-Copies-To: nobody ? i have seen both which is correct? (assuming any MUA actually pays any attention to this header anyway) -- Ethan Benson http://www.alaska.net/~erbenson/ pgpGg3g9t1U7S.pgp Description: PGP signature
Re: our broken man package
On Wed, Jan 03, 2001 at 03:23:03PM -0800, Joey Hess wrote: I'm concerned with some breakage in the man program. Here is an example: [snip examples] This is because man runs via a wrapper that makes it run as user man (and makes root's pager run as user man too for some reason). Related bugs: #74790, #60084, #58112, #42128. 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. 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) -- Ethan Benson http://www.alaska.net/~erbenson/ pgp1CiH8rxzJQ.pgp Description: PGP signature
Re: our broken man package
On Wed, Jan 03, 2001 at 11:53:37PM -0800, Joey Hess wrote: Ethan Benson wrote: 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. I'll bet (have not verified) that you can already trick it into writing bogus file by sticking trojan pages elsewhere in your manpath. i just tried it, did not end up with a cached file. [EMAIL PROTECTED] eb]$ export MANPATH=/home/eb/test [EMAIL PROTECTED] eb]$ find /var/cache/man -name 'bogus*' [EMAIL PROTECTED] eb]$ ls -l /home/eb/test/man8/ total 8 -rw-r--r--1 eb eb 5193 Jan 3 23:03 bogus.8 [EMAIL PROTECTED] eb]$ man bogus Reformatting bogus(8), please wait... ... [EMAIL PROTECTED] eb]$ find /var/cache/man -name 'bogus*' it also doesn't cache anything when pointing man directly at a specific man page: [EMAIL PROTECTED] eb]$ find /var/cache/man -name 'yaboot*' [EMAIL PROTECTED] eb]$ man devel/ybin/man/yaboot.8 Reformatting yaboot.8, please wait... ... [EMAIL PROTECTED] eb]$ find /var/cache/man -name 'yaboot*' [EMAIL PROTECTED] eb]$ and yes my caching does work as you can see for a normal man page: [EMAIL PROTECTED] eb]$ man yaboot Reformatting yaboot(8), please wait... ... [EMAIL PROTECTED] eb]$ find /var/cache/man -name 'yaboot*' /var/cache/man/cat8/yaboot.8.gz -- Ethan Benson http://www.alaska.net/~erbenson/ pgpKKDIEKxmZF.pgp Description: PGP signature
Re: bugs + rant + constructive criticism (long)
On Thu, Jan 04, 2001 at 02:48:46AM -0600, Manoj Srivastava wrote: That just demonstrates you have no idea what you are talking about. oh please. someone already pointed out to me that older versions of Gnus ignored M-F-To but the current one does not. go fuck off. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpBNlHDjb9vb.pgp Description: PGP signature
Re: bugs + rant + constructive criticism (long)
On Thu, Jan 04, 2001 at 03:34:26AM -0600, Manoj Srivastava wrote: You prove my point. Resorting to invective is the last refuge of the incompetent. This is your second demonstration of incompetence in a public forum in 24 hours; and I suspect your drop in the estimation of the readers of this mailing list is far worse than any response in kind I could indulge in. if only we could all be as perfect as you. I has simply made the statement that Gnus users were commonly ignoring M-F-To and rather then kindly point out that old versions did but the current one no longer has this problem like another poster did you had to be insulting and condescending. well i returned the favor. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpBzEHyz3hjA.pgp Description: PGP signature
Re: our broken man package
On Thu, Jan 04, 2001 at 07:14:13PM -0800, Joey Hess wrote: Here's one more real fun one. This only works if you are root and /root is mode 700 and $TMP is set to /root/tmp/: [EMAIL PROTECTED]:~man man man: can't create a temporary filename: Permission denied So incredibly broken.. here is one that is even more fun as works for any user: [EMAIL PROTECTED] /tmp]$ ls -ld . drwxrwxrwt6 root root 2048 Jan 4 20:33 . [EMAIL PROTECTED] /tmp]$ cp /usr/share/man/man1/ls.1.gz . [EMAIL PROTECTED] /tmp]$ ls -l ./ls.1.gz -rw-r--r--1 eb eb 2271 Jan 4 20:34 ./ls.1.gz [EMAIL PROTECTED] /tmp]$ man ./ls.1.gz ./ls.1.gz: No such file or directory man: can't remove /tmp/zmanZNdPIa: No such file or directory [EMAIL PROTECTED] /tmp]$ gunzip ls.1.gz [EMAIL PROTECTED] /tmp]$ man ./ls.1 Reformatting ls.1, please wait... ... [EMAIL PROTECTED] /tmp]$ this one is the wrapper's fault, it does a chdir() somewhere and then gzip doesn't find the page (since it gets a relative pathname). -- Ethan Benson http://www.alaska.net/~erbenson/ pgpkyqZNkMlCj.pgp Description: PGP signature
Re: bugs + rant + constructive criticism (long)
On Wed, Jan 03, 2001 at 02:26:33PM -0500, Adam McKenna wrote: Not exactly. List-reply sends a reply to the list and any other people listed in Mail-Followup-To. The thing that bugs me about this is that mutt often adds other list-readers' e-mail addresses to Mail-Followup-To, effectively rendering this feature useless. try reading the FM. in mutt 1.2 and later (also some 1.1 versions) the lists command causes both your address and the lists address to the Mail-Followup-To. the subscribe command on the other hand ONLY includes the list's address and NOT your own. as for including other's in the Mail-Followup-To mutt only does this if those users had used `lists' instead of `subscribe' indicating they WANT to be CCed. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpaK7nUjHzUw.pgp Description: PGP signature
Re: looking for replacement for run (because of critical bug in
On Tue, Dec 26, 2000 at 12:26:10PM +0100, Christian Kurz wrote: Well, this is a feature that tail on FreeBSD has. If you start it with -F, it will tail you the current file like our tail -f. But if know the logfile will be rotated, it will notice this and reopen the new current one and tail this one. This is a feature that I really miss in GNU tail. in fact GNU tail does have this feature, its just done a bit differently: tail --follow=name --retry /var/log/messages ive been using this for ages without any problems, works quite nicely with log rotation, tail just outputs a message saying the file has been replaced, and follows the new one. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpg3TAN5txVY.pgp Description: PGP signature
Re: What do you wish for in an package manager?
On Sun, Dec 24, 2000 at 09:52:47AM +0100, Sami Dalouche wrote: Hi guys, So my question is: What do you wish for in a package manager? I agree with Ethan. Start explaining why you want to reinvent the wheel then we maybe has some ideas for things to do when you reinventing for other reasons. If I had to change something in the Debian package manager, I would like it to use bzip2 instead of gzip, but this doesn't need a omplete reimplementation. The problem isn't technical, but it's been its quite trivial on the level of the packaging system and format, simply put a .tar.bz2 in the ar archive instead of a .tar.gz debated many times. I don't exactly know the problem w/ this compression except it saves time ;) Anyway, if you think something isn't perfect, you can always help the development of Dpkg, or apt. i think the problem is supporting older machines such as 486s. bzip2 is horridly slow on this hardware. and iirc bzip2 takes more memory (or its slower the less memory you have...) since its been discussed before thats all ill say about the subject. -- Ethan Benson http://www.alaska.net/~erbenson/ pgplMCcQvE8zY.pgp Description: PGP signature
Re: What do you wish for in an package manager?
On Sun, Dec 24, 2000 at 02:21:51PM -0500, Joseph Carter wrote: On Sun, Dec 24, 2000 at 09:52:47AM +0100, Sami Dalouche wrote: If I had to change something in the Debian package manager, I would like it to use bzip2 instead of gzip, but this doesn't need a omplete reimplementation. The problem isn't technical, but it's been debated many times. I don't exactly know the problem w/ this compression except it saves time ;) Anyway, if you think something isn't perfect, you can always help the development of Dpkg, or apt. I think if dpkg used some sort of hashed database index it would be a hell of a lot nicer to people's CPUs and memory. Whether or not that requires a re-implemenetation of dpkg or not isn't for me to say since I haven't looked at dpkg's code in 3 years. personally the plain text database is one of dpkg's greatest assets. its a royal pain to repair a binary database when it gets fscked. and yes i have already been saved from a total reinstall through the ability to fix dpkg's broken database with a text editor. if your talking about a different database then nevermind. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpyymQq7oXuH.pgp Description: PGP signature
Re: NSA's Secure Linux Distribution
On Fri, Dec 22, 2000 at 05:36:14PM -0500, Jacob Kuntz wrote: but what fact are these fears based in? would the nsa really plop a backdoor in an opensource project, hoping it missed and accepted with the rest of the code? i doubt it. their whole (advertised) motive was to protect against the possibility of Trusted (AIX|Solaris|PalmOS|whatever closed os) going belly up. Hi, I'm from the government, I'm here to help you. -- Ethan Benson http://www.alaska.net/~erbenson/ pgp6FbsCU6pA4.pgp Description: PGP signature
Re: What do you wish for in an package manager?
On Sat, Dec 23, 2000 at 10:47:00PM -0600, Dwayne C . Litzenberger wrote: Hello! I'm starting work on a new linux package manager. The idea is to be able to replace rpm, dpkg, apt, dselect (backend) with one,written mostly from scratch and designed to be as simple (code, not features) and clean as possible. For now, the work will be strictly academic, but if it works out, it may evolve into future standard package manager. So my question is: What do you wish for in a package manager? the debian packaging system answered most things i want from a packaging system. what exactly is missing/wrong with the debian packaging system that makes you feel the need for wheel reinvention? -- Ethan Benson http://www.alaska.net/~erbenson/ pgp6VFfxPZxrY.pgp Description: PGP signature
Re: OT Re: /bin/ksh as a default POSIX shell
On Wed, Sep 06, 2000 at 03:34:39AM -0500, Branden Robinson wrote: gpg: CRC error; 72a653 - dc372a gpg: quoted printable character in armor - probably a buggy MTA has been used This concerns me a lot more than the joke itself or what led up to it. Does anyone else have this problem with that mail? You don't have to be able to decrypt the message to see if the ASCII armoring has been borked. i had copied and pasted (gpm on console) the text into gpg and recieved no error except that i lacked the necessary private key to decrypt the message. i have mutt set to autoverify signatures, it verified your signature fine, and displayed the encrypted block as the message text (mutt ignored it) If mutt is hosing up my mails I'm gonna be mondo pissed. If my MTA (postfix) or murphy's MTA (still qmail?) is hosing up my mails I'm gonna be mondo pissed. i am using mutt 1.0.1-9, postfix, fetchmail and procmail for the entire mail setup. In fact, I'm gonna be mondo pissed no matter whose bug this is, let's try and track it down. When I discovered that fetchmail was mangling GPG mails a year or so ago, I had a thrombosis about it. maybe he was using one of those broken MUAs that don't understand RFC 2015? -- Ethan Benson http://www.alaska.net/~erbenson/ pgpkigoy52ZFa.pgp Description: PGP signature
Re: X and runlevels
On Mon, Sep 04, 2000 at 10:32:07AM +0200, Per Lundberg wrote: (Sorry if this has been discussed earlier, and/or this is the wrong list...) How come Debian don't have a non-X runlevel, like some other distributions, in the default configuration? I think this would be pretty convenient. perhaps because in the default configuration there is no display manager, and thus no automatic runage of X. also debian believes in leaving the runlevel configuration to the admin to define. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpIC6edoyEDt.pgp Description: PGP signature
Re: X and runlevels
On Mon, Sep 04, 2000 at 11:30:06AM +0200, Per Lundberg wrote: EB == Ethan Benson [EMAIL PROTECTED] writes: EB perhaps because in the default configuration there is no EB display manager, and thus no automatic runage of X. Sure. But whenever you install something that gets you a display manager, your system will boot up in X. To get it to boot up in is that not what you wanted when you installed *dm ? console mode, you have to manually remove the symlinks in your runlevel's script directory. The next time you update the display manager, you'll have to do this again. It is not really convenient. no there not, the symlinks are only restored if ALL of them were removed (that is your removed the link from runlevel 0 - 6) and if you did that why not just apt-get --purge remove *dm ? at least that is how update-rc.d works on all 5 debian systems i work with. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpToRWUOqvmi.pgp Description: PGP signature
Re: X and runlevels
On Mon, Sep 04, 2000 at 11:43:35AM +0200, Per Lundberg wrote: Maybe, but having the option to get into console mode too would be nice. Sometimes, you might not want X to start up when you reboot. (I don't do this very often, but I know there are people that do) the key is not everyone does it the same way, i personally used to, then realized i *NEVER* booted the system into a different runlevel to avoid X and quit bothering, i am fine with it. there are other software that i do tinker with the symlinks. (*cough* portmap) the thing is debian LETS me. it leaves the decision where it belongs with me. EB no there not, the symlinks are only restored if ALL of them EB were removed Are you *absolutely* sure? The reason I ask is because I've been /me checks, yup im sure. having this exact problem with gpm lately. I like to start it occasionally, because it interfers with my X configuration, so I use to remove the symlinks. Each and every time gpm is updated (two times the last week), they have been brought back to life. Pretty annoying, if you ask me. if that is true (and your only removing SOME of the symlinks not ALL of them) then its a bug and should be filed in the BTS. that is NOT how it is supposed to work. from the update-rc.d man page: If any files /etc/rcrunlevel.d/[SK]??name already exist then update-rc.d does nothing. This is so that the system administrator can rearrange the links, provided that they leave at least one link remaining, without having their configuration overwritten. (This is a woody system) i have a field of potatoes so maybe there is a new bug in woody. either that or gpm is being evil and making the symlinks itself instead of using update-rc.d like its supposed to. also you mean that the symlinks are recreated, not just gpm being restarted right? there is an obnoxious behavior in debian where upgraded packages are started even if they were not running in the first place. (*cough* portmap *cough*) there was a bit of discussion on fixing this but i don't know if its being worked on actively or not. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpGe0PalLsBj.pgp Description: PGP signature
Re: X and runlevels
On Mon, Sep 04, 2000 at 12:48:24PM +0100, Anton Ivanov wrote: [snip] Isn't ctrl-alt-F[1-6] good enough to get into console mode? In what circumstances whould you not want X to start up on boot if you had installed a *dm? In the circumstance when you are serving a flock of dumb clients from a single machine. NCD Xterms for example. In this case you *NEED* a *dm running with network access turned on but the machine itself may not even have a video. This setup is a small percentage of the installed base but it does exist and is used. except this configuration has nothing to do with the runlevel links. you have to alter the configuration file for xdm or whatever to not manage a local X server, but you still need the daemon started at boot, by yes a initscript. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpN2K27doUer.pgp Description: PGP signature
Re: Security of Debian SuX0r?
On Fri, Sep 01, 2000 at 08:06:20PM -0400, Jonathan D. Proulx wrote: Anything less than 700 breaks RSA authentication for ssh. A point to consider though I'll gladly concede that anyone using RSA keys ought to know what permissions they want on their home directory and how to change them. wrong, ssh only cares if the home directory is *WRITABLE* by other users then the owner, not if its readable. my home directory is mode 710 and ssh works fine, on other systems my home is mode 755 and ssh still works fine (all with RSA auth and StrictModes yes) -- Ethan Benson http://www.alaska.net/~erbenson/ pgplKUvwwNxmm.pgp Description: PGP signature
Re: Security of Debian SuX0r?
On Sat, Sep 02, 2000 at 01:25:09AM -0400, Adam McKenna wrote: my home directory is mode 710 and ssh works fine, on other systems my home is mode 755 and ssh still works fine (all with RSA auth and StrictModes yes) Actually, sshd only cares about ~/.ssh and ~/.ssh/authorized_keys and that they're not group or world writable. how much do you want to bet? [EMAIL PROTECTED] eb]$ chmod 770 . [EMAIL PROTECTED] eb]$ ls -ld ~ drwxrwx--- 56 eb users4096 Sep 1 23:04 /home/eb [EMAIL PROTECTED] eb]$ [EMAIL PROTECTED] eb]$ ssh -v socrates SSH Version OpenSSH-1.2.3, protocol version 1.5. Compiled with SSL. debug: Reading configuration data /home/eb/.ssh/config [snip] debug: Connection established. debug: Remote protocol version 1.5, remote software version OpenSSH-1.2.3 [snip] debug: Trying RSA authentication with key '[EMAIL PROTECTED]' debug: Remote: RSA authentication refused for eb: bad ownership or modes for '/home/eb/'. debug: Server refused our key. debug: Trying RSA authentication with key '[EMAIL PROTECTED]' debug: Remote: RSA authentication refused for eb: bad ownership or modes for '/home/eb/'. debug: Server refused our key. Permission denied. debug: Calling cleanup 0x8056820(0x0) [EMAIL PROTECTED] eb]$ [EMAIL PROTECTED] eb]$ chmod 710 . [EMAIL PROTECTED] eb]$ ls -ld . drwx--x--- 56 eb users4096 Sep 1 23:10 . [EMAIL PROTECTED] eb]$ [EMAIL PROTECTED] eb]$ ssh socrates Enter passphrase for RSA key '[EMAIL PROTECTED]': Last login: Fri Sep 1 19:09:40 2000 on tty9 [...] Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. You have mail. [EMAIL PROTECTED] eb]$ i also tried it with my home directory group set to my private group `eb' same deal. perhaps you have a different version of ssh? -- Ethan Benson http://www.alaska.net/~erbenson/ pgp4bkUmaIT9B.pgp Description: PGP signature
Re: Learning dpkg/apt
On Sat, Aug 19, 2000 at 05:07:41PM +0200, Simon Richter wrote: On Fri, 18 Aug 2000, Dwayne C . Litzenberger wrote: I want to learn the total innards of dpkg/apt. I recently filed a bug complaining about the fact that dpkg is too slow, but I want to actually _do_ something about it (other than ordering other developers around). Actuallu the slowest thing about dpkg is the database of files. I would be cool if dpkg could use some sort of relational database for that. no it wouldn't, as soon as that database gets corrupted in whatever way your completly screwed and have to reinstall. this happened to me once and the only thing that saved me was the fact that the dpkg databases were in human readable text format. ill take slow over unrecoverable any day. for things like querying (dpkg -s and such) install dlocate it solves that problem the Right Way. (unfortunatly it got removed from potato for less then critical bugs) -- Ethan Benson http://www.alaska.net/~erbenson/ pgpiQMnRN865i.pgp Description: PGP signature
Re: Learning dpkg/apt
On Sat, Aug 19, 2000 at 06:00:54PM -0600, Dwayne C . Litzenberger wrote: no it wouldn't, as soon as that database gets corrupted in whatever way your completly screwed and have to reinstall. That's why I suggested a *cacheing* system for the text database. Every write sorry i have not followed this thread very close. operation happens twice (once in the binDB, once in the txtDB), but every read operation can come straight from the binDB. Hashing could be used to check if the text database is still equal to the binary database. it seems to me that this would make things slower since everything is written twice, the text database would still have to be processed in order to update it properly, so i don't think installing packages would be much faster, if not slower. querying would indeed be fast but as i mentioned that can be better achieved by rebuilding a binary database with a cron job as in dlocate. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpMxwPV4b8ir.pgp Description: PGP signature
Re: ITP: lirc, devfsd
On Sun, Apr 02, 2000 at 10:09:30PM -0400, Ben Collins wrote: Similarly, I have packaged devfsd (http://www.atnf.csiro.au/~rgooch/linux/). This one still needs a couple of problems ironing out first. No offense, but I hope you realize the amount of effort that will be needed for devfsd. Since it is a key element in our 2.4.x upgrade path, the amount of policy and technical bugs will be tremendous (permissions, adding support for default compatibility devices, etc..). I just don't want to see anyone go lightly into packaging devfsd. If you aren't prepared to take on the responsiblity of what will most likely become a base and essential package, leave it for some one else to do. I hope debian is not planning on `forcing' [0] the use of devfs with 2.4, last i checked it was still a compile time option (and experimental at that) there are some of us who don't care for devfs and do not wish to use it. [0] read making it exceedingly inconvenient to forgo or disable devfs in 2.4 kernels, for example neglecting to maintain or provide a real (non-devfs) working /dev directory. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpIttMdLg8tg.pgp Description: PGP signature
Re: WNPP
On Mon, Mar 27, 2000 at 08:27:29PM -0500, Brian Almeida wrote: ...or maybe not. It's got cryptographic hashing algos (tiger, sha1, etc), so I probably can't package it due to wonderful US laws. Drat. actually the charming US laws appear to be fixed, at least for Free software. The kernel is going to be getting stong crypto merged in soon apparently, and Redhat is now shipping GnuPG and such with there dist, so it seems to apply to binaries too (non commercial anyway) On Mon, Mar 27, 2000 at 08:12:37PM -0500, Brian Almeida wrote: I'll do this, since it relates to my work. :-) On Mon, Mar 27, 2000 at 12:39:52PM -0800, Joey Hess wrote: Someone should package AIDE (http://www.cs.tut.fi/~rammer/aide.html). It's a free tripwire replacement. -- Brian Almeida Debian Developer | http://www.debian.org Linux Systems Engineer @ Winstar | http://www.winstar.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Ethan Benson http://www.alaska.net/~erbenson/ pgp49fUG5IAmR.pgp Description: PGP signature
Re: stuffit expander?
On Sun, Mar 26, 2000 at 09:50:54PM +0200, Nils Jeppe wrote: Hello, Is there any debian package (or in fact Unix tool at all) that allows uncompression of Mac .sit (stuffit) archives? there is no debian package, and more to the point there is no *nix utility period that will extract stuffit version 4 and version 5 files. this format is highly proprietary and only one compnay i am aware of has reverse engineered it, Mindvision (with there macos Mindexpander utility) they have however chosen not to share their knowledge with anyone (or their source). the version 5 file format no one has yet reverse engineered AFAIK. (look for Aladdin systems to be moving to Virginia soon)... there is however some OLD (have not been touched since '88) utilities that used to extract version 1.5 stuffit files, but they don't really work anymore, and are not included in any debian package i have seen. its just as well, they tend to do a better job creating corrupt files/archives then unpacking a .sit file. my suggestion is to deal with users using this blatently proprietary format to use something standard and open, such as a combination of macbinary and gzip. which unix utilities should not have any problem with. -- Ethan Benson http://www.alaska.net/~erbenson/
Re: stuffit expander?
On Sun, Mar 26, 2000 at 09:54:50PM -0400, Peter Cordes wrote: Date: Sun, 26 Mar 2000 21:50:54 +0200 (CEST) From: Nils Jeppe [EMAIL PROTECTED] To: debian-devel@lists.debian.org Subject: stuffit expander? Hello, Is there any debian package (or in fact Unix tool at all) that allows uncompression of Mac .sit (stuffit) archives? I think you want the macutils package. nope, that package does not include the stuffit 1.5 utilities, because they are quite old and broken. -- Ethan Benson http://www.alaska.net/~erbenson/
Re: 5 days till Bug Horizon
On Sat, Mar 25, 2000 at 08:14:21PM +1000, Anthony Towns wrote: On Sat, Mar 25, 2000 at 09:37:38AM +0100, Miros/law `Jubal' Baran wrote: 25.03.2000 pisze Anthony Towns (aj@azure.humbug.org.au): [0] update-inetd needs a rewrite. It also needs to remain more or less compatible. It also needs to end up being very tidy and flexible. I'll end up working on this eventually, if no one else does, but if someone else it first... Do you plan to implement a functionality similar to RH's chkconfig? What's RH's chkconfig do? its basically equivilent to update-rc.d except it lets you twiddle stuff on and off by runlevel without having to -f remove the whole batch of symlinks and then reinstall them again the way you wanted. i don't know what it has to do with inetd, IIRC all it did was manage /etc/rc?.d/* symlinks. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpKhvqaNxJa2.pgp Description: PGP signature
Re: emacs19 removal? [was: rms@gnu.org: Bug#57636: Security problem with emacs19]
On Fri, Mar 10, 2000 at 08:11:11PM +0100, Josip Rodin wrote: BTW I was told removing all non-current Netscape Navigator versions will be done RSN (if it wasn't already done, haven't checked today). that could be a problem on the powerpc branch as the only available netscape is an outdated version. it still needs the 4.7 binaries. -- Ethan Benson
Re: emacs19 removal? [was: rms@gnu.org: Bug#57636: Security problem with emacs19]
On Sat, Mar 11, 2000 at 03:52:16PM +0100, Josip Rodin wrote: On Fri, Mar 10, 2000 at 08:19:29PM -0900, Ethan Benson wrote: BTW I was told removing all non-current Netscape Navigator versions will be done RSN (if it wasn't already done, haven't checked today). that could be a problem on the powerpc branch as the only available netscape is an outdated version. it still needs the 4.7 binaries. We could then make netscape4.7 source package build binary packages only for powerpc. Adam (CC:ed), what do you think? actually i was not too clear the latest binaries for powerpc is 4.6 i should have said it needs 4.7* binaries... Someone should also bitch at Netscape Inc. for not providing 4.72 for powerpc. im not sure if there are 4.7.2 or not i know for sure there are 4.7.0 as linuxppc has them. -- enJoy -*/\*- don't even try to pronounce my first name -- Ethan Benson
