- Discuss - lists.centos.org

Installing Dag's RPMs
by dan.trainor 01 Jul '05

01 Jul '05

Hello, all - I wanted to know your guys' success rate when installing and rebuilding RPMs in CentOS (specifically 4.0) that have come from Dag's Repositories (http://dag.wieers.com/packages/) I have noticed a number of these packages stalling at various points throughout an rpmbuild process, and I can't quite get it. It looks almost as if they were all built for RHEL4.0, but if CentOS is supposed to follow so close in RHEL's footsteps, why would this be a problem? I'll give Dag an email and see if he has anything to say about that. Once I get enough information, I'll just go ahead and hack up the RPMs so that they work properly on my systems - but I thought I'd ask beforehand, as to not re-invent the wheel. Thanks! -dant

7 11

Vote for CentOS - AGAIN :)
by Johnny Hughes 01 Jul '05

01 Jul '05

The preliminary round voting is completed in the "2005 Readers' Choice Awards" at Linux Journal. CentOS was nominated in the "distribution:" category along with 18 other Linux distros ... and we finished in the top 3 (along with Ubuntu and FedoraCore). Thanks to every one who voted for CentOS. I really did not expect that we would be on the final ballot, though I am honored that we are. Now, lets do it again, and shock the world :) Please go to Linux Journal and vote for CentOS !!! http://www.linuxjournal.com/article/8272

4 3

Compaq cpqfc driver
by bertchen＠biomaps.rutgers.edu 01 Jul '05

01 Jul '05

Hi, I am trying to compile kernel 2.6.9-11.EL from kernel-sourcecode, and need the Compaq cpqfc HBA driver. I see the code for the driver under drivers/scsi but when I do a "make menuconfig" I do not have the option to select it. Any ideas on how I can get it to show up? Thanks. --

2 1

RPM -e for single architecture
by David Thompson 01 Jul '05

01 Jul '05

Hi All: On architectures where multiple architectures for an RPM may be simultaneously installed (my example is x86_64), does anyone know the RPM magic to remove only one version? For instance, if I have the x86_64 and i386 versions of an RPM installed, how I can specify to only remove the i386 version? I have been unable to find a search phrase that turns up any useful information. Thanks. Dave Thompson UW-Madison (ftp|http|rsync)://mirror.cs.wisc.edu/pub/mirrors/linux/centos

3 2

Postfix / Postini question
by Barry Brimer 01 Jul '05

01 Jul '05

I have a mail server that handles several domains. One of these domains has decided to use Postini. For those not familiar with Postini, you set your MX records to use their mail servers. They filter mail, and deliver you only the clean virus/spam free mail. The idea is to only allow incoming mail from their mail servers so spammers are unable to send to your mail server directly. This is fairly simple to do with standard restriction classes for a dedicated mail server. I am not sure how to accomplish this on a shared mail server. Ideally I would like to instruct postfix to accept mail from anywhere for all domains except one domain (the one using Postini) and only allow mail destined for that specific domain to originate from Postini's mail servers. Any ideas would be greatly appreciated. Thanks, Barry

2 8

Mark Mulconry/SYR/Empire is out of the office.
by Mark.Mulconry＠empireblue.com 01 Jul '05

01 Jul '05

I will be out of the office starting 06/30/2005 and will not return until 07/06/2005. Please call Ken Milberg at 718-312-5070 or Steve Goldman at 718-312-5075 if you have a midrange issue. Otherwise, I will respond to your note upon my return. "WellChoice, Inc." made the following annotations on 07/01/05 08:03:17 ------------------------------------------------------------------------------ Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement

1 0

MPlayer problem
by Dominik Składanowski 01 Jul '05

01 Jul '05

Hi, I have installed MPlayer from dag repo on my CentOS 4.1 and codecs from MPlayer site. When I try to watch some movie file I get an error: ----------------------------------------------------------------------- Error opening/initializing the selected video_out (-vo) device. ----------------------------------------------------------------------- When I start MPlayer from console (gmplayer movie.mpeg &), there is: ----------------------------------------------------------------------- [dominik@localhost]$ gmplayer movie.mpeg & [1] 4102 [dominik@localhost]$ Using GNU internationalization Original domain: messages Original dirname: /usr/share/locale Current domain: mplayer Current dirname: /usr/share/locale MPlayer 1.0pre7-3.4.3 (C) 2000-2005 MPlayer Team CPU: Intel (Family: 6, Stepping: 6) Detected cache-line size is 64 bytes CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 vo: X11 running at 1024x768 with depth 24 and 32 bpp (":0.0" => local display) Linux RTC init error in ioctl (rtc_irqp_set 1024): Permission denied Try adding "echo 1024 > /proc/sys/dev/rtc/max-user-freq" to your system startup scripts. Opening joystick device /dev/input/js0 Can't open joystick device /dev/input/js0 : No such file or directory Can't init input joystick Setting up LIRC support... mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. libpng warning: Incomplete compressed datastream in iCCP chunk libpng warning: Profile size field missing from iCCP chunk libpng warning: Incomplete compressed datastream in iCCP chunk libpng warning: Profile size field missing from iCCP chunk libpng warning: Incomplete compressed datastream in iCCP chunk libpng warning: Profile size field missing from iCCP chunk libpng warning: Incomplete compressed datastream in iCCP chunk libpng warning: Profile size field missing from iCCP chunk libpng warning: Incomplete compressed datastream in iCCP chunk libpng warning: Profile size field missing from iCCP chunk libpng warning: Incomplete compressed datastream in iCCP chunk libpng warning: Profile size field missing from iCCP chunk libpng warning: Incomplete compressed datastream in iCCP chunk libpng warning: Profile size field missing from iCCP chunk libpng warning: Incomplete compressed datastream in iCCP chunk libpng warning: Profile size field missing from iCCP chunk libpng warning: Incomplete compressed datastream in iCCP chunk libpng warning: Profile size field missing from iCCP chunk libpng warning: Incomplete compressed datastream in iCCP chunk libpng warning: Profile size field missing from iCCP chunk libpng warning: Incomplete compressed datastream in iCCP chunk libpng warning: Profile size field missing from iCCP chunk ----------------------------------------------------------------------- Regards. -- ____________________________________________________________________ D o m i n i k S k ł a d a n o w s k i e-mail: dominik.skladanowski(a)ch.pw.edu.pl

2 2

CentOS newbie question - updates
by Chris (CentOS list) 01 Jul '05

01 Jul '05

Pardon the newbie question, but I thought I'd check with you guys here since I couldn't find the answer to this one on CentOS web site. I installed CentOS 3.4 (needed an equivalent of RHEL 3.4 for a very specific purpose - not interested in newer releases at this point) and downloaded all available up2date stuff. However, Apache is at v2.0.46, php is at 4.3.4, and so on - which are all quite old versions. I was under the impression that Red Hat rolls updates into existing versions and what may show as Apache 2.0.46, may indeed include updates and patches that are available in the most current release, 2.0.54..... Is this the case here, with CentOS, or should I be looking somewhere for actual rpms for Apache, php, and so on, to bring them up to 'latest' standards? If so - where?? up2date doesn't seem to be loading anything more current than what I mentioned above. If current patches are rolled into old versions, how does one distinguish between the "old" Apache 2.0.46 and "new/patched" 2.0.46?? Thanks, Chris

3 3

RE: [CentOS] [OT] SPARC platforms -- WAS: Hot swap CPU
by Bryan J. Smith <b.j.smith＠ieee.org> 01 Jul '05

01 Jul '05

From: Peter Arremann <loony(a)loonybin.org> > Sun will very willingly support all certified solutions (including EMC, netApp > or Hitachi for storage) as well as provide some support with uncertified > hardware for us... no issues... You work in a Fortune 5, they will do anything you tell them. I've been there before, and that is a very nice position to hold. But not when you work for a 50 engineer semiconductor startup. Sun really pissed us off regularly, so we stuck with Fujistu. > Yep - but how is that a benefit if your stuff works? NVidia is fabless i.e. > and you surely don't want to tell me they aren't good at what they do... > Having your own fab or not has very little influence... I was just saying that anyone who only wants to go to Sun because they are behind SPARC might consider Fujitsu, who actually fabs the chips. I've walked into many shops who have had issues with Sun's support and they never knew about Fujitsu as an option. That's all. > Sbus ???? Now you're talking US-I/II again - and that is absolutely > no match for an opteron box... Sorry, I meant NUMA/UPA -- my bad. > Based on what? The Implementation of Solaris for AMD dates back to SE b68 or > 69... that's mid 2004... Compare that to an OS that already ran on the > software emulator before silicon was even out there... Solaris was _also_ running on the x86-64 emulator too. ;-> AMD and Sun were in negotiations before the first Opteron came out. > Solaris 10 on AMD64 is definitely less stable that Centos 4 on the same v40z... > Running the same apps we had 0 crashes with Linux vs. 2 explained and > patched, 1 explained still unpatched and 1 unexplained crash on Solaris10... I meant the design: "given its experience on partial mesh interconnected systems" I thought by putting that in the _same_statement_ you'd see what I meant by "mature." Sorry, I assumed wrong. ;-> > Why would you need to run on sparc to produce a stable OS for an opteron box? Re-read my full statement ... 'Solaris is probably the most "mature" OS for Opteron 200/800 right now, given its experience on partial mesh interconnected systems.' -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 2

Good, concurrent I/O design in a server -- WAS: SPARC platforms
by Bryan J. Smith <b.j.smith＠ieee.org> 01 Jul '05

01 Jul '05

From: Peter Arremann <loony(a)loonybin.org> > When have I ever argued about that chipset design is better? :-) > Opteron is a great example that you can do it better... > Where did you even get the idea I am fixated on that??? http://lists.centos.org/pipermail/centos/2005-June/007341.html "<even more anal>Except the iommu, those are limitations of chipset, bus and whatever, not EM64T.</even more anal>" It very much has to do with how EM64T differs from AMD64. GARTs and I/O MMUs are even more capable than the Opteron. The issue has not yet been forced on Intel _because_ they still use a "single point of contention" design. All CPUs share one bus, all memory shares another, etc... into a "hub" (with exception of a proprietary NUMA solution, but all I/O still goes through that MCH "hub" on even those designs). http://lists.centos.org/pipermail/centos/2005-June/007662.html "Lets be realistic here... all I/O on one CPU only makes a difference for the most IO intensive apps (talking several hundret MB/sec or more)..." avoid boards that attach all memory to one cpu - unless they cost .. so much less that you can add another gig or two in memory... I/O on the other hand, while not ideal, will have much lesser effect on your performance." This is very much an issue. If I have an OS that has processor affinity for I/O, like Solaris, on a partial mesh platform like most SPARCs (non-"i" versions), or the newer Opteron (with multiple AMD8131/8132 or even the nVidia Pro 2200+2050 combo), then I'm going to be able to handle _concurrent_ I/O for independent (and sometimes even inter-dependent) processors. You think of "raw throughput" like 8.4GBps FSB can easily handle a 0.5GBps transfer, but what you don't realize that the 0.5GBps transfer holds up the _entire_ 8.4GBps bus for _just_ 0.5GBps. I.e., it takes 1 second for a 0.5GBps burst from the I/O, which means you do _not_ "get the other 7.9GBps" while it's tied up. Now on workstations, not too much of an issue (except for when you need all: video, NIC, storage). And maybe not a web server where your Internet pipe is only 100Mbps. But if you are a major communications carrier, or even just a heavily trumped file server, near-line server (with both in-band and out-of-band connects), possibly multiple DB, etc..., it really _does_ make a _lot_ of different. http://lists.centos.org/pipermail/centos/2005-June/007668.html "The board: Asus K8N-DL" A board recommendation you ahd to quickly backtracked on after a post by myself. You even said: http://lists.centos.org/pipermail/centos/2005-June/007674.html "But give me some credit - after all it was you who threw out the $300 price mark and besides that, the original poster said he had no real IO requirements ... Completely agreed - spend the extra money if you want to build a serious server... " Which made me scratch my head, because there were other $300 boards with 8-16x the PCI I/O capability because they had an AMD8131. And that's just to start. Which is what these threads are all about, how to build high performance servers, which may not be the same as for yourself. The hot-plug thread, that's just the total icing on the cake because you can't possibly see why someone might want an old NUMA/SBUS platform. You can assume I'm "wrong," or go out-of-your-way to talk about it. But that's _not_ while I'm posting. I'm posting so people are aware that there _are_ applications where you _might_ want such capabilities. Your continued insistence in asserting there is no application whatsoever is what *I* have a "problem" with. It's not about "wrong" -- it's about what people _might_ need. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: Hot swap CPU -- "build" is not a good CPU benchmark
by Bryan J. Smith <b.j.smith＠ieee.org> 01 Jul '05

01 Jul '05

From: Peter Arremann <loony(a)loonybin.org> > It is a valid benchmark though :-) compile speed is a actually a > good measure for any integer app that is small enough to run in > large cache... Image processing, oil companies for their simulations, > cad... they all act very similar to compile benchmark - if a compile > is twice as fast, a software image rendering is usually twice as fast > too :-) Now hold on. Did I just here you state that the ALU is used for CAD, and most scientific and engineering applications? Now I'll grant you that _some_ image processing _can_ be 32/64-bit integer transforms. But most high-quality, 64-bit precise transforms use the FPU. Not even Intel's SSE (on the P3/P4) is good when you need such precision. In fact, I don't know how many times I've caught errors because someone threw the "-O3" switch on "-march=p4". You do _not_ want to use SSE for scientific computing -- it's for when you want performance in exchange for loss of precision (let alone accuracy). > If you run databases or so, then yes, your comment is valid. Thank you. > Fair enough :-) And people say *I* go off on tangents. No offense, you were already in 2 posts before I even responded. If you look at other threads, I'm typically responding "OT" after 2-3 people have done so, and I largely see an inaccuracy, or I see a correction very much necessary. [ My posts on that thread _prior_ had just been to inform people that yes, there _were_ Xeon and Itanium systems with hot-swap capability. ] That's all I was trying to do in this case. Not "prove you wrong." -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 2

RE: [CentOS] [OT] SPARC platforms -- WAS: Hot swap CPU
by Bryan J. Smith <b.j.smith＠ieee.org> 01 Jul '05

01 Jul '05

From: Peter Arremann <loony(a)loonybin.org> > US-V has been canceled... By Sun, yes. They believe they will transition to Opteron sooner than they thought. All I said was that it had been "planned through" US-V, including the design work done. My bet is that the engineers had finished the core design, even if not fully optimized, and that's when they were canned. It's still an option in the back of Sun's pocket. [ I.e., the core design occurs _years_ before products become available. E.g., even the latest Opterons are based on the 1997 core design. And until the Pentium 4 came out (just a refit), the Pentium 3 was still based on the 1994 Pentium Pro core. ] Fujitsu has yet to weigh in and possibly pick up the design. They have been designing SPARC modules (better ones IMHO) for a long time. All it takes is 1 customer who needs SPARC binary compatibility. There was an equal battle over the Alpha 364, with OpenVMS the driver. Especially since OpenVMS/Itanium was _slower_ (than an Alpha 264 from 3 years earlier no less!). But once [quality] emulators became available, that killed it. I don't think you'll see the same with SPARC, but I could be wrong. If the need by just 1 major user is there, you can be sure Fujitsu will come out with a PRIMEPower upgrade that uses the design. I never said Sun would release an UltraSPARC V, I just said it has been planned (i.e., designed). Sun has made it known that as of right now, UltraSPARC IV is the "end-of-the-line" for Solaris, and given how Solaris is working on Opteron, I don't blame them. But HP is _still_ selling Alpha 264s because of OpenVMS. ;-> A platform they have tried to kill off again and again and again. > US-IIIi is up to 4 way... I _never_ said it wasn't. I just said the 1-2 ways are comparable to a typical PC design**. But after 2-way, it's much better to go with a US-III or US-IV, kinda like it's much better to go with an Opteron instead of a Xeon beyond 2-way**. ;-> -- Bryan **NOTE: This is a recurring theme. You seem fixated on the assumption that a system that uses a single-point-of-contention design (namely the Intel MCH aka "northbridge") approach would _always_ be faster. You seem to lack the understanding beyond the real design contraints of a partial mesh interconnect on a real system interconnect (and not just a peripheral interconnect hacked on as a system interconnect). You have degraded most of my commentary as a "that's a chipset issue." You seem to have a very limited understanding outside of the traditional PC CPU-to-memory or CPU-to-I/O via a "chipset" and that's why you keeping missing my points on Opteron, UltraSPARC, etc... Not to mention this thread was just about finding a solution with hot-swappable components. I left it at that _until_ you wanted to assert all sorts of things (using "builds" as a benchmark for servers, even computational ones). -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

Re: [CentOS] Re: Hot swap CPU -- "build" is not a good CPU benchmark
by Bryan J. Smith <b.j.smith＠ieee.org> 01 Jul '05

01 Jul '05

From: Chris Mauritz <chrism(a)imntv.com> > <snipped> > Oy....I'm terribly sorry. Moderator, please delete my previous > message. It was supposed to be a private message to Peter. Bryan, > please accept my apology. It wasn't my intention to riducule you in > public. honest injun.... > <blush> > Must drink less coffee.... No apology required, everyone is entitled to their opinion. As far as this "thread," I think it's rather pathetic that I'm the only one being singled out when someone like Peter can take anyone's suggestion and just rip it out-of-context. Makes me wonder if Bruno is hesitant to post any suggestion again ... http://lists.centos.org/pipermail/centos/2005-June/007936.html http://lists.centos.org/pipermail/centos/2005-June/007937.html http://lists.centos.org/pipermail/centos/2005-June/007956.html http://lists.centos.org/pipermail/centos/2005-June/007974.html From: Peter Arremann > That is exactly what I said before you trimmed it off :-) No, you said ... "Compiles aren't a great benchmark for a box since its 100% cpu and neglects memory or disk performance but I had the numbers handy for that :-)" And you continue to assert that it _is_ a valid benchmark for computationally intensive server applications in your countless other posts. "Builds" _do_ often take memory and disk into account (especially memory latency, which _can_ actually be worse on P4 DDR2 platforms than some old EDO platforms ;-). I was just trying to "open your mind" to the fact that there _are_ applications where an 8-way, NUMA/SBUS solution _might_ just be usable. Maybe not for you, but for some applications, especially at the price point. That's _all_ I was saying. I noted others were also trying to give statements that were good reasons. You may think they are not solutions worth the power, but not all of us agree with you. That's _all_. -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

RE: [CentOS] [OT] SPARC platforms -- WAS: Hot swap CPU
by Peter Arremann 30 Jun '05

30 Jun '05

Bryan J. Smith b.j.smith at ieee.org wrote: >Not only that, but people forget that SPARC is not sold by just Sun. >SPARC is an IEEE standard licensed under "fair and non-discriminatory" >terms. The SPARC ISA and most architectural details are freely >available. Yep - but what is your point with bringing that up? >The _majority_ of my Solaris/SPARC experience in more recent years has >been on Fujitsu/HAL solutions. I not only prefer the Fujitsu/HAL >products over Sun, I not only prefer Fujitsu's "openness" to support >SPARC solutions with non-Fijitsu networking, storage, etc... attached >(whereas Sun likes 100% Sun equipment from a support perspective) Sun will very willingly support all certified solutions (including EMC, netApp or Hitachi for storage) as well as provide some support with uncertified hardware for us... no issues... > but >Fujitsu has taken over packaging design and fabrication of SPARCs for >Sun itself. I.e., Sun used to design their own SPARC packages and TI >was their foundary, but Fujitsu has almost always designed their own >SPARC modules/ daughtercards, and fabbed them themselves. Yep - but how is that a benefit if your stuff works? NVidia is fabless i.e. and you surely don't want to tell me they aren't good at what they do... Having your own fab or not has very little influence... >Sun even >sells Fujitsu PRIMEPOWER products on their site now. They don't - they had info for it a while ago but even that has been removed. >sun4u (UltraSPARC) is planned through UltraSPARC V US-V has been canceled... >, with UltraSPARC III >(and lightweight IIIi) and IV available today. The 1-2 way UltraSPARC >IIIi is more comparable to the cost/design of the Pentium III and IV, as >well as the Xeon. US-IIIi is up to 4 way... >The UltraSPARC III and IV, and their platform, are >_clearly_superior_ to even OEM proprietary NUMA Xeon implementations Yep >(you really have to start looking at proprietary IA-64/Itanium II to get >a good comparison). > >But the design of the Opteron is why Sun is moving forth with it's move. >The typical UltraSPARC NUMA/SBUS server architecture really doesn't >offer much over Opteron in a 2-8 way. Sbus ???? Now you're talking US-I/II again - and that is absolutely no match for an opteron box... >And to be honest, Solaris is >probably the most "mature" OS for Opteron 200/800 right now, given its >experience on partial mesh interconnected systems. Based on what? The Implementation of Solaris for AMD dates back to SE b68 or 69... that's mid 2004... Compare that to an OS that already ran on the software emulator before silicon was even out there... Solaris 10 on AMD64 is definitely less stable that Centos 4 on the same v40z... Running the same apps we had 0 crashes with Linux vs. 2 explained and patched, 1 explained still unpatched and 1 unexplained crash on Solaris10... >Linux will get >there, but it takes time and experience on a platform like SPARC >(Windows never well, not even thanx to SGI's past, although brief, >donations). Why would you need to run on sparc to produce a stable OS for an opteron box? Peter.

1 0

What is the latest STABLE release?
by M.C. Luigi Palmiero 30 Jun '05

30 Jun '05

Hi all, i want to install CentOS on my server in production. What is the latest stable release? Thanks Luigi

3 2

Re: Hot swap CPU -- "build" is not a good CPU benchmark
by Bryan J. Smith <b.j.smith＠ieee.org> 30 Jun '05

30 Jun '05

From: Peter Arremann <loony(a)loonybin.org> > Compiles aren't a great benchmark for a box since its 100% cpu and > neglects memory or disk performance but I had the numbers handy > for that :-) BTW, it is 100% ALU and a major strain on the ALU LOAD. In other words, it's not a good benchmark for even CPU. That's why the 3-issue ALU in the Nx586 on-ward blows the 2-issue ALU in PPro on-ward (especially the P4) to crap. But that's all besides the point because it has _0_ to do with server performance period, even computationally intensive. -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 3

Re: [CentOS] Hot swap CPU
by Bryan J. Smith <b.j.smith＠ieee.org> 30 Jun '05

30 Jun '05

From: Peter Arremann <loony(a)loonybin.org> > Actually that was exactly the point. The email I responded to was > mentioning ancient US-I/II frames as a solution for the hotswap issue. My > point was that for the same cost I can get a 8way E4500/400/4MB or a nice > P4 PC... > From the speed perspective you'll be hard pressed to find an app > that is faster on the sun and the age of the E4500 negates any advantage > it used to have in reliability. The E4500 doesn't even have redundant > power :-) Be careful with your continued assertions. I/O on the P4 (and the PC platform) _sucks_ compared to many of these solutions. PCIe is _not_ the "holy grail" for a platform that has some severe bottleneck issues in its design, let alone when we're talking a single processor versus a partial mesh system with a _real_ "system interconnect." ;-> Reality: Even a 200MHz, non-superscalar microcontroller prototype boards can handle 500MBps+ of storage I/O, but many PC mainboard I/O designs can_not_. ;-> > I was giving the E4500 as a comparison because it costs the same. > Unfortunately we got apps here that outgrow F15K frames - performance > can't ever be good enough. > But even if you get a V440 (from integer processing the currently fastest > cpu Sun has to offer) you're still so much slower when doing compiles. Once again, I will re-iterate, build times are _not_ a good "server benchmark" at all. If they were, then I don't know why _anyone_ would buy Intel -- AMD _roasts_ P4 _over_ 2:1 MHz for MHz. > Anyway, point I was trying to make is that if anyone points a US-II based > frame today they are mistaken about its performance and reliability. I don't think people were asserting "build" time at all, let alone performance in general. But there are some advantages to deploying even older SPARC platforms in some areas. It's obvious your experience has largely been in "build" or "dynamic web app" benchmarks. Please be considerate that it's not the _only_ "performance" consideration out there. ;-> > Just the disks in D1000 trays are so much of a headache that you > wouldn't believe it. And Sun doesn't support booting of EMC on the > smaller frames - so you need some local attached storage... There are options around that in various hardware selections. But yes, Sun does have some stock SAN limitations. -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

Re: Directory Server for CentOS 4.1
by Bryan J. Smith <b.j.smith＠ieee.org> 30 Jun '05

30 Jun '05

From: alex(a)milivojevic.org > Nope. On Windows during login users usually selects domain part from > drop-down box (yes, you can type it too if you want). [ Not that this matters, but ... ] First off, that's _only_ for the GINA portion, and not always. Unless you take the time to distribute all domains either at the server or client, you won't always see all domains. Secondly, inside of various apps, credentials are not always passed correctly, which requires the nomenclature. Of course, the application can save the username and other settings in the application itself. E.g., try to login to IIS' FTP server when you have multiple domains. ;-> You'll have to pass the DOMAIN/user nomenclature in many cases. > And usually whatever domain is selected in that drop-down box by > default is the correct one for the owner of the particular PC. [ Again, not that it matters, but ... ] And the same can be said for applications on a UNIX system with a particular user's login, and their configuration files (and mounted home directory -- you are automounting home directories, yes?). I'm kinda scratching my head here. I can setup a user's IMAP credentials in various applications (both Windows and UNIX/Linux) to remember their username for the setup, so that is avoided. I don't see the difference between multiple REALMs and multiple NTDOM/ADSDOMs. If you properly configure the login/apps to remember the user's domain, then it's not an issue. > Anyhow, historically real Unix accounts were used on email servers, > so after switch to virtual accounts requirement was that users don't > notice the change. Higher authority decided that it would be too > complicated for non-technical population to swtich from "username" > to "username@REALM". [ Lastly, also mot that it matters, but ... ] What are you using multiple REALMs for anyway if everyone was under a "real UNIX" account before? NOW WHAT MATTERS ... _Please_ read up on how NsDS works. It's _extremely_ "enterprise class" and much more capable than OpenLDAP, which was more of an "open framework" of different capabilities (not always well integrated). http://www.redhat.com/docs/manuals/dir-server/ag/ssl.htm "Netscape Directory Server Administrators Guide Chapter 11 ... Configuring Kerberos Kerberos v5 must be deployed on your system to utilize the GSS-API mechanism for SASL authentication ... ... Realms A realm is a set of users and the authentication methods for those users to access the realm. A realm resembles a fully-qualified domain name and can be distributed across either a single server or a single domain across multiple machines. A single server instance can also support multiple realms. Realms are used by the server to associate the DN of the client in the following form, which looks like an LDAP URL: uid=<user_name/[server_instance]>,cn=realm,cn=mechanism,cn=auth " Is that more of what you were looking for? How to put the Realm in the uid? -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

Re: [CentOS] Directory Server for CentOS 4.1
by Bryan J. Smith <b.j.smith＠ieee.org> 30 Jun '05

30 Jun '05

From: alex(a)milivojevic.org > As I said, there are multiple domains, so IMAP server can't simply slap > @REALM to the end of user supplied username and do the check directly. Ahhh, a key point I missed. My apologies. > For historical reasons, IMAP server uses flat userspace (while in reality it > is more tree-like). And nope, having users type the @REALM part during > login is not acceptable solution (most of them don't even know what > @REALM should be, nor should they be bothered with such details). Hmmm, most usrs have to do DOMAIN/user for Windows DCs so I don't know how "unacceptable" is is to require "@REALM," but that's just my view. -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

Re: Software RAID muck up
by Bryan J. Smith <b.j.smith＠ieee.org> 30 Jun '05

30 Jun '05

From: Dan Pritts <danno(a)internet2.edu> > I just looked at that a few weeks ago - it doesn't seem to have reached > critical mass. Would sure be nice. Oh, it _has_ reached "critical mass" among a lot of embedded and application-specific capabilities. But like most distribution channel issues, you can be sure that AMI, Phoenix and others are fighting it quite hard. Even Intel's so-called "open" initiatives are still in the "tight knit group" of BIOS vendors. And Microsoft would love nothing more than to make it impossible to access system configuration outside of Windows, Windows systems unable to boot be damned. Most hardware vendors are _also_ more than happy to see this, because they can start tying hardware to specific Windows versions. Hence the entire "superstore" hardware/distribution issue that will always plague Linux and partnerships to create Linux drivers. > heck, i'd settle for getting serial-bios capability out of commodity > motherboards. "server" systems (and maybe high-end "workstation" > motherboards) have it but things like the via c3 boxes i have posted > about before generally don't. I'm waiting to see what Apple cooks up. They won't share it, but it will possibly create enough stir to change the industry in general. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: [CentOS] Re: Installing Dag's RPMs
by Bryan J. Smith <b.j.smith＠ieee.org> 30 Jun '05

30 Jun '05

From: alex(a)milivojevic.org > Which is the smallest problem with Sun'S Java. They don't do "alternatives" > either (you have to set them up manually, if you want to have GCC's Java in > parallel). And Sun's license doesn't allow anybody to repackage it so that it > blends with the rest of the particular distribution (basically, fixing the > problem you had and the alternatives issue). Yeah, that's the #1 issue most everyone has with Java. Sun allows the JRE to be bundled with Solaris and Windows applications, but not Linux. And you have to be the size of Red Hat or SuSE to negotiate otherwise, and that's just for retail distributions. If they SCSL/whatever it into an MPL-like, that should change though. Java seems to be the _only_ thing Sun hasn't GPL'd or at least MPL'd. While I can understand some aspects of their viewpoint, the explicit denial of redistribution on Linux is just entirely inexecusible when they allow it to be bundled with Solaris and Windows applications (let alone the OSes). -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Problem with yum/kdevelop?
by Joshua Weage 30 Jun '05

30 Jun '05

I've produced a custom rpm for kdevelop 3.0.1. However, yum reinstalls the original CentOS rpm when I do 'yum update'. Yum shows the following for kdevelop: >yum list kdevelop -------------------------------------------------------------------------------- kdevelop i386 8:2.1.5-12.1 base Looking in Installed Packages: Name Arch Version Repo -------------------------------------------------------------------------------- kdevelop i386 3.0.1-1 db If I then to a "yum update", it will prompt me to install 2.1.5 over the top of 3.0.1, as it is reporting the version as "8:2.1.5-12.1". The header for kdevelop is named: kdevelop-8-2.1.5-12.1.i386.hdr Can anyone tell me why the header for kdevelop has a leading 8 rather than 0? Thanks, Josh ____________________________________________________ Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com

3 2

Hot swap CPU
by Peter Arremann 30 Jun '05

30 Jun '05

Sorry to disrupt the thread - my mail reader chewed up half my inbox today... alex(a)milivojevic.org wrote: > E4500 is discontinued for some time now. It is rather old machine, much > older that the above mentioned P4. I doubt that Peter's intention was to > compare speed of Sun's server in general with the speed of > latest-and-greates P4 systems. I hope that he simply forgot to mention > how much older that E4500 is than the P4 box. Actually that was exactly the point. The email I responded to was mentioning ancient US-I/II frames as a solution for the hotswap issue. My point was that for the same cost I can get a 8way E4500/400/4MB or a nice P4 PC... From the speed perspective you'll be hard pressed to find an app that is faster on the sun and the age of the E4500 negates any advantage it used to have in reliability. The E4500 doesn't even have redundant power :-) <snip> > People that buy E4500 nowdays are either buying them for spare parts, or > they simply want redundant box exactly the same as the old box they > already have. Or people that simply need some Sparc hardware around, > but don't want to spend money on current line of Sun's servers and don't > care if the system is slow as long as it does the job (my guess is > Peter's company falls into this category, from what he wrote, otherwise > they would be running their Sparc builds on something more recent) I was giving the E4500 as a comparison because it costs the same. Unfortunately we got apps here that outgrow F15K frames - performance can't ever be good enough. But even if you get a V440 (from integer processing the currently fastest cpu Sun has to offer) you're still so much slower when doing compiles. A build that can be done on a single cpu linux box (3.2Ghz P4) is a fraction of the time of that V440 time... Compiles aren't a great benchmark for a box since its 100% cpu and neglects memory or disk performance but I had the numbers handy for that :-) Anyway, point I was trying to make is that if anyone points a US-II based frame today they are mistaken about its performance and reliability. Just the disks in D1000 trays are so much of a headache that you wouldn't believe it. And Sun doesn't support booting of EMC on the smaller frames - so you need some local attached storage... Peter.

1 0

Re: [CentOS] Directory Server for CentOS 4.1
by Bryan J. Smith <b.j.smith＠ieee.org> 30 Jun '05

30 Jun '05

From: alex(a)milivojevic.org > Hm, sounds interesting alternative to OpenLDAP. Actually, OpenLDAP started as a GPL alternative to NsDS as far as I am concerned. @-p > It says it supports SASL authentication and MD5 password hashes. > Does it also support placing a pointer for SASL where to check the > password into password attribute (instead of placing actual password > in it)? The SASL capability can interface with any GSSAPI solution IIRC. I _know_ that includes a _real_ KDC. > What I'm talking about is putting something like "{SASL}user@REALM" > intopassword attribute. OpenLDAP would than use saslauthd to check > the password(passing it user@REALM and whatever user entered as > password). In my case saslauthd is configured to check passwords > using kerberos5 backend. > Basically, directory server does not store any passwords, passwords > are stored in Kerberos database That's _exactly_ how most enterprise have been running NsDS since the '90s, using Kerberos as the authentication end. > (and I have users spread across several distinctive Kerberos realms > (some Unix based, some Windows AD), to make things even more > interesting). The Florida Institute of Technology created a Windows side service called "acctsync" so a segmented ADS tree could pull/push password and other, basic meta-data changes. This was because more and more ADS-only Windows applications were being implemented, but they still wanted to keep NsDS as their "root" tree (where _all_ users were _always_ created/ removed first). Translation: FIT's AcctSync turned ADS into NsDS' bitch. This was _before_ MS Kerberos was even published, let alone any such interoperability, hence FIT's need and eventual solution. It doesn't use network services and protocols, but is a service that runs on the Windows DCs themselves. The Windows DCs pull/push from/to the NsDS LDAP stores. http://acctsync.sourceforge.net/ [ Side Note: FIT actually didn't use SASL to Kerberos for their password store, but hashes in the directory. But it would have worked for the SASL/Kerberos options too IIRC. ] > (having that functionality is "must-have" for me, before even thinking > about downloading FDS to try it out). Trust me, NsDS has been supporting these details for a _long_ time. Some of it has been with 3rd party software, but others have been BSD, GPL and other projects built around NsDS, even if it wasn't GPL before Red Hat. -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

an rpm howto question
by Nielsen, Steve 30 Jun '05

30 Jun '05

I am in a precarious spot.... I run centos 4.0. I upgraded my mod_perl RPM to mod_perl 2.0.1. CGI.pm 3.10 (3.05 comes with centos 4.0) fixes some namespace issues with mod_perl vs mod_perl 2.0.1. I need to upgrade to it to 3.10. Yet that file belongs to the perl rpm that comes with centos. What do people generally do in this type of situation? Do I need to compile a new perl just to upgrade CGI.pm to a newer version? Can I package the new CGI and install it ? If I do CGI.pm will be owned by 2 packages (the one I package and perl). Thoughts , ideas? Steve

3 2

RE: [CentOS] rpm spec file for "fakejava"
by Ash Christopher 30 Jun '05

30 Jun '05

Instead of faking the RPM database into thinking Java is installed, you could try installing Java via rpm. Check it out here: http://www.jpackage.org/rpm.php?id=2663 You basically download the Java binary, manually copy it into /usr/src/redhat/SOURCES and then perform an rpmbuild to make the actual rpm. -----Original Message----- From: centos-bounces(a)centos.org [mailto:centos-bounces@centos.org] On Behalf Of Dan Pritts Sent: Thursday, June 30, 2005 10:00 AM To: Robert Hanson Cc: centos(a)centos.org Subject: [CentOS] rpm spec file for "fakejava" Interestingly, i just posted to the list a similar SPEC file. look at the thread on CGI.pm. I've attached my spec file for "fakejava" as well. It was a lot of trial and error to make it work. None of the documentation I could find was for modern versions of RPM, and IIRC the documentation i did find for older versions was incorrect somehow. I think I had to specify a source package, but i didn't have to actually do anything with it. I'm cc'ing the list on this so it makes it into the archives. On Thu, Jun 30, 2005 at 08:53:06AM -0700, Robert Hanson wrote: > off list greetings! > > would you please share that expertise you just learned with me individually > or with the whole list please? > > that is, if it doesnt take you too long can you detail and share your > creation and how to use it etc that i may learn from it? > > thanks! > > - rh > > -----Original Message----- > From: centos-bounces(a)centos.org [mailto:centos-bounces@centos.org] On Behalf > Of Dan Pritts > Sent: Thursday, June 30, 2005 8:33 AM > To: CentOS mailing list > Subject: Re: [CentOS] Re: Installing Dag's RPMs > > On Tue, Jun 28, 2005 at 03:11:38PM -0700, dan.trainor wrote: > > cryptic nature. I've been doing a LOT of RPM exploration over the past > > few weeks, and found the process of actually creating an RPM to be a > > somewhat cumbersome and at times poorly documented system. I don't want > > Tell it, brother! > > I spent three hours figuring out how to write a spec file to create > an RPM that doesn't do anything other than tell the RPM database > that such and such a capability is installed (some java app didn't > think i have "java" since sun's rpms didn't tell RPM it was there). > > ugh. > > danno > -- > dan pritts - systems administrator - internet2 > 734/352-4953 office 734/834-7224 mobile > _______________________________________________ > CentOS mailing list > CentOS(a)centos.org > http://lists.centos.org/mailman/listinfo/centos > danno -- dan pritts - systems administrator - internet2 734/352-4953 office 734/834-7224 mobile

2 1

4.1 beta for Alpha platform
by User Lists 30 Jun '05

30 Jun '05

Hi all, I have tried to install this beta release on PWS 433 au but I can not boot /kernels/vmlinux.gz image. Error is: "unsupported compressed image". Is not posible to install under this Alpha model?? Thank you. __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.espanol.yahoo.com/

4 7

rpm spec file for "fakejava"
by Dan Pritts 30 Jun '05

30 Jun '05

Interestingly, i just posted to the list a similar SPEC file. look at the thread on CGI.pm. I've attached my spec file for "fakejava" as well. It was a lot of trial and error to make it work. None of the documentation I could find was for modern versions of RPM, and IIRC the documentation i did find for older versions was incorrect somehow. I think I had to specify a source package, but i didn't have to actually do anything with it. I'm cc'ing the list on this so it makes it into the archives. On Thu, Jun 30, 2005 at 08:53:06AM -0700, Robert Hanson wrote: > off list greetings! > > would you please share that expertise you just learned with me individually > or with the whole list please? > > that is, if it doesnt take you too long can you detail and share your > creation and how to use it etc that i may learn from it? > > thanks! > > - rh > > -----Original Message----- > From: centos-bounces(a)centos.org [mailto:centos-bounces@centos.org] On Behalf > Of Dan Pritts > Sent: Thursday, June 30, 2005 8:33 AM > To: CentOS mailing list > Subject: Re: [CentOS] Re: Installing Dag's RPMs > > On Tue, Jun 28, 2005 at 03:11:38PM -0700, dan.trainor wrote: > > cryptic nature. I've been doing a LOT of RPM exploration over the past > > few weeks, and found the process of actually creating an RPM to be a > > somewhat cumbersome and at times poorly documented system. I don't want > > Tell it, brother! > > I spent three hours figuring out how to write a spec file to create > an RPM that doesn't do anything other than tell the RPM database > that such and such a capability is installed (some java app didn't > think i have "java" since sun's rpms didn't tell RPM it was there). > > ugh. > > danno > -- > dan pritts - systems administrator - internet2 > 734/352-4953 office 734/834-7224 mobile > _______________________________________________ > CentOS mailing list > CentOS(a)centos.org > http://lists.centos.org/mailman/listinfo/centos > danno -- dan pritts - systems administrator - internet2 734/352-4953 office 734/834-7224 mobile

1 0

Software RAID muck up
by Lee W 30 Jun '05

30 Jun '05

Hi, I hope someone can help. Just started to play with software RAID on Centos 3.5 and was trying to simulate a faulty drive by using the -f switch on mdadm to mark the partition (drive) as faulty and I then I removed and readded the drive, which quit happily rebuilt according the /proc/mdstat and the output from the --detail switch of mdadm. After all this mucking around I shutdown the system and tried to restart it in the morning but the system now won't boot, it gets as far as "GRUB loading" and just stops I have hard reset to get it to reboot. I have rebooted using the install CD in rescue mode and I can see that all the arrays are setup quite happily (all RAID 1's if it matters) and mdstat reports the status as "dirty,no-errors". Is that status normal? all the how-tos I've seen about software RAID show this as the status, so I have kind of assumed that is okay. Given that all the data is readable from the arrays, I'm guessing that I had to do something to GRUB prior after rebuilding the arrays and before shutting down the system. Can anyone help fill in the gap in my knowledge as to what I should have done? Thanks for any help. Regards Lee

9 15

IMP 4
by Peter Farrow 30 Jun '05

30 Jun '05

Dear All, anyone installed IMP4 on Centos 4.1 yet, http://www.horde.org/imp/4.0/ if so what problems did you have, I have a webmail server I am going to upgrade to Centos 4.1 and Imp 4 from its current centos 3.3 implementation and imp3 This is going to be a labour intensive manual task, and I wondered if anyone else out there was mad enough to have tried it already.... Failing that just advice on IMP4 installation on Centos 4.1 will be fine :-) P.

6 8

RE: [CentOS] 4.1 beta for Alpha platform
by Mark A. Lewis 30 Jun '05

30 Jun '05

It's not FTP, but it's more accesable than torrents. Disc 3 is still uploading, it should be ~630 meg when done. FileZilla is saying 5hrs. http://www.kd5zlu.net/CentOS/Alpha/ > -----Original Message----- > From: centos-bounces(a)centos.org > [mailto:centos-bounces@centos.org] On Behalf Of Mark A. Lewis > Sent: Wednesday, June 29, 2005 3:00 PM > To: CentOS mailing list > Subject: RE: [CentOS] 4.1 beta for Alpha platform > > Downloading it now. Good speeds ~500k. Will post back once I > have uploaded it. > > > -----Original Message----- > > From: centos-bounces(a)centos.org > > [mailto:centos-bounces@centos.org] On Behalf Of William Warren > > Sent: Wednesday, June 29, 2005 2:46 PM > > To: CentOS mailing list > > Subject: Re: [CentOS] 4.1 beta for Alpha platform > > > > http://lists.centos.org/pipermail/centos-announce/2005-June/00 > > 0400.html > > > > Mark A. Lewis wrote: > > > > > If someone can send me a link to the torrent, I can put it > > on an FTP. > > > I am anxious to try it too. > > > > > > > > >>-----Original Message----- > > >>From: centos-bounces(a)centos.org > > >>[mailto:centos-bounces@centos.org] On Behalf Of Lamar Owen > > >>Sent: Wednesday, June 29, 2005 2:29 PM > > >>To: CentOS mailing list > > >>Subject: Re: [CentOS] 4.1 beta for Alpha platform > > >> > > >> > > >> > > >>>Hi all, > > >>> > > >>> I have tried to install this beta release on PWS 433 au > > >> > > >>but I can not > > >> > > >>>boot /kernels/vmlinux.gz image. Error > > >>>is: "unsupported compressed image". Is not posible to > > >> > > >>install under > > >> > > >>>this Alpha model?? > > >> > > >>Does anyone have an ftpable mirror of this yet? Bittorrent > > is great, > > >>except when you don't allow it. While I could loophole my > > own policy, > > >>I shouldn't. > > >>-- > > >>Lamar Owen > > >>Director of Information Technology > > >>Pisgah Astronomical Research Institute > > >>1 PARI Drive > > >>Rosman, NC 28772 > > >>(828)862-5554 > > >>www.pari.edu > > >>_______________________________________________ > > >>CentOS mailing list > > >>CentOS(a)centos.org > > >>http://lists.centos.org/mailman/listinfo/centos > > >> > > >>-- > > >>This message has been scanned for viruses and dangerous > content by > > >>MailScanner, and is believed to be clean. > > >> > > >> > > > > > > > > > > -- > > 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 > > > > -- > > This message has been scanned for viruses and dangerous content by > > MailScanner, and is believed to be clean. > > > > > > -- > This message has been scanned for viruses and dangerous > content by MailScanner, and is believed to be clean. > > _______________________________________________ > CentOS mailing list > CentOS(a)centos.org > http://lists.centos.org/mailman/listinfo/centos > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

2 1

Mark Mulconry/SYR/Empire is out of the office.
by Mark.Mulconry＠empireblue.com 30 Jun '05

30 Jun '05

I will be out of the office starting 06/30/2005 and will not return until 07/06/2005. Please call Ken Milberg at 718-312-5070 or Steve Goldman at 718-312-5075 if you have a midrange issue. Otherwise, I will respond to your note upon my return. "WellChoice, Inc." made the following annotations on 06/30/05 08:02:11 ------------------------------------------------------------------------------ Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement

1 0

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

30 Jun '05

Send CentOS-announce mailing list submissions to centos-announce(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. CESA-2005:535 Moderate CentOS 3 i386 sudo - security update (Tru Huynh) 2. CESA-2005:535 Moderate CentOS 3 x86_64 sudo - security update (Tru Huynh) 3. CESA-2005:535 Moderate CentOS 4 ia64 sudo - security update (Pasi Pirhonen) 4. CESA-2005:535 Moderate CentOS 3 ia64 sudo - security update (Pasi Pirhonen) 5. CESA-2005:535 Moderate CentOS 3 s390(x) sudo - security update (Pasi Pirhonen) 6. CESA-2005:535 Moderate CentOS 4 x86_64 sudo - security update (Johnny Hughes) 7. CESA-2005:535 Moderate CentOS 4 xi386 sudo - security update (Johnny Hughes) 8. CESA-2005:535-04: Moderate CentOS 2 i386 sudo security update (John Newbigin) ---------------------------------------------------------------------- Message: 1 Date: Wed, 29 Jun 2005 18:58:32 +0200 From: Tru Huynh <tru(a)centos.org> Subject: [CentOS-announce] CESA-2005:535 Moderate CentOS 3 i386 sudo - security update To: centos-announce(a)centos.org Message-ID: <20050629165832.GA21863(a)sillage.bis.pasteur.fr> Content-Type: text/plain; charset="us-ascii" CentOS Errata and Security Advisory CESA-2005:535 sudo security update for CentOS 3 i386: https://rhn.redhat.com/errata/RHSA-2005-535.html The following updated file has been uploaded and is currently syncing to the mirrors: i386: updates/i386/RPMS/sudo-1.6.7p5-1.1.i386.rpm source: updates/SRPMS/sudo-1.6.7p5-1.1.src.rpm You may update your CentOS-3 i386 installations by running the command: yum update sudo Tru -- Tru Huynh (CentOS-3 i386/x86_64 Package Maintenance) http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xBEFA581B

1 0

nfs install : kernel panic
by Rénald Legendre 30 Jun '05

30 Jun '05

hello, i just downloaded centos 4.1 dvd iso through bittorrent, compared it with the md5 checksum (result ok), and burned the 5Mb iso boot file, in order to make a nfs networked install. my nfs server is on 192.168.0.6 and i did a mount of the iso to /mnt/centos, then inserted the boot cd in the to-be-installed server, did a "ok, your ip is 192.168.0.7, the nfs server is 192.168.0.6, and the directory is /mnt/centos/", but there is a kernel panic... can someone tell me if there is something wrong with this please ? i already tried ftp & http installs, but it tells me "ftp://192.168.0.6//mnt/centos/(...)/net2(...).sys don't exist" (remark the two // after the ip address, both in ftp & http installs. i tried to do mnt/centos but the installer told me "no!"). thanks, legendre renald

2 1

Re: autofs handling of nis maps - Centos4
by Bryan J. Smith <b.j.smith＠ieee.org> 29 Jun '05

29 Jun '05

From: "Hilliard, Jay" <Jay.Hilliard(a)disney.com> > I have the following nis map (auto.facvs) > * -vers=3 &:/disk1 > Which allows hosts that have /disk1 exported to be mounted to > /facvs/$hostname > It works fine, but on Centos4, it allows me to > cd /facvs/foo (where foo isn't a real host out there) > I find it has mounted my local /disk1 as /facvs/foo. It seems to be > ignoring the key in the map pertaining to the host if it's not a valid host. > Does anyone know of a way to make it restrictive again and fail the > mount if the hostname match isn't valid? Hmmm, interesting. Normally if you don't have anything front of the ":", it assumes localhost. In your case, are you saying this didn't happen before when you have it an invalid hostname? Also, are you sure it's not DNS? Sometimes your local resolver automatically appends domainnames in your search. And some admins setup a "default" IN A record to be 127.0.0.1 on any lookup for a domain that doesn't properly resolve. I know that's kinda outside of your issue, but it's still something to check "just-in-case." Anyhoo, my typical "Golden Rule of Thumb" is to always export with the system name as part of the share. I find it avoids a lot of issues for myself, and it would in this case as well. I.e., only the system with the sharename that has the systemname could be mounted, and anything else would fail. Especially when it comes to systems with NFS automounts that host home directories that also share via Samba. I _avoid_ the default "homes" share, and explicitly setup a share that points to only an specific local path where user home directories could be located on that specific system. Now Samba does have good automounter support, and newer SMB has a DFS renaming approach, but it's still a nice option that works with any legacy setup (even when you have automounter and/or DFS in your Samba config). See page 1101 of "Appendix A" in "Samba Unleashed" on this -- as well as pages 1100-1102 for a general discussion of integration of NIS Automounter maps with Samba (non-DFS). It's circa 2000, but is still my recommended approach, even when Samba has been built with automounter and/or SMB DFS capability. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

boot failure - thanks
by Peter Farrow 29 Jun '05

29 Jun '05

Dear Everyone, once again I am amazed at the level of support and help provided by this list, staying subscribed to it has been very beneficial for me, even though I have been using Linux for many years now, I discover new things weekly just by being on this list, and that is a very good thing indeed, thanks to you all Pete

1 0

RE: [CentOS] 4.1 beta for Alpha platform
by Mark A. Lewis 29 Jun '05

29 Jun '05

Downloading it now. Good speeds ~500k. Will post back once I have uploaded it. > -----Original Message----- > From: centos-bounces(a)centos.org > [mailto:centos-bounces@centos.org] On Behalf Of William Warren > Sent: Wednesday, June 29, 2005 2:46 PM > To: CentOS mailing list > Subject: Re: [CentOS] 4.1 beta for Alpha platform > > http://lists.centos.org/pipermail/centos-announce/2005-June/00 > 0400.html > > Mark A. Lewis wrote: > > > If someone can send me a link to the torrent, I can put it > on an FTP. > > I am anxious to try it too. > > > > > >>-----Original Message----- > >>From: centos-bounces(a)centos.org > >>[mailto:centos-bounces@centos.org] On Behalf Of Lamar Owen > >>Sent: Wednesday, June 29, 2005 2:29 PM > >>To: CentOS mailing list > >>Subject: Re: [CentOS] 4.1 beta for Alpha platform > >> > >> > >> > >>>Hi all, > >>> > >>> I have tried to install this beta release on PWS 433 au > >> > >>but I can not > >> > >>>boot /kernels/vmlinux.gz image. Error > >>>is: "unsupported compressed image". Is not posible to > >> > >>install under > >> > >>>this Alpha model?? > >> > >>Does anyone have an ftpable mirror of this yet? Bittorrent > is great, > >>except when you don't allow it. While I could loophole my > own policy, > >>I shouldn't. > >>-- > >>Lamar Owen > >>Director of Information Technology > >>Pisgah Astronomical Research Institute > >>1 PARI Drive > >>Rosman, NC 28772 > >>(828)862-5554 > >>www.pari.edu > >>_______________________________________________ > >>CentOS mailing list > >>CentOS(a)centos.org > >>http://lists.centos.org/mailman/listinfo/centos > >> > >>-- > >>This message has been scanned for viruses and dangerous content by > >>MailScanner, and is believed to be clean. > >> > >> > > > > > > -- > 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 > > -- > This message has been scanned for viruses and dangerous > content by MailScanner, and is believed to be clean. > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

1 0

Re: Hot swap CPU
by Bryan J. Smith <b.j.smith＠ieee.org> 29 Jun '05

29 Jun '05

From: Rodrigo Barbosa <rodrigob(a)suespammers.org> > Memory hotswap ? Sounds fishy to me, at least on IA32{,e} > platforms. Are you sure about that ? Yes. They are proprietary NUMA implementations of both IA-32 Xeon and IA-64 Itanium that allow all sorts of swapping, largley via a daughtercard (i.e., the memory comes out with the CPU on a single board). In reality, this is really an area where Blades are more manageable for far less cost though. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

RE: [CentOS] 4.1 beta for Alpha platform
by Mark A. Lewis 29 Jun '05

29 Jun '05

If someone can send me a link to the torrent, I can put it on an FTP. I am anxious to try it too. > -----Original Message----- > From: centos-bounces(a)centos.org > [mailto:centos-bounces@centos.org] On Behalf Of Lamar Owen > Sent: Wednesday, June 29, 2005 2:29 PM > To: CentOS mailing list > Subject: Re: [CentOS] 4.1 beta for Alpha platform > > > > Hi all, > > > > I have tried to install this beta release on PWS 433 au > but I can not > > boot /kernels/vmlinux.gz image. Error > > is: "unsupported compressed image". Is not posible to > install under > > this Alpha model?? > > Does anyone have an ftpable mirror of this yet? Bittorrent > is great, except when you don't allow it. While I could > loophole my own policy, I shouldn't. > -- > Lamar Owen > Director of Information Technology > Pisgah Astronomical Research Institute > 1 PARI Drive > Rosman, NC 28772 > (828)862-5554 > www.pari.edu > _______________________________________________ > CentOS mailing list > CentOS(a)centos.org > http://lists.centos.org/mailman/listinfo/centos > > -- > This message has been scanned for viruses and dangerous > content by MailScanner, and is believed to be clean. > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

2 1

autofs handling of nis maps - Centos4
by Hilliard, Jay 29 Jun '05

29 Jun '05

I have the following nis map (auto.facvs) * -vers=3 &:/disk1 Which allows hosts that have /disk1 exported to be mounted to /facvs/$hostname It works fine, but on Centos4, it allows me to cd /facvs/foo (where foo isn't a real host out there) I find it has mounted my local /disk1 as /facvs/foo. It seems to be ignoring the key in the map pertaining to the host if it's not a valid host. Does anyone know of a way to make it restrictive again and fail the mount if the hostname match isn't valid? -- Jay Hilliard Sr. Systems Administrator Disney Feature Animation

1 0

RE: [CentOS] Hot swap CPU
by Mark A. Lewis 29 Jun '05

29 Jun '05

Compaq/HP Proliant DL580/DL760 both have this. > -----Original Message----- > From: centos-bounces(a)centos.org > [mailto:centos-bounces@centos.org] On Behalf Of Rodrigo Barbosa > Sent: Wednesday, June 29, 2005 1:13 PM > To: CentOS mailing list > Subject: Re: [CentOS] Hot swap CPU > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wed, Jun 29, 2005 at 12:59:24PM -0500, Bryan J. Smith > <b.j.smith(a)ieee.org> wrote: > > From: Rodrigo Barbosa <rodrigob(a)suespammers.org> > > > Btw, don't quote me on this one :) > > > I'm only 90% sure of the hotswapping capabilities, and > less than 50% > > > sure about the price :) > > > > There _are_ systems with hot-swap CPUs, memory and/or, > PCI[-X] slots. > > They are _not_ commodity and pricey, and require OS-level support. > > > > In fact, I believe Linux 2.6 has some support for hot-swap > -- at least > > at the PCI[-X] level, if not memory and possibly CPU as well. It > > requires extensive support though for that type of > "dynamic" flexibility. > > Memory hotswap ? > Sounds fishy to me, at least on IA32{,e} platforms. Are you > sure about that ? > > []s > > - -- > Rodrigo Barbosa <rodrigob(a)suespammers.org> "Quid quid Latine > dictum sit, altum viditur" > "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns) > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.0 (GNU/Linux) > > iD8DBQFCwuS4pdyWzQ5b5ckRAjSTAJ9hXlQ3kT4JAjSkkn/4QmYrKTFfcwCgkcPv > hsj3g/oh3Fy68DZmGXCygAI= > =y7II > -----END PGP SIGNATURE----- > _______________________________________________ > CentOS mailing list > CentOS(a)centos.org > http://lists.centos.org/mailman/listinfo/centos > > -- > This message has been scanned for viruses and dangerous > content by MailScanner, and is believed to be clean. > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

1 0

Re: Offtopic Posts [was Re: [CentOS] [OT] Memory Models and Multi/Virtual-Cores -- WAS: 4.0 -> 4.1 update failing]
by Bryan J. Smith <b.j.smith＠ieee.org> 29 Jun '05

29 Jun '05

From: Chris Mauritz <chrism(a)imntv.com> > I agree completely. Unfortunately, even though I've killfiled the > biggest offender, I'm still getting a lot of the noise since people > continue to feed him. I assume the former is a reference to me. As far as the latter, you might re-think your singularity focus. As I've said before, you can't complain about me without complaining about others too. I.e., I try to point out things with_out_ going down into the tangent. Then people "get smart" with me believing what I say is not true. I can then either "let it go" and then people dismiss my offering of my experience and knowledge. Or I can correct them with the tangent. It's a catch-22 for all of us. > If people want to feed the trolls, please, for the love of all that's > holy, trim your posts. 8-) The funniest thing is that when people define what a "troll" is, they aren't just defining it for myself. Your partiality has been noted. ;-> > Sigh, this is the first technical list filter I've ever had to > implement (for email...usenet is another story). No offense but sometimes the "popular" thought or ignorance is worse than the so-called "distractive" discussion that sheds some light on it. People are building servers with CentOS. This stuff is pertinent. I do _not_ introduce it myself, but when it comes up, I _will_ offer my recommendations based on experience and background. If you see people only as "feeding" my so-called "trollish nature," then maybe that's a sign you're not looking at the real issue. I'm not innocent, and I'll _never_ claim to be. But some others are very guilty of wanting many tangents and are posting just as much as I in a thread! Think about it. ;-> -- Bryan J. Smith mailto:b.j.smith@ieee.org

16 34

RE: [CentOS] Postfix / Postini question
by Marc Powell 29 Jun '05

29 Jun '05

> -----Original Message----- > From: centos-bounces(a)centos.org [mailto:centos-bounces@centos.org] On > Behalf Of Barry Brimer > Sent: Wednesday, June 29, 2005 9:47 AM > To: centos(a)centos.org > Subject: [CentOS] Postfix / Postini question > > > > I have a mail server that handles several domains. One of these domains > has > decided to use Postini. For those not familiar with Postini, you set your > MX > records to use their mail servers. They filter mail, and deliver you only > the > clean virus/spam free mail. The idea is to only allow incoming mail from > their > mail servers so spammers are unable to send to your mail server directly. > This > is fairly simple to do with standard restriction classes for a dedicated > mail > server. I am not sure how to accomplish this on a shared mail server. > Ideally > I would like to instruct postfix to accept mail from anywhere for all > domains > except one domain (the one using Postini) and only allow mail destined for > that > specific domain to originate from Postini's mail servers. Any ideas would > be > greatly appreciated. I'm not a postfix guru but I don't believe that is possible with a shared server. However, it's been my experience that if your server is not listed as an MX (and it won't), MXs exist (and they will -- Postini's) then mail will not be delivered to your machine by anyone except Postini. The only two scenarios I am aware of in which mail would get delivered to your server instead of Postini's would be if a) you were listed as a fallback MX or b) no MX's were specified then the A record for your domain would be used. Have you looked through the postfix wiki, documentation, faq, mailing list, etc? That'd be the first place I'd go since they _are_ the postfix experts ;). -- Marc

3 2

RE: [CentOS] [OT] Memory Models and Multi/Virtual-Cores -- WAS: 4.0-> 4.1 update failing
by Bryan J. Smith <b.j.smith＠ieee.org> 29 Jun '05

29 Jun '05

From: Robert Hanson <roberth(a)abbacomm.net> > or should i be more specific with the question(s)? > the reason i ask is that i just dumped 2 gig dram in a basic > P4 Intel 3.0GHz box to play with. > regards and TIA, At more than 1GiB on Linux/x86, you must use a 4G+4G kernel (this is the default) to see more than 960MiB. This causes a signficant (10%+) performance hit. On more than 4GiB, it is worsened as more extensive paging is used. If you have 1GiB or less, you should rebuild with_out_ "HIGHMEM" support which is a 1G+3G kernel, and you'll see better performance (and memory will be limited to 960MiB). In a nutshell, you should be running Linux/x86-64 on systems with more than 1GiB for optimal performance. If you have more than 4GiB of combined system and memory mapped I/O, you should be running Opterons with I/O MMUs. Intel EM64T systems will have protections in place for both earlier generation GTL+ limitations, as well as lack of an I/O MMU. Much of the additional "tangent" surrounded the fact that there are a few so-called "32-bit" Athlons that actually have a BIOS hack and Linux kernel support so it doesn't take a performance hit. Long story short, it has to do with the fact that even so-called "32-bit" Athlons have a core and underlying interconnect platform that supports 40-bit _linear_ addressing _natively_. -- Bryan J. Smith mailto:b.j.smith@ieee.org

4 10

with CentOS 4, and certain RAM, what specific kernel then?
by Robert Hanson 29 Jun '05

29 Jun '05

greetings how about some more of that practical CentOS stuff like amount of RAM vrs specific kernel info... im sure it is in a doc somewhere yet can someone enlighten... in all cases running latest" CentOS 4.... and since we all know when we have more than one processor, it is easy to choose SMP or not... and most of us can tell if we are i386, i586, i686, AMD whatever, Opteron etc... ...yet, what "kernel type" is best at what memory sizes... i know there are standard kernel and "hugemem" kernels and SMP and what have you.... are there others ive missed? at what amount of RAM should we go hugemem? is there more than one amount depending on processor? im guessing yes. is that what a lot of the discussions are about lately? do you always use a stock kernel below that? will a hugemem kernel self destruct at RAM memory amounts lower than what amount of RAM specifically calls for "hugemem"... and again... may i ask what web document spells this all out? regards and tia - rh

2 1

Re: Offtopic Posts [was Re: [CentOS] [OT] Memory Models and Multi/Virtual-Cores -- WAS: 4.0 -> 4.1 update failing]
by Bryan J. Smith <b.j.smith＠ieee.org> 29 Jun '05

29 Jun '05

From: Greg Knaddison <greg.knaddison(a)gmail.com> > Look - brevity is the soul of wit. It also keeps other folks on lists > from calling you a troll. The problem is that then the same people then start complaining about my "oversimplification." In fact, that's part of the problem here. I really _tried_ to make a recommendation without breaking down into the engineering non-sense. I really don't see how much "wit" I could do to satisify some people on that thread. > You pretty much get to blab as much as you want and argue with > people over tangent issues proving you are right, Dude, at this point, I'm tired of having my experience cut, sliced and diced by people who are like, "WTF does he think he is?" So you're right, I'm going to just state something _once_ and if people don't want to believe it, I'm just going to leave it. I tried several times in that thread, but yes, you are correct, I didn't stop, and I kept posting too. My apologies. > or you get to maintain "non-troll" status. Pick one, but don't > tangentially blab and get upset about being called a tangential > blabber. I don't have a problem with being called a "tangential blabber." What *I* have a problem is being singled out. Dude, re-read back in that last thread. Although I didn't stop posting, at some point, I realized it was going to have to go _deep_ before it would end. Now I've said my peace for the last time. I promise I will not repeat something more than once -- at the most, making only a 2nd post to "clarify" and if I didn't do a "good enough job" by then, I'll leave it be _regardless_. Your opinion is noted. But also note that someone else insinuated there was only *1* troll. I like holding everyone to the same standard. -- Bryan J. Smith mailto:b.j.smith@ieee.org

5 4

Re: [CentOS] [OT] Memory Models and Multi/Virtual-Cores -- WAS: 4.0 -> 4.1 update failing
by Bryan J. Smith <b.j.smith＠ieee.org> 29 Jun '05

29 Jun '05

From: Steven Vishoot <sir_funzone(a)yahoo.com> > As Carol Brady said "what was all that about" I dont > know if anyone else feels this way, but i think this > subjuct has been beaten to death and beyond. Not sure > if i remember right, but wasnt the original post about > upgrading from 4.0 to 4.1? How did this topic become > an engineering course? sorry for being a crab...but > come on.... If you deploy servers with more than 1GB of RAM, and definitely more than 4GB of RAM, you should be aware of what limitations there are with Intel solutions. That's what this was about. If someone else wanted to make it into a discussion of board traces and other, irrelevant non-sense, then I'm sorry for getting into that with him. -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 2

Re: [CentOS] [OT] Memory Models and Multi/Virtual-Cores -- WAS: 4.0 -> 4.1 update failing
by Bryan J. Smith <b.j.smith＠ieee.org> 29 Jun '05

29 Jun '05

From: alex(a)milivojevic.org > Well, this is how I interpreted Bryan's emails. He'll probably correct me if > I'm wrong (yeah, I have EE, but haven't done much EE work since I > graduated, it just happened to be mostly "software" things for me, so I'm > rather rusty here :-( If you haven't noticed, I am _not_ big on "credentials." As far as I'm concerned, as long as someone has the knowledge, I could care less about the paper**. Even most state BoPEs will allow you to replace an ABET Accredited BSE with 8-12 years of experience (plus another 4-5 years experience post-degree) to qualify to become a PE. There are semiconductor engineering mindsets and they create differ from programmer or even technologist. [ **NOTE: Being a consultant, I finally had to "give in" to the paper. I also decided to major in engineering "just in case I needed it" (and, later on, got to use it for 2 years in the semiconductor industry). ] > I don't think Bryan is talking about "external" width of the address bus, > how many lines you see printed on the motherboard. That's because it is _irrelevant_ in many cases. You can mux lines, which is exactly what the original EV6 Crossbar Athlon does. > He's talking how the things are organized internally, and about the way > the bus logic works. That would be what theoretically implementations > might use, not what some specific implementation is limiting itself to. Exactly. Until the new 40-bit Xeon MPs came out, they were pretty much "slap on" designs with extended ALUs and microcoding to be x86-64 compatible to a point. > Sorry for mixing software and hardware from now on, It hard not to. First you have to consider the programmer aspects. Then you have to realize those will influence hardware compatibility. Then you have to remember that with every new addressing model, you _exponentially_ increase the external logic to drive it. > just trying to make Peter see where his misconception is (the best > way I can, which might not be good way at all). It's fairly difficult to do it without breakout a basic memory controller circuit at least the transistor level, or possibly the combinational NAND gates it somewhat represents. > The programming model for 32-bit userland applications is obviusly > limited to 32 bits -- the sizeof(void *) will tell you that. So single > process can see only 32-bit logical linear address space. To a point. PAE36 is what allows you to break that, because even in the i386, the 16-bit segment register that is offset 4-bits from the 32-bit offset register results in a 36-bit "normalized" address (it can actually be 37-bit, but that's another story). How the processor handles that in a way that is compatible with the OS is the problem. PAE36 uses "paging" from above 32-bit (up to 36-bit/64GiB) down to below 32-bit (upto 4GiB). PAE36 processors can support this paging, and then have at least 36-bit traces on the platform. GTL+ logic was designed with this "slapped on," and never bothered with direct, linear access until just recently (with the new 40-bit redesign for Xeon MP). Athlon, on the other hand, has always been 40-bit EV6. AMD decided to support the PAE36 paging, which added logic. But they _always_ had the "40-bit linear addressing for free" inherently in the platform. That's where these few BIOS hacks come in, combined with an OS/model that can take advantage of it. If you enable this mode for Windows, it will _not_ work! > On the other hand, processor (the hardware) doesn't need to have > such limits, if it's internal organization is wider. So, AMD (processor) > is able to see 40-bit linear physical address space as one single big > chunk of memory. 32-bit applications will have their > 32-bit *logical* address space mapped into this 40-bit linear *physical* > address space of processor. I don't know if programming model of > "32-bit" AMD processors allows you to have wider-then-32-bit pointers > (even if it did, you would have to have compiler that can generate such > code, gcc can't do it for sure). Not true. The model is _still_ PAE36, up to 36-bit/64GiB. But instead of paging, the combination of Athlon's "inherent 40-bit" with an OS that can do it will not use paging. Normally PAE36 does paging, which is what PAE36 OSes normally do. > Obviously, the kernel needs to know how to manage things in this > wider physical address space, the reason why you need patched Linux > kernel to take advantage of it. The actual amount of space doesn't change -- at least not under the PAE36 model. It's just how the OS commands the memory logic to use it, and that also requires the firmware (BIOS) to pre-configure it at POST. Under a norminal PAE36 OS and board, the memory logic and OS always do paging to access above 32-bit/4GiB. But I don't think this hack is able to linearly address the entire 40-bit because of the limitations of what PAE36 can address. > Intel (the processor) on the other hand, is able to physically address > only 32-bit address space. Anything wider than that, it needs to page. > Dealing with paging will obviosly be additional work for OS, hence > lower performance. Paging is a significant hit. Anyone running in the 4G+4G "HIGHMEM" model of their Linux kernel and recompiles for 1G+3G model will notice a noticeable performance gain (as long with only 960MiB of memory). > So while both processors will have more that 32 address lines on the > packaging (and printed on motherboard) minus couple of lowest one > that are not needed) as you can see in various specifications that you > queted, that doesn't mean processor's core actually sees all that > address space. > How else to try explaining this... Hm... Remeber Intel 8086? It could > address only 16-bit address space, but it had more than 16 address lines > on the packaging. It used segmenting (hopefully the right term) to see > wider-than-16-bit address space. Now try to make analogy with what was > discussed so far ;-) It's somewhat correct, although it gets interesting. It's more like EMS than XMS, because XMS used to shunt the processor in and out of Protected286/386, and that required a 286/386 to access it. You could run a true 24-bit/32-bit, respectively, to avoid that. EMS worked on old 8088/8086 (as well as 80286/386), because pages above 1MB could be mapped in. The 80386 and some 80286 could emulate this as well without a special card with special addressing. In the GTL+ bus, this is exactly what it does. It offers special addressing lines for a memory logic that pages, because that's all the OS does. Even the early EM64T processors had to deal with this "limitation" of GTL+ platform. You want to ensure you get a new EM64T platform that doesn't have that approach. -- Bryan J. Smith mailto:b.j.smith@ieee.org

4 3

Re: [CentOS] [OT] Memory Models and Multi/Virtual-Cores -- WAS: 4.0 -> 4.1 update failing
by Bryan J. Smith <b.j.smith＠ieee.org> 29 Jun '05

29 Jun '05

From: Peter Arremann <loony(a)loonybin.org> > And that's exactly the part I don't get - if you have a 32bit address model > then you have to use PAE of some sort (compatible to Intel PAE36 or not) to > get to address more than that memory... The BIOS hack basically says "don't be stupid" >4GB. It tells the Athlon MP to the PAE36 addresses linearlly, instead of paging in GTL compatible fashion. With that said, do you mean _beyond_ 36-bit/64GiB? First off, I don't think there ever was an Athlon MP mainboard with more than 64GiB (or more than 32GiB for that matter). Secondly, programs are written to PAE36, so they can only address 64GiB (if not 32-bit/4GiB). *BUT* is it possible for the Athlon MP to still address more than 64GB and "window" (not page) PAE36/64GiB programs? That's a good question, and it's the #1 reason I'm trying to find that post in the LKML. In reality, if the hack uses Linux/x86-64, it could very well be that it puts the Athlon MP in "48-bit/256TiB Long Mode" and translates addreses linearlly. The Athlon MP wouldn't offer PAE52, no. But it _could_ offer PAE36 windows in a 48-bit (40-bit physical EV6) space. Remember, the Athlon/MP and Athlon64/Opteron are the _exact_same_ core design, including the 40-bit/1TiB EV6 interconnect for addressing outside the chip (even if the latter tunnels over HyperTransport between CPUs and I/O to other memory, instead of using a "crossbar switch"). > again - how do I generate a >32bit address when using a 32bit > address model without pages? :-) Remember, in i386 (and, subsequently, the i486 TLB), the segment register is offset at bit 20. That means the most significant bit (MSB) of the segment register actually has a value of 2^35 (32GiB)! Segment: 1111 1111 1111 1111 ____ ____ ____ ____ ____ Offset: ____ 1111 1111 1111 1111 1111 1111 1111 1111 Before PAE36 in the i686, Intel would thrown an exception if you set _any_ of the top 4-bits of the segment register, or if the 5th MSB of the segment was set and either the MSB of the offset, or the previous bits "overflowed" when "normalized" into the physical address. That would result in a physical address >32-bit/>4GiB. In i686 with PAE36, Intel now uses those >32-bit/>4GiB addresses as "pages" into <32-bit/<4GiB addresses. In EV6 with the incompatible "BIOS hack" and a supporting kernel, the Athlon MP's TLB doesn't page, it allows _direct_, _linear_ access above 32-bit/4GiB. Digital EV6 is capable of physically addresssing 40-bit. Intel GTL is only capable of 32-bit. When Athlon is in GTL compatibility mode, it only does 32-bit for full compatibility. But you can tell it to use native, 40-bit EV6 with this BIOS hack. The BIOS hack sets up the crossbar registers which the OS must then support. I'll confirm how this is being done. I believe it actually leverages the Linux/x86-64 kernel. > Once I have that address, throwing it out on the bus is > easy - but how do you generate that address without a PAE? That's where the hack comes in. Remember, _all_ kernels in _all_ OSes use the TLB, hence why an i486 ISA compatible is virtually required these days (or they do it in the kernel's software). Normally the Athlon TLB will do the same thing as any Intel GTL, so any such i686 kernel with PAE36 will normally do the same thing. But the BIOS hack puts the Athlon TLB into its _true_ 40-bit EV6 addressing, and the kernel then knows of this and uses it. > So you're simply talking about being the ability to output an > address longer than 32bit on the bus? It's more than just that. It's the combination of presenting PAE36 to _user_ software, while using _linear_ addressing physically. Intel i686+GTL already does PAE36, and pages in addressings above 32-bit. Athlon+EV6 normally just emulates that, right down to the TLB. This hack doesn't, it unleashes the Athlon as it's meant to work on a 40-bit interconnect designed for 64-bit Alpha processors. And that includes having the kernel drive the TLB to just take those >32-bit "normalized" addresses that would normally be "paged" and just act like it's linear space. As far as above 36-bit, I'm not sure. I'll check on that. > on AMD64, yes, thats for sure... but you were referring to > 32bit athlons in the statement I'm trying to understand. And what I'm saying is that Athlon is Athlon. It's the same core, same 40-bit EV6 interconnect. Everything else is compatibility. On Athlon 64, you can run a PAE52 kernel (on its 40-bit physical platform) and run PAE36 applications, giving linear address space to them all while they think paging is being used. What this hack does is do the same thing for Athlon MP -- marketed as "32-bit," but the _same_ 40-bit capable, _physical_ platform. EV6 is EV6, designed for 64-bit Alpha, and AMD couldn't "cripple" it. They use the same board logic and cores, whether a 32-bit Athlon or 64-bit Alpha are used. But doing anything but traditional, GTL 32-bit/PAE36 would normally _break_ hardware and OSes. Unless you have a hack to the BIOS which enables this "Linux" memory mode, and a kernel which supports it. Again, I'll find the post, which will lead me to the tech info. -- Bryan J. Smith mailto:b.j.smith@ieee.org

6 17

Re: [CentOS] Directory Server for CentOS 4.1
by Bryan J. Smith <b.j.smith＠ieee.org> 28 Jun '05

28 Jun '05

From: Johnny Hughes <mailing-lists(a)hughesjr.com> > The plan for Directory Server for CentOS-4 is to port RedHat Directory > Server (and not Fedora Directory Server) when it is released for RHEL. > That should happen when RedHat thinks it is stable for production in the > enterprise ... I would assume that they will charge for it like they do > for RHGFS/RHCS when they feel they have it stable. I thought that have been doing that since the AOL deal last year? It had been available on the RHN for awhile, in the unchanged/original form. Unless I was mistaken, the deal was that AOL would allow Red Hat to GPL it after an undisclosed number of sales had occurred _or_ by April 30, 2005, whichever came first. The new FDS and RHDS releases are just more updated/integrated releases with the Red Hat product line. E.g., more integrated SASL/Kerberos integration with Red Hat's offerings out-of-the-box. Previously there was a lot of post-install work to get Kerberos working via GSSAPI. -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss