- Discuss - lists.centos.org

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> 29 May '05

29 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> 29 May '05

29 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> 27 May '05

27 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

Still VPN
by Simone 27 May '05

27 May '05

Hi, still trying to understand one thing. I would definitely like to tell iptables to accept all packets coming from remote vpn only if they hit the $VIRTUALVPNINTERFACE. I tried -o ipsec0 but this is not working, looks like ipsec0 device doesn't exist or it is not recognized. I red on the Openswan users list, that Linux kernel 2.6 native ipsec don't create ipsec* interface (if I am not wrong this is something backported on kernel 2.4 RHEL3) just add a route to remote network through eth0, so if I want to ssh the vpn server on his internal ip from the other side of the vpn I need $IPTABLES -A INPUT -i *$EXTIF* -s $MYEXTNETWORK -d $INTIP -p tcp -m tcp --dport 22 -j ACCEPT and this is true for any other rule I would use ipsec0 in, I have to use $EXTIF. Even if I am going to set sshd to listen on a different port, I am a little worried this could harm my machine in any way. Comments are welcome Have a nice day Simone

2 2

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

27 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. Official CentOS CD/DVD Vendor Program (Johnny Hughes) 2. CESA-2005:413 Important CentOS 4 x86_64 ImageMagick - security update (Johnny Hughes) 3. CESA-2005:413 Important CentOS 4 i386 ImageMagick - security update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Thu, 26 May 2005 10:03:38 -0500 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] Official CentOS CD/DVD Vendor Program To: CentOS ML <centos(a)centos.org> Cc: centos-announce(a)centos.org Message-ID: <1117119818.1469.209.camel(a)myth.home.local> Content-Type: text/plain; charset="us-ascii" 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

1 0

bash 3.0 freezes
by jose luis faria 27 May '05

27 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

2 1

mouse issues in centos 4
by Mark Elam 27 May '05

27 May '05

Hi all, I am the IT department here at my office, I take care of everything pretty much. I chose Centos4 to deploy to my 50 workstations as it was the most compatible with the RHEL. We need the RHEL compatibility for support contract for different tools we use. So far it has been great. I have noticed a few issues since having 50 machines all exactly the same installed with centos 4. I have them clustered, and generally they work well. I often see random loss of the mouse cursor, which results in having to restart X. (really pisses the engineers off) I cannot seem to track down why this is happening. Nothing in any logs give any clue to what is happening. I thought it may have to do with VMware, as this is installed on 80% of these machines, and most of the time it happened when users were using Vmware. But recently I have seen the problem on machines without VMware running or even installed. I have also noticed a similar issue with a Wacom tablet. The user will be using it for some amount of time and then it stops working. At first it is assigned /dev/input/event3, the kernel module (wacom.o) is loaded and everything is fine. It will then stop working after a while, behind the scenes the system thinks the tablet has been unplugged and replugged, then assigns it /dev/input/event4. This of course doesn't work because in the xorg.conf file it is looking for it at event3. I am not sure if these are related or not. But the symptoms seem similar. Of course the wacom tablet is USB and the mouse issues are with PS/2 mice. So they may be unrelated. Any help would be appreciated. Thanks for your time. -- ############################################################################# Mark Elam Direct: 408.869.4029 IT Administrator Cell: 408.221.2689 Mobilygen Corporation melam(a)mobilygen.com #############################################################################

4 4

can't locate /etc/ini.d/mysqld file!
by israel.garcia＠cimex.com.cu 26 May '05

26 May '05

List, I installed my server and I want to start Mysql, but I can not find the file /etc/ini.d/mysqld .. [root@netflow ntop]# rpm -qa|grep mysql mysqlclient10-3.23.58-4.RHEL4.1 libdbi-dbd-mysql-0.6.5-10.RHEL4.1 mysql-4.1.10a-1.RHEL4.1 mysql-devel-4.1.10a-1.RHEL4.1 Am I missing some mysql rpm from Cds? regards. israel

6 6

Re: [Centos] Mounting Netware Volumes
by Nels Lindquist 26 May '05

26 May '05

On 24 Mar 2005 at 19:33, Paul wrote: > Well I dug though the RH's site and in the release notes for AS 3.95 ite > mentionsed that ncpfs has been deprecated. I can't find the release > notes for 4, but assume that they must have removed support in the > kernel along with the package. Try installing the kernel-unsupported module. Both ncpfs.o and ipx.o (should you still require it) are in that module, at least for CentOS 3.x--haven't looked at 4.0 yet myself. ---- Nels Lindquist <*> Information Systems Manager Morningstar Air Express Inc.

5 6

Re: Demonizing generic Linux issues as Fedora Core-only issues -- this thread has ended ...
by Bryan J. Smith <b.j.smith＠ieee.org> 26 May '05

26 May '05

From: Les Mikesell <lesmikesell(a)gmail.com> > If you believe that, you have to believe that Red Hat's programmers > are always better than the original upstream program author. How do you assert that? It has _nothing_ to do with my statement. You keep thinking there is this absolute "black/white" on why developers, vendors, etc... do this or that. There are reasons to upgrade to a newer version, and there are other reasons to backport. One is _not_ better than the other, or developers are not any more or less "smart" if they do. What I said was it is _harder_ for a distro to take the take to backport fixes and minimize impact to existing compatibility than to merely just rely and ship the latest version from a developer. There are reasons to upgrade (features, project support, etc...) and there are reason to backport (minimal impact, regression tested inter-package compatibility, etc...). There is no "black/white" on which one is "better." I just merely stated _why_ SLA guaranteed distros do the "backport," which is more difficult to accommodate because the project developers/support typically are just focused on the next version, and you have to replicate much of their knowledge/expertise internally (instead of just taking their next version with the patches/fixes). > 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. And _where_ did I say that? All I said was that _backporting_ is done to _minimize_ impact to the _entire_ set of _all_ packages that have been "regression tested" into a released, SLA guaranteed distro. That's what RHEL/SLES are about. At what point are you going to stop seeing what I saw as a black/white thing and realize that RHEL/SLES have _different_ foci than what you may want, and _that's_ why you're not getting what you want in stock CentOS? Is it really that hard to understand? When you understand that there is a pro/con to "staying current" v. "backports," and why distros like RHEL/SLES are typically "anal" to the "backport" side -- which seemingly conflicts with what you want, then we can talk. Until then, you seem to want to assert that what I'm saying is something about "better" when that is _not_ what I'm saying. I'm trying to explain "why" -- _not_ "better." End of thread. -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

About tunnels
by Maciej Żenczykowski 26 May '05

26 May '05

Hi folks, I have two CentOS 4 server I administrate doing routing and firewalling of two networks (one NATed and firewalled and the other one merely firewalled) and I'd like to build a tunnel to allow computers on the normal private network (and the firewall) to access the private IPs of computers behind the NAT/firewall. ie. ALPHA BETA 10.0.0.0/8 - CentOS4 - internet - CentOS4 - X.Y.Z.0/24 Private IPs Firewall Firewall Public IPs and NAT now the internet is intracity, within one provider and decently safe (6 hops), but still some sort of encryption would be nice... (otherwise I'd just use ip tunnel). How do I allow both BETA and X.Y.Z.0/24 to connect to the private IPs? Should I use CIPE? IPSEC? something else? any good howtos? Preferably something fast and reliable, doesn't need to be that easy to set up :) I'm basically looking for comments, I have looked around on google, and it seems there's _tons_ of options, but IPSEC seems to be winning out... am I correct in that assumption? Cheers, MaZe.

2 1

Re: [CentOS] Re: Official CentOS CD/DVD Vendor Program
by Bryan J. Smith <b.j.smith＠ieee.org> 26 May '05

26 May '05

From: Chris Mauritz <chrism(a)imntv.com> > If this was going to be a 100 unit/day or 1000 unit/day affair, I'd > agree with you, but it simply isn't. One or two people with cheap CD > and DVD duplicators, a paypal merchant account, and some time on their > hands is probably still overkill for the volume of sales, especially > when the product is available for free to anyone with a broadband > connection and a burner. Capacity planning. It's better to make only $500 and miss out on $1,000 than to have orders of $10,000 and only be able to service $2,500. > No, not really. What this says to me is that the CentOS team is doing > all the labour and some unecessary middleman is skimming the cream off > the top. Wouldn't you like to see the CentOS project receive more of a > share of the take for doing most of the work? I would. No, CentOS is focusing on what it does best and tapping others to do what they do best. But as someone else pointed out, form a CD/DVD duplication reseller and make a better offer and CentOS will likely take you up on it! > Spare me the condescending remarks. You knew what I meant. You mega-oversimplified, so no I did not. It's one thing to volunteer, that's great. In fact, at first, I thought that's what you were doing. But then you started to post all these things that just were like a "slap in face." Looking from the viewpoint of those CentOS managers who "put the time" and, more importantly, the _detail_ in on this, you showed you didn't have the faintest idea of what was involved. Again, as someone else pointed out, form a CD/DVD duplication reseller and make a better offer and CentOS will likely take you up on it! In fact, although there are the "minimal requirements" of $1/set under this plan, there's _nothing_ stopping different CD/DVD duplication resellers from playing a game of "one-up-manship" to gain the title of "highest proceeds" to CentOS. So instead of being so negative on what the leaders of this project have done so far, from a standpoint that was rather "shallow," why not be constructive and go ahead and offer to be a CD/DVD duplication reseller! The terms of the program are there -- go for it! You're open to it! ;-> > Looking back at the volume in the "demonizing" thread, I think I don't > have nearly the same amount of free time to spend jousting about > something so trivial in this mailing list with you. You're obviously a > very opinionated guy Oh, very, very much so. I am extremely opinionated. As far as "free time," I write for part of my living, and much of it comes from discussions on boards like this. As far as my "day job," it's largely 8x5, one advantage of being a traveling consultant that does more "architecture/design" than "analysis/support." > and often full of very sage advice to go along with the voluminous > opinion. Opinion to one is experience to another. I have _no_problem_ taking years to gain the trust of people. I think credentials don't mean squat, and trust comes from hearing people say things and finding out if they are applicable and useful over time. Again, even years. > But I found this reply to be more than a bit obnoxious. As did I your "volunteering." It's one thing to honestly "volunteer." It's another to belittle the initiative of the managers of this project who obviously took far more time, attention to detail and actually work to get the program going. There is no reason why you can't "volunteer" under this program by becoming a CD/DVD reseller yourself, under the same terms as any other. If you honestly believe you can do it better and cheaper than the current vendors who are signed up, then please do! We would all benefit if you did. That's all I was saying. And yes, I did berrate much of what you said for the reason I just explained. > The point of my message is that it seems like the CentOS guys > are doing all the heavy lifting and companies that (at least to me) > add very little value are taking the lion's share of the revenue for > these CD/DVD sets. As are arm-chair users who don't take the time to understand the details involved on things like this. I have taken what at least one other has said and re-gurgitated what you _can_ do under the program's terms that does _exactly_ what you want to do. So I suggest you consider becoming a CD/DVD duplicator/reseller yourself then. BTW, I might not be involved with CentOS, but I'm trying to do my (small/ too-small-to-even-speak-of) part on Fedora, which affects both RHEL and CentOS. And I can fully appreciate all of what the CentOS project does. -- Bryan J. Smith mailto:b.j.smith@ieee.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> 26 May '05

26 May '05

From: Les Mikesell <lesmikesell(a)gmail.com> > Thanks - as you probably know, the long-winded discussion isn't > really about CIPE specifically so much as the philosophy behind > bundling a few thousand things together and then trying to > please anyone with a blanket policy about maintaining backwards > compatibility vs bug fixes vs new features. You just can't please everyone. But it does help if people focus on "why" something is done -- the pros/cons versus doing something else -- instead of trying to assert what is "better" (as well as stopping to listen to someone and realize they are not asserting anything as "better," just trying to explain "why"). CentOS is based on RHEL. RHEL has its policies. > And while I realize that there may never be a good solution, I'll be > really happy if some new options fall out of it, like this being > included in a centos kernel-unsupported-something-or-other package. I think CentOS is optionally filling that gap between FC and RHEL quite well for those that want it. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss