Re: Memory limits for Scientific Linux kernels
On Fri, Jan 29, 2010 at 08:33:27AM +0100, Tim Edwards wrote: > > Unfortunately we have some internally-developed software which relies > strictly on a particular 'certified' OS version, architecture, package > versions etc. It takes a long time to get that re-certified for a newer > platform, especially an architecture change. Does the certification survive running the certified system on virtual hardware? (I would expect replacing real hardware with virtual hardware to to be equivalent to replacing an Intel NIC with a 3COM NIC, or an Intel mobo with an ASUS mobo, etc. If your certification is also tied to specific hardware, I so feel for you...) -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Memory limits for Scientific Linux kernels
On Fri, Jan 29, 2010 at 01:59:13PM -0800, Akemi Yagi wrote: > > [from red hat bugzilla] ... Additionally, the Red > Hat Enterprise Linux 5 PAE variant does not allow 4G of addressable memory > per-process like the Red Hat Enterprise Linux 4 kernel-hugemem variant does. If I remember right, this is what happened: For a 32-bit OS, a user process can only address 4 GiBytes of memory. But some of this memory has to be reserved by the OS itself for sundry OS needs. Originally, Linux had it divided as 2 GiBi user + 2 GiBi system, and it did not matter for machines with only 2 GB of physical memory or less (right?). Then, as machines with more memory became more affordable and common, users wanted to use this memory, so the user part was pushed up to 3+1 split, then to 3.5+0.5 (I think). Then Red Hat had a special patch for Linux 2.4 kernels that permitted 4+0 split, but it was not accepted into the mainstream kernel (I guess 0 bytes for kernel use was too little) and when the OS switched to the 2.6 kernels with RHEL5, this custom modification disappeared. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Memory limits for Scientific Linux kernels
On Fri, Jan 29, 2010 at 9:25 AM, Connie Sieh wrote: > Yes Oracle gets the same rules as everyone else. Note that there is the > concept of HUGEPAGES which a application can use which may help with this , > not sure if Oracle uses that. I think there are some Oracle tech notes > that cover this topic. While we are still talking about the memory stuff ... there is an interesting issue about "4G of addressable memory per process" in the upstream bugzilla[1]. Here's an excerpt: "Physical Address Extension allows x86 processors to address up to 64GB of physical RAM, but due to differences between the Red Hat Enterprise Linux 4 and 5 kernels, only Red Hat Enterprise Linux 4 (with kernel-hugemem package) is able to reliably address all 64GB of memory. Additionally, the Red Hat Enterprise Linux 5 PAE variant does not allow 4G of addressable memory per-process like the Red Hat Enterprise Linux 4 kernel-hugemem variant does. However, the x86_64 kernel does not suffer from any of these limitations, and is the suggested Red Hat Enterprise Linux 5 architecture to use with large-memory systems." [1] https://bugzilla.redhat.com/show_bug.cgi?id=241314 Akemi
Re: pirut from fastbugs pulls in rhn
Troy J Dawson wrote: Garrett Holmstrom wrote: Hi folks, The new version of pirut (1.3.28-17.el5 from sl-fastbugs) hasn't had its dependency on rhn-setup-gnome commented out, so all of our desktops now have rhn installed. It might be good to fix that in the repos unless the change to using the version from upstream was intentional. Fixing it now. Troy Fixed and pushed out. Though you will need to do a yum clean all before it will show up. Sorry about that. Troy -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LSCS/CSI/USS Group __
Re: pirut from fastbugs pulls in rhn
Garrett Holmstrom wrote: Hi folks, The new version of pirut (1.3.28-17.el5 from sl-fastbugs) hasn't had its dependency on rhn-setup-gnome commented out, so all of our desktops now have rhn installed. It might be good to fix that in the repos unless the change to using the version from upstream was intentional. Fixing it now. Troy -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LSCS/CSI/USS Group __
pirut from fastbugs pulls in rhn
Hi folks, The new version of pirut (1.3.28-17.el5 from sl-fastbugs) hasn't had its dependency on rhn-setup-gnome commented out, so all of our desktops now have rhn installed. It might be good to fix that in the repos unless the change to using the version from upstream was intentional. -- Garrett Holmstrom University of Minnesota School of Physics and Astronomy Systems Staff
Re: Memory limits for Scientific Linux kernels
On Fri, 29 Jan 2010, Howard, Chris wrote: =20 Do these memory limitations also include shared memory segments? For example, we have Oracle database servers with quite a bit of memory tied up in shared memory segments for the databases. 4 Gig won't get me very far with a large database. Yes Oracle gets the same rules as everyone else. Note that there is the concept of HUGEPAGES which a application can use which may help with this , not sure if Oracle uses that. I think there are some Oracle tech notes that cover this topic. > =20 Chris Howard -Connie Sieh
RE: Memory limits for Scientific Linux kernels
Do these memory limitations also include shared memory segments? For example, we have Oracle database servers with quite a bit of memory tied up in shared memory segments for the databases. 4 Gig won't get me very far with a large database. Chris Howard
Re: OpenSSL 1.x
On Jan 28, 2010, at 9:15 PM, P. Larry Nelson wrote: > Hi Troy, > > Troy Dawson wrote on 1/28/2010 1:55 PM: >> P. Larry Nelson wrote: >>> Hi, >>> >>> I just received a "HIGH criticality" email from >>> secur...@opensciencegrid.org stating: >>> >>> "Do NOT upgrade to OpenSSL 1.x. The new OpenSSL version breaks the >>> certificate authentication for OSG/VDT." >>> >>> Not having my ear to the ground vis-a-vis openssl, does anyone know if >>> that version is due to be released soon? Will it come from TUV or >>> directly from openssl.org? (Troy/Connie question) >>> >>> Right now, we have openssl-0.9.8e-12.el5_4.1. >>> >>> I suppose the thing to do is to go and edit the yum.cron.excludes on >>> all our OSG nodes to block openssl* until this issue is fixed. [sigh...] >>> >>> - Larry >>> >> >> Scientific Linux, and RHEL are enterprise linux distributions. >> This means that they do *not* just update to the latest versions of >> packages. RedHat and SL will *not* just update to the latest version of >> openssl, just because it was released. >> >> SL 4.0 had openssl 0.9.7a >> SL 4.8 has openssl 0.9.7a >> >> Thas is after five years, we still have the same version of openssl. >> RedHat backports all the security fixes into the 0.9.7a version for >> RHEL4 (and hense SL4). >> >> SL 5.0 had openssl 0.9.8b >> SL 5.4 has openssl 0.9.8e Even SL6 won't have openssl 1. It was only added after FC12 that SL6 will eventually be based on. Steve >> >> After 3 years, SL5 is still at version 0.9.8, although we have moved >> from b to e. >> I cannot say for 100% certain, because we are not RedHat. But according >> to all their policies, goals, statements and past history, they are not >> going to move openssl above version 0.9.8 for RHEL 5 (and hense SL5) >> >> Troy > > Thanks for the info and history lesson. I didn't know and didn't want > to assume. As far as I knew, openssl 1.x might have been a big hairy > deal security fix that was imminent. > > - Larry > > -- > P. Larry Nelson (217-244-9855) | Systems/Network Administrator > 461 Loomis Lab | High Energy Physics Group > 1110 W. Green St., Urbana, IL | Physics Dept., Univ. of Ill. > MailTo:lnel...@uiuc.edu| http://www.roadkill.com/lnelson/ > --- > "Information without accountability is just noise." - P.L. Nelson
