Re: using sarge on production machines
Stefan Fritsch wrote: > Updates that fix security issues usually have urgency=high and change > faster to testing. However, you cannot trust this since new release > critical bugs might still keep the new package from entering testing. New release critical bugs need not keep a security update from testing, unless the new release with the security update itself introduced more release critical bugs than it solved. If unrelated RC bugs are filed, the release team has the power to force a security fix into testing anyway. Dependency issues blocking a security update from reaching testing remains the main blocker for security updates reaching testing and probably will continue to do so until the autobuilders fully support testing. -- see shy jo signature.asc Description: Digital signature
Re: using sarge on production machines
Hi! On Saturday 19 February 2005 02:40, kurt kuene wrote: > so there WAS really a security team at that time. I eventually have > thought that I had only dreamed or misunderstood something. but > this is not debian-like. I have thought that if they run security > updates they will not just stop them again. No. There was never working security support for sarge. The testing-security-team checks which known security issues are still unfixed in sarge but there was never any infrastructure to ensure that fixes went in quickly. There are still quite a few unfixed issues [1]. > Do packages with important security problems (for example: remote > execution of arbitrary code) change faster from unstable to > testing? I think this is so but I am not sure... Updates that fix security issues usually have urgency=high and change faster to testing. However, you cannot trust this since new release critical bugs might still keep the new package from entering testing. Cheers, Stefan [1] http://merkel.debian.org/~joeyh/testing-security.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: using sarge on production machines
In article <[EMAIL PROTECTED]> you wrote: > I also think sarge will be used more and more over the next few weeks > and months whether it is released or not, certainly where security is > not such a big issue. Well, if you need a secure samba or recent PHP, you may not have an option. Greetings Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: using sarge on production machines
> "Florian" == Florian Weimer <[EMAIL PROTECTED]> writes: Florian> Running unreleased software on production systems is a Florian> touchy issue. Most system administrators simply won't Florian> admit it. We've started running sarge on at least one new internal production server - its a new backup/archive system and is not 100% in production yet, bits of it are but not all. Apparently it was setup painlessly although I'm not sure how it was installed whether using cfengine which we use for nearly all systems our hand installed then cfengine'd afterwards. I also think sarge will be used more and more over the next few weeks and months whether it is released or not, certainly where security is not such a big issue. Sincerely, Adrian Phillips -- Who really wrote the works of William Shakespeare ? http://www.pbs.org/wgbh/pages/frontline/shakespeare/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: using sarge on production machines
hi David Ehle <[EMAIL PROTECTED]> wrote: > IF, I had, say late last year heard that Sarge was going > stable REAL SOON, > and was trying to decide if I was going to go through the hoops being > described, or just do an early upgrade, since there WAS at the time a > working security repository for sarge, > I might have, Hypothetically, moved > some of my production systems to Testing. > If that had occurred, I might be > able to tell you that things have gone relativly > painlessly and safely. > But as was pointed out earlier, >doing something like that IS kind of iffy, > so of course, I couldn't do such a thing... this is exactly my situation! you described it better then me :) so there WAS really a security team at that time. I eventually have thought that I had only dreamed or misunderstood something. but this is not debian-like. I have thought that if they run security updates they will not just stop them again. however the situation is as it is. not good for me. but I have been very lucky because nothing special happened to my systems until now. I touch wood that the systems remain secure until the security-team begins its work again :) but this might not be enough. also the trust that I put in the debian project might not be enough. although debian sarge is called testing it is relatively stable and most of the time also secure comparing to other distros or even operating systems. but this is not enough. If debian sets up a security team for a distro, this persuades admins to upgrade. but then the work is stopped or has to be stopped for what reason does not matter. I believe that there are very good reasons for the stop (infrastructure issue). however I think that the debian project should develop a security concept that covers such problems at least partly. I think even that there are approaches: for example the priority with which a package transits from unstable to testing. Do packages with important security problems (for example: remote execution of arbitrary code) change faster from unstable to testing? I think this is so but I am not sure... Are there other debian related sources about securing sarge besides of this? http://secure-testing.alioth.debian.org/ How does debian deal with the problem? and specially because of this: >Running unreleased software on production systems is a touchy issue. >Most system administrators simply won't admit it. so, if admins do not admit it. no one talks about it. if no one talks about some thing, does this improve security?? I know that debian has a stable and very secure release but what resources does the debian project give to admins who have done the "mistake" of running sarge too early, because of reasons described above. what strategies are applied to deal with the problem? I talk like this because I trust the debian project very much and I also expect very much from it. the expectations are very high because debian does a very good job. so there must be some idea around ... thanks a lot again for the interesting feedback. It has clarified a many things. regards kuene -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: using sarge on production machines
> > Nobody is using Sarge? Am I the only one running Sarge on Servers? > > why? thats what I get to hear... > > no one uses sarge for important things? > > Running unreleased software on production systems is a touchy issue. > Most system administrators simply won't admit it. > Um... yes it would be hard to admit it. IF, I had, say late last year heard that Sarge was going stable REAL SOON, and was trying to decide if I was going to go through the hoops being described, or just do an early upgrade, since there WAS at the time a working security repository for sarge, I might have, Hypothetically, moved some of my production systems to Testing. If that had occurred, I might be able to tell you that things have gone relativly painlessly and safely. But as was pointed out earlier, doing something like that IS kind of iffy, so of course, I couldn't do such a thing... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: using sarge on production machines
* kurt kuene: >>From time to time, there was quite a lot of significant breakage >>(especially when we weren't as close to the release as we are now), >>but as I didn't have to fulfill any SLAs, it was typically no big deal >>to sort out the issues when they arose. > > so you think unstable with an eye on problems is still better than > testing? I don't know. If you know what you are doing, it seems to be less work. >>(especially when we weren't as close to the release as we are now) > close to the release? Yes. Otherwise, we would have had transitions to GCC 3.4 and libc 2.3.4 in the meantime, which would have had at least some impact on the stability of sid. > if only the security team would start working *sigh*. The team is ready, it's an infrastructure issue AFAIK. > Nobody is using Sarge? Am I the only one running Sarge on Servers? > why? thats what I get to hear... > no one uses sarge for important things? Running unreleased software on production systems is a touchy issue. Most system administrators simply won't admit it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: using sarge on production machines
Marc Haber schrieb am Friday, den 18. February 2005: > On Fri, Feb 18, 2005 at 04:40:56AM -0800, Harry wrote: > > --- Marc Haber <[EMAIL PROTECTED]> wrote: > > > What does this gain you? A compomised uml is as bad as a compromised > > > system. > > > Nice idea. However, if somebody roots one of the UML installation, > that somebody can probably escape out of the UML and gain user > privileges on the host system and then use one of the numerous kernel > vulnerabilities (I have long lost track of them) to escalate to root > on the host system. > > I am quite sceptical about using UML to allow security flaws in UMLled > system components. Have a look at vservers (http://linux-vserver.org/), designed specifically to fix the problems that can be circumvented with chroots, take up significantly less resources than UMLs, and are really quite cool. micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: using sarge on production machines
On Fri, Feb 18, 2005 at 03:28:11PM +0100, kurt kuene wrote: > so you think unstable with an eye on problems is still better than testing? I > don't know. Unstable is fine if you know exactly what you're doing and can fix a broken system yourself. unstable is potentiall unstable (surprise), but more secure since security-related updates go into unstable immediately. > if only the security > team would start working *sigh*. afaik, the security team is ready, but the infrastructure is not. > >From: Marc Haber <[EMAIL PROTECTED]> > >It is better to have a broken service. If you know exactly what you're > >doing, and take a close look at changelogs, this might be a good > >option. Maybe don't track unstable closely, but only update every - > >say - two weeks, while keeping a close look at new uploads' changelogs > >to spot security issues. > > what I do no understand is why this should be more secure than > running testing? You can immediately install a package that received a security update on an unstable system. If you do the same on testing (installing a package from unstable on a testing system), you will pull in libraries from unstable, potentially introducing breakage. > so nobody here is using sarge on productive systems?? Well, I am not. > I am always told that sarge comes soon. so why use sid? if sarge is > coming soon why worry? Currently, the sarge security infrastructure is missing. Thus, you will have a mandatory delay to wait for a fixed package to migrate from unstable to testing. > apt-pining gives a false security feeling. so pining is deceptive. Well, pinning was never intended to allow mixded-distribution systems. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: using sarge on production machines
hi first thanks a lot. you all helped me very much. apparently running stable with backports is best. so I made the wrong decision upgrading my systems to sarge. :( I did this because I thought it will come out soon and It is safe enough to use it. This was six month ago. If I could turn back time I would use backports. >Florian Weimer <[EMAIL PROTECTED]> >From time to time, there was quite a lot of significant breakage >(especially when we weren't as close to the release as we are now), >but as I didn't have to fulfill any SLAs, it was typically no big deal >to sort out the issues when they arose. so you think unstable with an eye on problems is still better than testing? I don't know. >(especially when we weren't as close to the release as we are now) close to the release? this was what I thought 6 month ago (changed to testing) and it may take an other six month. if only the security team would start working *sigh*. >From: Harry <[EMAIL PROTECTED]> > use UML and chroot it and run sarge in it. UML is no option for me because my users do not need root. on some machines they have ftp only without shell on the oder they have a shell user account without ftp. if uml gets hacked I need to use my backup anyway. naturally I have a complete backup of the systems. so if something bad happens I can play back everything, plug the hole and go back online. this would cost me some time, but more nerves. :| >From: Marc Haber <[EMAIL PROTECTED]> >It is better to have a broken service. If you know exactly what you're >doing, and take a close look at changelogs, this might be a good >option. Maybe don't track unstable closely, but only update every - >say - two weeks, while keeping a close look at new uploads' changelogs >to spot security issues. what I do no understand is why this should be more secure than running testing? so nobody here is using sarge on productive systems?? -- some use stable. this is best. -- if they need newer packages, using backports is best. I would do this if i could downgrade from sarge. but this is a pain in ... -- others use sid and makes updates only every two weeks if no security issue appear. -- I am always told that sarge comes soon. so why use sid? if sarge is coming soon why worry? summary: I would use backport if I could go back. I would not use sid because of stability. apt-pining gives a false security feeling. so pining is deceptive. -- Nobody is using Sarge? Am I the only one running Sarge on Servers? why? thats what I get to hear... no one uses sarge for important things? it is quite stable. but how to make it secure? at least some people know what I mean: http://secure-testing.alioth.debian.org/ fact is: I am using Sarge! :/ are there strategies in Securing Sarge that I have missed? Or would someone suggest me to downgrade, because it is far too dangerous using sarge on servers, or even on machines that are on the net? again thanks a lot for all the help :) regards kuene -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: using sarge on production machines
* kurt kuene: > so what strategies to use if you are forced to work with a distro > other then woody? I used to run unstable with irregular updates, and manually backport upstream security fixes to the version in unstable (especially if a new Debian packages was not available in unstable). >From time to time, there was quite a lot of significant breakage (especially when we weren't as close to the release as we are now), but as I didn't have to fulfill any SLAs, it was typically no big deal to sort out the issues when they arose. A different model uses unstable and periodic updates (say on a fixed day of the week), and security updates from unstable. This works reasonably well, too, although I wouldn't recommend to follow this model after the sarge release (because unstable will probably be less stable for a few months; there are some quite significant transitions that have been delayed so far because of the release). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: using sarge on production machines
--- Marc Haber <[EMAIL PROTECTED]> wrote: > Nice idea. However, if somebody roots one of the UML installation, > that somebody can probably escape out of the UML and gain user > privileges on the host system and then use one of the numerous kernel > vulnerabilities (I have long lost track of them) to escalate to root > on the host system. I can't guarantee 100% security but I can make it harder for someone to do it, its a trade off. As for gaining user rights on the host. Each user has passwords disabled and is in a chroot jail. The kernel is statically linked so there are 2 files in the jail, the kernel and the filesystem. It might not be bullet but then I have yet to hear of anything that is. > I am quite sceptical about using UML to allow security flaws in > UMLled system components. Thats not what I am doing, I offer UML accounts because people want root on a machine. I am certainly not about to give them all root on the host. Harry __ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: using sarge on production machines
> "Marc" == Marc Haber <[EMAIL PROTECTED]> writes: Marc> Nice idea. However, if somebody roots one of the UML Marc> installation, that somebody can probably escape out of the Marc> UML and gain user privileges on the host system and then use Marc> one of the numerous kernel vulnerabilities (I have long lost Marc> track of them) to escalate to root on the host system. Marc> I am quite sceptical about using UML to allow security flaws Marc> in UMLled system components. How pray tell do they do that ? A minimal UML chroot requires one file - the user mode linux binary. Check out the following :- http://user-mode-linux.sourceforge.net/slides/ists2002/umlsec.htm which discusses how UML can help with security and mentions chroot. Since this paper was written many people have used chrooted UMLs with great success. And just because one wants to use newer versions of packages on another "machine" (in theis case a virtual machine) doesn't mean that the physical host is left running old versions of packages with security holes in it. The original poster never mentioned leaving the machine unsecured. Sincerely, Adrian Phillips -- Who really wrote the works of William Shakespeare ? http://www.pbs.org/wgbh/pages/frontline/shakespeare/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: using sarge on production machines
--- Marc Haber <[EMAIL PROTECTED]> wrote: > On Fri, Feb 18, 2005 at 02:25:17AM -0800, Harry wrote: > > use UML and chroot it and run sarge in it. > > What does this gain you? A compomised uml is as bad as a compromised > system. I can wipe the UML if the host has not been compromised. This saves me a journey to the location where the host is stored and £75 quid to get to the machine to reinstall the host. If I have ten customers running various falvours of Debian in their UML its sods law that eventually one of them is going to be cracked. If I can prevent (as much as feasbly possible) this from spilling onto the host then it saves me a lot of work. Harry __ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: using sarge on production machines
On Fri, Feb 18, 2005 at 04:40:56AM -0800, Harry wrote: > --- Marc Haber <[EMAIL PROTECTED]> wrote: > > What does this gain you? A compomised uml is as bad as a compromised > > system. > > I can wipe the UML if the host has not been compromised. This saves me > a journey to the location where the host is stored and ?75 quid to get > to the machine to reinstall the host. > > If I have ten customers running various falvours of Debian in their UML > its sods law that eventually one of them is going to be cracked. If I > can prevent (as much as feasbly possible) this from spilling onto the > host then it saves me a lot of work. Nice idea. However, if somebody roots one of the UML installation, that somebody can probably escape out of the UML and gain user privileges on the host system and then use one of the numerous kernel vulnerabilities (I have long lost track of them) to escalate to root on the host system. I am quite sceptical about using UML to allow security flaws in UMLled system components. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: using sarge on production machines
On Fri, Feb 18, 2005 at 02:25:17AM -0800, Harry wrote: > use UML and chroot it and run sarge in it. What does this gain you? A compomised uml is as bad as a compromised system. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: using sarge on production machines
--- kurt kuene <[EMAIL PROTECTED]> wrote: > All of my 3 webservers (apache php mysql java tomcat). > on two other webserver I run woody with some packages from sarge > (apt-pining) > and the mail relay servers (spamassasin amavisd postfix clamav). > > I run sarge because I need more recent packages and I do not want to > use an other distro because I dont trust them as I trust the debian > project. I do not want to complain about sarge not being released, > this is not the place to do that. > > but my users (I work for a university of art and do linux based web > and mailserver there) want newer packages. > so somehow I was forced to upgrade to a newer version of debian. Some people have already said it. Use stable with backports. Where this absolutely won't do use UML and chroot it and run sarge in it. This is what I'm doing[0]. Harry [0] Not necessarily a positive recommendation ;) = Harry Join team plico. http://www.hjackson.org/cgi-bin/folding/index.pl __ Do you Yahoo!? All your favorites on one personal page Try My Yahoo! http://my.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: using sarge on production machines
On Fri, Feb 18, 2005 at 02:14:35AM +0100, kurt kuene wrote: > 1) > running unstable. > the updates are faster. security should be better then in testing. > but stability is far better in testing. > so the question is: > is it better to have a broken service or an insecure one? It is better to have a broken service. If you know exactly what you're doing, and take a close look at changelogs, this might be a good option. Maybe don't track unstable closely, but only update every - say - two weeks, while keeping a close look at new uploads' changelogs to spot security issues. > 2) > 2a) > using stable with backports: > backports may have security problems and stability problems. you have to > trust the maintainer of the package. > and read security news. > I think this is good if you need only few packages. That is IMO the best solution. > 2b) > running stable with some sarge packages (apt-pining) > the base system is stable and gets the security updates. Bad idea. One of your first sarge packages will pull in libc6 from sarge, and already your assumption that the base system is stable is wrong. Same goes for other libraries that might get pulled in from sarge. > the problem I have is that I have very little time and can not track > every security issue every time. so I must find some simple resources > or strategies to keep my systems save. Use stable with backports, maybe hire somebody external to look after your systems. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: using sarge on production machines
On 18 Feb 2005, kurt kuene wrote: > * I have to use testing (sarge). * Have to? > All of my 3 webservers (apache php mysql java tomcat). on two other > webserver I run woody with some packages from sarge (apt-pining) and > the mail relay servers (spamassasin amavisd postfix clamav). IIRC, all of those are available from backports.org, which would allow you to upgrade only those portions, keeping the rest of your system on the nice, stable basis of the current release. [...] > so what strategies to use if you are forced to work with a distro > other then woody? 0) Use backports.org, or do backports myself. Really, this is usually a lot less painful than it sounds, especially with the existing backports people doing most of what I care about for me. > 1) > running unstable. > the updates are faster. security should be better then in testing. > but stability is far better in testing. Is it? I can't honestly say that I have noticed that, frankly. > so the question is: > is it better to have a broken service or an insecure one? Broken, honestly. Insecure means that you get to spend your time picking up the pieces as you restore from backups (4 hours, at least), rather than fielding a few irate phonecalls. ...or you could use a "testbed" machine which you run your system acceptance tests against before you commit to any upgrades on your production systems. :) [...] > the problem I have is that I have very little time and can not track > every security issue every time. so I must find some simple resources > or strategies to keep my systems save. Using backports.org is usually sufficient -- they are on top of security issues very quickly, and you can watch their (low traffic) mailing list without too much time spent. Also, I recommend bugtraq as a way of knowing what is coming up; be brutal about filtering it away and ignoring anything you don't run, and it works pretty well I find. [...] > I am a bit worried and I begin to be nervous because of sarge is still > testing. If you can help me with suggestions about how to deal best > with the problem of using sarge in productive environments. (without > changing the distro) I hope my suggestions help. :) Daniel -- It could be that the real universe...is perhaps what has been started by some disastrous experiment performed some twenty billion years ago by a post-graduate student in order to test the structure of a vacuum of another universe. -- Johann Rafelski and Berndt Muller, _The Structured Vacuum_ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
using sarge on production machines
hi * I have to use testing (sarge). * All of my 3 webservers (apache php mysql java tomcat). on two other webserver I run woody with some packages from sarge (apt-pining) and the mail relay servers (spamassasin amavisd postfix clamav). I run sarge because I need more recent packages and I do not want to use an other distro because I dont trust them as I trust the debian project. I do not want to complain about sarge not being released, this is not the place to do that. but my users (I work for a university of art and do linux based web and mailserver there) want newer packages. so somehow I was forced to upgrade to a newer version of debian. -- * strategies * so what strategies to use if you are forced to work with a distro other then woody? 1) running unstable. the updates are faster. security should be better then in testing. but stability is far better in testing. so the question is: is it better to have a broken service or an insecure one? 2) 2a) using stable with backports: backports may have security problems and stability problems. you have to trust the maintainer of the package. and read security news. I think this is good if you need only few packages. 2b) running stable with some sarge packages (apt-pining) the base system is stable and gets the security updates. some packages come from testing and they are important and they get no security updates. I think this could be an option if the packages have not many dependencies otherwise this could be bad for stability. but the debian package system is quite flexible and if you configure apt pining correctly it woks astoundingly reliable. 2c) running stable and compiling newer packages directly from the relative project. this means a lot of work. I just have not the time for this. 3) running sarge sarge works quite stable. but has many updates. however they work. sometimes configration problems can happen during an update but they can be fixed easily. I am using debian for quite a while now also on desktop and testing had never real stability problems. so there is the security problem. sarge does not get any security updates. even right now that the sarge base system has been frozen. so am trying 2b and 3 both works for quite a while now on my servers but I am more afraid about security problems than stability. the problem I have is that I have very little time and can not track every security issue every time. so I must find some simple resources or strategies to keep my systems save. * weapons * so I have subscribed to some mailing lists: debian-security-announce@lists.debian.org this is cool! also I have an eye on: http://merkel.debian.org/~joeyh/testing-security.html great work! and for some special packages I can use the direct apt source of the trusted maintainer of a specific package for example clamav: http://people.debian.org/~sgran/ this might be even better than stable because I get the updates of the virus scanner very fast because sgran does a very good job. so, for a mail relay with spam filter and virus scanner sarge might be better and on some aspects more secure than stable. - what strategies are best? please write some opinions and suggestions about this issue. I am a bit worried and I begin to be nervous because of sarge is still testing. If you can help me with suggestions about how to deal best with the problem of using sarge in productive environments. (without changing the distro) thank you a lot. kuene -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
