Re: IPChains vs Cisco IOS Packer Filters
On 12 Apr, Eugene van Zyl wrote: > Can anyone tell me whether the Packet Filter on the Cisco IOS does > statefull packet inspection ? and whether I'll be losing by replacing > it with IPChains on Kernel 2.2.17? Not a big difference - neither Cisco IOS nor IPchains offer stateful inspection. For that choose Kernel 2.4 (IPtable) or *BSD (netfilter) Bye Volker -- Volker Tanger [EMAIL PROTECTED] -===- Research & Development Division, WYAE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Followup: Syslog
Il giorno Fri, Apr 13 in un momento di profonda ispirazione Micah Anderson scrisse riguardo a " Re: Followup: Syslog ": > One additional tweak which falls into line with the security setups, that I > think is a good idea is to made the log files in /var/log to be chattr +a > (append only) so logfiles cannot be modified or removed altogether to cover > up tracks. This isn't the the biggest security trick because all it does is > make it if you don't know about chattr then you can't install a trojan. If It's indeed *too* trivial. I'd suggest using LIDS for such things. For those who don't know it, it's a kernel patch which adds capabilities support. It makes impossible to delete logs 'cause in order to disable "append only" you should reboot with a kernel without lids, but lids forbids rebooting unless the admin is logged from a local console. -- Luca Gibelli ([EMAIL PROTECTED] || [EMAIL PROTECTED]) PGP Fingerprint: EC7C D6D2 D754 89F8 BDE8 8924 6341 3B07 C2F3 9102 PGP Key Available on: Key Servers || http://gibelli.oltrelinux.com/gibelli.asc BOFH excuse 208: Traffic jam on the Information Superhighway. PGP signature
Re: Logging practices (and why does it suck in Debian?)
On Fri, Apr 13, 2001 at 09:33:08PM -0300, Peter Cordes wrote: > It's not hard to find (once you to look for it:): I looked for it. See below. > bigfoot:~# apt-cache search less console > aview - An high quality ascii-art image(pgm) browser [...] # apt-cache search less console E: You must give exactly one pattern > bigfoot:~# apt-cache show console-log > Package: console-log [...] # apt-cache show console-log W: Unable to locate package console-log I use potato, bigfoot is woody, right? ;) > Description: Keeps a less syslog running on tty9 > console-log keeps your syslog and your exim mainlog running in a less That sounds good, thanks! > apt-cache is your friend. Learn how to use its features :) I have already but it's not easy to find a package which is not available. ;) Janto -- Janto TrappeGermany /* rapelcgrq znvy cersreerq! */ GnuPG-Key: http://www.sylence.de/gpgkey.asc Key ID: 0x8C53625F Fingerprint:35D7 8CC0 3DAC 90CD B26F B628 C3AC 1AC5 8C53 625F PGP signature
Re: Followup: Syslog
Of all the days, it was on Fri, Apr 13, 2001 at 05:54:07PM -0500 that Kevin van Haaren quoth: > > > --On Friday, April 13, 2001 3:40 PM -0700 Micah Anderson <[EMAIL PROTECTED]> > hath wrote: > > | One additional tweak which falls into line with the security setups, that > | I think is a good idea is to made the log files in /var/log to be chattr > | +a (append only) so logfiles cannot be modified or removed altogether to > | cover up tracks. This isn't the the biggest security trick because all it > | does is make it if you don't know about chattr then you can't install a > | trojan. If you've got root then removing the immutability flags is > | trivial, but only if you know how to, or even know they exist. But it has > | kept the lower-level admins at a site I work at from modifying the > | logfiles, which is against policy. > | > > if you want a real way to do this (more than just obscuring what you've > done) go get one of those old dot-matrix printers with fanfold paperfeed > and dump your logs to it in addition to the one on drive. Keep it in a > secured room. > Another technique is to use a separate logging server which has the transmit leads on it's ethernet connection snipped. It's capable of receiving (via UDP only, since it can't ACK!) log entries, but it's virtually impossible to start an interactive session remotely to shut it down or otherwise interfere with it. It's possible to attack the server that is sending the log entries to shut down its connection to the logging server, but this is probably no easier that disabling a printer on a parallel port (a simple way is to send 1 formfeeds), and by the time this can be accomplished, there should already be a trail of log entries. Old log entries can be written to multiple CDRs for archival purposes, with a copy stored in a secure off-site location. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Followup: Syslog
from the secret journal of Andy Bastien ([EMAIL PROTECTED]): > > Another technique is to use a separate logging server which has the > transmit leads on it's ethernet connection snipped. It's capable of > receiving (via UDP only, since it can't ACK!) log entries, but it's > virtually impossible to start an interactive session remotely to shut > it down or otherwise interfere with it. It's possible to attack the It also can't arp. You'll need to prime the arp cache from a file for every host that needs immutable logs. Have you tried this? I wonder if you'll even get a link light. A syslog that strips formfeeds and line feeds attached to a printer is a little better, but I haven't found an efficient way to egrep with my eyes. -- Jacob Kuntz [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://underworld.net/~jake -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Logging practices (and why does it suck in Debian?)
On Sat, Apr 14, 2001 at 05:07:47PM +0200, Janto Trappe wrote: > # apt-cache show console-log > W: Unable to locate package console-log > > I use potato, bigfoot is woody, right? ;) Ah, sorry. bigfoot is running unstable, actually. Some of my other machines run testing, but I've got the unstable package repository in my sources.list (and Default-Release "testing"; in /etc/apt/apt.conf, so unstable doesn't get used by default, but I can install packages from it. see apt-preferences(8). I just found this feature in apt a couple weeks ago, and I love it. :) I've got apt version 0.5.3 on my system running woody/testing. Even if you leave the rest of the system at potato, you might want to update to a new apt. > I have already but it's not easy to find a package which is not > available. ;) packages.debian.org has a search that lets you easily search for stuff that isn't immediately available for install on the machine you're using. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Followup: Syslog
On Sat, Apr 14, 2001 at 02:58:02PM +0200, Luca Gibelli wrote: > > One additional tweak which falls into line with the security setups, that I > > think is a good idea is to made the log files in /var/log to be chattr +a > > (append only) so logfiles cannot be modified or removed altogether to cover > > up tracks. This isn't the the biggest security trick because all it does is > > make it if you don't know about chattr then you can't install a trojan. If > > It's indeed *too* trivial. though a large number of script kiddies are really really dumb. > I'd suggest using LIDS for such things. > For those who don't know it, it's a kernel patch which adds capabilities > support. It makes impossible to delete logs 'cause in order to disable > "append only" you should reboot with a kernel without lids, but lids forbids > rebooting unless the admin is logged from a local console. or just use lcap lcap CAP_SYS_MODULE CAP_SYS_RAWIO CAP_SYS_BOOT CAP_LINUX_IMMUTABLE that revokes the ability to load modules, denies access to /dev/mem, /dev/kmem and /proc/kcore. revokes the ability to reboot(), and revokes the ability to set or remove immutable/append only bits. there are a few problems with this: throw away your logrotation scripts, they will now fail and your logs will permanently bloat until you reboot the system into single user mode and rotate them on the console manually. you can't reboot remotely anymore, a shutdown -r now will bring the system all the way down to where it runs the actual reboot command which will fail and init will spawn sulogin. there is no way to seal the raw disk devices using linux capabilities, so the immutability bits can be trivially removed by directly modifying the filesystem through /dev/hda* or /dev/sda*. this is a pretty lame oversight IMO given the BSD securelevel at level 1 revokes the ability to access raw devices for mounted filesystems, and at level 2 revokes the ability to access any raw disk device. you need to protect the script running lcap at boot, this means you have to make / or /etc immutable which will severely break your system (i have read an immutable / makes the system unusable) otherwise all the cracker needs to do is: cp -a /etc /etc.foo mv /etc /etc.crap mv /etc.foo /etc reboot of course that last step is liable to make someone notice, and if you revoked CAP_SYS_BOOT your machine will just go down and stay down until you take care of it and hopefully notice the bogus /etc.crap. (which can't be rm -rfed until after the reboot && chattr -R -ia /etc.crap) lids might be able to solve some of these problems, but remains a royally obnoxious thing to administer, you end up having to do pretty much everything from the console (depending on the config i suppose), and well if i wanted that i would use NT ;-) and it sounds like lids may not be portable to arch != i386. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: Logging practices (and why does it suck in Debian?)
> Ah, sorry. bigfoot is running unstable, actually. Some of my other >machines run testing, but I've got the unstable package repository in my >sources.list (and Default-Release "testing"; in /etc/apt/apt.conf, so >unstable doesn't get used by default, but I can install packages from it. >see apt-preferences(8). I just found this feature in apt a couple weeks >ago, and I love it. :) slightly off topic but.. I always found this aspect of debian a little puzzling. Debian to me is a collection of packages. It makes sense that some of these packages would be "stable" and others would be experimental but it never made sense to me that just because you subscribe to stable you should be stuck with some ancient version of apache, mozilla or whatever. Ideally the packages themselves should be labled stable, milestone, snapshot (or something similar) and you ought to be able to subscribe to packages themselves. This way if you trust the authors of a package (say postgres) then you could subscribe to postgres snapshot, but if you are not so sure about mozzilla you could subscribe to mozilla milestone. Anyway back to your regularly scheduled programming. -- Tim Uckun Mobile Intelligence Unit. -- "There are some who call me TIM?" -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Logging practices (and why does it suck in Debian?)
On Sat, Apr 14, 2001 at 07:29:05PM -0700, Tim Uckun wrote: > > > Ah, sorry. bigfoot is running unstable, actually. Some of my other > >machines run testing, but I've got the unstable package repository in my > >sources.list (and Default-Release "testing"; in /etc/apt/apt.conf, so > >unstable doesn't get used by default, but I can install packages from it. > >see apt-preferences(8). I just found this feature in apt a couple weeks > >ago, and I love it. :) > > slightly off topic but.. > I always found this aspect of debian a little puzzling. Debian to me is a > collection of packages. It makes sense that some of these packages would be > "stable" and others would be experimental but it never made sense to me > that just because you subscribe to stable you should be stuck with some > ancient version of apache, mozilla or whatever. > > Ideally the packages themselves should be labled stable, milestone, > snapshot (or something similar) and you ought to be able to subscribe to > packages themselves. This way if you trust the authors of a package (say > postgres) then you could subscribe to postgres snapshot, but if you are not > so sure about mozzilla you could subscribe to mozilla milestone. Well, assuming the version of the package in stable is stable, and the version in unstable is a snapshot, then you can do this with apt. According to apt-preferences(8), installing a package from unstable will cause your system to track the unstable version of that package for future upgrades. This seems to work, from what I've seen :) /etc/apt/preferences lets you pin packages wherever you want them. I agree, though, that it would be nice for the .deb to have a tag in its control info saying whether it was supposed to be stable or what. If anyone ever decides to add control info, they should add something like that along with signatures, and other stuff I haven't thought of right now :) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re[2]: Logging practices (and why does it suck in Debian?)
But what about when bob wants to run unstable glibc(2.2.2) and jimmy likes stable glibc(2.1.3)? There'd have to be stable/unstable/blah packages for every major version of glibc which I suppose isnt that many but it'd add up. I could be totally off base though. -- Kevin - [EMAIL PROTECTED] -- >> Ah, sorry. bigfoot is running unstable, actually. Some of my other >>machines run testing, but I've got the unstable package repository in my >>sources.list (and Default-Release "testing"; in /etc/apt/apt.conf, so >>unstable doesn't get used by default, but I can install packages from it. >>see apt-preferences(8). I just found this feature in apt a couple weeks >>ago, and I love it. :) > slightly off topic but.. > I always found this aspect of debian a little puzzling. Debian to me is a > collection of packages. It makes sense that some of these packages would be > "stable" and others would be experimental but it never made sense to me > that just because you subscribe to stable you should be stuck with some > ancient version of apache, mozilla or whatever. > Ideally the packages themselves should be labled stable, milestone, > snapshot (or something similar) and you ought to be able to subscribe to > packages themselves. This way if you trust the authors of a package (say > postgres) then you could subscribe to postgres snapshot, but if you are not > so sure about mozzilla you could subscribe to mozilla milestone. > Anyway back to your regularly scheduled programming. > -- > Tim Uckun >Mobile Intelligence Unit. > -- > "There are some who call me TIM?" > -- > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Logging practices (and why does it suck in Debian?)
[EMAIL PROTECTED] (Tim Uckun) writes: > Ideally the packages themselves should be labled stable, milestone, > snapshot (or something similar) and you ought to be able to subscribe to > packages themselves. A good idea, that doesn't work all that well in practice. Packages rarely stand alone... they depend on other packages, particularly shared libraries. It is hard to pull packages from unstable without finding yourself pulling in a number of shared library updates, at which point the rest of your system isn't really "stable" any more. Bdale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Logging practices (and why does it suck in Debian?)
On Sat, Apr 14, 2001 at 07:49:27PM -0600, Bdale Garbee wrote: > Packages rarely stand alone... they depend on other packages, particularly > shared libraries. It is hard to pull packages from unstable without finding > yourself pulling in a number of shared library updates, at which point the > rest of your system isn't really "stable" any more. Yeah, I noticed that. Even between testing and unstable, some unstable packages require libc6 >= unstable's version so I get the unstable libc. The biggest problem here is that to tell apt you only want the unstable version of a package so you can use some other package, you have to pin it with the preferences file. If you don't, then apt will track the unstable version of that package, even if that isn't needed to keep the unstable version of some other package happy. Sometimes, you can just wait a bit and testing will catch up with where unstable was, and apt should just upgrade to the newest testing version. Well, I guess it's a pretty handy feature that works well most of the time :) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: IPChains vs Cisco IOS Packer Filters
On 12 Apr, Eugene van Zyl wrote: > Can anyone tell me whether the Packet Filter on the Cisco IOS does > statefull packet inspection ? and whether I'll be losing by replacing > it with IPChains on Kernel 2.2.17? Not a big difference - neither Cisco IOS nor IPchains offer stateful inspection. For that choose Kernel 2.4 (IPtable) or *BSD (netfilter) Bye Volker -- Volker Tanger [EMAIL PROTECTED] -===- Research & Development Division, WYAE
Re: Followup: Syslog
Il giorno Fri, Apr 13 in un momento di profonda ispirazione Micah Anderson scrisse riguardo a " Re: Followup: Syslog ": > One additional tweak which falls into line with the security setups, that I > think is a good idea is to made the log files in /var/log to be chattr +a > (append only) so logfiles cannot be modified or removed altogether to cover > up tracks. This isn't the the biggest security trick because all it does is > make it if you don't know about chattr then you can't install a trojan. If It's indeed *too* trivial. I'd suggest using LIDS for such things. For those who don't know it, it's a kernel patch which adds capabilities support. It makes impossible to delete logs 'cause in order to disable "append only" you should reboot with a kernel without lids, but lids forbids rebooting unless the admin is logged from a local console. -- Luca Gibelli ([EMAIL PROTECTED] || [EMAIL PROTECTED]) PGP Fingerprint: EC7C D6D2 D754 89F8 BDE8 8924 6341 3B07 C2F3 9102 PGP Key Available on: Key Servers || http://gibelli.oltrelinux.com/gibelli.asc BOFH excuse 208: Traffic jam on the Information Superhighway. pgpZH7bITyDy1.pgp Description: PGP signature
Re: Logging practices (and why does it suck in Debian?)
On Fri, Apr 13, 2001 at 09:33:08PM -0300, Peter Cordes wrote: > It's not hard to find (once you to look for it:): I looked for it. See below. > bigfoot:~# apt-cache search less console > aview - An high quality ascii-art image(pgm) browser [...] # apt-cache search less console E: You must give exactly one pattern > bigfoot:~# apt-cache show console-log > Package: console-log [...] # apt-cache show console-log W: Unable to locate package console-log I use potato, bigfoot is woody, right? ;) > Description: Keeps a less syslog running on tty9 > console-log keeps your syslog and your exim mainlog running in a less That sounds good, thanks! > apt-cache is your friend. Learn how to use its features :) I have already but it's not easy to find a package which is not available. ;) Janto -- Janto TrappeGermany /* rapelcgrq znvy cersreerq! */ GnuPG-Key: http://www.sylence.de/gpgkey.asc Key ID: 0x8C53625F Fingerprint:35D7 8CC0 3DAC 90CD B26F B628 C3AC 1AC5 8C53 625F pgpkAqTt6BxRU.pgp Description: PGP signature
Re: Followup: Syslog
Of all the days, it was on Fri, Apr 13, 2001 at 05:54:07PM -0500 that Kevin van Haaren quoth: > > > --On Friday, April 13, 2001 3:40 PM -0700 Micah Anderson <[EMAIL PROTECTED]> > hath wrote: > > | One additional tweak which falls into line with the security setups, that > | I think is a good idea is to made the log files in /var/log to be chattr > | +a (append only) so logfiles cannot be modified or removed altogether to > | cover up tracks. This isn't the the biggest security trick because all it > | does is make it if you don't know about chattr then you can't install a > | trojan. If you've got root then removing the immutability flags is > | trivial, but only if you know how to, or even know they exist. But it has > | kept the lower-level admins at a site I work at from modifying the > | logfiles, which is against policy. > | > > if you want a real way to do this (more than just obscuring what you've > done) go get one of those old dot-matrix printers with fanfold paperfeed > and dump your logs to it in addition to the one on drive. Keep it in a > secured room. > Another technique is to use a separate logging server which has the transmit leads on it's ethernet connection snipped. It's capable of receiving (via UDP only, since it can't ACK!) log entries, but it's virtually impossible to start an interactive session remotely to shut it down or otherwise interfere with it. It's possible to attack the server that is sending the log entries to shut down its connection to the logging server, but this is probably no easier that disabling a printer on a parallel port (a simple way is to send 1 formfeeds), and by the time this can be accomplished, there should already be a trail of log entries. Old log entries can be written to multiple CDRs for archival purposes, with a copy stored in a secure off-site location.
Re: Followup: Syslog
from the secret journal of Andy Bastien ([EMAIL PROTECTED]): > > Another technique is to use a separate logging server which has the > transmit leads on it's ethernet connection snipped. It's capable of > receiving (via UDP only, since it can't ACK!) log entries, but it's > virtually impossible to start an interactive session remotely to shut > it down or otherwise interfere with it. It's possible to attack the It also can't arp. You'll need to prime the arp cache from a file for every host that needs immutable logs. Have you tried this? I wonder if you'll even get a link light. A syslog that strips formfeeds and line feeds attached to a printer is a little better, but I haven't found an efficient way to egrep with my eyes. -- Jacob Kuntz [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://underworld.net/~jake
Re: Logging practices (and why does it suck in Debian?)
On Sat, Apr 14, 2001 at 05:07:47PM +0200, Janto Trappe wrote: > # apt-cache show console-log > W: Unable to locate package console-log > > I use potato, bigfoot is woody, right? ;) Ah, sorry. bigfoot is running unstable, actually. Some of my other machines run testing, but I've got the unstable package repository in my sources.list (and Default-Release "testing"; in /etc/apt/apt.conf, so unstable doesn't get used by default, but I can install packages from it. see apt-preferences(8). I just found this feature in apt a couple weeks ago, and I love it. :) I've got apt version 0.5.3 on my system running woody/testing. Even if you leave the rest of the system at potato, you might want to update to a new apt. > I have already but it's not easy to find a package which is not > available. ;) packages.debian.org has a search that lets you easily search for stuff that isn't immediately available for install on the machine you're using. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE
Re: Followup: Syslog
On Sat, Apr 14, 2001 at 02:58:02PM +0200, Luca Gibelli wrote: > > One additional tweak which falls into line with the security setups, that I > > think is a good idea is to made the log files in /var/log to be chattr +a > > (append only) so logfiles cannot be modified or removed altogether to cover > > up tracks. This isn't the the biggest security trick because all it does is > > make it if you don't know about chattr then you can't install a trojan. If > > It's indeed *too* trivial. though a large number of script kiddies are really really dumb. > I'd suggest using LIDS for such things. > For those who don't know it, it's a kernel patch which adds capabilities > support. It makes impossible to delete logs 'cause in order to disable > "append only" you should reboot with a kernel without lids, but lids forbids > rebooting unless the admin is logged from a local console. or just use lcap lcap CAP_SYS_MODULE CAP_SYS_RAWIO CAP_SYS_BOOT CAP_LINUX_IMMUTABLE that revokes the ability to load modules, denies access to /dev/mem, /dev/kmem and /proc/kcore. revokes the ability to reboot(), and revokes the ability to set or remove immutable/append only bits. there are a few problems with this: throw away your logrotation scripts, they will now fail and your logs will permanently bloat until you reboot the system into single user mode and rotate them on the console manually. you can't reboot remotely anymore, a shutdown -r now will bring the system all the way down to where it runs the actual reboot command which will fail and init will spawn sulogin. there is no way to seal the raw disk devices using linux capabilities, so the immutability bits can be trivially removed by directly modifying the filesystem through /dev/hda* or /dev/sda*. this is a pretty lame oversight IMO given the BSD securelevel at level 1 revokes the ability to access raw devices for mounted filesystems, and at level 2 revokes the ability to access any raw disk device. you need to protect the script running lcap at boot, this means you have to make / or /etc immutable which will severely break your system (i have read an immutable / makes the system unusable) otherwise all the cracker needs to do is: cp -a /etc /etc.foo mv /etc /etc.crap mv /etc.foo /etc reboot of course that last step is liable to make someone notice, and if you revoked CAP_SYS_BOOT your machine will just go down and stay down until you take care of it and hopefully notice the bogus /etc.crap. (which can't be rm -rfed until after the reboot && chattr -R -ia /etc.crap) lids might be able to solve some of these problems, but remains a royally obnoxious thing to administer, you end up having to do pretty much everything from the console (depending on the config i suppose), and well if i wanted that i would use NT ;-) and it sounds like lids may not be portable to arch != i386. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpPL9O0tiz0f.pgp Description: PGP signature
Re: Logging practices (and why does it suck in Debian?)
Ah, sorry. bigfoot is running unstable, actually. Some of my other machines run testing, but I've got the unstable package repository in my sources.list (and Default-Release "testing"; in /etc/apt/apt.conf, so unstable doesn't get used by default, but I can install packages from it. see apt-preferences(8). I just found this feature in apt a couple weeks ago, and I love it. :) slightly off topic but.. I always found this aspect of debian a little puzzling. Debian to me is a collection of packages. It makes sense that some of these packages would be "stable" and others would be experimental but it never made sense to me that just because you subscribe to stable you should be stuck with some ancient version of apache, mozilla or whatever. Ideally the packages themselves should be labled stable, milestone, snapshot (or something similar) and you ought to be able to subscribe to packages themselves. This way if you trust the authors of a package (say postgres) then you could subscribe to postgres snapshot, but if you are not so sure about mozzilla you could subscribe to mozilla milestone. Anyway back to your regularly scheduled programming. -- Tim Uckun Mobile Intelligence Unit. -- "There are some who call me TIM?" --
Re: Logging practices (and why does it suck in Debian?)
On Sat, Apr 14, 2001 at 07:29:05PM -0700, Tim Uckun wrote: > > > Ah, sorry. bigfoot is running unstable, actually. Some of my other > >machines run testing, but I've got the unstable package repository in my > >sources.list (and Default-Release "testing"; in /etc/apt/apt.conf, so > >unstable doesn't get used by default, but I can install packages from it. > >see apt-preferences(8). I just found this feature in apt a couple weeks > >ago, and I love it. :) > > slightly off topic but.. > I always found this aspect of debian a little puzzling. Debian to me is a > collection of packages. It makes sense that some of these packages would be > "stable" and others would be experimental but it never made sense to me > that just because you subscribe to stable you should be stuck with some > ancient version of apache, mozilla or whatever. > > Ideally the packages themselves should be labled stable, milestone, > snapshot (or something similar) and you ought to be able to subscribe to > packages themselves. This way if you trust the authors of a package (say > postgres) then you could subscribe to postgres snapshot, but if you are not > so sure about mozzilla you could subscribe to mozilla milestone. Well, assuming the version of the package in stable is stable, and the version in unstable is a snapshot, then you can do this with apt. According to apt-preferences(8), installing a package from unstable will cause your system to track the unstable version of that package for future upgrades. This seems to work, from what I've seen :) /etc/apt/preferences lets you pin packages wherever you want them. I agree, though, that it would be nice for the .deb to have a tag in its control info saying whether it was supposed to be stable or what. If anyone ever decides to add control info, they should add something like that along with signatures, and other stuff I haven't thought of right now :) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE
Re[2]: Logging practices (and why does it suck in Debian?)
But what about when bob wants to run unstable glibc(2.2.2) and jimmy likes stable glibc(2.1.3)? There'd have to be stable/unstable/blah packages for every major version of glibc which I suppose isnt that many but it'd add up. I could be totally off base though. -- Kevin - [EMAIL PROTECTED] -- >> Ah, sorry. bigfoot is running unstable, actually. Some of my other >>machines run testing, but I've got the unstable package repository in my >>sources.list (and Default-Release "testing"; in /etc/apt/apt.conf, so >>unstable doesn't get used by default, but I can install packages from it. >>see apt-preferences(8). I just found this feature in apt a couple weeks >>ago, and I love it. :) > slightly off topic but.. > I always found this aspect of debian a little puzzling. Debian to me is a > collection of packages. It makes sense that some of these packages would be > "stable" and others would be experimental but it never made sense to me > that just because you subscribe to stable you should be stuck with some > ancient version of apache, mozilla or whatever. > Ideally the packages themselves should be labled stable, milestone, > snapshot (or something similar) and you ought to be able to subscribe to > packages themselves. This way if you trust the authors of a package (say > postgres) then you could subscribe to postgres snapshot, but if you are not > so sure about mozzilla you could subscribe to mozilla milestone. > Anyway back to your regularly scheduled programming. > -- > Tim Uckun >Mobile Intelligence Unit. > -- > "There are some who call me TIM?" > -- > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Logging practices (and why does it suck in Debian?)
[EMAIL PROTECTED] (Tim Uckun) writes: > Ideally the packages themselves should be labled stable, milestone, > snapshot (or something similar) and you ought to be able to subscribe to > packages themselves. A good idea, that doesn't work all that well in practice. Packages rarely stand alone... they depend on other packages, particularly shared libraries. It is hard to pull packages from unstable without finding yourself pulling in a number of shared library updates, at which point the rest of your system isn't really "stable" any more. Bdale
Re: Logging practices (and why does it suck in Debian?)
On Sat, Apr 14, 2001 at 07:49:27PM -0600, Bdale Garbee wrote: > Packages rarely stand alone... they depend on other packages, particularly > shared libraries. It is hard to pull packages from unstable without finding > yourself pulling in a number of shared library updates, at which point the > rest of your system isn't really "stable" any more. Yeah, I noticed that. Even between testing and unstable, some unstable packages require libc6 >= unstable's version so I get the unstable libc. The biggest problem here is that to tell apt you only want the unstable version of a package so you can use some other package, you have to pin it with the preferences file. If you don't, then apt will track the unstable version of that package, even if that isn't needed to keep the unstable version of some other package happy. Sometimes, you can just wait a bit and testing will catch up with where unstable was, and apt should just upgrade to the newest testing version. Well, I guess it's a pretty handy feature that works well most of the time :) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE
