- Discuss - lists.centos.org

S/N on this list is plummeting...
by Chris Mauritz 03 Jun '05

03 Jun '05

Is it possible to create an alternate list for the people who insist on spending their days posting long-winded political commentary and opinion? Maybe something like centos-offtopic? Reading the list has gone from "fun" status to "chore." Just a suggestion. Cheers, C

4 4

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

03 Jun '05

From: Johnny Hughes <mailing-lists(a)hughesjr.com> > As pointed out many times before on this list, RedHat is a great > company, and they do a lot of things for the OSS community ... but they > are not the "owners" of the code that CentOS uses. They get almost all > the items they publish from somewhere else. They are required, > therefore, to make their source code public. But Red Hat does release pretty much even anything "original" as GPL as well. > They take that requirement seriously, and they do an outstanding job > of publishing their source code openly. They should be commended for > that. I do it every chance I get :) And I personally appreciated your objectivity, alongside your dedication to the project. It's hard to find such a combo. Many people who put sweat into something are a bit eccentric. You are one who truly stands on the shoulders of others while lifting those above you far more than most. -- 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> 03 Jun '05

03 Jun '05

From: Simon Perreault <nomis80(a)lqt.ca> > I think you will agree with me that the amount of work Red Hat put on CentOS > (by way of RHEL) is much more significant than the work put on CentOS by > CentOS volunteers. That is not to say that the work of CentOS volunteers is > not to be appreciated. Don't get all worked up for nothing. And I think some of us agree with you. But as I said before, we're all standing on the shoulders of others. In general, I don't like "distro contests" because there's just so much overlap. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: [CentOS] Re: Reboots -- lsof and SIGHUP, a combination to know ...
by Bryan J. Smith <b.j.smith＠ieee.org> 03 Jun '05

03 Jun '05

From: Ralph Angenendt <ra+centos(a)br-online.de> > If you can read binary :) > The script section of the glibc RPM is a very simple one: > [angenenr@shutdown dict]$rpm -q --scripts glibc > postinstall program: /usr/sbin/glibc_post_upgrade.i686 > postuninstall program: /sbin/ldconfig > And I cannot find Documentation for glibc_post_upgrade at the moment, a > "strings" on that binary doesn't really help either. I'll look through the source. Looks like it may be a bit more involved than just a simple SIGHUP. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: [CentOS] Re: Reboots -- LSB 2.1 Core Generic Section 8.5
by Bryan J. Smith <b.j.smith＠ieee.org> 03 Jun '05

03 Jun '05

From: Rodrigo Barbosa <rodrigob(a)suespammers.org> > You didn't crossed me. Maybe it is because it is late here, and > english is not my primary language. I'm sorry if I gave you that > impression. > I just get repetitive sometimes, due to lack of better language > tools. Okay, I will keep that in mind. My apologies, and I should have picked up on that when you mentioned Connectiva. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Separate list for political/philosophical discussion
by Ugo Bellavance 03 Jun '05

03 Jun '05

Hi, How about creating another mailing list to let people vent themselves? It would make it easier for everyone, since technical/troubleshooting issues and opinions target different people. This messages is a test as well. I couldn't write to the list through gmane so I corrected the address with gmane admin. Hope this works. Regards,

1 0

CentOS-announce Digest, Vol 4, Issue 2
by centos-announce-request＠centos.org 03 Jun '05

03 Jun '05

