Discuss June 2005

discuss@lists.centos.org

197 participants
362 discussions

RE: [CentOS] How many supported DNS IP addresses maybe configured in/etc/resolv.conf ?
by Marc Powell 02 Jun '05

02 Jun '05

> -----Original Message----- > From: centos-bounces(a)centos.org [mailto:centos-bounces@centos.org] On > Behalf Of Prasad Pillarisetti > Sent: Thursday, June 02, 2005 12:32 PM > To: centos(a)centos.org > Subject: [CentOS] How many supported DNS IP addresses maybe configured > in/etc/resolv.conf ? > > How many supported DNS IP addresses maybe configured in /etc/resolv.conf ? > > Is it only 3, or can I configure more? There is no limit that I am aware of to the number of 'nameserver' directives if that's what you're asking. They'll all be tried in sequence until a response is received. From the resolv.conf man page -- "The algorithm used is to try a name server, and if the query times out, try the next, until out of name servers, then repeat trying all the name servers until a maximum number of retries are made" IMHO, if 2 or 3 aren't sufficient then you should really consider the root cause why you need more and correct that ;) -- Marc

1 0

Re: Reboots -- Reboot Logic ...
by Bryan J. Smith <b.j.smith＠ieee.org> 02 Jun '05

02 Jun '05

The main reason I see this topic come up over and over is because people who are new to UNIX coming from Windows don't realize that they have been "programmed" into thinking what reboots are for. Prior to the proliferation of Windows, barring hardware failure, reboots were pretty limited to scheduled maintenance. Sure, user-space programs have memory leaks, new options are buggy, etc... And sometimes you have to stop, start, debug, etc... those services. But for the most part, the core, kernel in just about any UNIX system has not only been fairly devoid of major issues because of the inherit attitude of its developers. _Nothing_ goes into the kernel that is not required, and that means _not_ putting in services for performance or other hacks. So that means that memory leaks and other things that are very problematic in newer services or changes are typically left to only user-space services which can be fully pre-emptive. Even NT 3.1 put things into kernel space that should have never been in there. It got worse with NT 3.51 "Daytona" for "Chicago" (DOS7.0 aka "Windows 95") compatibility, and NT 4.0 "Cario" was the ultimate bastard prior until NT 5.1 (XP/2003). In the UNIX world, you can stop all sorts of user-spaces -- pretty much all of them if you wish -- which many admins do to resolve issues. Take down nmb/smb, take down ldapd, etc... to deal with issues. The system usually stays up and continues servicing many other capabilities -- because they are not part of the kernel space itself. This is very much unlike the NT world. The server, spooler and other services are tied into the kernel. Restarting them is typically impossible or ineffective when there is an issue, because the issue is in the kernel, and the user-space component restart doesn't help. Then there are the "Chicago" components that have been tacked on since NT 3.51, 4.0 and, probably most deadly, in NT 5.1 (XP/2003). These services and libraries -- designed for the "free for all" of "Chicago" (including MS IE) -- wreak havoc on the protected NT kernel's space. KEY POINT: This is why you should _never_ reboot UNIX/Linux in the hope that it solves the problem like it typically does Windows. In the Windows world, it typically fixes the issue -- even if temporary -- because even the user space components typically have kernel-space services for performance, etc... -- e.g., IIS, SMB, etc... Although Microsoft seems to be putting IIS and other things into the "Indigo .NET Sandbox" in NT6.0 Longhorn, the ADS, SMB and other non-.NET services are still going to be 100% Legacy Win32+Chicago code. So it's not getting any better anytime soon, and reboots will still be required to "clean things out." In the UNIX world, if you reboot, you are typically presented with _no_ resolution. You're best bet is to find the root cause and fix it, instead of wasting time rebooting. Plus, there is also the additional consideration of additional issues a UNIX reboot can introduce. E.g., UNIX/Linux systems are rebooted so infrequently that many boot-time configurations can change but not be known for months, or even years! So it's best to _only_ reboot UNIX/Linux when you have time for scheduled maintenance. So if there is one thing I highly deter new UNIX/Linux administrators from doing, it is doing an "impulsive reboot." It's better to just work the problem, then to reboot, waste time (in the best case) and possibly introduce even more, unforseen issues in changes (in the worst case). -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: Vote For CentOS :) -- entitlements are to subscriptions, not products ...
by Bryan J. Smith <b.j.smith＠ieee.org> 02 Jun '05

02 Jun '05

From: Simon Perreault <nomis80(a)lqt.ca> > Isn't it acceptable for Red Hat to sell SLAs on a per-computer basis? > I really don't get where you're going. The main problem people have in understanding RHEL is that they don't understand it is a subscription with guarantees and, optionally, service level agreements (SLAs). It's _not_ a product at all. Red Hat has been wanting to get away from a "product" every since they came out with Red Hat Linux 6.2 "E" Service Level Agreements. E.g., you _never_ pay for an "upgrade," if you have an active entitlement, you are entitled to whatever product, current or past, that is still actively supported. You could even subscribe while RHEL 4 is current today and install RHEL 2.1 and be supported until it is retired (in another year or so). At the same time, you will get RHEL 5 if you have entitlements when it comes out. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: [CentOS] Vote For CentOS :)
by Bryan J. Smith <b.j.smith＠ieee.org> 02 Jun '05

02 Jun '05

From: Les Mikesell <lesmikesell(a)gmail.com> > That's a rather different case. The MS software doesn't start with a > license that ensures your right to copy it except in the case where > you impose additional restrictions. You are asserting things the GPL does not guarantee. Rights to additional IP is one of them. You do not need the Red Hat trademarks for the software to function. So they can be legally bundled with GPL software. This is not a Red Hat-only issue. But it is one that Red Hat got into real trouble with for failing to enforce their trademarks prior with Cobalt, Sun, etc... -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

RE: [CentOS] Reboots
by Marc Powell 02 Jun '05

02 Jun '05

> -----Original Message----- > From: centos-bounces(a)centos.org [mailto:centos-bounces@centos.org] On > Behalf Of Prasad Pillarisetti > Sent: Thursday, June 02, 2005 11:42 AM > To: centos(a)centos.org > Subject: [CentOS] Reboots > > > ***Do you perform downtimes just for the purpose of rebooting the systems? It's a matter of policy. We do not but all of our customer facing systems are load balanced. If they weren't and the reboot wasn't of an emergency nature then yes, we would reboot during a maintenance window. > ***Is there a recommended interval Linux system should be rebooted? Ideally never. You should only need to reboot for hardware or kernel changes. We have internal machines that have been up for over 3 years without interruption (let the uptime contest begin). -- Marc

2 1

auditd logs
by Dave 02 Jun '05

02 Jun '05

I've noticed my disk space filling up rapidy on my mail server, I noticed that /var/log/audit.d is using 2.1 G. Is it safe to remove those log files?

1 0

Re: [CentOS] Vote For CentOS :)
by Bryan J. Smith <b.j.smith＠ieee.org> 02 Jun '05

02 Jun '05

From: Simon Perreault <nomis80(a)lqt.ca> > I think you will agree that the difference between RHEL and Fedora > is greater than the one between CentOS and RHEL, enough for RHEL > to be a different distro from Fedora. As was Red Hat Linux (RHL) before it became Fedora Core (FC). Of course, all Red Hat Enterprise Linux (RHEL) packages start out as RHL/FC packages, and there is that 1:1 relationship. If you like Fedora Core, vote Fedora Core. If you like CentOS, vote CentOS. If you like RHEL w/SLAs, I'd vote RHEL (but that's just my viewpoint). But as I said, I think people will over-analyze things to death. People won't know about CentOS unless people vote for it, so if it's your favorite, just do so. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: Vote For CentOS :) -- yes, vote CentOS if it's what you like
by Bryan J. Smith <b.j.smith＠ieee.org> 02 Jun '05

02 Jun '05

From: Christopher Snow <cs(a)m0n0.co.uk> > If that's the case, shouldn't the credit vote go to Fedora? Disclaimer: This is 100% my _opinion_ (don't take it otherwise) 1. Credit At some point a lot of credit can go to a lot of projects. Yes, many are thanx to Red Hat -- by far the largest of any commercial entity. But then many are thanx to many maintainers in general. It's not really fair to them to give all credit to Red Hat by the same logic. 2. Who do you vote for? I think the purpose of the vote is to state your favorite distro that you install. If you believe CentOS is it, then vote for it. I would see it as, "I like RHEL, but I don't need SLAs." I'm sure a few will demonize it, but I think most people are fairly solid in that view. Now if you prefer a distro with SLAs, but just normally don't because of cost, I'd actually vote RHEL (or SLES if that is your preferrence) instead of CentOS. I guess I should actually read the wording of the vote, but it's kinda like cars. You can like a car without actually owning it. But don't feel any need to show loyalty to RHEL if you use CentOS, most people already know it's a replica of RHEL sans trademarks. > As in politics, your vote counts no matter the reason it is cast. Agreed. Vote what you want, don't try to analyze your vote. Far too many people do that only to get frustrated later. Just my $0.02, as always ... -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

Re: Vote For CentOS :)
by Bryan J. Smith <b.j.smith＠ieee.org> 02 Jun '05

02 Jun '05

From: Les Mikesell <lesmikesell(a)gmail.com> > If your favorite choice is accepting a contract that imposes limits on > where you can install free software that itself has a license that says > additional restrictions cannot be imposed, then by all means pick RHEL. Or SuSE Linux Enterprise Server, Novell Linux Desktop, etc... And there are plenty of other distros that prevent redistribution for reasons for select packages, trademarks, etc... Red Hat is not the only one, although I don't always see people recognizing this. It's just like the age-old IBM v. Microsoft problem. People seem to stand by one or the other, not realizing the other is no better. ;-> And there are more choices ou there than deciding to hate 1 of 2. Les, we get it. You don't like Red Hat. As someone who lacks tact myself, I'm fairly good at noticing others with the same problem. ;-> And even *I* said vote CentOS if you prefer it. This vote doesn't look like about awarding credit. Of course, if you like SLAs, even if you normally can't afford them, then I'd vote RHEL (or SLES/NLD). -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Canon MP780 driver
by Ian Bennett 02 Jun '05

02 Jun '05

Hi all, New member here and new to Linux. Please excuse me if my questions appear a bit dumb. I have just installed CentOS 4 and I am playing around. I must say the install process was fabulous and I had no problems. I am now playing with a few of the apps. I have a Canon Pixma MP780 multi-function centre which was correctly identified by the installer however I cannot find a driver for it and hence cannot print to it. Does anyone know if a Linux driver exists for this printer or alternatively what existing printer driver will work. Thanks in advance. Ian

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss June 2005