- Discuss - lists.centos.org

Re: [CentOS] Re: opensource backup software suggestions please -- VTL option ...
by Bryan J. Smith <b.j.smith＠ieee.org> 03 Jun '05

03 Jun '05

From: Ugo Bellavance <ugob(a)camo-route.com> > I'm using Thunderbird with nntp access on gmane and it works perfectly, > maybe you should try this out Brian. I use Evolution at home and it has no issues tracking Message Id. > I used to break threads with my other e-mail clients. Unfortunately, I have to use a web-based client at work. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: opensource backup software suggestions please -- VTL option ...
by Bryan J. Smith <b.j.smith＠ieee.org> 03 Jun '05

03 Jun '05

From: Jim Bartus <jbartus(a)advance.net> > Bryan, > Something about your replies causes them to always be new threads rather > than inline with the rest of the conversation. > Is this just me (thunderbird 1.0.2 on FC3) or does everyone get this? I don't think my webmail reader is honoring the Message ID in the header. And I know my Treo doesn't. I'm working on switching to a new webmail interface. I hate it because I have to manually bottom-post. Unfortunately, GMail doesn't honor Message ID well either, so it's no better. I might switch to Yahoo. -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 2

Topics in the CentOS-Announce list
by Johnny Hughes 03 Jun '05

03 Jun '05

I have been working with Joe Pruett (thanks Joe), to get the Topics feature for the mail list working. I think we now have the topics working fairly well. So if you only care about CentOS-3 i386 announcements (for example), you can pick that specific topic. There is also an option to pick the topics you care about, and all items that do not match any topics. (So that if we make an announcement that is not tied to one of those categories, you can get it too). If you are subscribed to the announce list and want to pick specific topics, go to: http://lists.centos.org/mailman/options/centos-announce Login with your e-mail address and password and choose the topics you want to receive. -- Johnny Hughes <http://www.HughesJR.com/>

1 0

Re: Vote For CentOS :) -- standing on the shoulders of each other
by Bryan J. Smith <b.j.smith＠ieee.org> 03 Jun '05

03 Jun '05

On Fri, 2005-06-03 at 09:36, Simon Perreault wrote: > i'm not sure you've considered your position thoroughly. > I am, and I will say it again just for the shock value: > Red Hat is the main developer of CentOS. On Fri, 3 Jun 2005, Les Mikesell wrote: > I'd put it this way instead: Red Hat is responsible for any > difficulty in creating the CentOS distribution, while sharing > the same upstream developers as all other Linux distributions. From: Maciej ?enczykowski <maze(a)cela.pl> > BULLSHIT And so it begins. I think we've all had our say at this point. I can understand (although not agree) with Les' viewpoint. And I'm sure Simon feels like I do, Red Hat doesn't get due credit. But this is why I dislike these "distro contests" in the first place. The are entirely subjective and full of "absolutes" and "versus." Reality is that there is much so much overlap. *** Because we all stand on the shoulders of each other! *** Vote CentOS if you like it best. Vote RHEL if you like it best. Do it on your own opinion for your own reasons. I laid out what I thought mine were before. At least one person liked it. I try not to talk in "absolutes." And try to understand why RHEL and CentOS exists, let alone the Fedora Core and Red Hat Linux lineages. Apparently people want to debate this from a marketing/branding, and that's _always_ going to be "subjective." There are those of us who aren't upset with Red Hat, and deploy _both_ RHEL and CentOS for various reasons. And there are those others of us who are upset with Red Hat, and believe CentOS should not have to exist, that Red Hat should be providing it. And I'm sure there are others who wonder why people don't just run Fedora Core, or another distro for that matter. And yet other viewpoints different from those. It's all GPL, so lets just appreciate each other. This is what I meant by people focusing more on ripping companies that produce GPL incompatible software, like IBM, Sun (sans OpenOffice.org) etc... <Flammatory=on> Red Hat v. CentOS, etc... -- it's like being a Christian watching Cathlotics and Protestants argue their religious viewpoints in Northern Ireland. Because in the end, it's really about focusing on differences than similarities -- and it doesn't matter how close those similarities are, people can find differences if they want. Sorry for this political analogy, but it pretty much fits well. At least from my ignorant American viewpoint. </Flammatory> -- 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> > It does not give added value over RHEL in the distro itself. Be careful with that statement. ;-> Also remember that CentOS is more than just the RHEL distro. -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

Triple /proc/net/stat/ip_conntrack files
by Maciej Żenczykowski 03 Jun '05

03 Jun '05

[root@tcs stat]# uname -a Linux tcs 2.6.9-5.0.5.ELsmp #1 SMP Wed Apr 20 00:16:40 BST 2005 i686 i686 i386 GNU/Linux [root@tcs stat]# pwd /proc/net/stat [root@tcs stat]# ls -al total 0 dr-xr-xr-x 2 root root 0 Jun 3 18:51 . dr-xr-xr-x 5 root root 0 May 31 23:12 .. -r--r--r-- 1 root root 0 Jun 3 18:51 arp_cache -r--r--r-- 1 root root 0 Jun 3 18:51 ip_conntrack -r--r--r-- 1 root root 0 Jun 3 18:51 ip_conntrack -r--r--r-- 1 root root 0 Jun 3 18:51 ip_conntrack -r--r--r-- 1 root root 0 Jun 3 18:51 ndisc_cache -r--r--r-- 1 root root 0 Jun 3 18:51 rt_cache Anyone getting the above triplication? Cheers, MaZe

1 0

Re: [CentOS] Re: opensource backup software suggestions please -- VTL option ...
by Bryan J. Smith <b.j.smith＠ieee.org> 03 Jun '05

03 Jun '05

From: Karanbir Singh <Mail-Lists(a)karan.org> > Which is a good thing really, since you can snip off the irrelevant bits > on your way down. Yes, I do it. But in my case, I've got to manually cut'n paste and add the greater-than signs. It gets tedious (especially on my Treo). But I do it because I believe in bottom-posting. > Gmail works fine. It sets the In-Reply-To: header. I am sure your move > to a more not-as-much-brain-dead client would be appreciated. Yeah, at least GMail would be better than this account. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: opensource backup software suggestions please -- VTL option ...
by Bryan J. Smith <b.j.smith＠ieee.org> 03 Jun '05

03 Jun '05

From: Chris Mauritz <chrism(a)imntv.com> > I've found that backing up to another disk to be both faster and more > practical. We've got a number of multi-terabyte RAID arrays to store > uncompressed video. Backing all that data up to tape just isn't a > tenable solution. So we've bitten the bullet and built an extra larger > multi-terabyte array to do online backups. Periodically we do snapshots > of the data on that backup array (like you do on a netapp filer). That > system works well for us. It wouldn't cover us if the building burned > down so the next step is an offsite mirrored array. If you have the dough, Virtual Tape Libraries (VTLs) are the ultimate in flexiblity. Although there are many solutions, nearly all of them are the Red Hat Linux 7.3 + FalconStor Software combination. Although EMC, IBM and others have traditionally use standard disk arrays as they use for other solutions (with the software slapped on), Copan Systems' hardware solution is designed specifically for VTL and VTL-only. The density, power/thermal, cost and other considerations are rather interesting. -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 2

Re: [CentOS] Separate list for political/philosophical discussion
by Bryan J. Smith <b.j.smith＠ieee.org> 03 Jun '05

03 Jun '05

From: Ugo Bellavance <ugob(a)camo-route.com> > 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. That's how most projects handle it. Because invariably, people will start breaking things down into marketing, legal and other meta-discussions. And I'm just the type of person that deals with them on a daily basis, so I have my viewpoints. Rule of thumb on what is on-topic for that last should default to the project maintainers, and we should respect their viewpoints. -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

Re: CentOS/RHEL versioning scheme? -- adversely affecting dist-tag
by Bryan J. Smith <b.j.smith＠ieee.org> 03 Jun '05

03 Jun '05

From: Morten Kjeldgaard <mok(a)bioxray.dk> > I am a bit puzzled at the versioning scheme of the RedHat clone family. > RedHat seems to use integer 4, Tao and Centos does the same. If you do > rpm -q --qf '%{version}\n' -f /etc/redhat-release > you get '4'. > However, Scientific Linux uses 4.0, and that seems to me to be a more > logical choise, since presumable there are going to be versions 4.1, > 4.2, etc. Unfortunately, the "release" file impacts build environments. E.g., dist-tag. So it shouldn't be done on a dime. Even Red Hat has really pulled some doozers -- like getting rid of revisions, restarting the numbering on Fedora Core to 1 which threw a wrench into the dist-tag through Red Hat Linux 9, etc... [ I can only assume there was a more important, legal reason, like not showing product lineage to protect Red Hat(R)? ] -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

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

Centos4 SMP Kernel OOM
by Maciej Żenczykowski 01 Jun '05

01 Jun '05