Send CentOS-announce mailing list submissions to centos-announce(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. CESA-2005:480 Moderate CentOS 3 i386 ImageMagick - security update (Tru Huynh) 2. CESA-2005:480 Moderate CentOS 3 x86_64 ImageMagick - security update (Tru Huynh) 3. CESA-2005:476 Moderate CentOS 4 ia64 openssl - security update (Pasi Pirhonen) 4. CESA-2005:430 Moderate CentOS 4 ia64 gnutls - security update (Pasi Pirhonen) 5. CESA-2005:433 Moderate CentOS 4 ia64 postgresql - security update (Pasi Pirhonen) 6. CESA-2005:476 Moderate CentOS 3 ia64 openssl - security update (Pasi Pirhonen) 7. CESA-2005:433 Moderate CentOS 3 ia64 postgresql - security update (Pasi Pirhonen) 8. CESA-2005:476 Moderate CentOS 3 s390(x) openssl - security update (Pasi Pirhonen) 9. CESA-2005:433 Moderate CentOS 3 s390(x) postgresql - security update (Pasi Pirhonen) 10. CESA-2005:480 Moderate CentOS 4 ia64 ImageMagick - security update (Pasi Pirhonen) 11. CESA-2005:480 Moderate CentOS 3 ia64 ImageMagick - security update (Pasi Pirhonen) 12. CESA-2005:480 Moderate CentOS 3 s390(x) ImageMagick - security update (Pasi Pirhonen) 13. CESA-2005:480 Moderate CentOS 4 i386 ImageMagick - security update (Johnny Hughes) 14. CESA-2005:480 Moderate CentOS 4 x86_64 ImageMagick - security update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Thu, 2 Jun 2005 17:28:25 +0200 From: Tru Huynh <tru(a)centos.org> Subject: [CentOS-announce] CESA-2005:480 Moderate CentOS 3 i386 ImageMagick - security update To: centos-announce(a)centos.org Message-ID: <20050602152825.GA23291(a)sillage.bis.pasteur.fr> Content-Type: text/plain; charset="us-ascii" CentOS Errata and Security Advisory 2005:480 ImageMagick security update for CentOS 3 i386: https://rhn.redhat.com/errata/RHSA-2005-480.html The following updated file has been uploaded and is currently syncing to the mirrors: i386: updates/i386/RPMS/ImageMagick-5.5.6-15.i386.rpm updates/i386/RPMS/ImageMagick-c++-5.5.6-15.i386.rpm updates/i386/RPMS/ImageMagick-c++-devel-5.5.6-15.i386.rpm updates/i386/RPMS/ImageMagick-devel-5.5.6-15.i386.rpm updates/i386/RPMS/ImageMagick-perl-5.5.6-15.i386.rpm source: updates/SRPMS/ImageMagick-5.5.6-15.src.rpm You may update your CentOS-3 i386 installations by running the command: yum update ImageMagick\* Tru -- Tru Huynh (CentOS-3 i386/x86_64 Package Maintenance) http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xBEFA581B

1 0

Problems with mod_auth_ldap module
by Harald Finnås 03 Jun '05

03 Jun '05

Just wondering if anyone's using the apache mod_auth_ldap module with require directives other than "valid-user"? Reason for asking is that no matter what require statement (except valid-user) I try to use, apache logs "unknown require directive". According to the ldap logs it does lookup, and find, the user in question. Any thoughts? Config error or bug? Regards, Harald

1 0

OpenCA rpm package
by User Lists 03 Jun '05

03 Jun '05

Hi all, Somebody knows where I can find an openca rpm package??? Thank you very much. __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.espanol.yahoo.com/

1 0

Is RHEL to CentOS conversion possible?
by Akop Pogosian 03 Jun '05

03 Jun '05

Is it possible to convert an RHEL 3 system into Centos 3 without reinstalling the OS? -- A k o p P o g o s i a n (akopps(a)ls.berkeley.edu) Unix Consultant Letters & Science Computer Resources 461 Birge Hall (phone: 510-643-2989)

3 4

Re: Reboots -- lsof and SIGHUP, a combination to know ...
by Bryan J. Smith <b.j.smith＠ieee.org> 03 Jun '05

03 Jun '05

From: Simon Perreault <nomis80(a)lqt.ca> > Sure, theoretically it would be possible, but how would you restart this one? > [nomis80@poste10-153 ~]$ sudo lsof | grep libc | grep init > init 1 root mem REG 253,0 1521500 999437 /lib/tls/libc-2.3.5.so I need to verify the post-install script for the glibc RPM, but I believe it SIGHUPs the process -- and SIGHUP tells GLibC to reload itself for all new calls from any new process, while leaving the old code available for running processes. Building a tree of service calls and dependencies is the way to figure out what is using what -- even if indirectly. lsof does a fantastic job of this with the right option combinations (I need to look at my command history). Remember, UNIX experience is everything, and that means if I don't know, I get out a test system and throw something like a SIGHUP at it and see what happens. ;-> The lack of using UNIX-like signals in NT is what really makes me dislike NT. Sure, there are lots of UNIX libraries/services that don't always handle every signal -- and many just use SIGHUP as a hard restart. But many of the critical ones do. The majority of even Microsoft's own core libraries are completely ignorant of NT, as they were written for "Chicago." Get to know your UNIX/Linux platform. It's the best way to document procedures that you may need to have in a situation. One I regularly document is how SIGHUP affects different libraries/services. -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 2

Re: Reboots -- LSB 2.1 Core Generic Section 8.5
by Bryan J. Smith <b.j.smith＠ieee.org> 03 Jun '05

03 Jun '05

From: Rodrigo Barbosa <rodrigob(a)suespammers.org> > There is nothing wrong with using X11 at runlevel 3. The only thing > that can't be present is a display manager (KDM, XDM, GDM etc). That's _exactly_ what I'm talking about. Run-level 3 starts xdm. Several Linux distros use 2 for multi-user, 3 for multi-user w/X. Run-level 2 as multi-user w/o networking or w/o NFS was introduced by Red Hat, and any Fedora-based (or RHL-based) distro uses it. > If it is, it is wrong, and doesn't comply with the unix standard (don't > remember exactly which, but I studied it when working for Conectiva). First off, it's not "wrong." Many distros established many different standards well before any standardization efforts. Even Linus admits that he based many things off of SunOS 4.1 (retroactively Solaris 1) and Solaris 2, and Solaris uses 2-3. [ Remember, Solaris was the original GNU platform. ] So in that regard, Debian is actually like Solaris in its use of 2-3, instead of Fedora-based 3-5. Secondly, you are referring to Linux Standards Base (LSB). Specifically, Section 8.5 in the General Section of the latest revision: http://refspecs.freestandards.org/LSB_2.1.0/LSB-Core-generic/LSB-Core-gener… And even this latest version states: "However, it is not required that LSB-compliant run-time environments use these run levels; the distribution-provided install_initd script may map the run levels specified below to whatever distribution-specified run levels are most appropriate." It should also be noted that not even Fedora Core's init scripts are fully LSB compliant, and Debian and SuSE do far better in many areas. LSB even declares RPM as the package standard. But at the same time, one might remember why LSB came into existance -- to try to get standards across largely FC/RHL forks and other RPM distros. As much as it attempts to be platform agnostic, some of its standards are heavily defaulting to RPM ones. > The standard is there. If a distro chooses not to follow it, > you can be very sure it will have acceptance problems. Not nit-pick, but your statement was _exactly_: "Also, run-levels are standarized, and should be the same on all unix-like platforms." Not only is there _no_ standard for System-V platforms, but pretty much LSB says even Linux distros can do what they want. There is _no_ "run-level standard" for "unix-like platforms." > When I have time later today (or tomorrow), I'll give out the > standard I'm mentoning and will give you a proper reference. > Sorry I can't provide it from the top of my head. LSB 2.1 Core Generic Section 8.5. Again, URL: http://refspecs.freestandards.org/LSB_2.1.0/LSB-Core-generic/LSB-Core-gener… Just to summarize, this thread was _not_ to "prove you wrong." It was just a reminder that not only do Linux systems vary wildly, but "UNIX-like" systems do as well and you should be careful with assumptions. ;-> -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 20

Re: Reboots -- Short Answer
by Bryan J. Smith <b.j.smith＠ieee.org> 03 Jun '05

03 Jun '05

From: Prasad Pillarisetti <prasad.pillarisetti(a)gmail.com> > ***Do you perform downtimes just for the purpose of rebooting the systems? > ***Is there a recommended interval Linux system should be rebooted? Okay, here's my short answer: Regardless of OS, you should _always_ reserve dates/times for preventive maintenance on a regular basis. But I agree with most others, unless it is a kernel upgrade or GLibC change, there's no absolutely need to reboot. Not even during preventive maintanence should you feel compelled. -- Bryan J. Smith mailto:b.j.smith@ieee.org

4 6

rhel3 < centos3 updates
by Stephen M. Gava 03 Jun '05

03 Jun '05

Hi all, I've been approached by someone who has an installation of rhel ES 3 (taroon update 2) to see whether I can take over doing security and other updates for them (no current rhn subscription). What I want to know is, with a suitable yum setup can I use a centos3 repository to apply updates to this box? If so, should I source updates from centos 3.5? Does the whole box need to become a centos3 box to do this? They'd really like to disturb the existing box (I agree) as little as possible since it's a stable production server, and mainly just want important security related updates etc. done. Ok, tia for any answers, Stephen. -- Stephen M. Gava <smig(a)users.sourceforge.net>

3 4

Re: Vote For CentOS :) -- at this point, call the FSF ...
by Bryan J. Smith <b.j.smith＠ieee.org> 03 Jun '05

03 Jun '05

From: Les Mikesell <lesmikesell(a)gmail.com> > Can you get the product without being bound by the restrictions? > That is, can one user purchase one and resell copies without the SLA > or with their own? Not with the trademark, that is mis-appropriation. If you want to complain about Red Hat doing this, then you'll want to complain about a number of distributors well before Red Hat who are far worse. > The GPL covers anything that can be considered a derivative work under > copyright law. That certainly includes binaries. Now you're mixing things. The GPL does _not_ address binaries, just what is required -- availability of source, and no restrictions on that source for things that are required for that source to work -- _regardless_ of what is redistributed. It also states that you can't use GPL source with someone non-GPL that requires it to function. Trademarks do not. The software functions the same regardless whether or not you have the trademark. > No one is obligated to provide them, but they cannot prohibit copying > or redistribution as long as the requirement to include or offer source is > met. No one can prohibit restricting the _source_. Again, you are mixing things. I can restrict whatever I want on the binaries, as long as I'm abiding by the other terms of the GPL on the source. That means I don't redistribute anything in any form, unless the source for that is freely available in a way that is unrestricted that the software works the same. SuSE, Dan's Guardian and other distros/software go farther in not even making source packages available. Red Hat at least dumps out _all_ SRPMs, even the overwhelming majority they could point to Fedora for. > No, it covers all derivative works. No, copyright law does. If a copyright holder explicitly states that he/she will not allow trademarks to be bundled with the software, or any installer or other "helper" software, then he/she has the right to do that. But the GPL itself does _not_. > Otherwise it could not prohibit distribution of something that must be > linked to a proprietary dynamic library to function. But trademarks are _not_ required for the software to function exactly the same. That's the difference! Again, you're mixing things. > Typically the FSF has claimed that anything linked into a binary > becomes part of the derivative work. [ The BS watches Les drop off the deep end ;-] > I don't particularly agree with it You don't particularly seem interested in realizing that Red Hat is the _least_ of our problems among commercial companies. And you don't seem to be interested in Trademark Law, and the whole concepts of why it exists. Red Hat's "goodwill" severely crippled their ability to deal with some companies who have no problem with trashing their name. I don't think you realize that Microsoft could have flooded the market with an ultra-crappy "Red Hat(R) Linux" that would have destroyed mindshare overnight. Sun was basically on their way to doing it too, which pissed a lot of us off. Because of Sun and others, Red Hat had to vehemetly defend their trademark to the anal power, and projects like CentOS are stuck with dealing with that as a result. Red Hat is the _only_ major commercial Linux entity that allowed redistribution of its trademark on a scale large enough that it could have been declared "public domain" by the USPTO. Red Hat lives with that now. *NO* other commercial vendor will attempt it in the future either. [ The only exception seems to be SuSE(R), which Novell seems to be turning into a "Fedora-like" trademark. ] > - I'm just reading what it says, and 'no additional restrictions' > seems pretty clear. Take "Red Hat(R)" out of the GPL software and it works _exactly_ the same. If you really have a bug up your ass about this, ask FSF lawyers. ;-> Red Hat can only say they've cleared it with the FSF so many times before people who don't want to believe will _never_ believe (like yourself). The maintainer of Dan's Guardian regularly gets ignorant pukes who complain he is "violating" the GPL by not making the source available on his web site. Same deal, he's got things cleared with the FSF and Stallman, but people want to assume things. The GPL is _not_ about "free" -- it's about "freedom." The "freedom" to modify source code and keep software alive, well after the copyright holders might be dead or don't care. It doesn't give you the right to mis-appropriate trademarks. And unlike patents, trademarks are _not_ required for the software to function legitimately and exactly. > If someone adds their trademark to something that becomes a > derivative work of something carrying the GPL, they should either > not be able to distribute at all, or they have to allow redistribution. If the GPL 3.0 says this, then pretty much not only will _all_ commercial distributions die, but pretty much all support avenues for Linux. I don't think you realize the precedent you're asking for. > Things that aren't embedded in a GPL work would be different, You _can_ "bundle" anything with GPL that it doesn't require. > like artwork that happens to be on the same disk and there is no > requirement to make it easy to separate the 'merely aggregated' > parts, though. What do you mean by "embedded"? RPM is merely just a USTAR 5KB block size (cpio System-V) archive. Even an ISO9660 "Yellow Book" track (data CD) can be considered an "archive." Do you _really_ want to open up that "subjective" door? At this point, ask the FSF. I think you're just going to argue this until you get the answer you like. Good luck with the FSF. -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 2

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

03 Jun '05

From: Les Mikesell <lesmikesell(a)gmail.com> > Of course. What does an SLA have to do with restricting copying or > redistribution? Because you're paying for services, not a product. > What kind of restriction would be excluded by the GPL if not ones that > restrict copying, installing on additional machines, or redistribution? Public redistribution of the _binaries_ is prohibited because of the trademarks. There is _no_ term in the GPL that mandates that anyone provide you with binaries or otherwise packaged software that is "ready-to-use." This is the GPL. At the same time, as long as the additives are not required for the software to function, Red Hat, SuSE, Novell, Mandrake, etc... are free to bundle whatever art, trademarks, etc... with the software, even the source code. The GPL still only guarantees you the right to _source_ code redistribution without restriction. If you want to play the trademark card, then you're going _outlaw_ pretty much _every_ major commercial company from producing GPL software. And Red Hat is the least of our concerns. ;-> -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 2

Re: Reboots -- everything's a file
by Bryan J. Smith <b.j.smith＠ieee.org> 03 Jun '05

03 Jun '05

From: Rodrigo Barbosa <rodrigob(a)suespammers.org> > Actually, there is another neat trick for rpm based systems. > You see, rpm, prior to removing anything, will rename that to ${NAME}.OLD. > So, libc.so.6 becomes libc.so.6.OLD, and then removed. > As we all know, if that library is currently open by any running process, > it won't be imediately removed (even tho you can't see it with a 'ls'). > The trick is pretty simple: lsof | grep OLD > That, of course, only aplies if you are doing everything using RPM > (yum, redhat-update, apt-get). That's because open file handles work in inode number, not filename. So you can rename things out-of-the-way for existing file handles, while creating a new file that will be opened for any new ones. Devices, processes, etc... in UNIX pretty much have the same logic as files. Which is why I love UNIX -- everything acts like a file, with similar meta-data, etc... -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

Reboots
by Prasad Pillarisetti 03 Jun '05

03 Jun '05

***Do you perform downtimes just for the purpose of rebooting the systems? ***Is there a recommended interval Linux system should be rebooted?

9 17

Re: Vote For CentOS :) -- assumptions based on branding ...
by Bryan J. Smith <b.j.smith＠ieee.org> 03 Jun '05

03 Jun '05

From: me(a)prestoncrawford.com > They could not do the latter as far as I understand it. Because > Fedora Core is not the source code (letter for letter) of RHEL. From: "Bryan J. Smith <b.j.smith(a)ieee.org>" > Every RHEL package as a 1:1 version to Fedora, typically Fedora > Core, possibly Fedora Development (as it seems MySQL 4 was). > This is fact. Nothing goes into RHEL without going through > Rawhide/Development first -- if not into Fedora Core. > If you read Red Hat's own development and lists, packages that > have "EL" are typically subsets of the FC version. Most of the > time, it's due to locale -- Red Hat strips out unsupported locale. > In other cases, there might be supersets, like the kernel. In those > rare cases, yes, Red Hat needs to redistribute those source changes. BTW, assumptions such as yours is entirely based on "branding." It's a common thing that people do, and goes to the heart of the trademark matter, as well as gross mis-representation and lack of attention to detail by many. People assume something is "Red Hat(R) Linux" because the "Red Hat(R)" trademark is on it. They assume it is completely different if the trademark is not. It doesn't matter if completely modified packages for an architecture Red Hat never supported, and the packages are even completely SRPM _incompatible_, people believed it was still "Red Hat(R) Linux." Ironically, people assume "Fedora(TM) Core" has nothing to do with "Red Hat(R) Enterprise Linux" -- or is at least completely different in its relationship with RHEL than "Red Hat(R) Linux" was -- merely because of the "branding." In training courses, I've taken people completely through an entire rebuild of core packages, down to version, of Fedora Core and Red Hat Enterprise Linux, as well as SuSE Linux and SuSE Linux Enterprise Server, and it's amazing to see that FC and RHEL differ far less than SL and SLES. If the RPM version is the same for a package of Fedora Core and Red Hat Enterprise Linux, they _are_ the same from the standpoint of GPL source code. Things that are modified have "EL" attached to the version, and in many cases, it's actually a locale subset consideration for RHEL. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

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

