Re: apt-get and mounting /tmp with noexec option
On Wed, Jan 14, 2004 at 03:53:35AM +0100, Arnoud Warmerdam wrote:
Hi,
I have mounted my /tmp directory (which has it's own partition) with the
noexec option. The reason i did this, was that a poorly written cgi-script
caused a binary to be downloaded and executed in /tmp. Luckily, the
firewall prevented it from doing any harm, but i wanted to prevent this
from happening again. In the future i plan to place apache in a chroot
jail, but in the meantime this seemed like a good thing to do. Here is the
line from my /etc/fstab:
/dev/sda9 /tmpext2noexec,nosuid,rw0 2
-snip-
Is it considered bad practice to mount /tmp with the noexec option? If not,
is there a way to tell apt to use another directory?
- Arnoud Warmerdam
I got tmp mounted noexec too.
/etc/apt/apt.conf.d/70debconf:
// Pre-configure all packages with debconf before they are installed.
// If you don't like it, comment it out.
#DPkg::Pre-Install-Pkgs {/usr/sbin/dpkg-preconfigure --apt || true;};
As you see, i dont like it.
--
Frode Haugsgjerd
Norway
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
need your help
i gave a following command ...as a result i was supposed to find a checkpasswor file inside bin \bin\checkpassword ...But i did not find any thing like that . So could you tell what may be my mistake for not finding the checkpassword file inside bin . kindly have a look on below mention things too :- [EMAIL PROTECTED] root]# gunzip checkpassword-0.90.tar [EMAIL PROTECTED] root]# tar -xf checkpassword-0.90.tar [EMAIL PROTECTED] root]# cd checkpassword-0.90 [EMAIL PROTECTED] root]# make [EMAIL PROTECTED] root]# make setup check -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: need your help
- Original Message - From: Ujjwal Rana [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 14, 2004 12:14 AM Subject: need your help i gave a following command ...as a result i was supposed to find a checkpasswor file inside bin \bin\checkpassword ...But i did not find any thing like that . So could you tell what may be my mistake for not finding the checkpassword file inside bin . kindly have a look on below mention things too :- Your mistake is that checkpassword is in /usr/bin : /usr/bin/checkpassword -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Considering Debian (currently using Red Hat)
Hi Everyone, I'd like to get some of your thoughts on a few things relating to the possibility of our company switching distributions from Red Hat to Debian. As most folks already know, Red Hat has drastically changed their strategy, and we ultimately must make *some* relatively drastic changes no matter what. And, we intend not to switch to RHEL (though not for financial reasons). This gives us the opportunity, welcome or not, to consider other distributions. And even other OS's -- we're frankly not closed to the idea of ultimately switching platforms entirely to BSD or Solaris. So with this in mind, 1.) One of the biggest reasons we went with Red Hat many years ago was RPM. Of course I know that Debian has a package system, and there're constant arguments about which is better, if either. What I wonder, though, is how they compare for the purposes of security checking. On a Red Hat system, practically any file or directory outside of /home can be found within the RPM database. We can check each and every file, its MD5 hash, etc. It's like having a built-in Tripwire installation so long as you trust the RPM database. We've modified the RPM installation such that we can trust it more than we trust Tripwire. Do Debian packages have similar security built-in? 2.) A related reason we used Red Hat was that practically anything you could want to use was pre-packaged in a simple to install RPM. And they were typically pretty high quality RPM's, and very often well maintained. Do admins typically find that they're able to find Debian packages for most software they're typically interested in using? I realise this varries greatly between markets, but I guess what I'm asking is do you usually find 70% of the packages you're interested in in Debian package format, and well maintained? 80%? Just a general idea. 3.) I read quite a bit of the Web site, and see that in general, releases seem to be very far and few between. This is advantageous to ISP's, of course, because we want things to just work. Is my perception correct in that releases are far apart? When is the next release expected? How significant is the difference from, say, 3.0 and 3.1. Can you just install a bunch of packages and call it an upgrade, or do you have to go through a whole ordeal as you do between Red Hat .X versions? 4.) How long are previous versions maintainaned with patches and such? Or to restate this, how long after a new version is released are you FORCED to upgrade in order to maintain security? How drastic are the changes in between minor version increments (say, 3.0 to 3.1)? For example, Red Hat has tended to make significant kernel upgrades and glibc upgrades in minor version changes, and has caused significant incompatibilities that have caught us by surprise. 5.) Of course we'll be testing it extensively ourselves, but what would you say the most significant differences, both from a user and an admin perspective, are between Debian and Brand X Linux? Or, maybe better stated, why Debian? I know that's a religeously charged question, but at the moment our only position is not RHL. We're open to being converted ;-) 6.) And finally, if you care to toss in any ideas or info, I'm very glad and excited to hear it. For instance, if you were going to switch all your systems within the next year, would you choose something else? A BSD port? Go back to Solaris? Novell? SCO? Just kidding. Thanks very much! -Fred Whipple -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Considering Debian (currently using Red Hat)
-Original Message- From: Fred Whipple [mailto:[EMAIL PROTECTED] Sent: 14 January 2004 14:57 To: [EMAIL PROTECTED] Subject: Considering Debian (currently using Red Hat) Hi Everyone, I'd like to get some of your thoughts on a few things... 1) Package: cruft Priority: optional Section: admin Installed-Size: 636 Maintainer: Anthony Towns [EMAIL PROTECTED] Architecture: i386 Version: 0.9.6-0.4 Depends: libc6 (= 2.3.1-1), file Filename: pool/main/c/cruft/cruft_0.9.6-0.4_i386.deb Size: 26690 MD5sum: a1dfa3e1828f92cbf9e03223f498f07c Description: Find any cruft built up on your system cruft is a program to look over your system for anything that shouldn't be there, but is; or for anything that should be there, but isn't. . It bases most of its results on dpkg's database, as well as a list of `extra files' that can appear during the lifetime of various packages. . cruft is still in pre-release; your assistance in improving its accuracy and performance is appreciated. I think that's what you want. Seems to work - just tried it. 2) Debian is the biggest distribution, it has *more* packages than redhat. It has almost 9000 packages in the main stable tree, I believe. Generally I find that I can find any program I want. If it's not in debian it's not worth having in a lot of cases! The exception to this is driver packages which often come as rpm-only. Anything non-proprietary is usually debian packaged, however. 3) Debian is not released in the same way as redhat, which seems to follow a windows style of releases. Debian development is a continous stream. A release is created by first taking a branch off the main development stream (unstable), calling it testing and declaring a freeze on any new packages or non security changes. After a while, that is released as the next stable release. Stable in this case means version-stable, It doesn't necessarily imply that newer development streams are more unreliable. If you were to take your updates from the unstable tree, as I do, you would never have install a upgrade, as your system would always be the latest. Even if you dont, upgrading doesn't involve finding a cd and rebooting, a apt-get dist-upgrade will do. 4) Stable like you say is updated fairly infrequently, however security updates are released at the same time as for other releases/trees/streams. I believe you can use the security updates no matter how old your initial release of debian is. 5) There's the political differences, as you are aware, but i'd say the biggest difference between debian and redhat is the absolute ease that you can keep your whole system up to date and the efficiency of the packaging system - dependency conflicts are rare on the unstable branch and unheard of on the stable and testing branches. There's none of this nonsense about premium updates support, special privileged ftp servers, etc. There is a large network of mirrors, and they all work reliably and quickly. 6) If it was a choice between GNU/Linux'es, debian, if it was a more general OS choice, it would depend on the task at hand. Dan Ros -Original Message- From: Fred Whipple [mailto:[EMAIL PROTECTED] Sent: 14 January 2004 14:57 To: [EMAIL PROTECTED] Subject: Considering Debian (currently using Red Hat) Hi Everyone, I'd like to get some of your thoughts on a few things relating to the possibility of our company switching distributions from Red Hat to Debian. As most folks already know, Red Hat has drastically changed their strategy, and we ultimately must make *some* relatively drastic changes no matter what. And, we intend not to switch to RHEL (though not for financial reasons). This gives us the opportunity, welcome or not, to consider other distributions. And even other OS's -- we're frankly not closed to the idea of ultimately switching platforms entirely to BSD or Solaris. So with this in mind, 1.) One of the biggest reasons we went with Red Hat many years ago was RPM. Of course I know that Debian has a package system, and there're constant arguments about which is better, if either. What I wonder, though, is how they compare for the purposes of security checking. On a Red Hat system, practically any file or directory outside of /home can be found within the RPM database. We can check each and every file, its MD5 hash, etc. It's like having a built-in Tripwire installation so long as you trust the RPM database. We've modified the RPM installation such that we can trust it more than we trust Tripwire. Do Debian packages have similar security built-in? 2.) A related reason we used Red Hat was that practically anything you could want to use was pre-packaged in a simple to install RPM. And they were typically pretty high quality RPM's, and very often well maintained. Do admins typically find that they're able to find Debian packages for most software they're typically interested in
Re: Considering Debian (currently using Red Hat)
On Wed, 14 Jan 2004 09:56:35 EST, Fred Whipple writes: I'll answer just the points I have opinions/knowledge on. 2.) A related reason we used Red Hat was that practically anything you could want to use was pre-packaged in a simple to install RPM. And they were typically pretty high quality RPM's, and very often well maintained. Do admins typically find that they're able to find Debian packages for most software they're typically interested in using? I realise this varries greatly between markets, but I guess what I'm asking is do you usually find 70% of the packages you're interested in in Debian package format, and well maintained? 80%? Just a general idea. Debian uses the .deb package format. I'd guess that well over 90 % of the software we need can be found pre-packaged (and well-maintained) as .deb's. 3.) I read quite a bit of the Web site, and see that in general, releases seem to be very far and few between. This is advantageous to ISP's, of course, because we want things to just work. Is my perception correct in that releases are far apart? Stable releases are quite far apart, yes. When is the next release expected? How significant is the difference from, say, 3.0 and 3.1. Can you just install a bunch of packages and call it an upgrade, or do you have to go through a whole ordeal as you do between Red Hat .X versions? Upgrading to a new release is just an `apt-get dist-upgrade` away. I've personally upgraded a box through every release from 1.mumble to 3.0 . 4.) How long are previous versions maintainaned with patches and such? Or to restate this, how long after a new version is released are you FORCED to upgrade in order to maintain security? A couple months at least, usually about half a year. How drastic are the changes in between minor version increments (say, 3.0 to 3.1)? For example, Red Hat has tended to make significant kernel upgrades and glibc upgrades in minor version changes, and has caused significant incompatibilities that have caught us by surprise. Debian focuses on security and stability in the stable branch, so there never should be any problems with that as long as you track stable (the testing and unstable releases are another matter, just as their names suggest). The trade-off, of course, is that new software (resp. new versions of software) takes its time to make it into the stable branch. 6.) And finally, if you care to toss in any ideas or info, I'm very glad and excited to hear it. For instance, if you were going to switch all your systems within the next year, would you choose something else? A BSD port? Go back to Solaris? Novell? SCO? Just kidding. IMHO Debians main advantage is the packaging. You can track security-updates of _all_ installed packages with a simple `apt-get upgrade`, and there should never be any surprising side-effect to it. Re-installs of the system for upgrading purposes are unknown for Debian (unless you're upgrading _to_ Debian ;) ). Another advantage is that there's no integrated admin-tool which will destroy your precious hand-crafted config files, no yast or suseconfig or somesuch. The downside to that is that you have to know how to use an editor, of course, and there's mostly no setup wizards to guide you. Packages do, of course, come with mostly sensible (and secure) default configs, though. Should an upgrade have the necessity to change a config-file, it'll ask you if you want it to (it can also show you a diff first) or not. Plus. according to policy, there's at least a man-page for everything in *bin and /etc, and some documentation for _eachevery_ installed package in /usr/share/doc/package. cheers, rw -- / Ing. Robert Waldner | Security Engineer | CoreTec IT-Security \ \ [EMAIL PROTECTED] | T +43 1 503 72 73 | F +43 1 503 72 73 x99 / pgp0.pgp Description: PGP signature
Re: Anybody Running OpenWebMail ?
Hello! We use it with a lot of success. It servers for web interface to mail for around 2000 customers - we are quite happy with. W liście z pon, 12-01-2004, godz. 20:56, Kevin Lynch pisze: Kevin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considering Debian (currently using Red Hat)
A few things that I haven't seen mentioned yet: If you decide to run stable, but want just some latest and gratest software you can normally download the latest Debianized source and compile you own pacakges against stable. There are also plenty of places on the net to get backported packages, but if you are security minded I would want to roll them myself, unless you really trust the UNOFFICIAL backport maintainer and the mirrors you are downloading from (there is another thread about this going on right now IIRC). So you just install a stable system, keep up with the security updates, build your own local repository (plenty of ways to do this) and build the few packages that you need newer versions of. This is what I am doing (just got apt-proxy working and it's great). This gives you a known secure system, and all you have to keep an eye on is security advisories that affect the packages you have built yourself. I keep my servers on stable, and run my workstations on testing. Also personally I don't have anything that is automatically updated, I prefer to be notified of updates and then apply them myself, just to be safe (who in there right mind would have any automatic changes, no matter how trusted the source, on a mission critical server?). If you've built your own integrity checker for RPM's then this should be a piece of cake for you. Personally I think that the biggest problem people have with Debian is just naming related. If it were called Server-Stable Workstation-Testing Painfully Bleeding Edge-Unstable One of the biggest complaints that I hear about Debian is that stable is too outdated. Well of course it is, that is what makes so great, everything is extremely well tested and works. This takes time, how else would you get this level of stability. Our (while not a maintainer I do feel like part of the family) testing distrobution is as/more stable than many other distros normal releases. Please take a look at the debian policy manual for more info on how debian is structured, it will answer many questions (I think I need to reread the policy manual myself). http://www.debian.org/doc/devel-manuals#policy Well I actually have a few more opinions on this subject, but I have to run for now. Back in a while. Matt Wehland [EMAIL PROTECTED] Littlegrassy.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
two router one host
I have got a second connection. My server is in one class C subnet, say a.b.c.d with a default gateway a.b.c.1 I have added a second connection eth1 g.f.e.246/30 (whose router, you can guess, is g.f.e.245) . Of course with this setup i can only access the router via the second NIC. If i add a second default route it end always using the second nic, it works for some addresses, but not for most: it looks that some host use the other route and the packet are not answered . I fear that it sends packets via eth1 with a.b.c.d address. What is the setup i have to add to have it working correctly. Also is there a script to change default route from one NIC to the Other if the connection is broken ? -- Leonardo Boselli Nucleo informatico e Telematico Dipartimento Ingegneria Civile Universita` di Firenze Via Santa Marta 3 I-50139 Firenze +39 055-4796-431 +39 348-8605-348 fax 055-495-333 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considering Debian (currently using Red Hat)
Fred Whipple said on Wed, Jan 14, 2004 at 09:56:35AM -0500: 1.) One of the biggest reasons we went with Red Hat many years ago was RPM. Of course I know that Debian has a package system, and there're constant arguments about which is better, if either. What I wonder, though, is how they compare for the purposes of security checking. On a Red Hat system, practically any file or directory outside of /home can be found within the RPM database. We can check each and every file, its MD5 hash, etc. It's like having a built-in Tripwire installation so long as you trust the RPM database. We've modified the RPM installation such that we can trust it more than we trust Tripwire. Do Debian packages have similar security built-in? Yes. Debian packages contain an MD5 sum of all of the packages in the deb. You can check these with the debsums tool. However, Debian has several security scanners packaged that are probably better than just using debsums; AIDE comes to mind. 2.) A related reason we used Red Hat was that practically anything you could want to use was pre-packaged in a simple to install RPM. And they were typically pretty high quality RPM's, and very often well maintained. Do admins typically find that they're able to find Debian packages for most software they're typically interested in using? I realise this varries greatly between markets, but I guess what I'm asking is do you usually find 70% of the packages you're interested in in Debian package format, and well maintained? 80%? Just a general idea. Over 80%. In general, I'd say that the more popular Debian packages are extremely well maintained, while the smaller, less popular packages range from extremely well maintained to pretty good. I do end up backporting from unstable to stable for a few packages that I want newer versions of. 3.) I read quite a bit of the Web site, and see that in general, releases seem to be very far and few between. This is advantageous to ISP's, of course, because we want things to just work. Is my perception correct in that releases are far apart? When is the next release expected? How significant is the difference from, say, 3.0 and 3.1. Can you just install a bunch of packages and call it an upgrade, or do you have to go through a whole ordeal as you do between Red Hat .X versions? Stable releases are far apart; one every 1.5 - 2 years, historically. Not sure when the next release is; sometime this year (2004), hopefully. Since 3.1 hasn't released yet, I'm not sure, but generally a new release involves a new major kernel revision (2.2 - 2.4, or 2.4 - 2.6), a new major libc, and new major releases of most of the important subsystems. Debian makes a point of having upgrades being smooth and as painless as possible; I've gone through two major upgrades by simply running `apt-get dist-upgrade', and it worked well. Obviously, you'll want to take precautions and have time to test. 4.) How long are previous versions maintainaned with patches and such? Or to restate this, how long after a new version is released are you FORCED to upgrade in order to maintain security? How drastic are the changes in between minor version increments (say, 3.0 to 3.1)? For example, Red Hat has tended to make significant kernel upgrades and glibc upgrades in minor version changes, and has caused significant incompatibilities that have caught us by surprise. I believe you get about a year's grace period after a new release for security. However, the security team are volunteers, and I think that they decide how long to support the last stable release. Minor version changes can be large; however, they are infrequent. It wouldn't be too out of line to consider every Debian release to be a major one. 5.) Of course we'll be testing it extensively ourselves, but what would you say the most significant differences, both from a user and an admin perspective, are between Debian and Brand X Linux? Or, maybe better stated, why Debian? I know that's a religeously charged question, but at the moment our only position is not RHL. We're open to being converted ;-) From the user's standpoint, the differences should be minimal. From an admin perspective; some things are handled differently (network config jumps out, Debian doesn't have /etc/sysconfig or similar), but generally things are the same. Debian tends to (IMHO) have a cleaner layout of files and configs than other systems I've dealt with (FreeBSD, Redhat, SunOS 5.6). 6.) And finally, if you care to toss in any ideas or info, I'm very glad and excited to hear it. For instance, if you were going to switch all your systems within the next year, would you choose something else? A BSD port? Go back to Solaris? Novell? SCO? Just kidding. I think that FreeBSD is also a good choice to consider. I like Debian's package management better, but I've good experiences with FreeBSD
Re: Considering Debian (currently using Red Hat)
This one time, at band camp, Fred Whipple said: 1.) One of the biggest reasons we went with Red Hat many years ago was RPM. Of course I know that Debian has a package system, and there're constant arguments about which is better, if either. What I wonder, though, is how they compare for the purposes of security checking. On a Red Hat system, practically any file or directory outside of /home can be found within the RPM database. We can check each and every file, its MD5 hash, etc. It's like having a built-in Tripwire installation so long as you trust the RPM database. We've modified the RPM installation such that we can trust it more than we trust Tripwire. Do Debian packages have similar security built-in? There is, for most packages, a file named /var/lib/dpkg/info/$package.md5sums, that contains exactly this. Some packagers do not like generating this file because they feel it wastes disk space or have other reasons. However, there is always an md5sum for the .deb itself in the corresponding Packages file, found at /var/lib/apt/lists/$url_Packages. 2.) A related reason we used Red Hat was that practically anything you could want to use was pre-packaged in a simple to install RPM. And they were typically pretty high quality RPM's, and very often well maintained. Do admins typically find that they're able to find Debian packages for most software they're typically interested in using? I realise this varries greatly between markets, but I guess what I'm asking is do you usually find 70% of the packages you're interested in in Debian package format, and well maintained? 80%? Just a general idea. I wouls say upwards of %90, roughly. The things I find not packaged for Debian are generally speaking proprietary software (like Realserver) or binary-only drivers for specialty hardware. Making your own .deb of these is usually trivial, however, so integrating them into the dpkg managed space is relatively painless. 3.) I read quite a bit of the Web site, and see that in general, releases seem to be very far and few between. This is advantageous to ISP's, of course, because we want things to just work. Is my perception correct in that releases are far apart? When is the next release expected? How significant is the difference from, say, 3.0 and 3.1. Can you just install a bunch of packages and call it an upgrade, or do you have to go through a whole ordeal as you do between Red Hat .X versions? At the moment, Debian seems to be releasing every couple of years, which is what I want at my job :) Many people complain that this is too far between, but I suspect they don't have to test upgrades of several hundred boxes, often located 100 miles or more away. The next release, code-named sarge, is expected relatively soon. It is difficult to tell exactly, but my perception is that we have presently basically frozen the toolchain, except for bugfixes. This means that the freeze for release is not far off, but this depends on many things, and so is notexactly predictable. Sorry that is not perfectly clear, but Debian being a volunteer organization means that a timeline is not always possible. 4.) How long are previous versions maintainaned with patches and such? Or to restate this, how long after a new version is released are you FORCED to upgrade in order to maintain security? How drastic are the changes in between minor version increments (say, 3.0 to 3.1)? For example, Red Hat has tended to make significant kernel upgrades and glibc upgrades in minor version changes, and has caused significant incompatibilities that have caught us by surprise. The last release (potato) was, IIRC, maintained by the security team for close to a year after the release of the current stable (woody). It may not always be that long, depending on their workload, but I would certainly count on 6 months or so. Debian stable releases, since they are usually years apart, do usually contain major version upgrades of lots of software. That being said, I have lived through several release cycles (and done several release upgrades at work, on strictly remote boxes), and it has been as minimally painful as possible. One of the usual tests maintainers are admonished to make is to make sure that their packages upgrade cleanly from the version in the current stable, and I have found that it mostly just works. There is always a release notes page on the website that details any extra steps that must be taken for the upgrade, for instance if libc6 or another package must be upgraded first, before upgrading everything else. The kernel itself will not be upgraded to a new version without your intervention, but it may be upgraded if a bugfix (for instance the do_brk fix) is backported into the _same_ kernel version that you are running. 5.) Of course we'll be testing it extensively ourselves, but what would you say the most significant differences,
Re: two router one host
On Thursday 15 January 2004 12:40, Leonardo Boselli wrote: I have got a second connection. My server is in one class C subnet, say a.b.c.d with a default gateway a.b.c.1 I have added a second connection eth1 g.f.e.246/30 (whose router, you can guess, is g.f.e.245) . Of course with this setup i can only access the router via the second NIC. If i add a second default route it end always using the second nic, it works for some addresses, but not for most: it looks that some host use the other route and the packet are not answered . If a.b.c.1 is your default gateway and someone on the Internet connects to g.f.e.246 then there is a problem. Your firewall will respond by sending the reply packets to it's default route, this will not work well (or at all depending on your ISP). You need to use the iproute utility to create multiple routing tables and a few routing rules. There are probably many ways to arrange your rules but here is the style that I stick to: First create a routing table for each connection (5 and 10 are randomly chosen table numbers): ip route add default via a.b.c.1 table 5 ip route add default via g.f.e.245 table 10 Next create some rules to ensure that local traffic stays local: ip rule add to a.b.c.0/24 lookup main pri 100 ip rule add to g.f.e.246/30 lookup main pri 100 Now create some rules based on source address so that you're outgoing packets get sent to the correct router: ip rule add from a.b.c.0/24 lookup 5 pri 200 ip rule add from g.f.e.246/30 lookup 10 pri 200 Flush routing cache so that rules take immediate effect: ip route flush cache I fear that it sends packets via eth1 with a.b.c.d address. Yes it does. If you find out the MAC address of your routers you can use tcpdump in conjunction with a filter (by MAC address) to confirm that. What is the setup i have to add to have it working correctly. Also is there a script to change default route from one NIC to the Other if the connection is broken ? Depends on what you're doing but you probably won't need a script once ip routing is setup correctly. Documents are at http://www.lartc.org/ IIRC. -- Fraser Campbell [EMAIL PROTECTED] http://www.wehave.net/ Georgetown, Ontario, Canada Debian GNU/Linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Loaded server or syn-flood?
Hi! Recently, my kernel started print messages like TCP: drop open request from [ip-number]/44669 TCP: drop open request from [ip-number]/44750 TCP: drop open request from [ip-number]/44668 TCP: drop open request from [ip-number]/44749 TCP: drop open request from [ip-number]/44748 TCP: drop open request from [ip-number]/44667 NET: 120 messages suppressed. I did a short investigation and found out that the server's either been syn-flooded or that it basicaly ran out of resources ... The machine acts web-server (apache) and serves about 3,500,000 requests / week. It's equipped with two p3-600mhz cpu's and 1gb ram. Vanilla kernel 2.4.21 and debian unstable. As this problem seems kind of unresolved it's hard to fix it by bumping up buffers or so. What's your experience? -- __ Yours sincerely, Christofer Algotsson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt-get and mounting /tmp with noexec option
On Wed, Jan 14, 2004 at 03:53:35AM +0100, Arnoud Warmerdam wrote:
Hi,
I have mounted my /tmp directory (which has it's own partition) with the
noexec option. The reason i did this, was that a poorly written cgi-script
caused a binary to be downloaded and executed in /tmp. Luckily, the
firewall prevented it from doing any harm, but i wanted to prevent this
from happening again. In the future i plan to place apache in a chroot
jail, but in the meantime this seemed like a good thing to do. Here is the
line from my /etc/fstab:
/dev/sda9 /tmpext2noexec,nosuid,rw0 2
-snip-
Is it considered bad practice to mount /tmp with the noexec option? If not,
is there a way to tell apt to use another directory?
- Arnoud Warmerdam
I got tmp mounted noexec too.
/etc/apt/apt.conf.d/70debconf:
// Pre-configure all packages with debconf before they are installed.
// If you don't like it, comment it out.
#DPkg::Pre-Install-Pkgs {/usr/sbin/dpkg-preconfigure --apt || true;};
As you see, i dont like it.
--
Frode Haugsgjerd
Norway
need your help
i gave a following command ...as a result i was supposed to find a checkpasswor file inside bin \bin\checkpassword ...But i did not find any thing like that . So could you tell what may be my mistake for not finding the checkpassword file inside bin . kindly have a look on below mention things too :- [EMAIL PROTECTED] root]# gunzip checkpassword-0.90.tar [EMAIL PROTECTED] root]# tar -xf checkpassword-0.90.tar [EMAIL PROTECTED] root]# cd checkpassword-0.90 [EMAIL PROTECTED] root]# make [EMAIL PROTECTED] root]# make setup check
Re: need your help
- Original Message - From: Ujjwal Rana [EMAIL PROTECTED] To: debian-isp@lists.debian.org Sent: Wednesday, January 14, 2004 12:14 AM Subject: need your help i gave a following command ...as a result i was supposed to find a checkpasswor file inside bin \bin\checkpassword ...But i did not find any thing like that . So could you tell what may be my mistake for not finding the checkpassword file inside bin . kindly have a look on below mention things too :- Your mistake is that checkpassword is in /usr/bin : /usr/bin/checkpassword
Considering Debian (currently using Red Hat)
Hi Everyone, I'd like to get some of your thoughts on a few things relating to the possibility of our company switching distributions from Red Hat to Debian. As most folks already know, Red Hat has drastically changed their strategy, and we ultimately must make *some* relatively drastic changes no matter what. And, we intend not to switch to RHEL (though not for financial reasons). This gives us the opportunity, welcome or not, to consider other distributions. And even other OS's -- we're frankly not closed to the idea of ultimately switching platforms entirely to BSD or Solaris. So with this in mind, 1.) One of the biggest reasons we went with Red Hat many years ago was RPM. Of course I know that Debian has a package system, and there're constant arguments about which is better, if either. What I wonder, though, is how they compare for the purposes of security checking. On a Red Hat system, practically any file or directory outside of /home can be found within the RPM database. We can check each and every file, its MD5 hash, etc. It's like having a built-in Tripwire installation so long as you trust the RPM database. We've modified the RPM installation such that we can trust it more than we trust Tripwire. Do Debian packages have similar security built-in? 2.) A related reason we used Red Hat was that practically anything you could want to use was pre-packaged in a simple to install RPM. And they were typically pretty high quality RPM's, and very often well maintained. Do admins typically find that they're able to find Debian packages for most software they're typically interested in using? I realise this varries greatly between markets, but I guess what I'm asking is do you usually find 70% of the packages you're interested in in Debian package format, and well maintained? 80%? Just a general idea. 3.) I read quite a bit of the Web site, and see that in general, releases seem to be very far and few between. This is advantageous to ISP's, of course, because we want things to just work. Is my perception correct in that releases are far apart? When is the next release expected? How significant is the difference from, say, 3.0 and 3.1. Can you just install a bunch of packages and call it an upgrade, or do you have to go through a whole ordeal as you do between Red Hat .X versions? 4.) How long are previous versions maintainaned with patches and such? Or to restate this, how long after a new version is released are you FORCED to upgrade in order to maintain security? How drastic are the changes in between minor version increments (say, 3.0 to 3.1)? For example, Red Hat has tended to make significant kernel upgrades and glibc upgrades in minor version changes, and has caused significant incompatibilities that have caught us by surprise. 5.) Of course we'll be testing it extensively ourselves, but what would you say the most significant differences, both from a user and an admin perspective, are between Debian and Brand X Linux? Or, maybe better stated, why Debian? I know that's a religeously charged question, but at the moment our only position is not RHL. We're open to being converted ;-) 6.) And finally, if you care to toss in any ideas or info, I'm very glad and excited to hear it. For instance, if you were going to switch all your systems within the next year, would you choose something else? A BSD port? Go back to Solaris? Novell? SCO? Just kidding. Thanks very much! -Fred Whipple
RE: Considering Debian (currently using Red Hat)
-Original Message- From: Fred Whipple [mailto:[EMAIL PROTECTED] Sent: 14 January 2004 14:57 To: debian-isp@lists.debian.org Subject: Considering Debian (currently using Red Hat) Hi Everyone, I'd like to get some of your thoughts on a few things... 1) Package: cruft Priority: optional Section: admin Installed-Size: 636 Maintainer: Anthony Towns [EMAIL PROTECTED] Architecture: i386 Version: 0.9.6-0.4 Depends: libc6 (= 2.3.1-1), file Filename: pool/main/c/cruft/cruft_0.9.6-0.4_i386.deb Size: 26690 MD5sum: a1dfa3e1828f92cbf9e03223f498f07c Description: Find any cruft built up on your system cruft is a program to look over your system for anything that shouldn't be there, but is; or for anything that should be there, but isn't. . It bases most of its results on dpkg's database, as well as a list of `extra files' that can appear during the lifetime of various packages. . cruft is still in pre-release; your assistance in improving its accuracy and performance is appreciated. I think that's what you want. Seems to work - just tried it. 2) Debian is the biggest distribution, it has *more* packages than redhat. It has almost 9000 packages in the main stable tree, I believe. Generally I find that I can find any program I want. If it's not in debian it's not worth having in a lot of cases! The exception to this is driver packages which often come as rpm-only. Anything non-proprietary is usually debian packaged, however. 3) Debian is not released in the same way as redhat, which seems to follow a windows style of releases. Debian development is a continous stream. A release is created by first taking a branch off the main development stream (unstable), calling it testing and declaring a freeze on any new packages or non security changes. After a while, that is released as the next stable release. Stable in this case means version-stable, It doesn't necessarily imply that newer development streams are more unreliable. If you were to take your updates from the unstable tree, as I do, you would never have install a upgrade, as your system would always be the latest. Even if you dont, upgrading doesn't involve finding a cd and rebooting, a apt-get dist-upgrade will do. 4) Stable like you say is updated fairly infrequently, however security updates are released at the same time as for other releases/trees/streams. I believe you can use the security updates no matter how old your initial release of debian is. 5) There's the political differences, as you are aware, but i'd say the biggest difference between debian and redhat is the absolute ease that you can keep your whole system up to date and the efficiency of the packaging system - dependency conflicts are rare on the unstable branch and unheard of on the stable and testing branches. There's none of this nonsense about premium updates support, special privileged ftp servers, etc. There is a large network of mirrors, and they all work reliably and quickly. 6) If it was a choice between GNU/Linux'es, debian, if it was a more general OS choice, it would depend on the task at hand. Dan Ros -Original Message- From: Fred Whipple [mailto:[EMAIL PROTECTED] Sent: 14 January 2004 14:57 To: debian-isp@lists.debian.org Subject: Considering Debian (currently using Red Hat) Hi Everyone, I'd like to get some of your thoughts on a few things relating to the possibility of our company switching distributions from Red Hat to Debian. As most folks already know, Red Hat has drastically changed their strategy, and we ultimately must make *some* relatively drastic changes no matter what. And, we intend not to switch to RHEL (though not for financial reasons). This gives us the opportunity, welcome or not, to consider other distributions. And even other OS's -- we're frankly not closed to the idea of ultimately switching platforms entirely to BSD or Solaris. So with this in mind, 1.) One of the biggest reasons we went with Red Hat many years ago was RPM. Of course I know that Debian has a package system, and there're constant arguments about which is better, if either. What I wonder, though, is how they compare for the purposes of security checking. On a Red Hat system, practically any file or directory outside of /home can be found within the RPM database. We can check each and every file, its MD5 hash, etc. It's like having a built-in Tripwire installation so long as you trust the RPM database. We've modified the RPM installation such that we can trust it more than we trust Tripwire. Do Debian packages have similar security built-in? 2.) A related reason we used Red Hat was that practically anything you could want to use was pre-packaged in a simple to install RPM. And they were typically pretty high quality RPM's, and very often well maintained. Do admins typically find that they're able to find Debian packages for most software they're
Re: Considering Debian (currently using Red Hat)
On Wed, 14 Jan 2004 09:56:35 EST, Fred Whipple writes: I'll answer just the points I have opinions/knowledge on. 2.) A related reason we used Red Hat was that practically anything you could want to use was pre-packaged in a simple to install RPM. And they were typically pretty high quality RPM's, and very often well maintained. Do admins typically find that they're able to find Debian packages for most software they're typically interested in using? I realise this varries greatly between markets, but I guess what I'm asking is do you usually find 70% of the packages you're interested in in Debian package format, and well maintained? 80%? Just a general idea. Debian uses the .deb package format. I'd guess that well over 90 % of the software we need can be found pre-packaged (and well-maintained) as .deb's. 3.) I read quite a bit of the Web site, and see that in general, releases seem to be very far and few between. This is advantageous to ISP's, of course, because we want things to just work. Is my perception correct in that releases are far apart? Stable releases are quite far apart, yes. When is the next release expected? How significant is the difference from, say, 3.0 and 3.1. Can you just install a bunch of packages and call it an upgrade, or do you have to go through a whole ordeal as you do between Red Hat .X versions? Upgrading to a new release is just an `apt-get dist-upgrade` away. I've personally upgraded a box through every release from 1.mumble to 3.0 . 4.) How long are previous versions maintainaned with patches and such? Or to restate this, how long after a new version is released are you FORCED to upgrade in order to maintain security? A couple months at least, usually about half a year. How drastic are the changes in between minor version increments (say, 3.0 to 3.1)? For example, Red Hat has tended to make significant kernel upgrades and glibc upgrades in minor version changes, and has caused significant incompatibilities that have caught us by surprise. Debian focuses on security and stability in the stable branch, so there never should be any problems with that as long as you track stable (the testing and unstable releases are another matter, just as their names suggest). The trade-off, of course, is that new software (resp. new versions of software) takes its time to make it into the stable branch. 6.) And finally, if you care to toss in any ideas or info, I'm very glad and excited to hear it. For instance, if you were going to switch all your systems within the next year, would you choose something else? A BSD port? Go back to Solaris? Novell? SCO? Just kidding. IMHO Debians main advantage is the packaging. You can track security-updates of _all_ installed packages with a simple `apt-get upgrade`, and there should never be any surprising side-effect to it. Re-installs of the system for upgrading purposes are unknown for Debian (unless you're upgrading _to_ Debian ;) ). Another advantage is that there's no integrated admin-tool which will destroy your precious hand-crafted config files, no yast or suseconfig or somesuch. The downside to that is that you have to know how to use an editor, of course, and there's mostly no setup wizards to guide you. Packages do, of course, come with mostly sensible (and secure) default configs, though. Should an upgrade have the necessity to change a config-file, it'll ask you if you want it to (it can also show you a diff first) or not. Plus. according to policy, there's at least a man-page for everything in *bin and /etc, and some documentation for _eachevery_ installed package in /usr/share/doc/package. cheers, rw -- / Ing. Robert Waldner | Security Engineer | CoreTec IT-Security \ \ [EMAIL PROTECTED] | T +43 1 503 72 73 | F +43 1 503 72 73 x99 / pgpQSWq23fGDV.pgp Description: PGP signature
Re: Anybody Running OpenWebMail ?
Hello! We use it with a lot of success. It servers for web interface to mail for around 2000 customers - we are quite happy with. W liście z pon, 12-01-2004, godz. 20:56, Kevin Lynch pisze: Kevin
Re: Considering Debian (currently using Red Hat)
A few things that I haven't seen mentioned yet: If you decide to run stable, but want just some latest and gratest software you can normally download the latest Debianized source and compile you own pacakges against stable. There are also plenty of places on the net to get backported packages, but if you are security minded I would want to roll them myself, unless you really trust the UNOFFICIAL backport maintainer and the mirrors you are downloading from (there is another thread about this going on right now IIRC). So you just install a stable system, keep up with the security updates, build your own local repository (plenty of ways to do this) and build the few packages that you need newer versions of. This is what I am doing (just got apt-proxy working and it's great). This gives you a known secure system, and all you have to keep an eye on is security advisories that affect the packages you have built yourself. I keep my servers on stable, and run my workstations on testing. Also personally I don't have anything that is automatically updated, I prefer to be notified of updates and then apply them myself, just to be safe (who in there right mind would have any automatic changes, no matter how trusted the source, on a mission critical server?). If you've built your own integrity checker for RPM's then this should be a piece of cake for you. Personally I think that the biggest problem people have with Debian is just naming related. If it were called Server-Stable Workstation-Testing Painfully Bleeding Edge-Unstable One of the biggest complaints that I hear about Debian is that stable is too outdated. Well of course it is, that is what makes so great, everything is extremely well tested and works. This takes time, how else would you get this level of stability. Our (while not a maintainer I do feel like part of the family) testing distrobution is as/more stable than many other distros normal releases. Please take a look at the debian policy manual for more info on how debian is structured, it will answer many questions (I think I need to reread the policy manual myself). http://www.debian.org/doc/devel-manuals#policy Well I actually have a few more opinions on this subject, but I have to run for now. Back in a while. Matt Wehland [EMAIL PROTECTED] Littlegrassy.com
two router one host
I have got a second connection. My server is in one class C subnet, say a.b.c.d with a default gateway a.b.c.1 I have added a second connection eth1 g.f.e.246/30 (whose router, you can guess, is g.f.e.245) . Of course with this setup i can only access the router via the second NIC. If i add a second default route it end always using the second nic, it works for some addresses, but not for most: it looks that some host use the other route and the packet are not answered . I fear that it sends packets via eth1 with a.b.c.d address. What is the setup i have to add to have it working correctly. Also is there a script to change default route from one NIC to the Other if the connection is broken ? -- Leonardo Boselli Nucleo informatico e Telematico Dipartimento Ingegneria Civile Universita` di Firenze Via Santa Marta 3 I-50139 Firenze +39 055-4796-431 +39 348-8605-348 fax 055-495-333
Re: Considering Debian (currently using Red Hat)
Fred Whipple said on Wed, Jan 14, 2004 at 09:56:35AM -0500: 1.) One of the biggest reasons we went with Red Hat many years ago was RPM. Of course I know that Debian has a package system, and there're constant arguments about which is better, if either. What I wonder, though, is how they compare for the purposes of security checking. On a Red Hat system, practically any file or directory outside of /home can be found within the RPM database. We can check each and every file, its MD5 hash, etc. It's like having a built-in Tripwire installation so long as you trust the RPM database. We've modified the RPM installation such that we can trust it more than we trust Tripwire. Do Debian packages have similar security built-in? Yes. Debian packages contain an MD5 sum of all of the packages in the deb. You can check these with the debsums tool. However, Debian has several security scanners packaged that are probably better than just using debsums; AIDE comes to mind. 2.) A related reason we used Red Hat was that practically anything you could want to use was pre-packaged in a simple to install RPM. And they were typically pretty high quality RPM's, and very often well maintained. Do admins typically find that they're able to find Debian packages for most software they're typically interested in using? I realise this varries greatly between markets, but I guess what I'm asking is do you usually find 70% of the packages you're interested in in Debian package format, and well maintained? 80%? Just a general idea. Over 80%. In general, I'd say that the more popular Debian packages are extremely well maintained, while the smaller, less popular packages range from extremely well maintained to pretty good. I do end up backporting from unstable to stable for a few packages that I want newer versions of. 3.) I read quite a bit of the Web site, and see that in general, releases seem to be very far and few between. This is advantageous to ISP's, of course, because we want things to just work. Is my perception correct in that releases are far apart? When is the next release expected? How significant is the difference from, say, 3.0 and 3.1. Can you just install a bunch of packages and call it an upgrade, or do you have to go through a whole ordeal as you do between Red Hat .X versions? Stable releases are far apart; one every 1.5 - 2 years, historically. Not sure when the next release is; sometime this year (2004), hopefully. Since 3.1 hasn't released yet, I'm not sure, but generally a new release involves a new major kernel revision (2.2 - 2.4, or 2.4 - 2.6), a new major libc, and new major releases of most of the important subsystems. Debian makes a point of having upgrades being smooth and as painless as possible; I've gone through two major upgrades by simply running `apt-get dist-upgrade', and it worked well. Obviously, you'll want to take precautions and have time to test. 4.) How long are previous versions maintainaned with patches and such? Or to restate this, how long after a new version is released are you FORCED to upgrade in order to maintain security? How drastic are the changes in between minor version increments (say, 3.0 to 3.1)? For example, Red Hat has tended to make significant kernel upgrades and glibc upgrades in minor version changes, and has caused significant incompatibilities that have caught us by surprise. I believe you get about a year's grace period after a new release for security. However, the security team are volunteers, and I think that they decide how long to support the last stable release. Minor version changes can be large; however, they are infrequent. It wouldn't be too out of line to consider every Debian release to be a major one. 5.) Of course we'll be testing it extensively ourselves, but what would you say the most significant differences, both from a user and an admin perspective, are between Debian and Brand X Linux? Or, maybe better stated, why Debian? I know that's a religeously charged question, but at the moment our only position is not RHL. We're open to being converted ;-) From the user's standpoint, the differences should be minimal. From an admin perspective; some things are handled differently (network config jumps out, Debian doesn't have /etc/sysconfig or similar), but generally things are the same. Debian tends to (IMHO) have a cleaner layout of files and configs than other systems I've dealt with (FreeBSD, Redhat, SunOS 5.6). 6.) And finally, if you care to toss in any ideas or info, I'm very glad and excited to hear it. For instance, if you were going to switch all your systems within the next year, would you choose something else? A BSD port? Go back to Solaris? Novell? SCO? Just kidding. I think that FreeBSD is also a good choice to consider. I like Debian's package management better, but I've good experiences with FreeBSD
Re: Considering Debian (currently using Red Hat)
This one time, at band camp, Fred Whipple said: 1.) One of the biggest reasons we went with Red Hat many years ago was RPM. Of course I know that Debian has a package system, and there're constant arguments about which is better, if either. What I wonder, though, is how they compare for the purposes of security checking. On a Red Hat system, practically any file or directory outside of /home can be found within the RPM database. We can check each and every file, its MD5 hash, etc. It's like having a built-in Tripwire installation so long as you trust the RPM database. We've modified the RPM installation such that we can trust it more than we trust Tripwire. Do Debian packages have similar security built-in? There is, for most packages, a file named /var/lib/dpkg/info/$package.md5sums, that contains exactly this. Some packagers do not like generating this file because they feel it wastes disk space or have other reasons. However, there is always an md5sum for the .deb itself in the corresponding Packages file, found at /var/lib/apt/lists/$url_Packages. 2.) A related reason we used Red Hat was that practically anything you could want to use was pre-packaged in a simple to install RPM. And they were typically pretty high quality RPM's, and very often well maintained. Do admins typically find that they're able to find Debian packages for most software they're typically interested in using? I realise this varries greatly between markets, but I guess what I'm asking is do you usually find 70% of the packages you're interested in in Debian package format, and well maintained? 80%? Just a general idea. I wouls say upwards of %90, roughly. The things I find not packaged for Debian are generally speaking proprietary software (like Realserver) or binary-only drivers for specialty hardware. Making your own .deb of these is usually trivial, however, so integrating them into the dpkg managed space is relatively painless. 3.) I read quite a bit of the Web site, and see that in general, releases seem to be very far and few between. This is advantageous to ISP's, of course, because we want things to just work. Is my perception correct in that releases are far apart? When is the next release expected? How significant is the difference from, say, 3.0 and 3.1. Can you just install a bunch of packages and call it an upgrade, or do you have to go through a whole ordeal as you do between Red Hat .X versions? At the moment, Debian seems to be releasing every couple of years, which is what I want at my job :) Many people complain that this is too far between, but I suspect they don't have to test upgrades of several hundred boxes, often located 100 miles or more away. The next release, code-named sarge, is expected relatively soon. It is difficult to tell exactly, but my perception is that we have presently basically frozen the toolchain, except for bugfixes. This means that the freeze for release is not far off, but this depends on many things, and so is notexactly predictable. Sorry that is not perfectly clear, but Debian being a volunteer organization means that a timeline is not always possible. 4.) How long are previous versions maintainaned with patches and such? Or to restate this, how long after a new version is released are you FORCED to upgrade in order to maintain security? How drastic are the changes in between minor version increments (say, 3.0 to 3.1)? For example, Red Hat has tended to make significant kernel upgrades and glibc upgrades in minor version changes, and has caused significant incompatibilities that have caught us by surprise. The last release (potato) was, IIRC, maintained by the security team for close to a year after the release of the current stable (woody). It may not always be that long, depending on their workload, but I would certainly count on 6 months or so. Debian stable releases, since they are usually years apart, do usually contain major version upgrades of lots of software. That being said, I have lived through several release cycles (and done several release upgrades at work, on strictly remote boxes), and it has been as minimally painful as possible. One of the usual tests maintainers are admonished to make is to make sure that their packages upgrade cleanly from the version in the current stable, and I have found that it mostly just works. There is always a release notes page on the website that details any extra steps that must be taken for the upgrade, for instance if libc6 or another package must be upgraded first, before upgrading everything else. The kernel itself will not be upgraded to a new version without your intervention, but it may be upgraded if a bugfix (for instance the do_brk fix) is backported into the _same_ kernel version that you are running. 5.) Of course we'll be testing it extensively ourselves, but what would you say the most significant differences,
Re: two router one host
On Thursday 15 January 2004 12:40, Leonardo Boselli wrote: I have got a second connection. My server is in one class C subnet, say a.b.c.d with a default gateway a.b.c.1 I have added a second connection eth1 g.f.e.246/30 (whose router, you can guess, is g.f.e.245) . Of course with this setup i can only access the router via the second NIC. If i add a second default route it end always using the second nic, it works for some addresses, but not for most: it looks that some host use the other route and the packet are not answered . If a.b.c.1 is your default gateway and someone on the Internet connects to g.f.e.246 then there is a problem. Your firewall will respond by sending the reply packets to it's default route, this will not work well (or at all depending on your ISP). You need to use the iproute utility to create multiple routing tables and a few routing rules. There are probably many ways to arrange your rules but here is the style that I stick to: First create a routing table for each connection (5 and 10 are randomly chosen table numbers): ip route add default via a.b.c.1 table 5 ip route add default via g.f.e.245 table 10 Next create some rules to ensure that local traffic stays local: ip rule add to a.b.c.0/24 lookup main pri 100 ip rule add to g.f.e.246/30 lookup main pri 100 Now create some rules based on source address so that you're outgoing packets get sent to the correct router: ip rule add from a.b.c.0/24 lookup 5 pri 200 ip rule add from g.f.e.246/30 lookup 10 pri 200 Flush routing cache so that rules take immediate effect: ip route flush cache I fear that it sends packets via eth1 with a.b.c.d address. Yes it does. If you find out the MAC address of your routers you can use tcpdump in conjunction with a filter (by MAC address) to confirm that. What is the setup i have to add to have it working correctly. Also is there a script to change default route from one NIC to the Other if the connection is broken ? Depends on what you're doing but you probably won't need a script once ip routing is setup correctly. Documents are at http://www.lartc.org/ IIRC. -- Fraser Campbell [EMAIL PROTECTED] http://www.wehave.net/ Georgetown, Ontario, Canada Debian GNU/Linux
Re: Considering Debian (currently using Red Hat)
Boy, are u gonna get answers El mié, 14-01-2004 a las 08:56, Fred Whipple escribió: Hi Everyone, I'd like to get some of your thoughts on a few things relating to the possibility of our company switching distributions from Red Hat to Debian. As most folks already know, Red Hat has drastically changed their strategy, and we ultimately must make *some* relatively drastic changes no matter what. And, we intend not to switch to RHEL (though not for financial reasons). This gives us the opportunity, welcome or not, to consider other distributions. And even other OS's -- we're frankly not closed to the idea of ultimately switching platforms entirely to BSD or Solaris. So with this in mind, 1.) One of the biggest reasons we went with Red Hat many years ago was RPM. Of course I know that Debian has a package system, and there're constant arguments about which is better, if either. What I wonder, though, is how they compare for the purposes of security checking. On a Red Hat system, practically any file or directory outside of /home can be found within the RPM database. We can check each and every file, its MD5 hash, etc. It's like having a built-in Tripwire installation so long as you trust the RPM database. We've modified the RPM installation such that we can trust it more than we trust Tripwire. Do Debian packages have similar security built-in? Yes although it wouldnt be safe to say ALL files in every package as some of the files (as config files) are generated from pre or postinstall proceses and thus are likely to say. Anyhow. Debian comes with a debsums command that takes the deb database and does an md5 comparission of everything. Its quite effective. Ive used aide, tiger and integrit as local IDS systems and they do their job quite well. Ive never fiddled with tripwire though. Those will do the debsums check for you plus, depending on package, will conduct other similar testing procedures to detect filesystem changes. 2.) A related reason we used Red Hat was that practically anything you could want to use was pre-packaged in a simple to install RPM. And they were typically pretty high quality RPM's, and very often well maintained. Do admins typically find that they're able to find Debian packages for most software they're typically interested in using? I realise this varries greatly between markets, but I guess what I'm asking is do you usually find 70% of the packages you're interested in in Debian package format, and well maintained? 80%? Just a general idea. Well. Its a tradeoff there. Third party (non distro) software is almost allways distributed in rpm's. This makes it much easyer for admins to integrate that packages into your stuff. Debian is another taco there, we have an authoritative source of packages (the debian project) and most packages youll ever need are there. Third party debian packaged software is generally complex to safely integrate into debian because non-stable debian moves a lot (thus many prefer the testing and unstable distribution, depending on usage) so most projects find it a PITA to manage debs as third party. On the other hand, debian makes it very easy for you to take a tarball and turn it into a safely installable (for whatever debian version you use) packacge through the dpkg-buildpackage command. If the third party package is GNU-style compatible (has a configure, make, make install style of distribution), dpkg-buildpackage will build you your deb and you can then install it with the equivalent of the redhat rpm command for debian, called dpkg. Finally, debian supports you tracking packages from different versions of it. Say, you want a stable (read OLD) setup for all email related services, but you need a younger version of apache. You can quite troublessly install the apache for debian/testing (which is younger) into your debian/stable setup, and it will only install whatever testing versions of the apache dependencies you need, thus leaving your email services safely in their old versions (unless they depend on the same libraries as the younger apache). 3.) I read quite a bit of the Web site, and see that in general, releases seem to be very far and few between. This is advantageous to ISP's, of course, because we want things to just work. Is my perception correct in that releases are far apart? When is the next release expected? How significant is the difference from, say, 3.0 and Yes. Very very far appart. Between stable releases what differs is just package versions, installation software upgrades and a whole lot of new packages. Naturally, they also change in administration software (see all the debian update-* commands, which make it easy to manage a lot of things) 3.1. Can you just install a bunch of packages and call it an upgrade, or do you have to go through a whole ordeal as you do between Red Hat .X versions? You can just install a bunch of
Loaded server or syn-flood?
Hi! Recently, my kernel started print messages like TCP: drop open request from [ip-number]/44669 TCP: drop open request from [ip-number]/44750 TCP: drop open request from [ip-number]/44668 TCP: drop open request from [ip-number]/44749 TCP: drop open request from [ip-number]/44748 TCP: drop open request from [ip-number]/44667 NET: 120 messages suppressed. I did a short investigation and found out that the server's either been syn-flooded or that it basicaly ran out of resources ... The machine acts web-server (apache) and serves about 3,500,000 requests / week. It's equipped with two p3-600mhz cpu's and 1gb ram. Vanilla kernel 2.4.21 and debian unstable. As this problem seems kind of unresolved it's hard to fix it by bumping up buffers or so. What's your experience? -- __ Yours sincerely, Christofer Algotsson