Hello, I've just run out of memory on a dual xeon with 5GB ram, considering there should have been around 4GB free (not counting buffers and cache)... this is unusual. Now after it OOM'ed I tried running top and memory usage was fine (around 1GB of 5, no swap usage of 12GB). So I thought it was a temporary thing, but processes kept on OOM'ing for no understandable reason... while swap was empty and memory continued to show 3GB free (and look at the weird log messages...) A reboot helped though, but still... :) [this is the normal CentOS4 i686 SMP kernel 2.6.9-5.0.5.ELsmp] May 31 22:31:25 tcs kernel: oom-killer: gfp_mask=0xd0 May 31 22:31:25 tcs kernel: DMA per-cpu: May 31 22:31:25 tcs kernel: cpu 0 hot: low 2, high 6, batch 1 May 31 22:31:25 tcs kernel: cpu 0 cold: low 0, high 2, batch 1 May 31 22:31:25 tcs kernel: cpu 1 hot: low 2, high 6, batch 1 May 31 22:31:25 tcs kernel: cpu 1 cold: low 0, high 2, batch 1 May 31 22:31:25 tcs kernel: cpu 2 hot: low 2, high 6, batch 1 May 31 22:31:25 tcs kernel: cpu 2 cold: low 0, high 2, batch 1 May 31 22:31:25 tcs kernel: cpu 3 hot: low 2, high 6, batch 1 May 31 22:31:25 tcs kernel: cpu 3 cold: low 0, high 2, batch 1 May 31 22:31:25 tcs kernel: Normal per-cpu: May 31 22:31:25 tcs kernel: cpu 0 hot: low 32, high 96, batch 16 May 31 22:31:25 tcs kernel: cpu 0 cold: low 0, high 32, batch 16 May 31 22:31:26 tcs postfix: Process did not exit cleanly, returned 0 with signal 9 May 31 22:31:26 tcs kernel: cpu 1 hot: low 32, high 96, batch 16 May 31 22:31:26 tcs kernel: cpu 1 cold: low 0, high 32, batch 16 May 31 22:31:26 tcs kernel: cpu 2 hot: low 32, high 96, batch 16 May 31 22:31:26 tcs kernel: cpu 2 cold: low 0, high 32, batch 16 May 31 22:31:26 tcs kernel: cpu 3 hot: low 32, high 96, batch 16 May 31 22:31:26 tcs kernel: cpu 3 cold: low 0, high 32, batch 16 May 31 22:31:26 tcs kernel: HighMem per-cpu: May 31 22:31:26 tcs kernel: cpu 0 hot: low 32, high 96, batch 16 May 31 22:31:26 tcs kernel: cpu 0 cold: low 0, high 32, batch 16 May 31 22:31:26 tcs kernel: cpu 1 hot: low 32, high 96, batch 16 May 31 22:31:26 tcs kernel: cpu 1 cold: low 0, high 32, batch 16 May 31 22:31:26 tcs kernel: cpu 2 hot: low 32, high 96, batch 16 May 31 22:31:26 tcs kernel: cpu 2 cold: low 0, high 32, batch 16 May 31 22:31:26 tcs kernel: cpu 3 hot: low 32, high 96, batch 16 May 31 22:31:26 tcs kernel: cpu 3 cold: low 0, high 32, batch 16 May 31 22:31:26 tcs kernel: May 31 22:31:26 tcs kernel: Free pages: 3579344kB (3578432kB HighMem) May 31 22:31:26 tcs kernel: Active:96900 inactive:20481 dirty:0 writeback:0 unstable:0 free:894836 slab:212200 mapped:86012 pagetabl es:1438 May 31 22:31:26 tcs kernel: DMA free:16kB min:16kB low:32kB high:48kB active:16kB inactive:0kB present:16384kB May 31 22:31:26 tcs kernel: protections[]: 0 0 0 May 31 22:31:26 tcs kernel: Normal free:896kB min:936kB low:1872kB high:2808kB active:240kB inactive:416kB present:901120kB May 31 22:31:26 tcs kernel: protections[]: 0 0 0 May 31 22:31:26 tcs kernel: HighMem free:3578432kB min:512kB low:1024kB high:1536kB active:387344kB inactive:81508kB present:4325372 kB May 31 22:31:26 tcs kernel: protections[]: 0 0 0 May 31 22:31:26 tcs kernel: DMA: 0*4kB 0*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 16kB May 31 22:31:26 tcs kernel: Normal: 0*4kB 0*8kB 2*16kB 1*32kB 1*64kB 0*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 896kB May 31 22:31:26 tcs kernel: HighMem: 1560*4kB 5190*8kB 4683*16kB 1632*32kB 2304*64kB 1512*128kB 781*256kB 349*512kB 157*1024kB 66*20 48kB 583*4096kB = 3578432kB May 31 22:31:26 tcs kernel: Swap cache: add 0, delete 0, find 0/0, race 0+0 May 31 22:31:26 tcs kernel: Out of Memory: Killed process 11250 (MailScanner). and again moments later... May 31 22:31:30 tcs kernel: oom-killer: gfp_mask=0xd0 ... and repeat two dozen or more times for different processes. Cheers, MaZe.

3 2

Use NTFS Partition.
by David González Romero 01 Jun '05

01 Jun '05

Hi!! I have a CentOS 4.o install on some machine in my job. I need setting the system for read/write partition NTFS. I know the kernel-2.6.x this support is part of the kernel, but in CentOS this support is unaviable. How can aviable this support whit out recompiler kernel?? Some rpm packege for do that?? Regards, David _________________________________________ Tec. David Gonzalez Romero Network/System Administrator CNAP- Centro Nacional Áreas Protegidas Linux counter: 242534 _________________________________________

7 8

On SSH
by Maciej Żenczykowski 01 Jun '05

01 Jun '05

Hello, does anybody know how to achieve the following with SSH... a) accept RSA authentication for all but root from any IP b) accept RSA authentication for root from a couple IPs/Netmasks c) accept password authentication for all but root from a dozen Netmasks d) accept password authentication for root from 3 local netmasks only ie. make authentication depend on the USER,METHOD,CLIENT-IP triplet... Cheers, MaZe.

6 5

Re: [CentOS] Re: Demonizing generic Linux issues as Fedora Core-only issues -- WAS: Hi, Bryan
by Bryan J. Smith <b.j.smith＠ieee.org> 31 May '05

31 May '05

From: Les Mikesell <lesmikesell(a)gmail.com> > Agreed. But note that the standards are set long before that... ??? By "standard" what do you mean. ??? Linux's history has been notorious for variance from ANSI, NIST, POSIX and GNU standards. Yes, far less than Microsoft and even some UNIX vendors, but there are still major issues today with this. When developers try to change things for standards compliance, they get reamed by all the people who want backward compatibility instead. That's why companies like Red Hat and SuSE try to not do it for several versions until it comes to a head (typically future adoption required). > If you are doing anything complicated, I'm not sure you have any > other choice. But then you run into ugliness where you want to > run perl programs that need perl=>5.8.3 to get character set handling > right, and you can't, or you have to do a local install trying not > to break the system version. Internationalization is a reality and we English speaking Americans, as well as Westerners in general, can't go around complaining when a program really _does_ need to get off its American/Western-only duff. That means getting away from ASCII as well as ISO8859. In reality, there is a massive set of issues in the UNIX space where there are no less than 15 common different interpretations of byte order, endianess and organization just for 4-byte ISO character sets. Pretty much all standards-based platforms are moving to UTF-8 because it solves the multi-byte organizational issues. ASCII is still 7-bit (1 byte), while any 4-byte ISO character set can be accomodated in 2-6 bytes total. And as 1-6 streamed bytes, the common endianness is network order (big endian), no multi-byte endianness/order issues. Ironically, being an American company, this is where Red Hat has done a phenominal job of any "western" distro company, IMHO, of pushing _hard_ for UTF-8. Red Hat made this major shift with CL3.0 (Red Hat Linux 8.0), which then went into EL3, which was based on CL3.1 (Red Hat Linux 9). Typical bitching and moaning was present, condemnations of both Perl maintainers of 5.8 and Red Hat Linux 8.0, etc... More on the GUI front, I think Java and .NET/Mono have the right idea, ISO10464 Unicode everything. > Or you need mysql 4.x for transactions. Again, there is a licensing issue with MySQL 4 that MySQL AB introduced that most people, short of Red Hat, are ignoring. MySQL AB is GPL, _not_ LGPL or BSD, so you have to be very careful what you link to it. I see that Fedora Core 4 Test does adopt MySQL 4 though. I need to read up on what Red Hat did, or is possibly excluding to make MySQL AB happy (unless they changed their stance on some static linking) to find out more. > I guess my real complaint is that the bugfixes and improvements to > the old releases that you are forced by the situation to run are > minimal as soon as it becomes obvious that the future belongs to > a different version - that may be a long time in stabilizing to > a usable point. So what's your solution? I'm still waiting for someone to show me one better than the: 2-2-2 -> 6-6-6 model In fact, the full model is really: 2-2-2 -> 6-6-6 -> 18-18-18 model Whereby Red Hat and SuSE maintain up to 3 simultaneous versions of their 18 month distros. [ Actually, SuSE is dropping the first "enterprise" release, SLES 7 just shy of 5 years. ] So if you are talking about stability/maturity, then run RHEL2.1 or now. Heck, Fedora Legacy is _still_ supporting CL2.3 (RHL7.3) too! ;-> > It will be interesting to see how this works out for Ubuntu. I think it > would be possible to be more aggressive with the application versions > but hold back more than RH on the kernel changes. And that's the real question. What is the "best balance"? > Of course they'll have it easy for the first few since they don't have to > be backwards compatible to a huge installed base. Exactomundo! ;-> In reality, Red Hat has probably the longest "backward compatible" run of any vendor. Why? Because they adopt things early -- like GLibC 2, GCC 3, NPTL, etc... Heck, pretty much everything released for CL/EL2 (GLibC 2.2, GCC 2.96/3.0 -- RHL7.x/RHEL2.1) still runs on my latest Fedora Core 4 Test systems. > How was the CIPE author supposed to know that what would be > released as FC2 would have a changed kernel interface? My God, I actually can't believe you could even make such a statement. At this point, it's _futile_ to even really debate you anymore, you keep talking from a total standing of "assumption" and "unfamilarity." Something a maintainer of a package would not be, unless he honestly didn't care. Fedora Core 2 (2004May) was released 6 months _after_ Linux 2.6 (2003Dec). Fedora Core 1 -- fka Red Hat Linux 10 -- had just been released (2003Nov) before kernel 2.6. Within 2 months, Rawhide/Development had Fedora Core 2's intended kernel -- 2.6. There was absolutely _no_question_ what it was going to be. I know, I was checking out the packages on Fedora Development -- saw 2.6.1/2.6.2. I believe 2.6.3 was the first one used in Fedora Core 2 Test 1 in 2004Mar. Red Hat's Rawhide, now Fedora Development (although many Red Hat employees still call it "Rawhide" ;-), has been around since the Red Hat Linux 5.x timeframe. It's the packages that are being built for the next revision -- be it same version or a major version change. Rawhide/Dev is the "package testing," so you can see what packages they are looking at. Beta/Test is the "regression testing" of the entire release as a whole (packages against packages testing in all). Again, the 2-2-2 model. There is at least 4 months before release when you can find out pretty much _anything_ that's going to be in the distro for a good certainty. Pretty much every major distro -- Red Hat, SuSE, etc... adopted Linux 2.6 within 6 months. SuSE even released SuSE Linux 9.0 before 2.6 was released, but with a lot of the backports (like Red Hat) in prepartion for 2.6 in SL9.1. > He did respond with 1.6 as quickly as could be expected after a released > distribution didn't work with it and a user reported problems on the mailing > list. How can you blame this on distributions? Honestly, I don't see it at all! There were months and months of pre-release 2.6 releases in 2003. I saw the comments that many things weren't working (including CIPE). There were 6 months between Linux 2.6's release and FC2. Heck, I believe SL9.1 came out with it before that. > About the kernel, or all of the drivers' authors that assumed that > kernel interfaces shouldn't change? Many drivers were actually _deprecated_ in kernel 2.6, and not built by default because people didn't come forward and take ownership. I know, the lack of the "advansys.c" SCSI driver got me good. ;-> But who did I blame? Myself for not volunteering! At some point, when there's lack of interest, it typically means there are not enough people interested to hold up everything. > And if you want the things that work to not change??? Then you do _not_ adopt the latest distro that just came out -- especially not an "early adopter" release. It was well known that Fedora Core 2 was changing a lot of things, just like SuSE Linux 9.0/9.1. [ SIDE NOTE: Again, I have stated that I am _disappointed_ that Red Hat does not use revisioning to designation something like Fedora Core 2 as a ".0" revision. But it was well known it was going to be kernel 2.6 4 months before its release. ] > Where do you find the real info? It takes me 5 minutes to figure out what Red Hat's up to. Red Hat is pretty explicit on what their plans are, and the packages are out there for all to see during Development, even _before_ the Test hits (Development is about 4 months before release). Heck, when their Test 1 hits (a good 2+ months before release), they go over _all_ the major changes in the "Release Notes." SuSE and even Mandrake are similar too. > Specific example: I'm trying to make a software RAID1 partition with > one internal IDE and a matching external drive in a firewire case work. > FC1 worked flawlessly once the raid was established but would not > autodetect the drive, either when hotplugged or at bootup. Everything > later that I've tried is worse. Some get the autodetect right on a > hotplug but crash after some amount of runtime. > Is any distro likely to autodetect at bootup in time to cleanly connect > the RAID and then keep working? When you disconnect a drive from the RAID array, there is no way for the software to assume whether or not the drive is any good anymore when it reconnects unless you _manually_ tell it (or configure it to always assume it is good). This is not a Red Hat issue either. And LVM2 is still going through some maturity with RAID-1 and snapshots. > Maybe it matters that the filesystem is reiserfs - I see some bug > reports about that, but rarely have problems when the internal IDE > is running as a broken mirror. Filesystem shouldn't matter, it's a Disk Label (aka Partition Table) consideration. > Like letting it be a surprise to the CIPE author that it didn't work > at release time. I don't remember seeing a hint about this on the > CIPE mail list when someone must have known well ahead that it was > coming. More assumptions. CIPE has been breaking in 2.6 since the very early 2.5.2+ developments. I'm sure the author was waiting until late in 2.5 (say near 2.5.70+) as it came closer to 2.6. I saw reports on all sorts of network code breakage the second it hit in 2003Dec -- 6 months before. In looking through Fedora Development, I note lots of references to all sorts of issues with the 2.6-test releases as of summer of 2004 (over 9 months before FC2 release, months before kernel 2.6's official release). There were efforts to get cipe to work -- both in FC2 and then in Fedora Extras for FC2, but they were eventually dropped because of lack of interested by the CIPE developers themselveas in getting "up-to-speed" on 2.5/2.6. The first hints of recommendations to go IPSec instead were that fall. By March of 2004, I see the last comments to not even bother with CIPE for Fedora Core 2 (as well as SuSE Linux 9.1) were made from several. > Buggy. I don't mean RH bugs, I mean bugs from the upstream packages > that got their first huge real world exposure because RH bundled them > on a CD that you could drop into just about any PC and have a working > system. I mean things like the bind, sendmail, and ssh versions that > went out with RH 4.0 and were installed on more machines than ever > before - all with remote exploits that weren't known yet. Yes, Linux is not free from vunerabilities. This is not new. Either you pay for a subscription (and optional SLA) to an "enterprise" distro that maintains 5+ years of support, or you rely on community projects (like Fedora Legacy) that attempt to do the same. Fedora Legacy is still supporting CL2.3 (Red Hat Linux 7.3), even though they dropped CL3.0 (Red Hat Linux 8.0) a long time ago because CL3.1/3.2 (Red Hat Linux 9 / Fedora Core 1) exist. > The real world is a complicated place. If you want to substitute > a different program for an old but non-standard one you need to > make sure it handles all the same things. But what if those either conflict with standards or are broken? > Until just recently, star didn't even come close to getting incrementals > right and still. unlike gnutar, requires the runs to be on filesystem > boundaries for incrementals to work. And, it probably doesn't handle > the options that amanda needs. Theory, meet practice. You assume "GNU Tar" is the "standard." ;-> It's not, never has been, and is years late to the POSIX-2001/SUSv3 party. As far as not crossing filesystem boundaries, that is easily accomodated. > By 'first', I meant before RH 4.x, which in my opinion really drove > the popularity of Linux simply because it had a decent installer > that came up working on most hardware at the time. Freebsd was > around at the time but in a form that was much more difficult > for a new user to get working. > That depends on when you started. Before SP6, NT was also unreliable. Hell of a lot better than "Chicago," but yes, I agree. > Remember that in the timeframe of RH4, you could kill an NT box > by sending it an oversized ping packet - and have a fair chance of > corrupting the filesystem beyond repair from the ungraceful shutdown. Oh, you could hang Linux in various ways too, just not as many. > It wasn't so much the cloning as it was setting the IP address > with their GUI tool (and I did that because when I just made > the change to the /etc/sysconfig/network-scripts/ifcfg-xxx file > the way that worked in earlier RH versions it sometimes mysteriously > didn't work). Then I shipped the disks in their hot-swap carriers to > the remote sites to be installed. Again, I will repeat that "configuration management" is part of avoiding "professional negligence." You should have tested those carriers before shipping them out by putting them in another box. > That procedure can't be uncommon. No, it's not uncommon, I didn't say that. I'm just saying that vendors can't test for a lot of different issues. Don't get me started on the design of NTFS and the Registry SAM-SID issues. The current "hack" is to either put everything in a domain, or use Dynamic Discs to store stuff outside of a NTFS filesystem because you can _never_ safely access a NTFS filesystem _except_ for the NT installation that created it (not even with another install of the same NT version). > And the same thing would happen if you swapped a NIC card - > hmmm, I wonder about PCMCIA cards now. Yes, maybe that has something to do with it, eh? ;-> For example, maybe when you want to switch between an unclassified and classified network, you use a different card (and hard drive), which will connect to a different subnet. ;-> I'm sure some changes have been for "Common Criteria" compliance. I've seen similiar on SuSE as well. They might have been made mid-update. > I'm not sure exactly when it happened because it was an update that > did not include a new kernel so the machines weren't rebooted > immediately. I think the ones where I noticed it first were somewhere > in the Centos 3.4 range with some subsequent updates (maybe a month > or so ago). I'll check it out then. > I think this was just an update without a version number change. As it > turned out, I saw the screen of one that was rebooted at a nearby site > and knew more or less what happened but before I got around to fixing > them all a machine crashed at a distant site and I had to talk someone > who didn't know vi through finding the file and removing the hardware > address entry. No offense, but when I ship out components to remote sites, I do my due dilligence and test for every condition I can think of. But maybe I'm anal because I ship things out to places like White Sands, Edwards, etc... and techs can't be expected debugging such concepts, so I always test with at least a partially replicated environment (which would be at least 1 change of physical system ;-). > If I hadn't already known about it by then or if a lot of the remote > servers had been rebooted and came up with no network > access it might have ruined my whole day. I think you're assigning blame in the wrong direction. You might think that's rude and arrogant, but in reality, if you keep blaming vendors for those type of mistakes, you're going to have a lot more of them coming your way until you change that attitude. No offense. ;-> -- Bryan J. Smith mailto:b.j.smith@ieee.org

8 21

Can't unmount floppy
by Robert Moskowitz 31 May '05

31 May '05

Using the Disk Management GUI. I mounted the floppy copied a file to it by dragging from one Nautilus window to another Then I tried to unmount the floppy and got an error that the device (/media/floppy) was busy. This is not the first time this has happened to me. And it does not happen all the time. In fact, yesterday I did the exact same steps with no problem.

3 7

Having problems with SSL and Apache on CentOS
by Edward Croft 31 May '05

31 May '05

I had a RH7.3 box that provided some web services, but the hard drive recently started to throw errors. So I got another drive and built a new system using CentOS4. Unfortunately, there is no one to one as far as Apache since COS4 uses Apache 2 and there is a dramatic difference in the way the config files are done. I have managed to get it to recognize the directory on my other drive after finding the selinux commands to allow that directory to be used. I can get to the startup page if I go through port 80. I also have it redirecting to our main webserver and that works. However, if I try to go to secure http, I get an error stating that some data may have been sent but it does not present the certificate to be accepted. Because this is an internet exposed box, I prefer to leave selinux intact. Am I missing something? apachectl configtest, says all is OK. Apache starts. I just can't connect to the server. Any help would be appreciated. Thanks. Ed. -- If the sane say the insane are insane, What if the sane are insane? Would that make the insane sane? Explains a lot in Washington! --E. Croft

3 3

bash 3.0 freeze
by jose luis faria 31 May '05

31 May '05

Hello centos users, I download the bash 3.0 and compile it in CentOS 4.0 with or withiut all patchs. But when I execute the comand ls -l it freezes. Any idea? -- :) cumprimentos -------------------------- José Luís Faria

5 7

Re: [CentOS] Re: CentOS and SL, together? -- attributing statements to me (that I didn't make)
by Bryan J. Smith 31 May '05

31 May '05

From: Dag Wieers > Bryan, stop generalising and dramatising. What dramatising? At some point, several people decide that anything they dislike was said by me. Several other people said far more negative comments about CIPE than myself. Those comments have now been attributed to me. I purposely avoided making it about whether or not CIPE should or shouldn't not be included, just why it wasn't based on what I found. I recognize 99% of the people on this list didn't do that. > It's not you against the world. Who said it wasn't. But I regularly find that some people, even if only 1%, don't care about solving problems. They want to complain, so I start trying to explain why. Eventually these people don't stop, and others join my position. And that's when these few people start taking anything said they disagreed with and attribute it to me. There's plenty to dislike about me than to make up stuff. ;-> > Much of the commotion is related to the manner you > communicate and interprete what people say, But it doesn't excuse them for taking what _others_ said, even if it was defending my position, and saying I did. So as I said, that's what I hate about these lists and such meta-discussions. It totally results in making myself a focal point for things I didn't even say. > regardless of some good points you make. > Your above statement is a perfect example of that. Agreed. Sorry, it's just something I despise, because I have had some illegal things attributed to me on other lists by some, select people. > BTW I'm not saying this to attack you, but to help you. Why would I consider this an attack? Despite what you might think, I don't think the list is against me. I just know that all it takes is 1% of a list to start attributing all sorts of things to me. > I tried being diplomatic in private and in public, but it did not help much. I appreciate your continued professionalism. In fact, I let this thread go for several hours, letting others respond. Unfortunately, what those other said from a familiar position has now been attributed to me. Sorry I got upset about it, but I'm still hearing about things I never said or did on other lists. So I didn't want it to stand here.

5 4

Newbie Query about Centos: where it is going...
by Sanjay Arora 30 May '05

30 May '05

Hi all Just joined this list. Am presently a whitebox 4 & FC 3 user. Have some questions about this distro...hope someone...maybe the list-owner or the power centers in this list will deign to reply ;-) - Site seems to say...Basic Centos will remain same as RHEL...is that absolute code/binary /naming & path compatibility? Is this for ever. ConfirmedDDD? - Somewhere else it says addons will be there....again sure that these will be seperate in extras but will keep the RHEL conventions? ConfirmedDDD? - Now about creating a local repository...I create a local repository of all software I use and other computers installed in our company can use. At this time we are charged by the MB, so can't be public. So what repository do I rsync with? East US woulb be best for me...but I don't think I should hog on layer 1 repositories...so please do guide.