03 Jun '05

From: me(a)prestoncrawford.com > I blame it for a lot already, thanks. :-) In reality, there are good reason for it. E.g., people who had Cobalt systems assumed they were running Red Hat Linux. They were not, just running a heavily modified version. So when people tried to patch and update, they got upset with Red Hat. When the reality was that the distro should have _never_ had Red Hat's name on it. This was just one example. I still hear non-sense from Cobalt users on this. It's funny to see them come full circle on the logic. > This is what I don't get, though? What's the difference between internal > and external? Whatever the lawyers can prove it is. ;-> In a nutshell, there is no "cheat sheet" to respecting IP -- be it copyrighted GPL, trademarked IP or patents. You must document before you distribute. If you are using something like GPL, trademarks, etc... "internally" -- you must guarantee they won't be redistributed to guarantee you won't be distributing something without a license. That's all. No different than any other software. The GPL does not trump copyright or any other IP law, although copyright holders are free to clarify what is and isn't allowed. > I know, I know, it's all about the trademarked logos, names, etc. > But at the end of the day, the source code is still the source code. And we have Red Hat to thank for a lot of it too. > And it's still GPL. So they have to provide (assuming they're distributing > a GPL product) if you ask for it, regardless of whether it's internal to your > company, external, whatever. Whomever you distribute it to is the only one you are required to give the source code to. And you can't put any restrictions on that source code, or anything required for it to work. If I do something within my company, my company isn't going to consider it redistribution. My company is aware that I am using something under circumstances that are not public. So there is no need to abide by the GPL license in how I use it, and no need for a trademark license either. But once I start redistributing that outside the entity I work for, then that's when the legal issues mount. If I am redistributing additional code with the GPL software that modifies it in a way that it works differently, then the original copyright holder, under the granted terms of the GPL, says I have to offer the source code of those modifications under the same terms, without restriction. If I don't, then I am distributing the copyright holder's work without a license, and he is due damages. Same deal with trademark. Once I start redistributing Red Hat's trademark publicly, I am doing so without a license. And they are due damages. Lack of Red Hat's trademark and artwork does not prevent the GPL software from being used the same as with it. That's the difference. Red Hat -- like other distros -- are merely branding their work, into a packaged unit. > Once they've distributed GPL-based software, they have to offer the > source. Period. Yes, and they do. They could claim that Fedora Core SRPMS are everything, except for maybe the kernel and a few other SRPMS. That's what other distros do. Most commercial distros have 2 versions: 1 redistributable, 1 non. The commercial distros then only redistribute the source packages for the redistributable version, and not for the non. Red Hat is one of the very few that do for _both_, so things like CentOS can exist. And it depends on who you redistributed it to. That's why I used the term "publicly" redistributed. Because unlike the MPL1.0 (or is the opposite, and 1.1?) and many GPL-incompatible licenses, the GPL does _not_ require you to return any modifications to the copyright holders _unless_ you redistribute it. The MPL and most off-shoots _do_. GPL gives you the right to do what the heck you want with it -- even merge it with proprietary source code. But if you redistribute that modification outside of our own, internal uses, then that's when it becomes an issue. > They can ask that you not include the trademarks, On a "public" redistribution. What is done internally is not a violation of Trademark Law. I'm not mis-representing some product or service I redistribute as "Red Hat(R)" by merely using it. So there is no redistribution of the trademark without a license. > but that aside, they can't tell you that since it's "internal" it can't be > redistributed. Huh? I think you are confused on what I meant by internal/external. If you use it internally and don't redistribute it, then you are free to install RHEL on as many systems as you want. You can even have a field day and put "Red Hat sucks" all over their trademark. Unless Red Hat can prove that you are misappropriating their trademarks _publicly_ -- their mark in the trade -- then they can't prevent you from installing it on as many systems as you want, and doing what they heck you want. At least on the GPL/LGPL portions. MPL, IBM CPL/IPL, Sun SCSL/etc... will differ. > That's not my understanding of the GPL when it comes to source. GPL source code has nothing to do with this. The GPL source code does not require the Red Hat(R) trademarks to operate. You can freely bundle anything you want with GPL as long as it's not required to work. So for all intents and purposes, there is nothing wrong with bundling GPL source code with Red Hat, SuSE, Mandrake, etc... I can even take the SRPMS, rebuild them, and install them on my systems, with_out_ removing the Red Hat trademark. But if I'm providing services for others -- at cost or not -- with Red Hat's trademark, then it gets a bit more messy. Why? Because Red Hat can claim I'm mis-appropriating their trademark. That's what got Red Hat into trouble before. They let everyone freely use the Red Hat(R) trademark, and it came back to bit them when they tried to get select vendors (Cobalt, Sun, etc...) to stop leaving it on massively modified versions. It was killing the value of their trademark, because people were assumed something was Red Hat Linux when it was nothing of the sort. But that's when Sun barked back and used Trademark Common Law against Red Hat. Hence why Fedora(TM) became a reality. The other aspects to Fedora Core were already established in Red Hat Linux in years prior. > Understood. But their trademark is different from the other > 99.99999% of the distribution, which is Open Source code. The trademark is bundled with the GPL code, but it is not required for it to operate. > I never said anyone had the right to binaries. I'm simply confused > as to how you can put licensing restrictions on source code simply > because it's "internal". That is the issue in question, I believe. There is _no_ "licensing restrictions" because it is "internal." You can use Red Hat trademarks as you see fit as long as you are _not_ proliferating their "mark" in the "trade." The latter is "external"/"public" redistribution. Which is where you can get into legal trouble. > They could not do the latter as far as I understand it. Because > Fedora Core is not the source code (letter for letter) of RHEL. Every RHEL package as a 1:1 version to Fedora, typically Fedora Core, possibly Fedora Development (as it seems MySQL 4 was). This is fact. Nothing goes into RHEL without going through Rawhide/Development first -- if not into Fedora Core. If you read Red Hat's own development and lists, packages that have "EL" are typically subsets of the FC version. Most of the time, it's due to locale -- Red Hat strips out unsupported locale. In other cases, there might be supersets, like the kernel. In those rare cases, yes, Red Hat needs to redistribute those source changes. > So they HAVE to make the RHEL source code available somehow. > Even if it's "pay us for the CDs". Nope. Not at all. As long as the package is the same between Fedora Core and RHEL, no need. One of these days I'm going to finish a book on Red Hat Configuration Management and show an _exact_ lineage of a RHEL release built on Fedora Core. Trust me on this, I've built Fedora Core systems that were _exact_ package equivalents to RHEL -- with the only real exception being the kernel. I typically had to "hold back" on versions from what was "current" in Fedora Core, as well as align up the Fedora Core version to RHEL. But they are 1:1 -- versions are everything. SuSE does the same thing for SuSE Linux v. SuSE Linux Enterprise Server. They don't redistribute a lot of the latter. Xandros is the same on many of its details, etc... > I agree. What I don't agree with is this idea that once the SRPMS > are out there in the wild that somehow Red Hat can put restrictions > on the distribution of the source. There is no redistribution restriction on the source. But there are redistribution on the trademarks if you rebuild from source. > They just can't, as far as I understand the GPL. If you outlaw any bundling with GPL code, then you're going to outlaw 99.999% of the GPL distribution in existance. > Once the source has been made available to SOMEONE, regardless > of whether it's internal, external, whatever, it can be passed on. Yes, without any IP that are not required for the software to function anyway. > That's good that they stick "closer" to the letter. I'm not so sure > they're following it completely, though. They are. Ask the FSF. Too many people put Red Hat under the microscope when there are other distros are doing far, far less "community friendly." It's a double-standard I quite tire of. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

CentOS 4 in Virtual PC for Mac 7.0.1
by T'Krin 02 Jun '05

02 Jun '05

Hey all. Has anyone been able to successfully install CentOS 4 in Virtual PC on the Mac? I have tried numerous times in both gui and text install mode w/ and w/o package customization and minimum and everything install. The install dies just when packages are beginning to be installed or very shortly thereafter. I don't get a full screen of errors to share as they pass by the screen too far and end w/ a message saying the installation has died unexpectedly. Any ideas? Thanks, ~Dan

4 5

Re: [CentOS] Vote For CentOS :)
by me＠prestoncrawford.com 02 Jun '05

02 Jun '05

-------- Original Message -------- > From: "Bryan J. Smith <b.j.smith(a)ieee.org>" <thebs413(a)earthlink.net> > Sent: Thursday, June 02, 2005 2:31 PM > To: CentOS mailing list <centos(a)centos.org>, centos(a)centos.org > Subject: Re: [CentOS] Vote For CentOS :) > > From: me(a)prestoncrawford.com > > I'm not confused. I think the point is (and this has seemingly > > been a persistent issue since the RHEL rebuilds appeared on the > > scene) > > Blame US Trademark Law then. I blame it for a lot already, thanks. :-) > > that Red Hat puts licensing restrictions on GPL software. > > Red Hat does not put any restriction on your use of their trademarks > internally. But due to US Trademark Law, Red Hat cannot let you This is what I don't get, though? What's the difference between internal and external? I know, I know, it's all about the trademarked logos, names, etc. But at the end of the day, the source code is still the source code. And it's still GPL. So they have to provide (assuming they're distributing a GPL product) if you ask for it, regardless of whether it's internal to your company, external, whatever. Once they've distributed GPL-based software, they have to offer the source. Period. They can ask that you not include the trademarks, but that aside, they can't tell you that since it's "internal" it can't be redistributed. That's not my understanding of the GPL when it comes to source. > publicly redistribute anything "Red Hat(R)" in a way that would allow > a judge to rule Red Hat allows free redistribution of their trademark > without a license. Understood. But their trademark is different from the other 99.99999% of the distribution, which is Open Source code. > Furthermore, please point me to the section where the GPL says I > have the right to binaries and other package distributions of GPL > software? It only says I have a right to any GPL source code, and I never said anyone had the right to binaries. I'm simply confused as to how you can put licensing restrictions on source code simply because it's "internal". That is the issue in question, I believe. > any required source code (which is then also GPL) for the software > to function under no other terms than GPL. > > > And that strikes many of us as odd. > > What is odd to me is that people see this as a Red Hat-only issue. > Not only is Trademark Law really a PITA for Red Hat, but Trademark > Laws in other countries -- notably Germany -- is why SuSE's hand > has been forced even more. Agreed. > [ E.g., does anyone remember the KIllustrator name change? > It wasn't Adobe's doing at all! ] > > And most don't stop to read the GPL, and what it's real terms are. > > If I sell GPL software, I do _not_ have to put the source code on > my site. In fact, Red Hat could choose to _only_ distribute the > GPL source code on CDs or -- better yet, do what SuSE does -- > and say the GPL source code is available in Fedora Core. They could not do the latter as far as I understand it. Because Fedora Core is not the source code (letter for letter) of RHEL. So they HAVE to make the RHEL source code available somehow. Even if it's "pay us for the CDs". > Let me say that again, Red Hat doesn't even need to offer SRPMS. > They could just plunk out the "raw" source code, or just point to > Fedora Core -- or maybe just the few SRPMS (like the kernel) that > differ -- and make it 100x more difficult for distros like CentOS to > exist! I agree. What I don't agree with is this idea that once the SRPMS are out there in the wild that somehow Red Hat can put restrictions on the distribution of the source. They just can't, as far as I understand the GPL. Once the source has been made available to SOMEONE, regardless of whether it's internal, external, whatever, it can be passed on. > Red Hat doesn't play such games. They put out source packages > for _both_ Fedora Core _and_ RHEL -- so there are no questions. That's good that they stick "closer" to the letter. I'm not so sure they're following it completely, though. Preston

1 0

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

02 Jun '05

From: me(a)prestoncrawford.com > I'm not confused. I think the point is (and this has seemingly > been a persistent issue since the RHEL rebuilds appeared on the > scene) Blame US Trademark Law then. > that Red Hat puts licensing restrictions on GPL software. Red Hat does not put any restriction on your use of their trademarks internally. But due to US Trademark Law, Red Hat cannot let you publicly redistribute anything "Red Hat(R)" in a way that would allow a judge to rule Red Hat allows free redistribution of their trademark without a license. Furthermore, please point me to the section where the GPL says I have the right to binaries and other package distributions of GPL software? It only says I have a right to any GPL source code, and any required source code (which is then also GPL) for the software to function under no other terms than GPL. > And that strikes many of us as odd. What is odd to me is that people see this as a Red Hat-only issue. Not only is Trademark Law really a PITA for Red Hat, but Trademark Laws in other countries -- notably Germany -- is why SuSE's hand has been forced even more. [ E.g., does anyone remember the KIllustrator name change? It wasn't Adobe's doing at all! ] And most don't stop to read the GPL, and what it's real terms are. If I sell GPL software, I do _not_ have to put the source code on my site. In fact, Red Hat could choose to _only_ distribute the GPL source code on CDs or -- better yet, do what SuSE does -- and say the GPL source code is available in Fedora Core. Let me say that again, Red Hat doesn't even need to offer SRPMS. They could just plunk out the "raw" source code, or just point to Fedora Core -- or maybe just the few SRPMS (like the kernel) that differ -- and make it 100x more difficult for distros like CentOS to exist! That's _exactly_ what SuSE does with SuSE Linux Enterprise Server (SLES). And many other distros are similar -- they have their "redistributable" source packages for their "redistributable" version, and then _none_ for their non-redistributable version. Red Hat doesn't play such games. They put out source packages for _both_ Fedora Core _and_ RHEL -- so there are no questions. -- 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> > Let me ask again... What could possibly impose a restriction if you > don't the consider the penalties of contract breakage to be a > restriction? I think one point that is being missed is that one licenses the subscription and any services the license it entitles one to, and not the software. So if one breaks the contract, one is not breaking the contract on the software, but the license for those entitlements to the subscription/services. As far as the trademarks and art goes, Red Hat doesn't care as long as you are not redistributing them to other entities. That was the whole reason for the several revisions and clarifications of the "Red Hat(R)" trademark prior and the eventual switch to _only_ allow redistribution of the "Fedora(TM)" trademark by other parties. > Since RH does permit source redistribution regardless Don't confuse external with internal redistribution. When you redistribute Red Hat Enterprise Linux internally, you are not publicly distributing "Red Hat(R)" without a license. The GPL itself actually works very similar. You can mix GPL and non-GPL code freely, as long as you don't publicly redistribute it. This is how corporations modify GPL software all-the-time without releasing the source code of their modifcations. In my standard license terminology for corporate legal departments, I call this "Sourceware" (Open Source, Proprietary Standard). It is GPL code that has been modified with proprietary code, so it can never be redistributed. Because under the terms of the GPL, if it is redistributed, then any and all modifications to the source will have to be as well. I can copy anything "Red Hat(R)" to my hearts content as long as I don't publicly redistribute it. Because I'm not redistributing their trademark without a license. > and hence the existence of projects like Centos, they are not > strictly breaking the GPL here, but if that contract isn't a > restriction I'd like someone to explain what would be in the > sense excluded by the GPL. The contract doesn't cover the software. And regardless of a contract or not, you do _not_ have rights to redistribute "Red Hat(R)" any more than "Mandrake(R)," "SuSE(R)," "Novell(R)," etc... Red Hat tried to clarify its trademark guidelines on "Red Hat(R)" several times to allow for Cheapbytes and other, 100% unmodified redistribution. But eventually the entire issue came to a head, and US Trademark Common Law is rather non-forgiving on Red Hat's past history of allowing its trademark to be freely redistributed. The reason why GPL is enforceable is because it doesn't take away copyright. In the same regard, the GPL does not take away any other rights to IP. Now should any copyright clarify that he/she will not allow any trademark or other IP restrictions on redistribution of their GPL, then pretty much _every_ commercial distro is going to be SOL. > I'm not a particular fan of the GPL. I just don't see how it works > to distribute GPL'd stuff along with a contract that imposes additional > restrictions and penalties for breaking them. Because the contract does not tell you what you can and can't do with GPL software. It only specifies what you can do with things bundled with that GPL software -- namely the trademarks. Since the trademarks are not required for the software to function, there is no violation of the GPL terms. _Furthermore_, if you read the GPL carefully, it _never_ says what limits you can and can't place on _binaries_. It only says _source_. It says you must provide the source to anyone you redistribute the software to (in whatever form that software may be). This is Stallman's "Moral Delima" at its finest. Several GPL products exist where the vendor does _not_ provide you with the binary redistribution for free, or even the source for that matter, but the source is included with the binary distribution -- "for a nominal fee." This is one of the reasons why people fear the GPL 3.0 license might change some minor things that will affect them majorly. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: [CentOS] Vote For CentOS :)
by me＠prestoncrawford.com 02 Jun '05

02 Jun '05

I'm not confused. I think the point is (and this has seemingly been a persistent issue since the RHEL rebuilds appeared on the scene) that Red Hat puts licensing restrictions on GPL software. And that strikes many of us as odd. Preston ---------------------------------------- From: Simon Perreault <nomis80(a)lqt.ca> Sent: Thursday, June 02, 2005 2:13 PM To: CentOS mailing list <centos(a)centos.org> Subject: Re: [CentOS] Vote For CentOS :) On Thursday 02 June 2005 16:01, Les Mikesell wrote: > What kind of restriction would be excluded by the GPL if not ones that > restrict copying, installing on additional machines, or redistribution? Nobody's restricting anyone to do that with RHEL. Is anybody else as confused as I am? _______________________________________________ CentOS mailing list CentOS(a)centos.org http://lists.centos.org/mailman/listinfo/centos

1 0

Re: Reboots -- run-levels 2-5 vary wildly ...
by Bryan J. Smith <b.j.smith＠ieee.org> 02 Jun '05

02 Jun '05

From: Rodrigo Barbosa <rodrigob(a)suespammers.org> > rcS.d is not a runlevel. It is the equivalent of rc.sysinit on other > distributions/flavors or, should I say, and expansion of that idea. Correct, that's why I said "before" the run-levels at boot. But you still need to know about it. > 0 - Halt > 1 - Single User > 2 - Multi User (No NFS) > 3 - Multi User > 4 - Reserved > 5 - Multi User (Graphical, originaly XDM) > 6 - Reboot > The processes started at each runlevel will differ, of course. > Not all machines will run httpd on run levels 2, 3 and 5. But > none should run it at run levels 0, 1 or 6. This are the Fedora-based distro run-levels. Level 2-5 actually _differ_ on many UNIX/Linux platforms. E.g., _many_ use 3 _not_ 5 for X11. The only consistency seems to be 0, 1 and 6 -- although many distros differ on a "maintanence" run-level between 0 and 1. -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

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

02 Jun '05

From: Lamar Owen <lowen(a)pari.edu> > Red Hat didn't go the SuSE route though and not freely license their > installer; Anaconda is GPL, but YaST was not, thus you couldn't even > do with SuSE what is being done now with RHEL. Until Novell bought SuSE and started GPL'ing things, correct. Of course, Novell already has enough of its own, proprietary** software so SuSE's hold was chump change. [ **NOTE: Unlike many people, I don't consider "proprietary" software to be inheritly bad. I'm also careful not to call some software from Microsoft "proprietary," because much of their software doesn't even qualify as "proprietary" because they lack even "proprietary" standards. ] Something should also be said about Red Hat only producing GPL software -- be it new developments of their own creation (and copyright), as well as supporting only projects that are GPL except in rare cases. Other than maybe Murdock's Progeny, I don't know of another, major commercial Linux vendor who produces 100% GPL software. To make a comparison, Red Hat completely blows IBM out-of-the-water in GPL donations -- both man-hours as well as company buy-outs -- let alone it makes no difference to include "GPL compatible" -- which no IBM "Open Source" license is. And as you've said me say before, even Sun roasts IBM on GPL donations as well. > As a great example, PostgreSQL is a BSD-licensed package. Red Hat > has made significant contributions to the PostgreSQL community (one > by providing full-time PostgreSQL employment for Tom Lane, a Core > PostgreSQL developer, two by paying for several enhancements and > backported bugfixes): It should be noted that PostgreSQL is one of the few, existing projects that Red Hat is supporting that was not licensed GPL. Red Hat really avoids working on things that aren't GPL. > Red Hat is not required by the terms of the BSD license to return > ANYTHING to the PostgreSQL community, nor are they required to > make their version of PostgreSQL, Red Hat Database (now known as > PostgreSQL, Red Hat Edition) source code available to anyone. But > they did make it available. While Red Hat isn't the only major commercial software company that "just gets it." They are the only major commercial Linux company that has a major distro that does. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

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

02 Jun '05

From: Rodrigo Barbosa <rodrigob(a)suespammers.org> > Also, run-levels are standarized, and should be the same on all unix-like > platforms. ??? Debian and Solaris run-levels differ from Red Hat. And some distros, like Solaris and SuSe, also have a "rcS.d" directory that runs in addition to, and before, the run-level. -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

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

02 Jun '05

From: Ken Godee <ken(a)perfect-image.com> > The "POST" routine can give you early warnings of pending > hardware failures that might go un-noticed until complete > failure otherwise. In such cases where that is a worry, I'm going to want to deploy real-time hardware management instead. It's worth the extra few bucks. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

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

02 Jun '05

From: Rodrigo Barbosa <rodrigob(a)suespammers.org> > That, my friend, is very much true. > Depending on the kind of server you are running (mumber of different > processes), a reboot will be much easier. Did that myself a few times. As far as examining running processes, one should have _good_ operational procedures and practices to track what is and isn't running on your system. If you can, stick with Sys-V start/kill init scripts for everything, and document anything that can't be (as well as why). I don't like to rely on reboots to do such things. In fact, when building a new, standard system configuration, I like to shunt to "init 1" and back to "init 3" (run-levels assume distro is Fedora-based) several times to ensure that all my start/kill init scripts are proper. That way I can stop and start user-space services piecemeal and completely. -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 2

How many supported DNS IP addresses maybe configured in /etc/resolv.conf ?
by Prasad Pillarisetti 02 Jun '05

02 Jun '05

How many supported DNS IP addresses maybe configured in /etc/resolv.conf ? Is it only 3, or can I configure more?

3 2

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

CentOS-announce Digest, Vol 4, Issue 1
by centos-announce-request＠centos.org 02 Jun '05

02 Jun '05

Send CentOS-announce mailing list submissions to centos-announce(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. CESA-2005:430 Moderate CentOS 4 i386 gnutls - security update (Johnny Hughes) 2. CESA-2005:430 Moderate CentOS 4 x86_64 gnutls - security update (Johnny Hughes) 3. CESA-2005:433 Moderate CentOS 4 x86_64 postgresql - security update (Johnny Hughes) 4. CESA-2005:433 Moderate CentOS 4 i386 postgresql - security update (Johnny Hughes) 5. CESA-2005:476 Moderate CentOS 4 i386 openssl - security update (Johnny Hughes) 6. CESA-2005:476 Moderate CentOS 4 x86_64 openssl - security update (Johnny Hughes) 7. CESA-2005:476 Moderate CentOS 3 i386 openssl - security update (Tru Huynh) 8. CESA-2005:476 Moderate CentOS 3 x86_64 openssl - security update (Tru Huynh) 9. CESA-2005:433 Moderate CentOS 3 i386 postgresql - security update (Tru Huynh) 10. CESA-2005:433 Moderate CentOS 3 x86_64 postgresql - security update (Tru Huynh) 11. CESA-2005:476-01: Moderate CentOS 2 i386 openssl security update (John Newbigin) ---------------------------------------------------------------------- Message: 1 Date: Wed, 01 Jun 2005 12:23:30 -0500 From: Johnny Hughes <mailing-lists(a)hughesjr.com> Subject: [CentOS-announce] CESA-2005:430 Moderate CentOS 4 i386 gnutls - security update To: centos-announce(a)centos.org Message-ID: <1117646610.2514.14.camel(a)myth.home.local> Content-Type: text/plain; charset="us-ascii" CentOS Errata and Security Advisory 2005:430 gnutls security update for CentOS 4 i386: https://rhn.redhat.com/errata/RHSA-2005-430.html The following updated files have been uploaded and are currently syncing to the mirrors: i386: gnutls-1.0.20-3.2.1.i386.rpm gnutls-devel-1.0.20-3.2.1.i386.rpm src: gnutls-1.0.20-3.2.1.src.rpm

1 0

top not showing %CPU
by Warren Harris 02 Jun '05

02 Jun '05

I'm running with CentOS4 on a 2 cpu machine. I'm running a java process which creates a large number of threads as well as other native processes running under heavy load mixing 200+ audio streams. However, top shows none of these having any %CPU time. All of them read 0.0, except for top itself which occasionally shows up with 0.7, and migration/N with 0.3. All other processes read 0.0. The load average of the machine varies between 1.5 and 4.0. Any suggestions on where to look for the problem would be appreciated, Warren

3 2

amavis+nai+clamav
by Mark Quitoriano 02 Jun '05

02 Jun '05

is it possible to parse an e-mail to 2 AV? when the server recieve an e-mail with attachment it will run on both AV? in amavis' logs i can only see one AV which is nai. And i also noticed that clamd configuration in amavisd.conf is on the av_scanners_backup part.

1 0

CentOS4 installer can't find a hard drive to install.
by Takashi Nakamura 02 Jun '05

02 Jun '05

Hi, My computer is DELL DIMENSION 8400. SATA setting is below: port0 is connected to a WDC WD2500JD-75H and making RAID1 with prot2. port1 is connected to a MAXTOR 6Y120MO and set to Non-RAID. port2 is connected to a WDC WD2500JD-75H and making RAID1 with prot0. WindowsXP is installed in the RAID1 set. I want to install CentOS4 into the MAXTER's hard drive, but I can't. CentOS4 installer says "No drive was found. Do you find a driver now?" I tried all drivers that the installer showed. Each driver doesn't work. Finally the installer says "No drive to install. Check your hardware." BIOS recognizes MAXTER and diagnostic is PASS. WindowsXP finds MAXTER as a new found device. Why CentOS4 installer can't fined any hard drives? Thanks in advance, Takashi Nakamura

1 0

ntwork problem
by William Warren 02 Jun '05

02 Jun '05

I switched my file server's hard disks from a p-2 350 to a p-3 deley 1.1 ghz. I ran kudzu and it detected the new nic and unconfigured the old one. I may have messed up the static ip assignment because hte system is not able to do anything on the network. How do i check the ipaddress asignment and also ensure the proper linksys LNE-100TX driver is loaded? thanks. William -- Computer House Calls, Networks, Security, Web Design: http://www.emmanuelcomputerconsulting.com What businesses are in Brunswick, Maryland? Check Brunswick First! http://www.checkbrunswickfirst.com My "Foundation" verse: Isa 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD. -- carpe ductum -- "Grab the tape" CDTT (Certified Duct Tape Technician) Linux user #322099 Machines: 206822 256638 276825 http://counter.li.org/

2 4

advice on removing these daemons from server - rpc.statd rpc.idmapd acpid
by Robert Hanson 01 Jun '05

01 Jun '05

greetings, is there any reason i would want any of these daemons active in memory on a simple DNS server if i do not use NFS and... of course, the unit is not being used as a workstation. 1712 ? Ss 0:00 rpc.statd 1745 ? Ss 0:00 rpc.idmapd 1813 ? Ss 0:00 /usr/sbin/acpid tia - rh

5 4

Fw: [Fedora-directory-announce] Fedora Directory Server news!
by Bryan J. Smith <b.j.smith＠ieee.org> 01 Jun '05

01 Jun '05

For those of you who have been following Red Hat's purchase of Netscape Directory Server from AOL last fall (and possibly have been playing with the "technology preview release" from RHN from earlier this year), Red Hat has made good on GPL'ing it (which they were entitled to as of April 30, 2005 per their contract with AOL). To me, this is probably the most exciting announcement in the Linux world in the last 5 years. I've been deploying Netscape Directory Server since the late '90s, and have always found OpenLDAP to be lacking in comparison as a whole. "The Fedora Directory Server is a world-class Directory Server implementation. Some of the more interesting features that are included are: * 4-Way Multi-Master Replication * Scalability: thousands of operations per second, tens of thousands of concurrent users, tens of millions of entries, hundreds of gigabytes of data * SSL and SASL for secure authentication and transport * Support for most LDAPv3 features, including many common controls and extensions * Schema update over LDAP" -----Forwarded Message----- From: Bob Lord <blord(a)redhat.com> Sent: Jun 1, 2005 11:52 AM To: fedora-directory-announce(a)redhat.com Subject: [Fedora-directory-announce] Fedora Directory Server news! I'm proud to announce that the Red Hat Directory Server product, and the Fedora Directory Server open source project have launched! Here are the press releases: Red Hat Announces Directory Server http://www.redhat.com/en_us/USA/Home/Company/News%2Band%2BEvents/Red%2BHat%… Fedora Directory Server Now Available to the Open Source Community http://www.redhat.com/en_us/USA/Home/Company/News%2Band%2BEvents/Red%2BHat%… The main page for the open source project is here: http://directory.fedora.redhat.com/wiki/Main_Page From there, you'll find links to mailing lists, IRC channels, and a wealth of information about the project. We invite you to get involved! -Bob -- Bryan J. Smith mailto:b.j.smith@ieee.org -- Fedora-directory-announce mailing list Fedora-directory-announce(a)redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-announce

1 0

Attempting custom CentOS4 network install
by Ajay 01 Jun '05

01 Jun '05

Hi I am installing CentOS4 over ether network using http and kickstart. I boot from the first CentOS CD and at "boot:" prompt I input "ks=http://localserver/install/custom.cfg". Except for minor glitches like "Kernel-Development group not found" warning, the process is smooth and is almost completely automated. Now, I want to add additional RPMS to the CentOS/RPMS directory to install additional packages in the default install. In preparation, I was regenerating the hdlist using "genhdlist" even before adding the extra RPMS, just to checkout. A new hdlist and hdlist2 is sucessfully regenerated in CentOS/base dir with a small reduction in file size of hdlist, but the network install fails at the end of "Preparing RPM transaction" screen with the message "install exited abnormally" and shuts down. Am I missing something? Thanks in advance Ajay

3 2

Re: Use NTFS Partition. -- only applies to same disk ...
by Bryan J. Smith <b.j.smith＠ieee.org> 01 Jun '05

01 Jun '05

From: Mark Jarvis <mark.jarvis(a)pvmail.maricopa.edu> > HUH? FAT32 problem??? No, it's a geometry issue on legacy BIOS/DOS Disk Labels (Partition Table Format) aka "Basic Disc" in NT5+ (2000+) when both NT and Linux share the disk for booting. Microsoft never standardized how geometry should be handled after NT4.0 Service Pack 4 (SP4) other than using legacy LBA32 -- i.e., always assuming Sectors/Heads of 63/255. In NT5+, this is what it does on a "Basic Disc" which cannot store geometry information, at least through NT5.1 (XP/2003) Service Pak 1 (SP1). Unfortunately, assuming LBA32 is not compatible with Extended Int13h Disk Services. And for broken BIOSes, it can cause issues with 3rd party boot managers and disk utilities. This isn't an issue with using the Logical Disk Manager (LDM) Disk Label (Partition Table Format) aka "Dynamic Disc" because all NT5+ (2000+) instances on the system can read it's explicitly reserved areas and find out the exact geometry assumed by the first NT5+ install that created it. The Linux kernel as of early 2.4.x, thanx to work done by the NTFS-LDM project, can also read this and not have to make any assumptions on geometry (which can be an issue with 2.6 and its standard support for Extended Int13h Services -- see below). Microsoft has tried to address it with both some pre-NT5.1 Service Pack 2 (SP2) hot-fixes, some applied in SP2 and even more post-NT5.1SP2 hotfixes. Because the legacy BIOS/DOS Disk Label does not have a place where to reserve disk geometry, Microsoft choose part of Cylinder 0 where it's MBR doesn't reside. Unfortunately, many 3rd party boot managers, including GRUB, do use part of that space. I've run into this first-hand where I had no problems dual-booting on even a 800GB disk array _until_ I upgraded to NT5.1SP2 (XPSP2). After the upgrade, GRUB was broken. After re-installing GRUB, it would no longer boot XP, because GRUB overwrote the hidden geometry info in Cylinder 0 that XP needed for boot-time support. After a few more systems, I discovered that XP only wrote it if the boot volume passed the 33.8GB (32GiB) barrier -- at least on my disks that were BIOS LBA32 geometry with Sectors/Heads of 63/255. On newer disk arrays that break the 2.2TB (2TiB) barrier by supporting LBA48 / >255 heads, you _must_ basically use a LDM Disk Label. It appears Microsoft is not interested in any more "hacks" to support legacy BIOS/DOS Disk Labels -- especially given the fact that a lot of PC BIOS' out there are "broken" in their Extended Int13h Services and support for geometry beyond LBA32. In a nutshell, Microsoft doesn't trust anything from the PC BIOS, and expects to always rely on the geometry info in the LDM Disk Label for now on (and I don't blame them). Linux kernel 2.6 was written to the ATA-6/LBA48 and Extended Int13h Services specifications to overcome the LBA32/2.2TB (2TiB) limit but is breaking all sorts of things in the process. Newer user-space tools like Parted and GRUB are now getting "more intelligent" in trying to apply what geometry to "assume" based on what kernel 2.6 gives them. It's no longer safe to blindly assume Sectors/Heads of 63/255, which is how 2.4 and earlier used to deal with dual-booting. > My system has two 120GB disks I've typically found that as long as: A) I'm not dual-booting late NT5.1 hot-fixes/service packs (i.e., SP2+) B) I stay under LBA28/137GB (128GiB) I don't have the issue, even when booting NT and Linux on the same disk. > and a 160 GB disk. As long as it is not the booting disk, and being shared by both NT and Linux for booting, it shouldn't matter. > The 120s have a 1GB DOS, a 24+GB NTFS, and a 84+GB FAT32 partition. > I keep (almost) all of my data in the FAT32 partition. Are you dual-booting Linux on the _same_ disk? > The first 120 is (fairly) regularly cloned onto the second. Since I upgraded > my BIOS, I have never had any trouble accessing anything in either of the > big FAT32 partitions from either the XP installation or any one of the > various Linux installations (CentOS, WBEL, SUSE, Fedora core 3, or Yoper) > on the 160GB disk. Then you're fine. As long as NT and Linux aren't sharing the same disk for boot, you'll typically have no issues. The Linux kernel, even more so 2.6, is pretty good at trying to figure out the geometry. It's only when booting that geometry can get screwed up, because you're at the mercy of the BIOS -- or a boot-loader that attempts to overcome it's limitations. On a LDM Disk Label (Dynamic Disc), it can directly read the geometry assumed by NT. On a legacy BIOS/DOS Disk Label (Basic Disc), it will try various geometries -- from legacy LBA32 to (in 2.6) full standard Extended Int13h Services geometry support. Unfortunately, NT5.1 doesn't support the latter (although more hot-fixes are attempting to). > At various times I have installed the NTFS code in a Linux installation, > but when the NTFS crew's website says "read, but don't write" I believed > them. What I'm talking about is disk geometry issues. It doesn't matter if NTFS or FAT32 is used, you can run into it when you dual-boot on the same disc. Especially when you are dual-booting NT5.1 with late hotfixes / service packs. In fact, I highly recommend using the LDM Disk Label (Dynamic Disc) on any NT5+ accessed disk to avoid geometry issues between NT5+ itself. Otherwise, I've seen people dual-booting 2000 and XP and seen the Disk Label (Partition Table) get trashed. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss