Re: Logging practices (and why does it suck in Debian?)
On Sat, Apr 14, 2001 at 11:03:01PM -0300, Peter Cordes wrote: 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. You can solve this problem by pinning unstable to a priority under 100 in the preferences file (see the manpage for details). -- James Deikun, Techie(tm), CSI Multimedia The opinions expressed c. -- 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 11:03:01PM -0300, Peter Cordes wrote: 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. You can solve this problem by pinning unstable to a priority under 100 in the preferences file (see the manpage for details). -- James Deikun, Techie(tm), CSI Multimedia The opinions expressed c.
Re: Logging practices (and why does it suck in Debian?)
That way, I get newer versions of postgres, zope, apache, whatever, but don't have to completely upgrade to woody or sid. Those lazier, more impatient, or less CPU-capable than I might want to look into Stephane Bortzmeyer's list of unofficial apt sources to see if anyone has already built something you're looking for. As we go on discussing this mostly off topic subject something occurs to me. We are describing a workaround instead of a fix. In linux programs should not be able to break other programs (that's what windows is for). There is something wrong further on in the food chain that causes this fundemental flaw. The culprit we all know is shared libraries and maybe it's time to rethink that whole concept. In this day of giant hard drives and fast processors how much does saving a megabyte or two of disk space really matter. I know for sure I would prefer the old DOS (yes I said it!) way of doing things mainly .. The application lives in it's own directory. The application is blissfully unaware of anything else in the system. Removing the directory removes the application It's possible to have multiple versions of the same app installed at the same time apt-cache search is replaced by ls /apps Shared libraries may have been a good idea but somehow the implementation in both windows and linux got all weird. I just did a search for *.dll on my windows 2K system and it came back with 4,303 files. How much you want to bet half of them have a function to split strings into parts. If the goal of the DLLs was to encourage code reuse it failed, if it was to save disk space it also failed. I say there should be a firewall between the apps and the OS and between the apps themselves. Installing an app should not break the OS or other apps. :wq Tim Uckun Due Diligence Inc. http://www.diligence.com/Americas Background Investigation Expert. If your company isn't doing background checks, maybe you haven't considered the risks of a bad hire. -- 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 Fri, Apr 20, 2001 at 10:12:42AM -0600, Tim Uckun wrote: Shared libraries may have been a good idea but somehow the implementation in both windows and linux got all weird. I just did a search for *.dll on my windows 2K system and it came back with 4,303 files. Doesn't win2k do what you suggest, and have a the dlls for each app in a directory for that app? How much you want to bet half of them have a function to split strings into parts. If the goal of the DLLs was to encourage code reuse it failed, if it was to save disk space it also failed. I think statically linking everything is a crappy idea. With shared libraries, two processes that have the same library mapped can share that memory, and instruction cache, space. It not only saves disk space, it also makes things run faster. Especially with the Unix paradigm of having lots of small programs that all do one thing well, you'd have a ridiculous amount of memory usage. Think about the extra IO traffic from loading a statically linked ls, cat, rm, cp, etc. all the time. Also, if there's a bug in shared library code, you have to upgrade every application statically linked against it instead of just upgrading the shared library. Same deal for optimizations, like a 3dnow or altivec libjpeg or something. And BTW, installing stuff in Debian won't break other packages, unless one package lists the other in its Conflicts: line. If so, apt won't let you install both at once. That's not so bad. You can tell apt to download source, build the package, and install it for you if you don't have the lib versions it was compiled against. -- #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: Logging practices (and why does it suck in Debian?)
On Friday, 2001-04-20 at 14:14:13 -0300, Peter Cordes wrote: On Fri, Apr 20, 2001 at 10:12:42AM -0600, Tim Uckun wrote: Shared libraries may have been a good idea but somehow the implementation in both windows and linux got all weird. I just did a search for *.dll on my windows 2K system and it came back with 4,303 files. I thought Linux supports versioning for shared libraries. Forgive me for being a Solaris weenie, but I can't understand why you can't have several versions of one shared library. Or can you in *Linux*, but the Debian packaging breaks this? In Solaris, you have major version numvers for incompatible changes, and minor versions numbers for fixes. Most libraries only use the major version number. I think statically linking everything is a crappy idea. With shared libraries, two processes that have the same library mapped can share that memory, and instruction cache, space. It not only saves disk space, it also makes things run faster. Especially with the Unix paradigm of having lots of small programs that all do one thing well, you'd have a ridiculous amount of memory usage. Think about the extra IO traffic from loading a statically linked ls, cat, rm, cp, etc. all the time. When Sun introduced shared library, disk space requirements sank significantly, much more than mein memory requirements. But don't forget about the additional CPU requirements of PIC code on many architectures, and the cycles required by the dynamic linking phase. Trivial programs tend to be in the filesystem cache, so I/O will be very low. Also, if there's a bug in shared library code, you have to upgrade every application statically linked against it instead of just upgrading the shared library. Same deal for optimizations, like a 3dnow or altivec libjpeg or something. The Solaris recommended patch cluster tends to be 10~20 MB in size, depending on release and age. Patches never shrink ;-) I guess it would be at least twice that size if programs where statically linked. And BTW, installing stuff in Debian won't break other packages, unless one package lists the other in its Conflicts: line. If so, apt won't let you install both at once. That's not so bad. You can tell apt to download source, build the package, and install it for you if you don't have the lib versions it was compiled against. Well, can you have two versions of libc? Lupe Christoph -- | [EMAIL PROTECTED] |http://free.prohosting.com/~lupe | | I have challenged the entire ISO-9000 quality assurance team to a | | Bat-Leth contest on the holodeck. They will not concern us again. | | http://public.logica.com/~stepneys/joke/klingon.htm| -- 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?)
Doesn't win2k do what you suggest, and have a the dlls for each app in a directory for that app? Not really. Some are others are in winsys others are in program files/shared etc. Since W2K also absolutely trusts Microsoft and Microsoft installs and upgrades are notorious for breaking things it's kind of a useless implementation. Sure I can't write an app which will overwrite an important DLL but the ADO people at MS can and when you upgrade IE or ADO then it can ruin your week. The system ought to only trust me! Also, if there's a bug in shared library code, you have to upgrade every application statically linked against it instead of just upgrading the shared library. Same deal for optimizations, like a 3dnow or altivec libjpeg or something. Everything you say is 100% absolutely true. But it also has a price. For me the price can be summed up like this. When there is a new version of postgres out I want to be able to type apt-get update apt-get upgrade and have it installed. Right now I can't do that because debian has frozen on a well known and tested configuration which does not include postgres 7.1 In fact for all debian knows installing postgres 7.1 may break other apps or cause library problems. In the end I guess it's a tradeoff but I can't help but wonder if there is some third alternative. One that would let me keep the stable debian OS I have and let's me install using apt the newest postgresql/php/apache that I have come to rely on. Right now I have to manually compile the three most important parts of my system which makes apt less useful. :wq Tim Uckun Due Diligence Inc. http://www.diligence.com/Americas Background Investigation Expert. If your company isn't doing background checks, maybe you haven't considered the risks of a bad hire. -- 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?)
Lupe Christoph [EMAIL PROTECTED] writes: On Friday, 2001-04-20 at 14:14:13 -0300, Peter Cordes wrote: On Fri, Apr 20, 2001 at 10:12:42AM -0600, Tim Uckun wrote: Shared libraries may have been a good idea but somehow the implementation in both windows and linux got all weird. I just did a search for *.dll on my windows 2K system and it came back with 4,303 files. I thought Linux supports versioning for shared libraries. Forgive me for being a Solaris weenie, but I can't understand why you can't have several versions of one shared library. Or can you in *Linux*, but the Debian packaging breaks this? Huh ? ls -l /lib/libncurses.so.* lrwxrwxrwx1 root root 17 Nov 8 16:04 /lib/libncurses.so.4 - libncurses.so.4.2 -rw-r--r--1 root root 238700 Mar 5 2000 /lib/libncurses.so.4.2 lrwxrwxrwx1 root root 17 Nov 26 20:38 /lib/libncurses.so.5 - libncurses.so.5.0 -rw-r--r--1 root root 233816 Nov 21 19:55 /lib/libncurses.so.5.0 In Solaris, you have major version numvers for incompatible changes, and minor versions numbers for fixes. Most libraries only use the major version number. Same in Debian... Well, can you have two versions of libc? You could, but glibc (=2.1) provides versionned symbols and in theory the soname will never have to change again :-) Phil. -- 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 Fri, Apr 20, 2001 at 01:31:49PM -0600, Tim Uckun wrote: Doesn't win2k do what you suggest, and have a the dlls for each app in a directory for that app? Not really. Some are others are in winsys others are in program files/shared etc. Since W2K also absolutely trusts Microsoft and Microsoft installs and upgrades are notorious for breaking things it's kind of a useless implementation. Sure I can't write an app which will overwrite an important DLL but the ADO people at MS can and when you upgrade IE or ADO then it can ruin your week. The system ought to only trust me! Also, if there's a bug in shared library code, you have to upgrade every application statically linked against it instead of just upgrading the shared library. Same deal for optimizations, like a 3dnow or altivec libjpeg or something. Everything you say is 100% absolutely true. But it also has a price. For me the price can be summed up like this. When there is a new version of postgres out I want to be able to type apt-get update apt-get upgrade and have it installed. Right now I can't do that because debian has frozen on a well known and tested configuration What about apt-get source --build postgres? Doesn't that work? Sure, it takes a bit longer, but it's still automated. You can list unstable sources and stable binaries in sources.list which does not include postgres 7.1 In fact for all debian knows installing postgres 7.1 may break other apps or cause library problems. In the end I guess it's a tradeoff but I can't help but wonder if there is some third alternative. One that would let me keep the stable debian OS I have and let's me install using apt the newest postgresql/php/apache that I have come to rely on. Right now I have to manually compile the three most important parts of my system which makes apt less useful. If apache is important for you, don't you want to custom-compile it anyway? (maybe apache's a bad example, since their modules setup lets you do a lot without recompiling...). You can keep up to date on stuff you don't want to bother with using apt, and build stuff you care about yourself. (of course, the best would be to have a system where you could get the latest versions of the stuff you care about, but linked to the libs for the stable system. There's no reason this couldn't happen, but it would make the debian archive really big, because you'd need different versions of packages that were linked against different libs. It would get ugly, especially when package maintainers got behind and didn't keep up with new libraries coming out.) -- #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: Logging practices (and why does it suck in Debian?)
On Thu, Apr 19, 2001 at 05:06:06PM -0600, Tim Uckun wrote: I couldn't agree more. apt-get will install postgres 6.5 in potato. Postgres has gone through two versions since (7.0 and 7.1). It kind of defeats the purpose of apt if you have manually build everything anyway. Especially considering that most sites use a combination of apache/php/postgres all of which have newer versions. It does defeat the idea of apt as the all-powerful binary grabber/installer, but I've been pointing my deb-src lines at woody or sid for some time now. For many packages, at least, a simple apt-get source (packagename) and a look through the Build-Depends: line of debian/control before compiling fixes my problems. That way, I get newer versions of postgres, zope, apache, whatever, but don't have to completely upgrade to woody or sid. Those lazier, more impatient, or less CPU-capable than I might want to look into Stephane Bortzmeyer's list of unofficial apt sources to see if anyone has already built something you're looking for. -- Mike Renfro / RD Engineer, Center for Manufacturing Research, 931 372-3601 / Tennessee Technological University -- [EMAIL PROTECTED]
Re: Logging practices (and why does it suck in Debian?)
That way, I get newer versions of postgres, zope, apache, whatever, but don't have to completely upgrade to woody or sid. Those lazier, more impatient, or less CPU-capable than I might want to look into Stephane Bortzmeyer's list of unofficial apt sources to see if anyone has already built something you're looking for. As we go on discussing this mostly off topic subject something occurs to me. We are describing a workaround instead of a fix. In linux programs should not be able to break other programs (that's what windows is for). There is something wrong further on in the food chain that causes this fundemental flaw. The culprit we all know is shared libraries and maybe it's time to rethink that whole concept. In this day of giant hard drives and fast processors how much does saving a megabyte or two of disk space really matter. I know for sure I would prefer the old DOS (yes I said it!) way of doing things mainly .. The application lives in it's own directory. The application is blissfully unaware of anything else in the system. Removing the directory removes the application It's possible to have multiple versions of the same app installed at the same time apt-cache search is replaced by ls /apps Shared libraries may have been a good idea but somehow the implementation in both windows and linux got all weird. I just did a search for *.dll on my windows 2K system and it came back with 4,303 files. How much you want to bet half of them have a function to split strings into parts. If the goal of the DLLs was to encourage code reuse it failed, if it was to save disk space it also failed. I say there should be a firewall between the apps and the OS and between the apps themselves. Installing an app should not break the OS or other apps. :wq Tim Uckun Due Diligence Inc. http://www.diligence.com/Americas Background Investigation Expert. If your company isn't doing background checks, maybe you haven't considered the risks of a bad hire.
Re: Logging practices (and why does it suck in Debian?)
On Fri, Apr 20, 2001 at 10:12:42AM -0600, Tim Uckun wrote: Shared libraries may have been a good idea but somehow the implementation in both windows and linux got all weird. I just did a search for *.dll on my windows 2K system and it came back with 4,303 files. Doesn't win2k do what you suggest, and have a the dlls for each app in a directory for that app? How much you want to bet half of them have a function to split strings into parts. If the goal of the DLLs was to encourage code reuse it failed, if it was to save disk space it also failed. I think statically linking everything is a crappy idea. With shared libraries, two processes that have the same library mapped can share that memory, and instruction cache, space. It not only saves disk space, it also makes things run faster. Especially with the Unix paradigm of having lots of small programs that all do one thing well, you'd have a ridiculous amount of memory usage. Think about the extra IO traffic from loading a statically linked ls, cat, rm, cp, etc. all the time. Also, if there's a bug in shared library code, you have to upgrade every application statically linked against it instead of just upgrading the shared library. Same deal for optimizations, like a 3dnow or altivec libjpeg or something. And BTW, installing stuff in Debian won't break other packages, unless one package lists the other in its Conflicts: line. If so, apt won't let you install both at once. That's not so bad. You can tell apt to download source, build the package, and install it for you if you don't have the lib versions it was compiled against. -- #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: Logging practices (and why does it suck in Debian?)
On Friday, 2001-04-20 at 14:14:13 -0300, Peter Cordes wrote: On Fri, Apr 20, 2001 at 10:12:42AM -0600, Tim Uckun wrote: Shared libraries may have been a good idea but somehow the implementation in both windows and linux got all weird. I just did a search for *.dll on my windows 2K system and it came back with 4,303 files. I thought Linux supports versioning for shared libraries. Forgive me for being a Solaris weenie, but I can't understand why you can't have several versions of one shared library. Or can you in *Linux*, but the Debian packaging breaks this? In Solaris, you have major version numvers for incompatible changes, and minor versions numbers for fixes. Most libraries only use the major version number. I think statically linking everything is a crappy idea. With shared libraries, two processes that have the same library mapped can share that memory, and instruction cache, space. It not only saves disk space, it also makes things run faster. Especially with the Unix paradigm of having lots of small programs that all do one thing well, you'd have a ridiculous amount of memory usage. Think about the extra IO traffic from loading a statically linked ls, cat, rm, cp, etc. all the time. When Sun introduced shared library, disk space requirements sank significantly, much more than mein memory requirements. But don't forget about the additional CPU requirements of PIC code on many architectures, and the cycles required by the dynamic linking phase. Trivial programs tend to be in the filesystem cache, so I/O will be very low. Also, if there's a bug in shared library code, you have to upgrade every application statically linked against it instead of just upgrading the shared library. Same deal for optimizations, like a 3dnow or altivec libjpeg or something. The Solaris recommended patch cluster tends to be 10~20 MB in size, depending on release and age. Patches never shrink ;-) I guess it would be at least twice that size if programs where statically linked. And BTW, installing stuff in Debian won't break other packages, unless one package lists the other in its Conflicts: line. If so, apt won't let you install both at once. That's not so bad. You can tell apt to download source, build the package, and install it for you if you don't have the lib versions it was compiled against. Well, can you have two versions of libc? Lupe Christoph -- | [EMAIL PROTECTED] |http://free.prohosting.com/~lupe | | I have challenged the entire ISO-9000 quality assurance team to a | | Bat-Leth contest on the holodeck. They will not concern us again. | | http://public.logica.com/~stepneys/joke/klingon.htm|
Re: Logging practices (and why does it suck in Debian?)
Doesn't win2k do what you suggest, and have a the dlls for each app in a directory for that app? Not really. Some are others are in winsys others are in program files/shared etc. Since W2K also absolutely trusts Microsoft and Microsoft installs and upgrades are notorious for breaking things it's kind of a useless implementation. Sure I can't write an app which will overwrite an important DLL but the ADO people at MS can and when you upgrade IE or ADO then it can ruin your week. The system ought to only trust me! Also, if there's a bug in shared library code, you have to upgrade every application statically linked against it instead of just upgrading the shared library. Same deal for optimizations, like a 3dnow or altivec libjpeg or something. Everything you say is 100% absolutely true. But it also has a price. For me the price can be summed up like this. When there is a new version of postgres out I want to be able to type apt-get update apt-get upgrade and have it installed. Right now I can't do that because debian has frozen on a well known and tested configuration which does not include postgres 7.1 In fact for all debian knows installing postgres 7.1 may break other apps or cause library problems. In the end I guess it's a tradeoff but I can't help but wonder if there is some third alternative. One that would let me keep the stable debian OS I have and let's me install using apt the newest postgresql/php/apache that I have come to rely on. Right now I have to manually compile the three most important parts of my system which makes apt less useful. :wq Tim Uckun Due Diligence Inc. http://www.diligence.com/Americas Background Investigation Expert. If your company isn't doing background checks, maybe you haven't considered the risks of a bad hire.
Re: Logging practices (and why does it suck in Debian?)
On Fri, Apr 20, 2001 at 08:24:03PM +0200, Lupe Christoph wrote: On Friday, 2001-04-20 at 14:14:13 -0300, Peter Cordes wrote: On Fri, Apr 20, 2001 at 10:12:42AM -0600, Tim Uckun wrote: Shared libraries may have been a good idea but somehow the implementation in both windows and linux got all weird. I just did a search for *.dll on my windows 2K system and it came back with 4,303 files. I thought Linux supports versioning for shared libraries. Forgive me for being a Solaris weenie, but I can't understand why you can't have several versions of one shared library. Or can you in *Linux*, but the Debian packaging breaks this? In Solaris, you have major version numvers for incompatible changes, and minor versions numbers for fixes. Most libraries only use the major version number. It's all done with the ELF SONAME. The program looks for libc.so.6 or something, and the dynamic linker finds it. Other libraries, like libcrypto, have the SONAME including a longer version string. ldd ssh: ... libcrypto.so.0.9.6 = /usr/lib/libcrypto.so.0.9.6 ... A bugfix to libcrypto could just replace the file, or could install libcrypto.so.0.9.6.1, with SONAME set to libcrypto.so.0.9.6, so ldconfig would make the right symlink, and programs linked against it would look for it by that name. (that's how the linker figures out what dynamic library name to use when it only reads /usr/lib/libfoo.so. err, that ignores linker scripts like you see in /usr/lib/libc.so. whatever.) I think statically linking everything is a crappy idea. With shared libraries, two processes that have the same library mapped can share that memory, and instruction cache, space. It not only saves disk space, it also makes things run faster. Especially with the Unix paradigm of having lots of small programs that all do one thing well, you'd have a ridiculous amount of memory usage. Think about the extra IO traffic from loading a statically linked ls, cat, rm, cp, etc. all the time. When Sun introduced shared library, disk space requirements sank significantly, much more than mein memory requirements. But don't forget about the additional CPU requirements of PIC code on many architectures, and the cycles required by the dynamic linking phase. Trivial programs tend to be in the filesystem cache, so I/O will be very low. my point is that they won't be if they're all 1MB because they have libc statically linked. You can statically link random uncommon libs that only one prog uses anyway, but Tim was talking about libc. Yikes! Also, don't forget the advantages of sharing pages of RAM. This also shares the instruction cache across processes, which is a Good Thing. I don't have any numbers on this, but it probably makes around 1% difference or less since processes don't switch very often. And BTW, installing stuff in Debian won't break other packages, unless one package lists the other in its Conflicts: line. If so, apt won't let you install both at once. That's not so bad. You can tell apt to download source, build the package, and install it for you if you don't have the lib versions it was compiled against. Well, can you have two versions of libc? Yup. I've got libc5 maple installed on my machine, but everything else is using glibc. Nobody does it, but you could if you wanted to have a system where the C libraries had finer grained versioning, so you could have two versions of libc6 installed. llama:~$ ldd /bin/ls librt.so.1 = /lib/librt.so.1 (0x4001b000) libc.so.6 = /lib/libc.so.6 (0x4002d000) libpthread.so.0 = /lib/libpthread.so.0 (0x4014) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) (Since when does ls use pthread and rt?!?!) ls looks for libc.so.6. If all your programs were linked to look for glibc-2.2 or glibc-2.1, or something, then you could have both glibc versions installed at once without trouble. For compatibility with the rest of the world, Debian doesn't do this. Oh, and BTW, Tim, you can make everything statically linked just as soon as you buy me more RAM and disk space for all my computers. (including the 486 laptop that can't hold more than the 20MB RAM it has now. It's running a mix of woody and sid :) The minor inconveniences of shared libraries are a small price to pay for the advantages. (This might not be the case if you haven't taken the time to figure out how the linker figures out what to do, since then things are just confusing and it's no better than windoze, except for the Debian packaging system which keeps things straight. I don't have a clue about the details of DLLs in windoze, all I know is that it looks in your $PATH for them. I even wrote one (for excel to use) and I still don't know!) -- #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
Re: Logging practices (and why does it suck in Debian?)
Lupe Christoph [EMAIL PROTECTED] writes: On Friday, 2001-04-20 at 14:14:13 -0300, Peter Cordes wrote: On Fri, Apr 20, 2001 at 10:12:42AM -0600, Tim Uckun wrote: Shared libraries may have been a good idea but somehow the implementation in both windows and linux got all weird. I just did a search for *.dll on my windows 2K system and it came back with 4,303 files. I thought Linux supports versioning for shared libraries. Forgive me for being a Solaris weenie, but I can't understand why you can't have several versions of one shared library. Or can you in *Linux*, but the Debian packaging breaks this? Huh ? ls -l /lib/libncurses.so.* lrwxrwxrwx1 root root 17 Nov 8 16:04 /lib/libncurses.so.4 - libncurses.so.4.2 -rw-r--r--1 root root 238700 Mar 5 2000 /lib/libncurses.so.4.2 lrwxrwxrwx1 root root 17 Nov 26 20:38 /lib/libncurses.so.5 - libncurses.so.5.0 -rw-r--r--1 root root 233816 Nov 21 19:55 /lib/libncurses.so.5.0 In Solaris, you have major version numvers for incompatible changes, and minor versions numbers for fixes. Most libraries only use the major version number. Same in Debian... Well, can you have two versions of libc? You could, but glibc (=2.1) provides versionned symbols and in theory the soname will never have to change again :-) Phil.
Re: Logging practices (and why does it suck in Debian?)
On Fri, Apr 20, 2001 at 01:31:49PM -0600, Tim Uckun wrote: Doesn't win2k do what you suggest, and have a the dlls for each app in a directory for that app? Not really. Some are others are in winsys others are in program files/shared etc. Since W2K also absolutely trusts Microsoft and Microsoft installs and upgrades are notorious for breaking things it's kind of a useless implementation. Sure I can't write an app which will overwrite an important DLL but the ADO people at MS can and when you upgrade IE or ADO then it can ruin your week. The system ought to only trust me! Also, if there's a bug in shared library code, you have to upgrade every application statically linked against it instead of just upgrading the shared library. Same deal for optimizations, like a 3dnow or altivec libjpeg or something. Everything you say is 100% absolutely true. But it also has a price. For me the price can be summed up like this. When there is a new version of postgres out I want to be able to type apt-get update apt-get upgrade and have it installed. Right now I can't do that because debian has frozen on a well known and tested configuration What about apt-get source --build postgres? Doesn't that work? Sure, it takes a bit longer, but it's still automated. You can list unstable sources and stable binaries in sources.list which does not include postgres 7.1 In fact for all debian knows installing postgres 7.1 may break other apps or cause library problems. In the end I guess it's a tradeoff but I can't help but wonder if there is some third alternative. One that would let me keep the stable debian OS I have and let's me install using apt the newest postgresql/php/apache that I have come to rely on. Right now I have to manually compile the three most important parts of my system which makes apt less useful. If apache is important for you, don't you want to custom-compile it anyway? (maybe apache's a bad example, since their modules setup lets you do a lot without recompiling...). You can keep up to date on stuff you don't want to bother with using apt, and build stuff you care about yourself. (of course, the best would be to have a system where you could get the latest versions of the stuff you care about, but linked to the libs for the stable system. There's no reason this couldn't happen, but it would make the debian archive really big, because you'd need different versions of packages that were linked against different libs. It would get ugly, especially when package maintainers got behind and didn't keep up with new libraries coming out.) -- #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: Logging practices (and why does it suck in Debian?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lupe Christoph [EMAIL PROTECTED] writes: On Friday, 2001-04-20 at 14:14:13 -0300, Peter Cordes wrote: On Fri, Apr 20, 2001 at 10:12:42AM -0600, Tim Uckun wrote: Shared libraries may have been a good idea but somehow the implementation in both windows and linux got all weird. I just did a search for *.dll on my windows 2K system and it came back with 4,303 files. I thought Linux supports versioning for shared libraries. Forgive me for being a Solaris weenie, but I can't understand why you can't have several versions of one shared library. Or can you in *Linux*, but the Debian packaging breaks this? Linux supports shared versioning, and Debian exploits this greatly (witness the presence of tk8.0, tk8.2, and tk8.3 all simultaneously present and until recently all installed on my main workstation, for example). I don't know what problem the guy Tim is responding to is running into, but I'm certainly not seeing it myself. As near as I can tell Windows does *not* support versioning libraries (versioned COM objects is another thing), they hack around this by renaming the DLL every `major revision'. Ultimately the same solution, just less elegant. snip And BTW, installing stuff in Debian won't break other packages, unless one package lists the other in its Conflicts: line. If so, apt won't let you install both at once. That's not so bad. You can tell apt to download source, build the package, and install it for you if you don't have the lib versions it was compiled against. Well, can you have two versions of libc? Of course! You just can't have two versions of glibc; for whatever reason they didn't increment the major version number for 2.0-2.1 and yea, some things did indeed break. But I can and do have libc5 on my workstation at home. - -- Graham Hughes [EMAIL PROTECTED] PGP fingerprint: 1F1D 0027 B835 E114 3F5B 2C7C 64D1 83A0 C5C7 312A -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard http://www.gnupg.org/ iD8DBQE64JnPZNGDoMXHMSoRAmtsAKDB4Yx4+Nz1SgL8xXnsaA0wkppc8QCgxOqb k/6ILUL2i59ZitQXI0eehwI= =UljW -END PGP SIGNATURE-
Re: Logging practices (and why does it suck in Debian?)
The trouble is, unstable packages tend to rely on a new version of things like libc6 and other important shared libraries that I don't want to upgrade because it would destabilize the whole system. What I'd like to see is some kind of snapshot status where it was linked against the stable versions of all the common libraries etc. I couldn't agree more. apt-get will install postgres 6.5 in potato. Postgres has gone through two versions since (7.0 and 7.1). It kind of defeats the purpose of apt if you have manually build everything anyway. Especially considering that most sites use a combination of apache/php/postgres all of which have newer versions. :wq Tim Uckun Due Diligence Inc. http://www.diligence.com/Americas Background Investigation Expert. If your company isn't doing background checks, maybe you haven't considered the risks of a bad hire. -- 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?)
Peter Cordes [EMAIL PROTECTED] writes: On Sat, Apr 14, 2001 at 07:29:05PM -0700, Tim Uckun wrote: 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 :) The trouble is, unstable packages tend to rely on a new version of things like libc6 and other important shared libraries that I don't want to upgrade because it would destabilize the whole system. What I'd like to see is some kind of snapshot status where it was linked against the stable versions of all the common libraries etc. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.bayview.com/~hermit/ - Those are my principles. If you don't like them I have others.-Groucho Marx
Re: Logging practices (and why does it suck in Debian?)
The trouble is, unstable packages tend to rely on a new version of things like libc6 and other important shared libraries that I don't want to upgrade because it would destabilize the whole system. What I'd like to see is some kind of snapshot status where it was linked against the stable versions of all the common libraries etc. I couldn't agree more. apt-get will install postgres 6.5 in potato. Postgres has gone through two versions since (7.0 and 7.1). It kind of defeats the purpose of apt if you have manually build everything anyway. Especially considering that most sites use a combination of apache/php/postgres all of which have newer versions. :wq Tim Uckun Due Diligence Inc. http://www.diligence.com/Americas Background Investigation Expert. If your company isn't doing background checks, maybe you haven't considered the risks of a bad hire.
Re: Logging practices (and why does it suck in Debian?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Speaking of problems with console-log, has anyone else had trouble with it when syslog restarts (e.g. when logs are rotated)? I found that after a syslog restart, no new messages would appear in the less concerned. Adding the following line to /etc/init.d/sysklogd just before the exit 0 at the end seems to have fixed it: /etc/init.d/console-log $1 /dev/null 21 - -- Chris Boyle - Winchester College - http://archives.wincoll.ac.uk/ For my PGP key visit: http://archives.wincoll.ac.uk/finger.php?q=chrisb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE63gNXD834tscfhTwRAmCWAJ0V162wrwRCaz4LoT2l+M88SSPjhgCdHzQk 6ay1JcdoT156inNNtPRTOnY= =v0mG -END PGP SIGNATURE- -- 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 Tue, Apr 17, 2001 at 10:58:22AM -0600, Nate Duehr wrote: I had problems early on with console-log keeping machines from properly rebooting during remote reboots over ssh. Did that get cleared up? I could never track down why so I didn't submit a bug report on it, because I wasn't sure if it was a local problem to that machine only or not. just remove the symlink to console-log from /etc/rc0.d and /etc/rc6.d, maybe /etc/rc1.d too. the stop script is broken it seems, if you remove the symlinks, it will get killed anyway -- ,---. Name: Alson van der Meulen Personal: [EMAIL PROTECTED] School: [EMAIL PROTECTED] `---' Say, What does Superblock Error mean, anyhow? -
Re: Logging practices (and why does it suck in Debian?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Speaking of problems with console-log, has anyone else had trouble with it when syslog restarts (e.g. when logs are rotated)? I found that after a syslog restart, no new messages would appear in the less concerned. Adding the following line to /etc/init.d/sysklogd just before the exit 0 at the end seems to have fixed it: /etc/init.d/console-log $1 /dev/null 21 - -- Chris Boyle - Winchester College - http://archives.wincoll.ac.uk/ For my PGP key visit: http://archives.wincoll.ac.uk/finger.php?q=chrisb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE63gNXD834tscfhTwRAmCWAJ0V162wrwRCaz4LoT2l+M88SSPjhgCdHzQk 6ay1JcdoT156inNNtPRTOnY= =v0mG -END 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: On Fri, Apr 13, 2001 at 02:45:43AM +0200, Janto Trappe wrote: On Wed, Apr 11, 2001 at 10:13:36AM -0300, Peter Cordes wrote: debugging. There's a package that pipe into less on a console, so you can Do you know the name of this package? I think its very useful. It's not hard to find (once you to look for it:): bigfoot:~# apt-cache search less console aview - An high quality ascii-art image(pgm) browser console-log - Keeps a less syslog running on tty9 konsole - X terminal emulation for KDE The winner is ... console-log. bigfoot:~# apt-cache show console-log Package: console-log Priority: optional Section: admin Installed-Size: 48 Maintainer: Marc Haber [EMAIL PROTECTED] Architecture: all Version: 0.5 Depends: less, run (=0.9.2-4), console-tools Filename: pool/main/c/console-log/console-log_0.5_all.deb Size: 5000 MD5sum: fdded8c42d3b4e9322a9e2d3dcd608fe Description: Keeps a less syslog running on tty9 console-log keeps your syslog and your exim mainlog running in a less process on tty9/tty8. It also makes sure that this console is visible automatically after system boot so that a crashed system at least leaves the syslog readable on the console before reset. Using less makes searching, tagging and highlighting possible. apt-cache is your friend. Learn how to use its features :) -- #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 I had problems early on with console-log keeping machines from properly rebooting during remote reboots over ssh. Did that get cleared up? I could never track down why so I didn't submit a bug report on it, because I wasn't sure if it was a local problem to that machine only or not. -- Nate Duehr [EMAIL PROTECTED] GPG Key fingerprint = DCAF 2B9D CC9B 96FA 7A6D AAF4 2D61 77C5 7ECE C1D2 Public Key available upon request, or at wwwkeys.pgp.net and others. -- 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 Fri, Apr 13, 2001 at 09:33:08PM -0300, Peter Cordes wrote: On Fri, Apr 13, 2001 at 02:45:43AM +0200, Janto Trappe wrote: On Wed, Apr 11, 2001 at 10:13:36AM -0300, Peter Cordes wrote: debugging. There's a package that pipe into less on a console, so you can Do you know the name of this package? I think its very useful. It's not hard to find (once you to look for it:): bigfoot:~# apt-cache search less console aview - An high quality ascii-art image(pgm) browser console-log - Keeps a less syslog running on tty9 konsole - X terminal emulation for KDE The winner is ... console-log. bigfoot:~# apt-cache show console-log Package: console-log Priority: optional Section: admin Installed-Size: 48 Maintainer: Marc Haber [EMAIL PROTECTED] Architecture: all Version: 0.5 Depends: less, run (=0.9.2-4), console-tools Filename: pool/main/c/console-log/console-log_0.5_all.deb Size: 5000 MD5sum: fdded8c42d3b4e9322a9e2d3dcd608fe Description: Keeps a less syslog running on tty9 console-log keeps your syslog and your exim mainlog running in a less process on tty9/tty8. It also makes sure that this console is visible automatically after system boot so that a crashed system at least leaves the syslog readable on the console before reset. Using less makes searching, tagging and highlighting possible. apt-cache is your friend. Learn how to use its features :) -- #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 I had problems early on with console-log keeping machines from properly rebooting during remote reboots over ssh. Did that get cleared up? I could never track down why so I didn't submit a bug report on it, because I wasn't sure if it was a local problem to that machine only or not. -- Nate Duehr [EMAIL PROTECTED] GPG Key fingerprint = DCAF 2B9D CC9B 96FA 7A6D AAF4 2D61 77C5 7ECE C1D2 Public Key available upon request, or at wwwkeys.pgp.net and others.
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: 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: 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: 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: 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: 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: 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: 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
Re: Logging practices (and why does it suck in Debian?)
On Fri, Apr 13, 2001 at 02:45:43AM +0200, Janto Trappe wrote: On Wed, Apr 11, 2001 at 10:13:36AM -0300, Peter Cordes wrote: debugging. There's a package that pipe into less on a console, so you can Do you know the name of this package? I think its very useful. It's not hard to find (once you to look for it:): bigfoot:~# apt-cache search less console aview - An high quality ascii-art image(pgm) browser console-log - Keeps a less syslog running on tty9 konsole - X terminal emulation for KDE The winner is ... console-log. bigfoot:~# apt-cache show console-log Package: console-log Priority: optional Section: admin Installed-Size: 48 Maintainer: Marc Haber [EMAIL PROTECTED] Architecture: all Version: 0.5 Depends: less, run (=0.9.2-4), console-tools Filename: pool/main/c/console-log/console-log_0.5_all.deb Size: 5000 MD5sum: fdded8c42d3b4e9322a9e2d3dcd608fe Description: Keeps a less syslog running on tty9 console-log keeps your syslog and your exim mainlog running in a less process on tty9/tty8. It also makes sure that this console is visible automatically after system boot so that a crashed system at least leaves the syslog readable on the console before reset. Using less makes searching, tagging and highlighting possible. apt-cache is your friend. Learn how to use its features :) -- #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: Logging practices (and why does it suck in Debian?)
On Fri, Apr 13, 2001 at 02:45:43AM +0200, Janto Trappe wrote: On Wed, Apr 11, 2001 at 10:13:36AM -0300, Peter Cordes wrote: debugging. There's a package that pipe into less on a console, so you can Do you know the name of this package? I think its very useful. It's not hard to find (once you to look for it:): bigfoot:~# apt-cache search less console aview - An high quality ascii-art image(pgm) browser console-log - Keeps a less syslog running on tty9 konsole - X terminal emulation for KDE The winner is ... console-log. bigfoot:~# apt-cache show console-log Package: console-log Priority: optional Section: admin Installed-Size: 48 Maintainer: Marc Haber [EMAIL PROTECTED] Architecture: all Version: 0.5 Depends: less, run (=0.9.2-4), console-tools Filename: pool/main/c/console-log/console-log_0.5_all.deb Size: 5000 MD5sum: fdded8c42d3b4e9322a9e2d3dcd608fe Description: Keeps a less syslog running on tty9 console-log keeps your syslog and your exim mainlog running in a less process on tty9/tty8. It also makes sure that this console is visible automatically after system boot so that a crashed system at least leaves the syslog readable on the console before reset. Using less makes searching, tagging and highlighting possible. apt-cache is your friend. Learn how to use its features :) -- #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: Logging practices (and why does it suck in Debian?)
On Wed, 11 Apr 2001, Jamie Heilman wrote: Dan Bernstein's multilog program is the only logger I've seen that offers various reliability guarentees and actually delivers on them, but it has some prerequisites for usage that can frequently be difficult to meet. What I'd really like to see is a facility logger that could collect logs like traditional syslog but then would let me hand them to something like multilog to be stored on disk. I wrote something like that some time ago. Basically a listener that listens on /dev/log and sends it to multilog, or anything that reads from stdin. With multilog doing the logging there is no need for a crond to call logrotate anymore. Unless you need crond for other things... Of course, I may have made some horrible assumptions and introduced some really bad bugs when I wrote this, so just audit the source yourself :-) Also, I have some similar code somewhere, probably on my non networked host at home, that uses select() on two sockets, one being /dev/log and the other a UDP network thing, so you can also log remote things. ftp://linuxuser.co.za/pub/gluelog-0.1.tar.gz There were some issues with klogd, or at least, someone reported issues. I never had any problems, I simply started klogd after gluelog and it worked. I know it is possible to modify the code to read from /proc/kmsg instead, then you can also replace klogd. The only problem with this code is that it does not do any filtering based on the "facilities", and it simply dumps them to a file as is, ie, you get the ugly numbers straight into the file. Anyway, the code is unmaintained atm, so if anyone wants to take over and do something with it, be my guest :-) It is of course GPL'ed. I also remember seeing a solution with some kind of preloaded library that makes writes to the syslog go to stdout instead. You can then simply pipe it into multilog. regards, Izak -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Izak Burger ([EMAIL PROTECTED]) http://www.linuxuser.co.za/ Tel. +27 83 274 9199 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= chown -R us.enemy your_base -- 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?)
snip Before I start this, however, I would really like to know if this is just going to be something I'll do for myself, or if there's anybody else interested in it? Maybe even design it for inclusion in Debian? I personally think this should be done, since the default now sucks (to put it mildly). /snip That would be great! I'm still quite new to Linux/Debian and a doc and a decent logging config would be a great help in securing a box and managing it! Thanks, Eugene van Zyl -- 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?)
Hi, On Wed, Apr 11, 2001 at 10:13:36AM -0300, Peter Cordes wrote: debugging. There's a package that pipe into less on a console, so you can Do you know the name of this package? I think its very useful. 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: Logging practices (and why does it suck in Debian?)
Kenneth Vestergaard Schmidt wrote: Before I start this, however, I would really like to know if this is just going to be something I'll do for myself, or if there's anybody else interested in it? Maybe even design it for inclusion in Debian? I personally think this should be done, since the default now sucks (to put it mildly). Personally I always redo the standard syslog.conf, but I find it can only be done well if you know what role your machine is going to generally play ahead of time. For example on my workstations I remove the uucp, lpr, and cron entries, because of the programs I traditionaly use those entries never see enough use to justify seperate log files, I just let them get put into the syslog. I also remove the mail logs that are sorted by priority because a) on my workstations I use nullmailers and hence don't generate many logs, and b) on my servers I use qmail w/multilogger. Finally on my servers I always remove the xconsole dump as X has no place on a secure server and hence nobody is going to be looking at that pipe anyway. But then I can do all this because I already know what kind of logs to expect during normal usage and I can budget for it. I wouldn't say that my configuration is going to work for everybody. Actually the default debian syslog config is better than many other default configs in that the split is fairly intuitive. OTOH there's something to be said for shipping a lousy a default configuration as it makes people sit down and become more familiar with the software they are using. Syslog and other facility based loggers just generally suck. Thats not really Debian's fault and I'm not really sure what you're going to do about it. Unfortunately facility based logging has become the standard in Unix, even though most of the time its not very usefull. Worse yet syslog just isn't reliable. I run syslog-ng on a few machines but its not much better, though it is an improvement. I think this is mostly because syslog-ng tries too hard to be all things to all people in all situations. Dan Bernstein's multilog program is the only logger I've seen that offers various reliability guarentees and actually delivers on them, but it has some prerequisites for usage that can frequently be difficult to meet. What I'd really like to see is a facility logger that could collect logs like traditional syslog but then would let me hand them to something like multilog to be stored on disk. -- Jamie Heilman http://audible.transient.net/~jamie/ We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure. -Rosencrantz
Re: Logging practices (and why does it suck in Debian?)
On Wed, Apr 11, 2001 at 10:10:38PM -0700, Jamie Heilman wrote: Dan Bernstein's multilog program is the only logger I've seen that offers various reliability guarentees and actually delivers on them, but it has some prerequisites for usage that can frequently be difficult to meet. What I'd really like to see is a facility logger that could collect logs like traditional syslog but then would let me hand them to something like multilog to be stored on disk. Some such solutions are intermittently discussed, designed, etc. on the [EMAIL PROTECTED] list. Suggest you subscribe and hang out for a while. :) http://cr.yp.to/lists.html
Re: Logging practices (and why does it suck in Debian?)
Jim Breton wrote: Some such solutions are intermittently discussed, designed, etc. on the [EMAIL PROTECTED] list. Suggest you subscribe and hang out for a while. :) http://cr.yp.to/lists.html Really? See now I've just been browsing archives and I didn't see anything so I figured subscribing would be yet another list where I'd watch the same old folks flame the same old newbies... not that I don't find it amusing, I just figured why add another. ;) But hey if somebody's gonna write the glue to stitch facilites and multilog together I'm all for it, especially if somebody else can figure out how to make logger that does reliable and perhaps secure network transport. -- Jamie Heilman http://audible.transient.net/~jamie/ ...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity... -Rimmer
Re: Logging practices (and why does it suck in Debian?)
On Wed, 11 Apr 2001, Jamie Heilman wrote: Dan Bernstein's multilog program is the only logger I've seen that offers various reliability guarentees and actually delivers on them, but it has some prerequisites for usage that can frequently be difficult to meet. What I'd really like to see is a facility logger that could collect logs like traditional syslog but then would let me hand them to something like multilog to be stored on disk. I wrote something like that some time ago. Basically a listener that listens on /dev/log and sends it to multilog, or anything that reads from stdin. With multilog doing the logging there is no need for a crond to call logrotate anymore. Unless you need crond for other things... Of course, I may have made some horrible assumptions and introduced some really bad bugs when I wrote this, so just audit the source yourself :-) Also, I have some similar code somewhere, probably on my non networked host at home, that uses select() on two sockets, one being /dev/log and the other a UDP network thing, so you can also log remote things. ftp://linuxuser.co.za/pub/gluelog-0.1.tar.gz There were some issues with klogd, or at least, someone reported issues. I never had any problems, I simply started klogd after gluelog and it worked. I know it is possible to modify the code to read from /proc/kmsg instead, then you can also replace klogd. The only problem with this code is that it does not do any filtering based on the facilities, and it simply dumps them to a file as is, ie, you get the ugly numbers straight into the file. Anyway, the code is unmaintained atm, so if anyone wants to take over and do something with it, be my guest :-) It is of course GPL'ed. I also remember seeing a solution with some kind of preloaded library that makes writes to the syslog go to stdout instead. You can then simply pipe it into multilog. regards, Izak -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Izak Burger ([EMAIL PROTECTED]) http://www.linuxuser.co.za/ Tel. +27 83 274 9199 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= chown -R us.enemy your_base
RE: Logging practices (and why does it suck in Debian?)
snip Before I start this, however, I would really like to know if this is just going to be something I'll do for myself, or if there's anybody else interested in it? Maybe even design it for inclusion in Debian? I personally think this should be done, since the default now sucks (to put it mildly). /snip That would be great! I'm still quite new to Linux/Debian and a doc and a decent logging config would be a great help in securing a box and managing it! Thanks, Eugene van Zyl
Re: Logging practices (and why does it suck in Debian?)
Hi, On Wed, Apr 11, 2001 at 10:13:36AM -0300, Peter Cordes wrote: debugging. There's a package that pipe into less on a console, so you can Do you know the name of this package? I think its very useful. 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 pgpUtRhnOYqYy.pgp Description: PGP signature
Re: Logging practices (and why does it suck in Debian?)
On Wed, 11 Apr 2001, Kenneth Vestergaard Schmidt wrote: My first grievance was, that my mail-logs quickly filled up with duplicate information. Also, some of my other log-files seemed to contain a lot of duplicate entries. So, I started reading the syslog.conf manpage, and actually got a little insight into the workings of syslog :) I've been there, and I have done some of that as well... So, what I want to do now is totally overhaul syslog.conf, so I have more specific logging, with little or no duplicate entries (unless this is wanted, of course). I think most people which run some sort of automatic log parser have had to do something like this or live with duplicate log entries. Before I start this, however, I would really like to know if this is just going to be something I'll do for myself, or if there's anybody else interested in it? Maybe even design it for inclusion in Debian? I agree it should be done, and I agree it ought to be included in Debian. IMHO you ought to ask the sisklogd packager to use it as a better default. I don't think such a revised configuration should be in a separate package. I really need some feedback on this: is sysklogd what people use? I do use sysklogd. I tried syslog-ng, and perhaps will try it again sooner or later, but syslog-ng was broken for some time in unstable, so I reverted to sysklogd. Who has modified their syslog.conf? And to what need, and was it sufficient? I did it myself, mainly to avoid some duplication and to put some entries in a separate log file of their own. What do people want from their logging? Is there any standards that I should be aware of? I want a good signal to noise ratio and I want to know exactly where I should look to find a specific kind of log entry. If you have grand plans, I have a suggestion for you: prepare a set of update-syslog scripts in debian style, which pick up pieces in a well defined directory and build syslog.conf from it. In this way, a new package that produces a specific kind of logs would just drop its own configlet in that directory, run update-syslog and voil, syslog will put those logs in their new, dedicated file, very much like update-modules works. If you are REALLY brave and have VERY grand plans, you could also make your script work like update-menus, and build an appropriate configuration file for the logging system installed on the computer, be it sysklogd, syslog-ng or whatever. However, even if you do not have such grand plans, even just an improved syslog.conf would be very welcome :^) Bye Giacomo _ Giacomo Mulas [EMAIL PROTECTED], [EMAIL PROTECTED] _ OSSERVATORIO ASTRONOMICO Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA) Tel.: +39 070 71180 216 Fax : +39 070 71180 222 _ "When the storms are raging around you, stay right where you are" (Freddy Mercury) _ -- 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 Wednesday 11 April 2001 13:21, Giacomo Mulas wrote: I want a good signal to noise ratio and I want to know exactly where I should look to find a specific kind of log entry. So a README to the "new" syslog.conf :) If you have grand plans, I have a suggestion for you: prepare a set of update-syslog scripts in debian style, which pick up pieces in a well defined directory and build syslog.conf from it. In this way, a new package that produces a specific kind of logs would just drop its own configlet in that directory, run update-syslog and voil, syslog will put those logs in their new, dedicated file, very much like update-modules I don't see how it would benefit from that - syslog has a specified set of "facilities" that you can log from, and that set can't be expanded. The only thing you'd gain from that would be the ability to add more duplicity in other files... Howver, had you been able to have custom facilities, then yes, that would have been how it should have done. Having said that, is there any system loggin daemons which allow custom facilities? However, even if you do not have such grand plans, even just an improved syslog.conf would be very welcome :^) Neato. That's 3 people in total who think it's a good idea.. :/ Regards Kenneth -- 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 Wednesday 11 April 2001 15:03, Christian Hammers wrote: For this reason (to stay on topic) logging should at least keep the current behaviour to have one log where everything is logged to, as it's now with /var/log/syslog. And maybe the /var/log/auth.log with stuff that most people may not see as it's security relevant. Why? I think it is really wasted when everything is logged to syslog, and also logged to other, more specific files. If you want to search for something, use grep. And if you want to find something, look in the log-files that are relevant. What relevancy can it ever have to log *.debug, or mail.info messages to syslog, if you want to find stuff about instrusion detection? Having the current mail.err, mail.warn, mail.debug where everything "with or below that severity" is logged so that the admin can choose what is worth to read daily is fine for me. Again, I think this is wasted effort. Instead, as an admin, you could read mail.err, then mail.warn, and if you still feel up to it, mail.debug - it doesn't remove any details, but 1) it uses less disk space, 2) it removes the clutter, and 3) each log file has a specific purpose. But anyway, thanks for your comments! I am really trying to find "the perfect solution", although I'll probably come to realize that there isn't one :( Regards Kenneth -- 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 Wed, Apr 11, 2001 at 03:29:16PM +0200, Kenneth Vestergaard Schmidt wrote: Why? I think it is really wasted when everything is logged to syslog, and also logged to other, more specific files. If you want to search for Maybe people what to archive syslog for a year and the others only for a week or so. Also I find it comfortable to e.g. do a "tail -f /var/log/syslog" and get everything. (ok, have to append auth.log) Again, I think this is wasted effort. Instead, as an admin, you could read mail.err, then mail.warn, and if you still feel up to it, mail.debug - it This is arguable. I don't have a real optinion on it as I use logcheck to remove the unnecessary messages from syslog and read the rest. Maybe this is really clutter. Would be interestingly to know how other distributions and other Unices do. Regards Kenneth bye, -christian- -- Christian HammersWESTEND GmbH - Aachen und Dueren Tel 0241/701333-0 [EMAIL PROTECTED] Internet Security for ProfessionalsFax 0241/911879 WESTEND ist CISCO Systems Partner - Premium Certified -- 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?)
Neato. That's 3 people in total who think it's a good idea.. :/ It's probably the 3 people in total who bother to check the logs... make that 4. I always have an xterm with a tail -f /var/log/syslog running so I can see what is happening to the system. I have a firewall setup but I don't know if it is good enough so I usually monitor the syslog file for suspicious activity. jmb -- 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?)
Here is another one who bother to check the logs :) Cheers, Cristian On Wed, 11 Apr 2001, JonesMB wrote: Neato. That's 3 people in total who think it's a good idea.. :/ It's probably the 3 people in total who bother to check the logs... make that 4. I always have an xterm with a tail -f /var/log/syslog running so I can see what is happening to the system. I have a firewall setup but I don't know if it is good enough so I usually monitor the syslog file for suspicious activity. -- 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 Wed, Apr 11, 2001 at 01:40:13PM -0500, JonesMB wrote: make that 4. I always have an xterm with a tail -f /var/log/syslog running so I can see what is happening to the system. I have a firewall setup but I don't know if it is good enough so I usually monitor the syslog file for suspicious activity. This is more of a helpful comment or someone new to security on debian. Monitoring the logs (i.e. syslog) for suspicious activity may NOT provide you with any details of suspicious activity by default. Please make sure you have properly setup your firewall and have it reporting details (you request) to your log. Also some sort of intrusion detection (snort), will also help your effort. Mark Hurley -- 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 Wed, Apr 11, 2001 at 10:10:38PM -0700, Jamie Heilman wrote: Dan Bernstein's multilog program is the only logger I've seen that offers various reliability guarentees and actually delivers on them, but it has some prerequisites for usage that can frequently be difficult to meet. What I'd really like to see is a facility logger that could collect logs like traditional syslog but then would let me hand them to something like multilog to be stored on disk. Some such solutions are intermittently discussed, designed, etc. on the [EMAIL PROTECTED] list. Suggest you subscribe and hang out for a while. :) http://cr.yp.to/lists.html -- 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?)
Jim Breton wrote: Some such solutions are intermittently discussed, designed, etc. on the [EMAIL PROTECTED] list. Suggest you subscribe and hang out for a while. :) http://cr.yp.to/lists.html Really? See now I've just been browsing archives and I didn't see anything so I figured subscribing would be yet another list where I'd watch the same old folks flame the same old newbies... not that I don't find it amusing, I just figured why add another. ;) But hey if somebody's gonna write the glue to stitch facilites and multilog together I'm all for it, especially if somebody else can figure out how to make logger that does reliable and perhaps secure network transport. -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer -- 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 Wed, 11 Apr 2001, Kenneth Vestergaard Schmidt wrote: Having said that, is there any system loggin daemons which allow custom facilities? yes, syslog-ng, for example. This was one of the main reasons I had switched to it in the past (and probably will again, when I have some time to work on it, since it seems to be supported again in unstable) Neato. That's 3 people in total who think it's a good idea.. :/ It's probably the 3 people in total who bother to check the logs... Bye Giacomo _ Giacomo Mulas [EMAIL PROTECTED], [EMAIL PROTECTED] _ OSSERVATORIO ASTRONOMICO Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA) Tel.: +39 070 71180 216 Fax : +39 070 71180 222 _ When the storms are raging around you, stay right where you are (Freddy Mercury) _ -- 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 Wed, 11 Apr 2001, Kenneth Vestergaard Schmidt wrote: My first grievance was, that my mail-logs quickly filled up with duplicate information. Also, some of my other log-files seemed to contain a lot of duplicate entries. So, I started reading the syslog.conf manpage, and actually got a little insight into the workings of syslog :) I've been there, and I have done some of that as well... So, what I want to do now is totally overhaul syslog.conf, so I have more specific logging, with little or no duplicate entries (unless this is wanted, of course). I think most people which run some sort of automatic log parser have had to do something like this or live with duplicate log entries. Before I start this, however, I would really like to know if this is just going to be something I'll do for myself, or if there's anybody else interested in it? Maybe even design it for inclusion in Debian? I agree it should be done, and I agree it ought to be included in Debian. IMHO you ought to ask the sisklogd packager to use it as a better default. I don't think such a revised configuration should be in a separate package. I really need some feedback on this: is sysklogd what people use? I do use sysklogd. I tried syslog-ng, and perhaps will try it again sooner or later, but syslog-ng was broken for some time in unstable, so I reverted to sysklogd. Who has modified their syslog.conf? And to what need, and was it sufficient? I did it myself, mainly to avoid some duplication and to put some entries in a separate log file of their own. What do people want from their logging? Is there any standards that I should be aware of? I want a good signal to noise ratio and I want to know exactly where I should look to find a specific kind of log entry. If you have grand plans, I have a suggestion for you: prepare a set of update-syslog scripts in debian style, which pick up pieces in a well defined directory and build syslog.conf from it. In this way, a new package that produces a specific kind of logs would just drop its own configlet in that directory, run update-syslog and voilà, syslog will put those logs in their new, dedicated file, very much like update-modules works. If you are REALLY brave and have VERY grand plans, you could also make your script work like update-menus, and build an appropriate configuration file for the logging system installed on the computer, be it sysklogd, syslog-ng or whatever. However, even if you do not have such grand plans, even just an improved syslog.conf would be very welcome :^) Bye Giacomo _ Giacomo Mulas [EMAIL PROTECTED], [EMAIL PROTECTED] _ OSSERVATORIO ASTRONOMICO Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA) Tel.: +39 070 71180 216 Fax : +39 070 71180 222 _ When the storms are raging around you, stay right where you are (Freddy Mercury) _
Re: Logging practices (and why does it suck in Debian?)
On Wednesday 11 April 2001 13:21, Giacomo Mulas wrote: I want a good signal to noise ratio and I want to know exactly where I should look to find a specific kind of log entry. So a README to the new syslog.conf :) If you have grand plans, I have a suggestion for you: prepare a set of update-syslog scripts in debian style, which pick up pieces in a well defined directory and build syslog.conf from it. In this way, a new package that produces a specific kind of logs would just drop its own configlet in that directory, run update-syslog and voilà, syslog will put those logs in their new, dedicated file, very much like update-modules I don't see how it would benefit from that - syslog has a specified set of facilities that you can log from, and that set can't be expanded. The only thing you'd gain from that would be the ability to add more duplicity in other files... Howver, had you been able to have custom facilities, then yes, that would have been how it should have done. Having said that, is there any system loggin daemons which allow custom facilities? However, even if you do not have such grand plans, even just an improved syslog.conf would be very welcome :^) Neato. That's 3 people in total who think it's a good idea.. :/ Regards Kenneth
Re: Logging practices (and why does it suck in Debian?)
On Wed, 11 Apr 2001, Kenneth Vestergaard Schmidt wrote: Having said that, is there any system loggin daemons which allow custom facilities? yes, syslog-ng, for example. This was one of the main reasons I had switched to it in the past (and probably will again, when I have some time to work on it, since it seems to be supported again in unstable) Neato. That's 3 people in total who think it's a good idea.. :/ It's probably the 3 people in total who bother to check the logs... Bye Giacomo _ Giacomo Mulas [EMAIL PROTECTED], [EMAIL PROTECTED] _ OSSERVATORIO ASTRONOMICO Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA) Tel.: +39 070 71180 216 Fax : +39 070 71180 222 _ When the storms are raging around you, stay right where you are (Freddy Mercury) _
Re: Logging practices (and why does it suck in Debian?)
Hi On Wed, Apr 11, 2001 at 02:50:47PM +0200, Giacomo Mulas wrote: It's probably the 3 people in total who bother to check the logs... at least 4, just for the records, you can't administrate production servers without having logcheck or similar installed! For this reason (to stay on topic) logging should at least keep the current behaviour to have one log where everything is logged to, as it's now with /var/log/syslog. And maybe the /var/log/auth.log with stuff that most people may not see as it's security relevant. Having the current mail.err, mail.warn, mail.debug where everything with or below that severity is logged so that the admin can choose what is worth to read daily is fine for me. Disk space isn't the problem any more and if you run services that produces so much logs you'll probably have enough anyways. bye, -christian- -- Christian HammersWESTEND GmbH - Aachen und Dueren Tel 0241/701333-0 [EMAIL PROTECTED] Internet Security for ProfessionalsFax 0241/911879 WESTEND ist CISCO Systems Partner - Premium Certified
Re: Logging practices (and why does it suck in Debian?)
uOn Wed, Apr 11, 2001 at 02:50:47PM +0200, Giacomo Mulas wrote: On Wed, 11 Apr 2001, Kenneth Vestergaard Schmidt wrote: Having said that, is there any system loggin daemons which allow custom facilities? yes, syslog-ng, for example. This was one of the main reasons I had switched to it in the past (and probably will again, when I have some time to work on it, since it seems to be supported again in unstable) Neato. That's 3 people in total who think it's a good idea.. :/ It's probably the 3 people in total who bother to check the logs... I use logcheck to filter out routine log messages, and mail me the rest. Still, I'd sure like to have a revised syslog.conf. The only change I've made to mine is to log everything to tty10. This is really handy when debugging. There's a package that pipe into less on a console, so you can search and go back, but I just use *.*/dev/tty10 -- #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: Logging practices (and why does it suck in Debian?)
On Wednesday 11 April 2001 15:03, Christian Hammers wrote: For this reason (to stay on topic) logging should at least keep the current behaviour to have one log where everything is logged to, as it's now with /var/log/syslog. And maybe the /var/log/auth.log with stuff that most people may not see as it's security relevant. Why? I think it is really wasted when everything is logged to syslog, and also logged to other, more specific files. If you want to search for something, use grep. And if you want to find something, look in the log-files that are relevant. What relevancy can it ever have to log *.debug, or mail.info messages to syslog, if you want to find stuff about instrusion detection? Having the current mail.err, mail.warn, mail.debug where everything with or below that severity is logged so that the admin can choose what is worth to read daily is fine for me. Again, I think this is wasted effort. Instead, as an admin, you could read mail.err, then mail.warn, and if you still feel up to it, mail.debug - it doesn't remove any details, but 1) it uses less disk space, 2) it removes the clutter, and 3) each log file has a specific purpose. But anyway, thanks for your comments! I am really trying to find the perfect solution, although I'll probably come to realize that there isn't one :( Regards Kenneth
Re: Logging practices (and why does it suck in Debian?)
On Wed, Apr 11, 2001 at 03:29:16PM +0200, Kenneth Vestergaard Schmidt wrote: Why? I think it is really wasted when everything is logged to syslog, and also logged to other, more specific files. If you want to search for Maybe people what to archive syslog for a year and the others only for a week or so. Also I find it comfortable to e.g. do a tail -f /var/log/syslog and get everything. (ok, have to append auth.log) Again, I think this is wasted effort. Instead, as an admin, you could read mail.err, then mail.warn, and if you still feel up to it, mail.debug - it This is arguable. I don't have a real optinion on it as I use logcheck to remove the unnecessary messages from syslog and read the rest. Maybe this is really clutter. Would be interestingly to know how other distributions and other Unices do. Regards Kenneth bye, -christian- -- Christian HammersWESTEND GmbH - Aachen und Dueren Tel 0241/701333-0 [EMAIL PROTECTED] Internet Security for ProfessionalsFax 0241/911879 WESTEND ist CISCO Systems Partner - Premium Certified
Re: Logging practices (and why does it suck in Debian?)
Here is another one who bother to check the logs :) Cheers, Cristian On Wed, 11 Apr 2001, JonesMB wrote: Neato. That's 3 people in total who think it's a good idea.. :/ It's probably the 3 people in total who bother to check the logs... make that 4. I always have an xterm with a tail -f /var/log/syslog running so I can see what is happening to the system. I have a firewall setup but I don't know if it is good enough so I usually monitor the syslog file for suspicious activity.
Re: Logging practices (and why does it suck in Debian?)
On Wed, Apr 11, 2001 at 01:40:13PM -0500, JonesMB wrote: make that 4. I always have an xterm with a tail -f /var/log/syslog running so I can see what is happening to the system. I have a firewall setup but I don't know if it is good enough so I usually monitor the syslog file for suspicious activity. This is more of a helpful comment or someone new to security on debian. Monitoring the logs (i.e. syslog) for suspicious activity may NOT provide you with any details of suspicious activity by default. Please make sure you have properly setup your firewall and have it reporting details (you request) to your log. Also some sort of intrusion detection (snort), will also help your effort. Mark Hurley