7 10

Multiple sound cards
by Jeffrey B. Layton 30 May '05

30 May '05

Afternoon, I recently upgraded a machine to CentOS 4.0 and it has two sound cards: built-in VIA, Cmedia PCI card. The OS recognizes both and I can use the tool, system-config-soundcard to test them. However, I can't seem to get any sound out of the VIA card, but the Cmedia plays the test sound just fine. The problem is that I can't get any sound apps to use the Cmedia card, particularly xmms. Any hints or helpful comments? TIA! Jeff

3 3

Package dependancy
by Kyle Gordon 30 May '05

30 May '05

Hey folks, I'm running CentOS4 (excellent work btw :-) here, and have apt installed and configured to pull from http://apt.sw.be/redhat/el4/en/i386/ It's all working swimmingly, other than when I try to install nagios-plugins, whereupon it bails out looking for perl(Net::SNMP) Am I missing a repository here, or has something gone amiss with dependancies? Regards Kyle

3 4

real used RAM!
by israel.garcia＠cimex.com.cu 30 May '05

30 May '05

List, I've installed my CentOS Server running progress 9.1D database system, with only 15 users working every day, this server has 2GB RAM, so, my question is: Why the 2GB of RAM is always used? Even with only one user connected... How can I messuare the real RAM MEM used by my system split in proccess? Is there another tools which I use to compare the results from top. Or vmstat? Regards, Israel

5 4

PostgreSQL/SELinux Error - relation "pg_catalog.pg_user" does not exist
by Matt Arnilo S. Baluyos (Mailing Lists) 30 May '05

30 May '05

hello everyone, i'm trying to run a postgresql service on my newly-installed centos4 box. i have been able to recreate my users, set up the permissions, and restore the database dump. also, i can already log-in to my databases. there is, however, one annoying problem. whenever i type \du (or \d or \l) on the psql prompt, i get the following error: ERROR: relation "pg_catalog.pg_user" does not exist after some googling, i'm beginning to suspect that this is a SELinux issue. i then try to disable SELinux on the postgresql daemon by doing: # setsebool postgresql_disable_trans true that does not work unfortunately as i'm still stuck with the same error. while i can definitely just disable SELinux on this box, i would want a more elegant solution that solves this annoying problem. can anyone help me on this? thanks in advance! matt -- Stand before it and there is no beginning. Follow it and there is no end. Stay with the ancient Tao, Move with the present.

12 27

VPN
by Simone 30 May '05

30 May '05

Hi list, I am trying to create a VPN between two different locations. On the first location we have a cisco pix 525 Natting the internal 192.168.100.x network, while on the second location we have a Centos3 box Natting via iptables the internal 192.168.10.x netowrk. My goal is to connect this 2 over the internet via IPsec. I created the IPsec Net2Net via the network configuration graphic tool, and I configured the cisco following the howto http://www.johnleach.co.uk/documents/freeswan-pix/freeswan-pix.html . From my understanding, I should have an ipsec0 network device showing up, so that I could route all traffic from 192.168.10.x directed to 192.168.100.x through it. The thing is that when I try to ifup ipsec0 I get the following errors: modprobe: modprobe: Can't locate module ripemd160 modprobe: modprobe: Can't locate module cast128 modprobe: modprobe: Can't locate module lzs modprobe: modprobe: Can't locate module lzjh So, after googling and reading a lot with no success, I would like to ask for advice on this, and successfull story :). I really need to have this VPN running, and I am not tied to this one solution only, linux-to-linux VPN, openVPN or anything else you could suggest would be great. Thanks in advice Simone

4 6

Re: [CentOS] Re: CentOS and SL, together? -- attributing statements to me (that I didn't make)
by Bryan J. Smith 30 May '05

30 May '05

There's nothing like asking someone to "give it a rest" while taking the opportunity to make fun of them. Lucky for you (and the list), I can laugh at myself, because I can seem comical at times. But in all seriousness, just remeber to hold us all to the same standard. And we are all responsible for what we say and how we say it, and I'll never claim to be better than the worst of the list. If anything, I'm the one who draws them out from time to time, because I'm the one who occassionally gets sick of the rheotic so I'll challenge them. And an annoying thread results, as I'm sure many found it to be. Otherwise, your statements are noted to be a fairly accurate portral of myself. And I'm sure my over-use of underline emphasis won't be the only thing that offends many sometime in a future thread as well. ;-> -----Original Message----- From: Chris Mauritz Date: 05-5-29 23:23 To: CentOS mailing list Subj: Re: [CentOS] Re: CentOS and SL, together? -- attributing statements to me (that I didn't make) Bryan J. Smith wrote: >From: Dag Wieers > > >>Bryan, stop generalising and dramatising. >> >> > >What dramatising? At some point, several people decide that anything they dislike was said by me. >Several other people said far more negative comments about CIPE than myself > > How about just giving it a rest? Your comments are often abrasive. Fortunately, there is also some good information sprinkled in there for people who can overlook the attitiude (or challenged social skills). Finding some happy medium where you express your opinion without insulting the people you're trying to "help" would be a good thing. You do get bonus points for the profuse usage of underlining in your posts though.... Can't we all just get along???? _______________________________________________ CentOS mailing list CentOS(a)centos.org http://lists.centos.org/mailman/listinfo/centos

1 0

OSCAR for Centos vote
by Morten Kjeldgaard 30 May '05

30 May '05

Those of you who would like to see Centos on the supported-list for the clustering software OSCAR, head over to http://oscar.openclustergroup.org/register and cast your vote! Cheers, Morten -- Morten Kjeldgaard, Asc. professor, Ph.D. Department of Molecular Biology, Aarhus University Gustav Wieds Vej 10 C, DK-8000 Aarhus C, Denmark Lab +45 89425026 * Mobile +45 51860147 * Fax +45 86123178 Home +45 86188180 * ICQ 27224900 * http://www.bioxray.dk/~mok

4 4

Re: CentOS and SL, together? -- the _real_ history of Red Hat Linux support
by Bryan J. Smith <b.j.smith＠ieee.org> 30 May '05

30 May '05

From: Les Mikesell <lesmikesell(a)gmail.com> > Here's a classic example: somewhere in the updates of RH 7.2, > the apache DSO module for mod_perl was finally compiled with > the correct options and became usable as shipped so people > running web sites with it no longer had to recompile apache > with mod_perl included statically. This was also supplied > in the 7.3 release. Unfortunately it broke again when RH 8.0 > moved to apache 2.0 but that's beside the point - or perhaps > it was the beginning of the new era. Yes, it's a ".0". We've been through this. At this point, I could care less what you think of the 2-2-2, 6-6-6 model. I _never_ said it's the "best." I just said that many of us believe it's the best we know of, and several vendors agree. > What, in fedora, is ever going to be equivalent of that > RH 7.2 -> RH 7.3 transition where features weren't exactly > frozen but there was a focus on getting existing things > right without introducing new problems. First off, I've been very critical of Red Hat's decision to drop revisions as of RHL8.0->9. But, Fedora Core 1 was pretty much the ".2" from Red Hat Linux 9, the ".1" from Red Hat Linux 8.0, the ".0" There were _some_ "sanity checks" in Fedora Core 1, but it was pretty much a "drop in" for Red Hat Linux 9. That's why I call them in my configuration management system: CL3.0: Red Hat Linux 8.0 CL3.1: Red Hat Linux 9 CL3.2: Fedora Core 1 Then Red Hat changed things with CL4.0, Fedora Core 2. But then they matured in CL4.1, Fedora Core 3. Now I wish Red Hat would have used a revision to warn us that Fedora Core 2 was a ".0" -- but it was well known that they were switching the kernel, among other things common to ".0" (like SELinux, udev -- although not totally until FC3, etc...). The reality here is that Red Hat _must_ continue to keep something aligned with the 2-2-2, 6-6-6 model in Fedora Core's development. So far, they have pretty much done this. Fedora Development-Test-Core replaces Red Hat Rawhide-Beta-Linux. Fedora Core _continues_ to hit a 6 month release schedule, just like Red Hat Linux before it (with exception of the "switchover" from Red Hat Linux 10 to Fedora Core 1 -- which added 2 months). There was basically a "maturity" in Fedora Core 1 beyond Red Hat Linux 9, which several things fixed in Fedora Core 1 also being applied in RHEL 3 updates. Fedora Core 4 hasn't been released yet, but it looks to be a CL5.0, which several changes (e.g., GCC 4.0). I wish Red Hat would stick with GCC 3.4 for one more release, and making it a CL4.2, and then change GCC in Fedora Core 5 (which would be CL5.0). But the quality of Fedora Core is reduced, it _will_ affect RHEL. Red Hat knows this, although I think the lack of revisions starting with Red Hat Linux 9 is starting to cause some concern. I'm one of the people that has been vocal on this. So don't you assume for a moment that I am not critical of Red Hat. In fact, I'm using Novell 9-10 / SuSE 9-10.x as an example that there is _no_reason_ Red Hat shouldn't be using revisions on Fedora Core. > No one here is interested in SLA's, or we wouldn't be having this > discussion on the mail list of a distribution that doesn't offer them. But the discussion is _why_ CentOS doesn't have this or that. This is what I mean by "ignorance" -- people don't stop to realize that it's based on RHEL, several maintainers have stated it will continue to be based on RHEL, and RHEL is SLA-focused, completely. Because Red Hat _does_ take owernship of anything it ships with it. > We just want a product that mostly works and isn't too far behind > the developers. Then if you're talking anything Red Hat developed, then you want Fedora Core. What I designate as CL4.1, Fedora Core 3, is _very_ _stable_ IMHO. Of course CL4.0, Fedora Core 2, was not, and I avoided it. And yes, I sure wish Red Hat would re-introduce versioning in the Fedora Core releases, after that stopped with Red Hat Linux 9. > Come on - I would have guessed that you still had some RH 7.3 boxes > in production too. Or do you only work with companies that will > pay for vendor support on everything? First off, Red Hat Linux 7.3 is _still_ supported by Fedora Legacy. But that's not the point here. The point is _please_ show me any release that Red Hat supported for 4 years other than Red Hat Linux 6.2 and Red Hat Linux 7.3? Pretty much Red Hat's unofficial history has been "support the last .2 release for 2 years, drop most of the .0/.1 releases." Red Hat's unofficial policy has _never_ been to support Red Hat Linux releases a long time. When Red Hat Linux 8.0 came out, and Red Hat Linux 6.2 dropped, Red Hat was also going to drop Red Hat Linux 7, 7.1 and was considering 7.2. All of the sudden, people bitched and moaned. Why? Because a lot of companies had standardized on Red Hat Linux 6.2 nad Red Hat Linux 7.1. And that's when this whole "myth" of Red Hat supposedly supporting .0/.1 releases for 2+ years began, let alone .2 releases for seemingly forever. The reality is that people had sold companies on the fact that Red Hat was Microsoft, and 5+ years support was going to be maintained so they could get Linux in companies. That was _never_ true. So when bosses started questioning why, the buck was passed onto Red Hat. In fact, Red Hat _rarely_ did it more than 2 years for a ".2" release. E.g., the second Red Hat Linux 7 came out, Red Hat dropped 5.2 -- and they had dropped 5.0 and 5.1 well before that (by Red Hat Linux 6.1). At various points of Red Hat Linux 7.x releases, they started dropping Red Hat Linux 6.x releases. But by the time Red Hat Linux 8.0 came out, Red Hat Linux 6.2 and 7.1 were so widely adopted, people didn't want to budge. The old, unwritten rule of upgrade to the last .2/.3, and the previous version's .2/.3, was no longer being accepted by users when Red Hat Linux 8.0 came out. They expected Red Hat to support there distros longer -- a total _waste_ at bugfixes for 7 simultaneous revisions. Which is why the new 1 year support policy was announced -- over 18 months _before_ the Fedora Project was announced. Now Red Hat continued to support Red Hat Linux 7.3, because it was the "last .3," but they wanted a blanket policy of "don't expect us to support it more than one year." That's always been their "underpromise, overdeliver." They just wanted people to stop expecting them to do things they _never_ did. I still can't believe people still proliferate things they _never_did_ do before they introduced Red Hat Linux 8.0. Companies that want a 5+ year supported distro need to pay for RHEL. And those same consumers were the ones already complaining that Red Hat Linux was "too experimental." Hence the SLA ownership. Now, after all this, am I just an asshole? Or am I merely trying to explain the realities of Red Hat's _real_ history? People who believed that Red Hat would support .2/.3 releases more than 2 years, or every little .0/.1 release more than 1 year were lying to themselves. Red Hat never ran into that _until_ they tried to introduce Red Hat Linux 8.0 and drop support for at least 6.2, 7 and 7.1, as well as 7.2 now that 7.3 had been out. Not even SuSE promised to support their releases more than 2 years, and have typically fallen short. And only the Debian project seems to have a history of support on-par with Red Hat (but they also aren't as adopting as Red Hat simultaneously either). So, when is this going to end? When I've decided to live in this "When Red Hat was 'good'" fantasy that many others seem to live in? -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

Re: CentOS and SL, together? -- attributing statements to me (that I didn't make)
by Bryan J. Smith <b.j.smith＠ieee.org> 30 May '05

30 May '05

From: Collins Richey <crichey(a)gmail.com> > I roll my eyes when I hear how good and great and all-virtuous > RedHat is, On GPL. That's all. On GPL. IBM is praised while HP, Red Hat and Sun are demonized. Companies have their agendas, and we need to be _cautious_. But one thing remains: Stallman's Moral Delima Which means that the only thing that matters in the end is GPL. As long as Red Hat is a 100% GPL company, nothing else matters. Same deal with IBM. If they go 100% GPL, I'll love them too. Heck, I'd just be happy if they'd drop the CPL and IPL on their donations. They virtually have no GPL, at least Sun can claim some major ones. > and I roll my eyes when I hear some of the complaints about > RedHat. As is always (at least since the time of ancient Greece) the > case, somewhere in the middle lies truth. I'm just thankful that > CentOS makes the RedHat software with all its benefits AND warts > available to a wider audience. Agreed. Did I ever disagree with that? > I'm essentially a believer in FOSS. I prefer to use the term Freedomware, which doesn't need a definition to those not familiar. ;-> > I would never purchase a shrink-wrapped RedHat were it still available, > nor do I have any need for an SLA, As is your choice. No one at Red Hat is forcing you to do so. Tiemann basically said in not so few words that they don't want you as a consumer, only possibly a user of Fedora Core if you wish. > but I'm very thankful that RedHat fully subscribes to the GPL and makes its > SRPM's available. Which is why, taking everything else away because it's "subjective" to many people from different views, is why Red Hat is a "friend" and not so much of a "partner." > As a wiser person than I said in another post, it doesn't help much to > tell someone who is used to having a particular feature that he can't > have that any more and why. Of course it does. If they would have looked at early Fedora Core 2 development, they would have known what to expect. Then they would have known what to tell their clients, and how to come up with a solution that minimizes risk to existing operations. Blaming Red Hat for something outside their control does nothing. Or should I put it this way, if you _complain_ about something, there is nothing wrong with someone else explaining why you shouldn't. You can't complain about me trying to explain things any more than someone who is just complaining in the first place. > Even less does it help to tell that person that he is an ignorant fool I reserved the word "ignorant" until it got to the point that they just didn't care why, how or how to accommodate such very likely and similar changes in the future. At some point, if you choose to be ignorant, you are only hurting yourself. > and better off without that feature. I _never_ said he was "better off without that feature." I *NEVER* SAID THAT! At least 2 _other_ people did, as well as the Red Hat rationales. I never said either way whether CIPE was good or bad -- I _purposely_avoided_ doing so! This is what I really _hate_ about these lists. All of the sudden, _anything_ negative said by _anyone_ in a thread is attributed only to me -- and I'm the focal point for 100% of what people don't like. REGARDLESS IF I SAID IT OR NOT! 100% GETS PUT ON MY NAME! At this point, you are not bothering to accurate listen to what I actually said. There is a "method to my madness" and I'm pretty darn ethical in my approach. And that includes _reserving_opinion_ of whether or not something should or should not be included. And just trying to understand why decision are made by others. It's funny, people say I don't try to look at something from someone else's viewpoint. I'm quite the opposite. Whether it's a client, vendor or individual, I step into their shoes. In fact, one of the reasons I try to explain things is so people don't fall into the same assumptions again. Because assumptions are the biggest problems of all. And I really think some people would rather hate than to stop and be tolerant of people and projects who typically don't have the same focus as they. -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

Re: [CentOS] Re: centos] Re: Demonizing generic Linux issues as Fedora Core-only issues -- WAS: Hi, Bryan
by Bryan J. Smith <b.j.smith＠ieee.org> 29 May '05

29 May '05

From: R P Herrold <herrold(a)owlriver.com> > Bryan - Please don't overstate this and make a problem where > none exists. There is an infinity of choices of which you > list three ... > Nor does one _have_ to 'get involved' with either the > RH-Fedora or Centos project to do effective distribution > building, or add-on packaging. There are independent > packagers who have packaged for years and years outside of > RH's Fedora and its required representations and paperwork to > be a committer, outside of Centos. Tummy, Matthias (pre-his > move to RH Fedora Extras), Dag, again my longstanding archive. > RPMForge offers a home. You too my statement out of context. I was talking about how to affect CentOS _directly_! I didn't say those were the only ways to help Linux in general. Because, after all, the people I have a problem with aren't complaining about what is or isn't available in the Linux world. They are complaining why CentOS doesn't have this, and typically blaming Red Hat. So given the criteria of CentOS, my 3 major options are pretty much it. 1. Get involved with Fedora, so things change early 2. Get involved with CentOS, to help out the additional projects 3. Or just complain and nothing changes RHEL is pretty much about what we make in Fedora. CentOS is pretty much what we add around RHEL. Complaints don't do anything, they are generally destructive. And they are even more so a "slap in the face" to those who actually take the time to be constructive and help out these projects. If you don't like Red Hat, tell them so in Bugzilla! They want to _know_ what poeple are having issues with -- they _will_ respond and try to please. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: [CentOS] Re: CentOS and SL, together?
by Bryan J. Smith <b.j.smith＠ieee.org> 29 May '05

29 May '05

From: Collins Richey <crichey(a)gmail.com> > It's just too bad that there is really nothing on offer for these > former customers. Please don't suggest Fedora. The customers who are > complaining the loudest are not interested in experimental versions. To me, the quality of Fedora Core is no better or no less than Red Hat Linux before it. One thing I _do_ find is that people are making claims on Red Hat Linux that were _never_ true. SLAs were _never_ offered, except on Red Hat Linux 6.2 "E". Support was virtually never offered as standard beyond installation. Yes, there were and still are professional services, but they are typically more for development anyway (which includes Fedora). Updates were typically cut off for all releases except the last .2 once the next series came out. This all changed in the version 7 series, because companies and users started demanding it. But after the version 7 series, 2 years before Fedora, Red Hat switched back to no more updates beyond one year. So as far as "abadonment," I never saw anything Red Hat did above and beyond as unofficial charity. And I rather tire of claims that Red Hat did this or did that on Red Hat Linux when they _never_ did. Which is why I scratch my head. Especially when you compare what people want and the fact that there's virtually no other company that offers it. Even SuSE doesn't make it's 2 year guarantees, and they are yanking support on SuSE Linux 7. It's almost like there is this Red Hat Linux product that existed like a myth, a word-of-mouth fairy tale. And that's what just makes me roll my eyes. At the same time, people still complain about the GLibC 2.0 change, the GCC 2.96/3.0 change, the NPTL change, etc... It's like even the critics sometimes contradict themselves -- much like I also see done with Microsoft as well. It's not that Red Hat doesn't have its issues or focus. It's just that people need to focus on those details that are actual issues, and not invent things. Like this Red Hat Linux product I never knew existed. ;-> -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 2

Re: [CentOS] logrotate
by William Warren 29 May '05

29 May '05

Where are currently used .conf files kept? the /etc/logrotate.conf file does not contain any useful information. This is Centos 4 BTW. replies-lists-centos(a)listmail.innovate.net wrote: > between the man page for logrotate, the /etc/logrotate.conf file and > some of the files in the logrotate.d directory you should be able to > see all the bits necessary to accomplish what you're after. > > the /etc/logrotate.d/exim file gives you an example of wildcarding > the files that are included. > > by default, gzip deletes the file when compression is complete, so > you don't have a file delete issue. > > you'll probably need to use the "force" option during setup and > testing. > > > ------------ Original Message ------------ > >>Date: Sunday, May 29, 2005 10:06:20 AM -0400 >>From: William Warren <hescominsoon(a)emmanuelcomputerconsulting.com> >>To: CentOS mailing list <centos(a)centos.org> >>Subject: [CentOS] logrotate >> >>I am googgling right now but am unable to find a simpler >>description of how to get logrotate to do what i want it to do. >> >>I have a cs 1.6 server that generates quite a bit of logs. That >>log generation is going to increase significantly with one of my >>plugins i am going to be installing(logD and the impressive >>plugin). I want to tell logrotate to daily rotate all the logs >>inside my /servers/hlds/cstrike/logs folder. A new log is >>generated every map change and when any on-the-fly configuration is >>changed. Over the past 5 days there are 350 logfiles. How can i >>tel logrotate to rotate all of the individual logs in the folder, >>when rotating to compress them, store the compressed files in the >>same directory..delete the uncompressed logs..and not to delete any >>old logs for 6 months? >> >> >>-- >>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/ >>_______________________________________________ >>CentOS mailing list >>CentOS(a)centos.org >>http://lists.centos.org/mailman/listinfo/centos > > > ---------- End Original Message ---------- > > -- 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 2

logrotate
by William Warren 29 May '05

29 May '05

I am googgling right now but am unable to find a simpler description of how to get logrotate to do what i want it to do. I have a cs 1.6 server that generates quite a bit of logs. That log generation is going to increase significantly with one of my plugins i am going to be installing(logD and the impressive plugin). I want to tell logrotate to daily rotate all the logs inside my /servers/hlds/cstrike/logs folder. A new log is generated every map change and when any on-the-fly configuration is changed. Over the past 5 days there are 350 logfiles. How can i tel logrotate to rotate all of the individual logs in the folder, when rotating to compress them, store the compressed files in the same directory..delete the uncompressed logs..and not to delete any old logs for 6 months? -- 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/

1 0

Re: [CentOS] Re: Demonizing generic Linux issues as Fedora Core-only issues -- WAS: Hi, Bryan
by Bryan J. Smith <b.j.smith＠ieee.org> 29 May '05

29 May '05

From: Dag Wieers <dag(a)wieers.com> > I have a real problem with this thread. It seems as if, according to some, > someone can only be with or against Red Hat. Yes, that was my major complaint too. > I'm sure Red Hat has made stupid decisions, has adopted buggy software and > are responsible for some of the headaches people have had. And I'm sure > even Red Hat employees (like with any other distributor) would recognize > this. Agreed. If you attempt to please all people, you will fail utterly. Red Hat has its focus, pretty much all SLA-related on RHEL. Some people may demonize it as "that's where the money is" but in reality, it's because it's designed for paying customers who pay for those SLAs. At the same time, we still have Fedora Core. While people will debate over the merits of the greater Fedora Project in general, Fedora Core and RHEL are designed for two completely different sets of users. Just like RHEL was once it came out alongside RHL. Are there places in-between? Hell yes! And I like what I see in the CentOS project, where Red Hat has not addressed. But Red Hat already has 2 levels of focus, and I don't see them changing it. It seems to work, and work well for them. Novell-SuSE seems to be similar. But in the end, this is the reality that some people don't wake up to. They've got 3 choices: 1. Get involved with Fedora Core, which affects RHEL 2. Get involved with CentOS, which affects add-ons for their rebuild 3. Complaint, and nothing will change at all ;-> In reality, I typically ignore #3. The problem is when people do #3 and they just don't care to understand anything technical with FC-RHEL development and focus, and just get things dead wrong. Especially things that have redistribution and/or licensing issues, or the fact that sooner or later, newer versions have to be adopted. In fact, many people seem to be "wishy washy" on whether Red Hat should "hold back/backport" or "adopt newer" releases. The reality is that Red Hat doesn't ship anything in RHEL that hasn't been through Fedora Core prior (with rare exception, like MySQL 4 in RHEL4 that wasn't in FC2/FC3 -- kinda shocked even me). > But just pointing things out does not put you on one or the other side, > I may hope. Yes and no. No in the fact that your posts have made me aware of some considerations I never looked at before. That is a good thing. But yes, when people don't stop to understand the technical and licensing issues, let alone what RHEL's purpose is -- things that will _never_ change -- it's just bitching. It's one thing to complain in the hope of change, and even better to get involved. But bitching is just that -- the complaint that people are upset that CentOS doesn't do something out-of-the-box. And that means they blame Red Hat -- no matter where the actual blame _may_ fall. Worse yet, I've just sat back and actually let others attempt to explain how Red Hat wasn't involved in a decision (other projects did, which Red Hat merely simply complied with), and these "bitchers" will simply continue, and just make more comments that just show they have no interest in anything other than "bitching." It's beyond not being constructive, it's just flat out ignorance. That's what really gets to me. I can accept people aren't happy and wish for things. But when they want to blame Red Hat when there's nothing Red Hat can do about them, or they would radically change RHEL's focus to something that breaks the entire SLA model, then I just have to recognize that some people just won't see anything from another viewpoint. > I always have a sour taste in my mouth if you have to pick sides, because > that kills healthy rationalizing/critizing and often this has a hidden > agenda attached to it. Agreed. The problem is that many people who are "explaining" Red Hat are considered a "side" in the first place. I have been labeled a "Red HAt apologist" just for merely explaining many things that people will not believe is anything but a "Fedora Core / Red Hat-only bug." It doesn't matter how you explain it, there is always an avenue for them to assign blame to Red Hat -- and no one else. Ironically, if you have a SLA with Red Hat, they do take ownership of everything. Which is why RHEL is designed the way it is, to absolutely minimize anything that is not well package and integration tested. -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

Centos 4 on a portable hard drive..help!!
by Hugh Tollan 29 May '05

29 May '05

G'day one and all, I would like to install Centos 4 on a freecom classic hard drive (usb) ..the box I want to use can boot from removable devices. Any ideas how to go about installing onto the portable drive? If not can anyone point me in the right direction? I have tried to google but have not come up with much info....or info that I understand anyway!!!!! As usual, many thanks in advance. _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

2 1

Re: [CentOS] Re: CentOS and SL, together? -- GPL, LGPL, kernel and user ...
by Bryan J. Smith <b.j.smith＠ieee.org> 29 May '05

29 May '05

From: Johnny Hughes <mailing-lists(a)hughesjr.com> > Sorry ... I was talking about the SRPM from SL ... it also build the > kernel modules ... Oh, right, sorry -- understand what you mean now. BTW, one of the worst assumptions I've seen is that because a distro or project ships something, its users believe it was done legally or with permission. I've seen many cases where things were never allowed to be redistributed, and they are no longer because the distro or project finally received a cease-and-desist letter. Not good if you're working in a company where people have installed it. Which is why I appreciate projects like Debian, Fedora, CentOS, etc... -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: [CentOS] Re: CentOS and SL, together?
by Bryan J. Smith <b.j.smith＠ieee.org> 29 May '05

29 May '05

From: "Bryan J. Smith <b.j.smith(a)ieee.org>" <thebs413(a)earthlink.net> > Which is why I scratch my head. Especially when you compare what > people want and the fact that there's virtually no other company that > offers it. Even SuSE doesn't make it's 2 year guarantees, and they > are yanking support on SuSE Linux 7. Sorry, that last part should read "yanking support early on SuSE Linux Enterprise Server 7." Underpromise, overdeliver, that's always been the Red Hat way. Unfortunately, people seem to have taken their occassional past overdeliveries as policy. Especially since they were largely just short-lived, and never promised. -- Bryan J. Smith mailto:b.j.smith@ieee.org -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: [CentOS] CentOS and SL, together?
by Bryan J. Smith <b.j.smith＠ieee.org> 29 May '05

29 May '05

From: Lamar Owen <lowen(a)pari.edu> > Referencing SL3 and CentOS 3 (as I haven't run SL4 as yet) there were some > scientific applications and some Java stuff, eclipse for one, You do understand the redistribution issues with Java, correct? It's a Sun problem (a typical thorn for Red Hat in general), not a Red Hat one. > part of cluster suite for another, included. > Lessee, > https://www.scientificlinux.org/distributions/30x/features/ is the reference. > GFS, Eclipse, Cluster Suite, OpenAFS, ksh93, a set of 'tweak' RPMs (my > favorite being the serial console tweak RPM). Red Hat is pushing to get GFS in the stock kernel. They bought out Sistina for a reason, to keep it GPL. These things don't happen overnight. ;-> GFS was introduced as an add-on, and probably will until it is in the stock kernel -- Red Hat is trying to avoid heavily patching the kernel nowdays (for various reasons). As far as OpenAFS, I assume you mean the server? Or you don't like Red Hat's included client in the kernel? As always, make a Bugzilla request if you want something. > For SL4, the doc is at > https://www.scientificlinux.org/distributions/4x/features/ and includes fewer > addons. OpenAFS is the biggest of these, I guess. And I too have deployed OpenAFS. The server is 100% userspace, so it shouldn't be too difficult to get it included, at least in Fedora Core (possibly the next RHEL5). > Once the cluster suite and eclipse are available they probably will be rolled in. Eclipse is now in Fedora Core 4. One thing to always remember that Eclipse's licensing is outside the control of Red Hat, and is IBM. It is also released under a non-GPL compatible license by IBM, and is similar in restriction to Sun/Mozilla licenses, so I'm sure Red Hat was hesitant to include it before. > The Fermi version of SL 3 had included a packaged JRE and was very attractive > for that, but later releases have not had that and rather have pointers to > download from sun. It is illegal to redistribute the JRE for Linux without a license. Again, see Sun for details. ;-> > Pine also is in the SL dists. Pico/Pine also changed licenses awhile back and is considered "non-free." Nano replaced Pico, can't remember what replaced Pine. Once again, I will remind people that an "enterprise/SLA" focused distro will rarely be focused on features. At the same time, it's clear that it requires many "enterprise" software packages built upon an "enterprise" distro -- which is not uncommon. Red Hat can't ship an "all-in-one" distro for enterprises -- and a SL solution is going to be on the other side of the spectrum from, say, a financial industry focused Linux. So Red Hat would rather ship a common base, supported by SLAs, and then sell add-ons with SLAs for a more specific configuration. If you want an industry-specific Linux, you're not going to find it from a generic distribution vendor. And you shouldn't wonder why they don't throw in things -- especially not things like Java which are _illegal_ to bundle freely. -- Bryan P.S. As always, maintain your own APT/YUM repository internally, and mix in any required RPMs. I virtually _never_ install from CD/DVD, almost always via NFS -- possibly with some post-install APT/YUM. -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 3

Re: [CentOS] CentOS and SL, together?
by Bryan J. Smith <b.j.smith＠ieee.org> 29 May '05

29 May '05

From: Johnny Hughes <mailing-lists(a)hughesjr.com> > Righto ... no JRE redistributes in CentOS ... that is not allowed :) > They also have mp3 stuff ... also not allowed :) If you want an example of what I consider "ignorance," that's it right there. Someone who asks, "why doesn't Red Hat include X," won't get grief. But people who say, "I use Y because it includes X and Red Hat does not," sorry, that's starting to play into that game. I have a rule at my clients: "No Linux CDs are allowed into the building until they are approved -- especially _not_ Knoppix." Why? Because I have to verify they are "pure" Linux and not an indemnification nightmare. > For CentOS-3.x you can get GFS (and RH ClusterSuite) here: > http://bender.it.swin.edu.au/centos-3/ > (there is no GFS/RHCS for RHEL-4 (or CentOS-4) yet) BTW, I haven't looked yet, is Netscape Directory Server available for CentOS? You can get it from the RHN (as well as the "technology preview"), just wondering if it's available for CentOS from another source. > OpenAFS: I'll have to look at the license that it is released under ... > that might be able to be in Extras ... someone want to maintain it :) IBM's IPL, yet another GPL-incompatible license along with IBM's CPL. People claim I have an "agenda" against IBM. No, but I _do_ have an "agenda" to get people to realize that they should hold IBM up against the same standard (and "agenda") they have against Sun. http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses Now the last time I checked, Red Hat did include the OpenAFS client in the kernel -- at least GPL portions (the history of AFS is a little interest). The OpenAFS server is user-space, so there is not a licensing issue there. I typically just download and build the full IPL licensed client/server from OpenAFS, despite the licensing issues. If it's for private use, you can do this per the GPL -- you just can't redistribute anything that isn't GPL compatible linked against GPL (which is what I make my clients aware of). BTW. If people think "ignorance" is a "harsh word," understand when you are "ignorant" as a consulting engineer with a Professional Engineering license, the term becomes "Professsional Negligence" with the same, _liability_ as an MD. ;-> So I tend to avoid "ignorance" and care about little details. ;-> > Correct ... Pine is non-free license, won't be built for CentOS-4 :) But remember, it's Red Hat's fault. ;-> -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 2

Re: [CentOS] Re: Demonizing generic Linux issues as Fedora Core-only issues -- WAS: Hi, Bryan
by Bryan J. Smith 29 May '05

29 May '05

Even I've left this thread. I guess we're all waiting for Lee to turn Blue. ;-> Or is it Red (Hat)? ;-> Okay Lee, we all agree, Red Hat makes stupid decisions, adopts buggy software - especially the kernel and Red Hat is to blame for the decisions in the kernel, and also stupidly backports fixes instead of adopting newer versions with the fixes. And there is absolutely no need for Red Hat to do so. Happy? -----Original Message----- From: Les Mikesell Date: 05-5-28 0:55 To: CentOS mailing list Subj: Re: [CentOS] Re: Demonizing generic Linux issues as Fedora Core-only issues -- WAS: Hi, Bryan On Fri, 2005-05-27 at 19:13, Lamar Owen wrote: > On Thursday 26 May 2005 14:17, Les Mikesell wrote: > > If you believe that, you have to believe that Red Hat's programmers > > are always better than the original upstream program author. > > For the most part, the Red Hat crew is the best in the business. Or have you > never heard of Jakub Jelinek, Alan Cox, Rick van Riel, and many many other of > the top upstream developers that are employed in some capacity by Red Hat? I think we've beaten these topics to death, but since it is kind of fun if you don't take it too seriously: Which of these guys knows how to make perl do character set conversions correctly better than the perl team? > > I'll > > agree that they are good and on the average do a good job, but > > that stops far short of saying that they know better than the > > perl (etc.) teams what version you should be running. > > The perl team has no business telling me what version I should be running, > either. What version I run is dependent upon many things; one of which is > 'what version does my vendor support?' Sigh... at this point it is "how many versions does the vendor support"? And the issue is that the perl version (among many other things) that does a certain operation correctly is only included with a kernel version that has features missing and broken. > > So, you want a working application, take an incomplete kernel. I > > understand that's the way things are. I don't understand why > > you like it. > > Long term version stability. There has to be a freeze point; Red Hat has > chosen the very documented 2-2-2 6-6-6 scheme, and sticks to its schedule, > for the most part. Or, to put it very bluntly, just exactly which of the > over a thousand packages are worth waiting on? And who decides which package > holds up progress? CIPE, the example used here, is relatively insecure to > begin with and interoperates with nobody. I don't see how you can call setting up a WAN with many CIPE nodes, then finding it unavailable in the next release 'long term stability'. > Better to use IPsec (which > virtually everybody supports to a degree) than a relatively nonstandard VPN > like CIPE (I'd go as far as to say that most of the other VPN solutions are > in the same boat; what's needed on the server side is typically > Microsoft-compatible PPP over L2TP over IPsec, which is so easy to set up on > the Windows client side it isn't even funny). That's why for-purpose > firewall/VPN appliance Linux dists (SmoothWall and Astaro, for instance) are > not using anything but IPsec. I have a SmoothWall box myself, and it Just > Works. Can you run it through NAT routers? I have locations where the end point is already NATed by equipment I don't control. CIPE doesn't mind and the blowfish encryption is pretty CPU-friendly. And again, it might be "long-term stability" if this had already been a choice in several prior versions so you didn't have to upgrade OS revs on machines in several countries on the same day to keep your machines connected. > > Is there a reason that a Centos or third-party repository > > could not be arranged such that an explicit upgrade could be > > requested to a current version which would then be tracked like > > your kernel-xxx-version is when you select smp/hugemem/unsupported? >

4 5

Re: Demonizing generic Linux issues as Fedora Core-only issues -- WAS: Hi, Bryan
by Bryan J. Smith <b.j.smith＠ieee.org> 29 May '05

29 May '05

From: Les Mikesell <lesmikesell(a)gmail.com> > No, I am looking for a solution that provides what a typical user needs, > not what a particular vendor feels like supporting this week. I didn't > really want this to be about motives for vendor's business decisions but > I think Johnny Hughes nailed it in saying the push for 2.6 was because > SLES 9 had it. Their decision wasn't stupid, but my point is that it > wasn't the best thing for some number of their old users. At what point does Red Hat hold off on adopting Linux 2.6? Or GCC 3? Or GLibC 2.0? As I said, there is a chicken-egg issue between "waiting for something to be well-tested with many packages" and "adopting something so it is well-tested with many packages." This existed back in the Red Hat Linux timeframe, and it still exists today. That's why RHEL is essentially based on the ".1" or ".2" release. Then it is kept fairly _static_ over its lifetime for SLA reasons. > However, I also support a number of general-purpose servers and some > desktops where a larger mix of applications need to be integrated > along with a variety of oddball hardware that has, over the years > been connected and supported one way or another. In this scenario > you are very likely to want to upgrade a single application and > find that you can't do it RedHat's-way(tm) because the bundled > upgrade will break something else that you need to keep running. And other "packages" distros don't have this problem? If you find Fedora Core + repositories doesn't solve what you need either, I think someone else pointed out that a "ports" distro, like Gentoo, might be more of what you are looking for. Especially if you're rolling out lots of "bleeding edge" distros. BTW, just so everyone knows, I support Debian, Fedora, Gentoo, NLD, RHEL, SuSE and SLES as a paid consultant. And I've been a maintainer in several projects so I'm not just a "Red Hat-only lacky" as many people believe. In fact, I am a software engineer at many clients (I just get stuck with the IT / configuration management because I seem to know how to do this with Linux better than the others around me). So I'm very partial to using "ports" distributions like Gentoo and BSD. ;-> > Explaining the reason the vendor made the decision that doesn't > work in my case isn't particularly helpful. Understanding why either allows you to: A) See what you can do to get the vendor to change, _or_ B) Better recognizing what you can do to accommodate the vendor I said it before and I'll say it again, one of the reasons I have very much sought after -- almost always by personal reference -- it because I can come in, look at someone's business/engineering model, and then architect a solution that maximizes the application of a solution while mitigating risk to any product changes. Unless you understand how and why the vendor is doing something, you can't either do "A" or "B" and customize the solution one way or another. The last thing my clients want to hear from me is "damn, Microsoft/RedHat/etc... broke your network." Furthermore, when architecting a solution, I can also give the client options and say, "if you go with RHEL, you're going to run into the re-occuring problem of X, Y and Z." In most cases, it helps me eliminate Microsoft from client consideration early on, but in some cases, I actually end up rolling out a completely _non-Red Hat_ solution. > You might as well try to explain to me why upgrading or installing > certain MS products require moving the whole enterprise to Active > Directory first. That's different, although the concepts are similiar. There is no vendor that can provide a solution that doesn't need accommodate at some point in a solution. Fortuntely, we don't have the "on-a-whim" changes in the RHEL space like we do in Windows -- _primarily_ _because_ Red Hat _never_ mixes in "new features" mid-release. But configuration management is _always_ an issue. You are _never_ going to eliminate much of it even in the Linux space. It is a necessary evil that you must do -- and that will vary on the focus of the distro. In fact, not doing configuration management in Linux roll-outs and, essentially, _falsifying_ the savings on Linux with it, is the absolute #1 reason why Linux projects fail. Having a background in defense, I liken this to NASA's COTS (commercial off-the-shelf) adoption in the '90s. After Sojouner (Mars Pathfinder) proved that GNU/VxWorks was a viable platform that cost 1/10th of custom software/hardware development, NASA's nexgen probes started adopting the same platforms/software as Pathfinder. The problem on these other projects is that the 90% savings was no longer applied to just software/hardware, but _all_ aspects of the project's budget. So unlike Sojouner, the QA (quality assurance) budget was cut. So when Mars Polar Lander entered the orbit assuming the units in a register were miles when they were, in fact, kilometers -- because there was not the QA between two engineering teams at two different companies several states away from each other -- I was not surprised one bit. Configuration management is quality assurance. You must do it and there will _never_ be a vendor, distro or other "off-the-shelf" solution that will allow you to avoid doing it. Because a solution is _never_ available that is customized for you and regression tested to work without issue. That's just reality. > I'm not really interested in playing a 'vendor lock-in' game. Okay, this is the typically spiral I see people do. They start talking about "vendor lock-in" with regards to Red Hat, applying their experiences with Microsoft. Sorry, this is _exactly_ the "demonization" I'm talking about. You are comparing the world's greatest, "we lack even proprietary standards" company to Red Hat, the absolute #1 pro-GPL commercial company. So there's _no_ sense in my responding further. -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

Re: CentOS and SL, together? -- GPL, LGPL, kernel and user ...
by Bryan J. Smith <b.j.smith＠ieee.org> 29 May '05

29 May '05

From: Johnny Hughes <mailing-lists(a)hughesjr.com> > Nope ... I can't build that with GNU gcc and against GNU glibc and > release it ... sorry, no OpenAFS :( ??? Actually, you _can_. You just can't link it into the GPL kernel program. [ I'm not posting this to cross you. But someone correct me if I'm wrong. ] There is nothing in the GPL that prevents a GPL compiler from producing non-GPL code. And LGPL can be statically linked against non-GPL compatible code. So that means the OpenAFS _server_, which is user-space, can be built with GPL GCC and dynamically linked against LGPL GLibC. But the OpenAFS _client_, which is kernel-space, cannot be statically linked into the GPL kernel program. [ I believe there is an OpenAFS client that is GPL, missing various IBM code. ] -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

Re: [CentOS] Re: Demonizing generic Linux issues as Fedora Core-only issues -- WAS: Hi, Bryan
by Bryan J. Smith <b.j.smith＠ieee.org> 29 May '05

29 May '05

From: Collins Richey <crichey(a)gmail.com> > It's a little more than that. I find few people who consider RedHat to > be a Demon Evil or that they can't do anything right, but I can > understand the concern about some of their decisions which have made > life difficult for (granted) a few, and it's not really helpful to > demonize those who complain, as Bryan has done. In essence, RedHat is > a business entity, and they make their decisions for business reasons. No offense, but I tire of being the "focal point of example" when all I'm doing is explaining why Red Hat has done something. Especially when one thing that severely dominates the landscape are statements of "Fedora Core / Red Hat-only bugs" which are simply total fabrications. Why am I blamed for pointing out that they are not? Oh, that's right, it's not popular to explain something as not a Red Hat-instigated issue. I seem to remember that same issue in the Windows world as well, where people seem to want to assign blame to Microsoft for everything too. The problem is that when everyone just instantly blames Red Hat for everything, just like Microsoft, it drowns out all those who do have _legitimate_ and _technically_ "well thought out" issues that _could_ be of good consideration for Red Hat. It's hard to make these issues known among a screaming bunch of "bitchers." And that's what it is. Especially when people do not stop to recognize the root causes of the issue. It's not "picking a side" -- it's about stopping and understanding why. Because only when you understand why can you either A) see it changed and, if that is not a solution, B) accommodate it as best as you can. > True enough. My biggest problem, philosophically at least with RedHat, > is the now unified release: what's good for server users is what > Desktop users get. This goes back to the whole eWeek mis-quote of Michael Tiemann where the whole world said Red Hat was "getting out of the desktop market." In reality, I totally agree that it's really not of any interest to Red Hat to keep trying to _sell_ a _product_ that is geared towards all the endless uses of a consumer/custom desktop. It's _cheaper_ and more _effective_ for Red Hat to put people on developing and giving away a distro like Fedora Core. It was a basic admission that Red Hat Linux as a "product" was attempting to please way too many people, and was failing to do so. If you don't like what you see in RHEL/CentOS as standard, your best bet is to get involved with Fedora Core, and attempt to see things included and tested in it first. Just a Bugzilla request, sometimes it's that simple to get what you want -- as long as you're willing to wait out Red Hat's testing cycle. That's the problem, people want it now, and that just ain't gonna happen. ;-> > I'm still looking for the binary distro that has a really stable base but > offers functionality upgrades as they come along. Balance but not > bleeding edge is the name of the game. You're going to be waiting forever. Even if you can somehow have the absolutely most stable package versions from all the various projects, there is no guarantee they will work together well. Only integration testing of all packages as a whole unit do that -- and it's not something that you can do without time and testing. Which is where 2-2-2, 6-6-6 come in better than anything else. > Yes, I know about Gentoo. I've run it almost since inception, and it's > ideal in many respects. Gentoo is a "ports" distro which has _many_advantages_. Unfortunately, maintaining "configuration management" on a ports distro is a bit more involved. I.e., you have basically moved 100% of regression testing onto yourself. ;-> > I've enjoyed this discussion and learned a lot about RedHat that I > didn't know. I thank you for your rational comments. Unlike Bryan, I > think you realize that not everyone who disagrees with RedHat on a > given topic is an ignoramus. Thank you for demonizing me so. The only time I said someone was "ignorant" is when they absolutely refused to stop and understand why Red Hat develops RHEL the way they do, and want to call things "Fedora Core / RHEL-only bugs." In other words, blindly assign blame to Red Hat all-the-time, for everything. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

CentOS-announce Digest, Vol 3, Issue 17
by centos-announce-request＠centos.org 28 May '05

28 May '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-2004:650 CentOS 3 i386 libxml - security update (Tru Huynh) 2. CESA-2004:650 CentOS 3 x86_64 libxml - security update (Tru Huynh) 3. CESA-2004:638 CentOS 3 i386 gd - security update (Tru Huynh) 4. CESA-2004:638 CentOS 3 x86_64 gd - security update (Tru Huynh) ---------------------------------------------------------------------- Message: 1 Date: Fri, 27 May 2005 15:28:28 +0200 From: Tru Huynh <tru(a)centos.org> Subject: [CentOS-announce] CESA-2004:650 CentOS 3 i386 libxml - security update To: centos-announce(a)centos.org Message-ID: <20050527132828.GA11260(a)sillage.bis.pasteur.fr> Content-Type: text/plain; charset="us-ascii" CentOS Errata and Security Advisory 2005:650 libxml security update for CentOS 3 i386: https://rhn.redhat.com/errata/RHSA-2004-650.html The following updated file has been uploaded and is currently syncing to the mirrors: i386: updates/i386/RPMS/libxml-1.8.17-9.2.i386.rpm updates/i386/RPMS/libxml-devel-1.8.17-9.2.i386.rpm source: updates/SRPMS/libxml-1.8.17-9.2.src.rpm You may update your CentOS-3 i386 installations by running the command: yum update libxml\* Tru -- Tru Huynh (CentOS-3 i386/x86_64 Package Maintenance) http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xBEFA581B

1 0

Re: Re: [CentOS] Re: centos] Kickstart from FTP or USB
by Vladan Nikolic 28 May '05

28 May '05

>Bryan J. Smith wrote: > >>Yes. DHCP is the successor to BOOTP that offers a superset of its >>functionality. But in the original BOOTP functionality, you would pass >>the filename the BOOTP client would retrieve from a TFTP server so it >>could boot. The file was then booted. >> >>This is how we have been installing workstations/servers in the UNIX >>world for 2+ _decades_ -- BOOTP+TFTP (plus, typically, an NFS mount). >>The PC only adopted it in more recent years. >> >>E.g., Microsoft Remote Installation Services (RIS) sets up the same >>thing (although uses a SMB mount after the BOOTP+TFTP). >> >> > >Thanks. > >So I guess I should take this as:- > > No, it is not possible just to put the ks file onto an FTP server along >with the install file. I have to have a proper DHCP server and TFTP. Nope, it's not true. I have ftp server, and in root directory I have all ks files for my servers. It is the same ftp server that servers as repository for ks instalations (every distribution has it's own subfolder). All i have to do is boot server from instalation CD, on boot prompt enter: linux ..ks=ftp://192.168.10.10/ks.cfg .... and in ks.cfg there is something like (i type this from head, search for exact line): url ftp://192.168.10.10/distrib1 and that's it

3 2

Kickstart from FTP or USB
by Lee W 28 May '05

28 May '05

Hey Everyone, I was wondering if anyone has managed to do a network install where the kickstart file is located either on an FTP site (which is also where the packages are stored) or on a USB flash drive. I've tried starting the installer with "linux ks=/dev/sda/ks.cfg" or "linux ks=/dev/sda1/ks.cfg" or "linux ks=ftp://what.ever.Ip.address/pub/ks.cfg" but when the installer starts I just gen error (something) like "null: bad address. I've checked the RH docs and it seems that at the very least the USB method should work. Thanks in advance Regards Lee

5 6

rpm problem after recent yum update
by Ping-Wu Zhang 28 May '05

28 May '05

After a yum update (yesterday), I am now unable to install any rpm package. An example of the error message is duplicated below: %pre(VMwareWorkstation-5.0.0-13124.i386) scriptlet failed, exit status 255 error: install: %pre scriptlet failed (2), skipping VMwareWorkstation-5.0.0-13124 Could anyone help? Thanks in advance.

3 6

XFree86-devel package error
by John Quaglieri 28 May '05

28 May '05

I'm not sure if this has been brought up before, but there is error with the XFree86-devel package on CentOS3. Both gccmakedep and xft-config are broken symlinks to archexec in the folder /usr/X11R6/bin. Is there another RPM that provides archexec? This is not a problem on CentOS4. It does look like RHEL suffers from the same problem. -- Regards, John Quaglieri InterServer, Inc 201-643-0135x101

1 0

Re: [CentOS] Intel Matrix SATA RAID drivers
by Bryan J. Smith <b.j.smith＠ieee.org> 28 May '05

28 May '05

From: Mickael Maddison <mike(a)kamloopsbc.com> > Hello CentOS, > Does anyone know if there's a driver out there that'll enable CentOS > 4.x to use the Intel Matrix SATA RAID settings on the 915 chipsets? All FRAID cards do is setup the RAID organization in the 16-bit Int13h disk services. In other words, the vendor introduces its own data organization for RAID, instead of relying on the OS. So there's really no such thing as a RAID driver for any FRAID card (Fake/ Free RAID) implementation. It's all software RAID. The system directly drives the ATA channels, which means the OS uses the standard ATA driver. That means that the FRAID card must either: A) Provide the FRAID logic as a kernel module A few do, and it's a massive binary object that is kernel build-specific. The FRAID logic is licensed from a 3rd party, and that 3rd party makes all of its money from that proprietary logic, so it will never be GPL. B) Write a data organization/interface wrapper kernel module to Linux's ataraid.c FRAID logic module. The GPL/reverse engineered hptraid.c, pdcraid.c and silraid.c modules are examples that don't work well at all, and only for a few models of each. C) Write a data organziation/interface wrapper to Linux's LVM/MD instead of the ataraid.c logic module. This is far more ideal and higher performing, but it makes it OS-specific. I believe this might be what the RAIDCore cards do for Linux support. Intelligent, hardware RAID don't have to do A-C, because the RAID logic is on-board in the firmware, driven directly by an on-board microcontroller or ASIC. FRAID cards use your host CPU and software. That's why RAID are so cheap and have *0* additional hardware over a standard ATA controller. -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

Intel Matrix SATA RAID drivers
by Mickael Maddison 27 May '05

27 May '05

Hello CentOS, Does anyone know if there's a driver out there that'll enable CentOS 4.x to use the Intel Matrix SATA RAID settings on the 915 chipsets? -- Best regards, Mickael mailto:mike@kamloopsbc.com www.MickaelMaddison.com

1 0

Official CentOS CD/DVD Vendor Program
by Johnny Hughes 27 May '05

27 May '05

All, I would like to announce our Official CentOS CD/DVD Vendor Program. We currently have 3 vendors, and 2 more who are putting together their information. (Not bad ... the official program has been going for less than 12 hours :) The details of the program (how to get in it, what they give back to the CentOS Project, etc.) are here: http://www.centos.org/images/CentOS_CD_Vendors.pdf Here is the page that contains the current vendors: http://www.centos.org/vendors The CentOS project has looked at the vendors listed, and we highly recommend them if you want to buy CentOS CDs or DVDs. They give back to the CentOS Project for every CentOS CD/DVD they sell and we greatly appreciate it. If you are a CD/DVD vendor and are interested in being in our official program, see the above guide. If you are a CentOS user looking to buy CDs or DVDs, please use our official vendors to get all your pre-made CDs or DVDs (not just CentOS products) ... and if you are buying other products from them because they are official CentOS vendors, let them know that is the reason :) Thanks, Johnny Hughes

8 12

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss