Re: LDAP & BUS ERROR
I think it is under 200 groups he belongs to. He is one of our security people and I think he is a member of almost all groups. The weird thing is other info security people (with large group memberships) can login and SU over just fine. From: Linux on 390 Port on behalf of Mark Post Sent: Wed 9/12/2007 5:48 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: LDAP & BUS ERROR While not an answer to your question, and not trying to say it might not be a bug, I have to ask what the reason is for him being a member of so many groups? If it is a bug, it needs to be fixed, but I'm wondering is there might be a better way to accomplish whatever is being done that requires so many group memberships. Mark Post -Original Message- From: "Goodwin, Derric" <[EMAIL PROTECTED]> To: Linux on 390 Port Sent: 9/12/2007 2:17:47 PM Subject: LDAP & BUS ERROR I have a batch of new SuSE 9 guests that authenticate via LDAP. I have a problem with one and only one user. He is our security admin and belongs to a lot of groups. When ever he tries to log in or (as root) you try to SU to his ID we get a BUS ERROR. An strace on the command shows it bails in the set groups part of the SU process. Anyone seen this before? Any suggestions? Derric Goodwin Distributed Systems Integration Acxiom CDC / TransUnion 312-985-3312 / 312-247-0669 [EMAIL PROTECTED] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: linux performance behind load balancer
Rob, As we are just switching to Omegamon and almost up to implementation of our first user to come into a new zLinux front end, can you give ant further details on your comment below? Thanks Kevin -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij Sent: Thursday, September 13, 2007 4:07 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: linux performance behind load balancer On 9/13/07, Alan Altmark <[EMAIL PROTECTED]> wrote: > Finishing the thought, IBM's OMEGAMON comes to mind as well. There's more > than one "decent" performance monitor Out There, so shop and compare. But since that will present incorrect CPU breakdown per Linux process, it may lead to wrong conclusions. ESALPS will correct the CPU usage for virtualization effects. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: linux performance behind load balancer
On Friday, 09/14/2007 at 02:19 EDT, Rob van der Heij <[EMAIL PROTECTED]> wrote: > But you *are* very right that performance monitor should be part of > your Proof of Concept. We don't see a PoC fail these days because > software does not work or cannot be found. We see it fail because > people suffer from poor performance and have nobody to turn to for > help in that new environment. So they get folks with Linux skills on > discrete servers and they do all the wrong things because tuning with > Linux on z/VM is rarely intuitive. Or folks using the wrong tools to > measure and draw the wrong conclusions about the capacity of their > installation and their TCO if they grow it. Amen. Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: LDAP & BUS ERROR
On Friday, 09/14/2007 at 06:40 EDT, "Goodwin, Derric" <[EMAIL PROTECTED]> wrote: > I think it is under 200 groups he belongs to. He is one of our security people > and I think he is a member of almost all groups. The weird thing is other info > security people (with large group memberships) can login and SU over just fine. The number of groups on setgroups() cannot exceed NGROUPS. (And I don't know where NGROUPS is set.) Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: LDAP & BUS ERROR
I think, here at least, it would be a security red flag if the security people asked to be added to a large list of groups. The security person doesn't need access to the data in order to secure and monitor the data. I think that you need to re-think how things are being done. We handle patient data here. Our data security people are just as liable, in terms of having access to something without the necessary authority and 'need", as anyone in data processing, or out on the hospital floor. The government says that I can't have access to patient data, and that goes for our security people as well. -- .~.Robert P. Nix Mayo Foundation /V\RO-OE-5-55200 First Street SW /( )\ 507-284-0844 Rochester, MN 55905 ^^-^^ - "In theory, theory and practice are the same, but in practice, theory and practice are different." On 9/14/07 5:38 AM, "Goodwin, Derric" <[EMAIL PROTECTED]> wrote: > I think it is under 200 groups he belongs to. He is one of our security people > and I think he is a member of almost all groups. The weird thing is other info > security people (with large group memberships) can login and SU over just > fine. > > > > From: Linux on 390 Port on behalf of Mark Post > Sent: Wed 9/12/2007 5:48 PM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: LDAP & BUS ERROR > > > > While not an answer to your question, and not trying to say it might not be a > bug, I have to ask what the reason is for him being a member of so many > groups? If it is a bug, it needs to be fixed, but I'm wondering is there > might be a better way to accomplish whatever is being done that requires so > many group memberships. > > Mark Post > > -Original Message- > From: "Goodwin, Derric" <[EMAIL PROTECTED]> > To: Linux on 390 Port > > Sent: 9/12/2007 2:17:47 PM > Subject: LDAP & BUS ERROR > > I have a batch of new SuSE 9 guests that authenticate via LDAP. > > > > I have a problem with one and only one user. He is our security admin > and belongs to a lot of groups. > > When ever he tries to log in or (as root) you try to SU to his ID we get > a BUS ERROR. > > > > An strace on the command shows it bails in the set groups part of the SU > process. > > > > Anyone seen this before? Any suggestions? > > > > > > > > > > Derric Goodwin > > Distributed Systems Integration > > Acxiom CDC / TransUnion > > 312-985-3312 / 312-247-0669 > > [EMAIL PROTECTED] > > > > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > > > > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: LDAP & BUS ERROR
>>> On Fri, Sep 14, 2007 at 6:38 AM, in message <[EMAIL PROTECTED]>, "Goodwin, Derric" <[EMAIL PROTECTED]> wrote: > I think it is under 200 groups he belongs to. He is one of our security > people and I think he is a member of almost all groups. The weird thing is > other info security people (with large group memberships) can login and SU > over just fine. You didn't answer the question that I asked: what is the reason for him being a member of so many groups? Or any of your security team, for that matter? On most Linux systems I've seen, they are a member of _one_ group only. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: LDAP & BUS ERROR
>>> On Fri, Sep 14, 2007 at 8:10 AM, in message <[EMAIL PROTECTED]>, Alan Altmark <[EMAIL PROTECTED]> wrote: -snip- > The number of groups on setgroups() cannot exceed NGROUPS. (And I don't > know where NGROUPS is set.) According to include/linux/limits.h: #define NGROUPS_MAX65536/* supplemental group IDs are available */ Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: LDAP & BUS ERROR
I have been watching this discussion thinking I might learn something, and
today I did. I did some looking for NGROUPS, and I eventually found that the
number of groups allowed can be determined by sysconf(). This implies that it
can be changed by a configuration parameter. Perhaps the program below can
help determine the maximum on the failing system.
/*
* Display the number of groups allowed.
*/
#include
#include
int main( int argc, char **argv )
{
long ngroups_max;
ngroups_max = sysconf( _SC_NGROUPS_MAX );
fprintf( stdout, "ngroups_max = %ld\n", ngroups_max );
return 0;
}
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of
Alan Altmark
Sent: Friday, September 14, 2007 5:11 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: LDAP & BUS ERROR
On Friday, 09/14/2007 at 06:40 EDT, "Goodwin, Derric"
<[EMAIL PROTECTED]> wrote:
> I think it is under 200 groups he belongs to. He is one of our security
people
> and I think he is a member of almost all groups. The weird thing is
other info
> security people (with large group memberships) can login and SU over
just fine.
The number of groups on setgroups() cannot exceed NGROUPS. (And I don't
know where NGROUPS is set.)
Alan Altmark
z/VM Development
IBM Endicott
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: SLES10 SDK Installation Server
After enough playing around, I finally stubbed my foot on the solution. >From SUSE's home directory (/home/suse) which is on a FTP server; mkdir sdk cd sdk mkdir CD1 mkdir CD2 mkdir CD3 mkdir CD4 cd .. mount -o loop,ro SLE-10-SDK-s390x-GMC-CD1.iso sdk/CD1 mount -o loop,ro SLE-10-SDK-s390x-GMC-CD2.iso sdk/CD2 mount -o loop,ro SLE-10-SDK-s390x,GMC-CD3.iso sdk/CD3 mount -o loop,ro SLE-10.SDK-s390x-GMC-CD4.iso sdk/CD4 And from Yast on the machine that wants the SDK: 1. Forget about the Add-on Product. 2. Under "Installation Source": specify Protocol: FTP Server name: 192.168. Directory on server: sdk/CD1 User name: suse Password: x Now "Software Management" now picks up all four SDK CDs. Yea, I know. Everyone else "knows" this stuff . Tom Duerbusch THD Consulting FELINE PHYSICS: Law of Cat Inertia A cat at rest will tend to remain at rest, unless acted upon by some outside force - such as the opening of cat food, or a nearby scurrying mouse. >>> Tom Duerbusch 9/12/2007 11:37 AM >>> I have SLES 10 with SP1 installed. The source is the DVD, iso image on a FTP server. Everything installs fine and is really fast. Now I want to add in the SDK (4 iso images to the FTP server). For installation, the install userid is "suse". So on the ftp server, the DVD is mounted as: /home/suse/suse10 I currently have the 4 SDK images mounted as: /home/suse/sdk1 /home/suse/sdk2 /home/suse/sdk3 /home/suse/sdk4 Well, using yast software add-on product I can specify the sdk1 directory and that works, but for only those packages on the first CD. When I redo the "add-on products" to specify the second CD, to pick up the rest of the packages, I get: File ./media.1/directory.yast not found on media: ftp://[EMAIL PROTECTED]/sdk2 Right, it is not there. It is on the first CD. So, there must be a certain method of mounting the sdk CDs, so "add-on Products" can find the "media.1" directory plus get access to the other 3 CDs. Where is this documented? This "add-on products" is new with SLES10 and seems to have a specific directory structure for all 4 CDs. The "sles-admin.pdf" just shows how to use the sdks, not how to mount them. Thanks Tom Duerbusch THD Consulting FELINE PHYSICS: Law of Cat Inertia A cat at rest will tend to remain at rest, unless acted upon by some outside force - such as the opening of cat food, or a nearby scurrying mouse. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: linux performance behind load balancer
>>> On Fri, Sep 14, 2007 at 6:48 AM, in message <[EMAIL PROTECTED]>, "Evans, Kevin R" <[EMAIL PROTECTED]> wrote: > Rob, > > As we are just switching to Omegamon and almost up to implementation of > our first user to come into a new zLinux front end, can you give ant > further details on your comment below? Prior to the kernels used in SLES10 and RHEL5, the way CPU consumption was tracked by the Linux kernel didn't take into account that the system may be running in a shared/virtualized environment. The (valid until LPARs, z/VM, VMware, and Xen) assumption in place was that the kernel was in complete control of the hardware, so any passage of time between the last clock value taken, and the current one, was assigned to whatever process was dispatched in the interval. The problem being, of course, that the virtual machine/LPAR might not have been running at all during that time. So, Linux could report that the CPU was 100% busy, when in fact it was only being dispatched, for example, 3% of the time. Of the various performance monitors that were being marketed for mainframe Linux, only Velocity Software's product combined the Linux data with the z/VM monitor data, and normalized the Linux values to be correct. (Obviously this only worked in an environment where z/VM was being used as the hypervisor.) This was a big factor in many cases of which monitor to choose. Since the release of the "cpu accounting" patches, and incorporation into SLES and RHEL, that's no longer the case, unless you're still running SLES8 (Hi, Marcy!) and SLES9 (Hi, almost everyone else!), or RHEL3 or 4. Now the decision is based on more traditional criteria, as opposed to being right or very wrong. If you have a userid and password to access the SHARE proceedings, you can see Martin Schwidefsky's presentation on this at http://www.share.org/member_center/open_document.cfm?document=proceedings/SHARE_in_Seattle/S9266XX172938.pdf (I have no idea why I didn't ask Martin for a copy of that for the linuxvm.org web site. Rats.) Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: linux performance behind load balancer
(Hi Mark!) That's the disadvantage of starting before everyone else and having too many servers :) At least I've killed the sles7's! The problem with sles8 to sles9x is it's a new server. That requires the cooperation of the users. They don't like to do that if everything is all hunky dory. They have other things to do (so they tell me). I'm hoping sles9x to sles10x is a true upgrade and we can do it without bothering the applications folks. That's a project to figure out over the holiday freeze, though. I'm pretty sure all of production will be sles9x within the next 2 months - woo hoo! The promise of better performance from WAS6.1 and sles9x saving them a few IFLs is finally getting their attention. (see you next week). Marcy Cortes "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Friday, September 14, 2007 9:20 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] linux performance behind load balancer >>> On Fri, Sep 14, 2007 at 6:48 AM, in message <[EMAIL PROTECTED]>, "Evans, Kevin R" <[EMAIL PROTECTED]> wrote: > Rob, > > As we are just switching to Omegamon and almost up to implementation > of our first user to come into a new zLinux front end, can you give > ant further details on your comment below? Prior to the kernels used in SLES10 and RHEL5, the way CPU consumption was tracked by the Linux kernel didn't take into account that the system may be running in a shared/virtualized environment. The (valid until LPARs, z/VM, VMware, and Xen) assumption in place was that the kernel was in complete control of the hardware, so any passage of time between the last clock value taken, and the current one, was assigned to whatever process was dispatched in the interval. The problem being, of course, that the virtual machine/LPAR might not have been running at all during that time. So, Linux could report that the CPU was 100% busy, when in fact it was only being dispatched, for example, 3% of the time. Of the various performance monitors that were being marketed for mainframe Linux, only Velocity Software's product combined the Linux data with the z/VM monitor data, and normalized the Linux values to be correct. (Obviously this only worked in an environment where z/VM was being used as the hypervisor.) This was a big factor in many cases of which monitor to choose. Since the release of the "cpu accounting" patches, and incorporation into SLES and RHEL, that's no longer the case, unless you're still running SLES8 (Hi, Marcy!) and SLES9 (Hi, almost everyone else!), or RHEL3 or 4. Now the decision is based on more traditional criteria, as opposed to being right or very wrong. If you have a userid and password to access the SHARE proceedings, you can see Martin Schwidefsky's presentation on this at http://www.share.org/member_center/open_document.cfm?document=proceeding s/SHARE_in_Seattle/S9266XX172938.pdf (I have no idea why I didn't ask Martin for a copy of that for the linuxvm.org web site. Rats.) Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: SLES10 SDK Installation Server
Which is what I suggested on August 14 (but in a much more general sense). Tom, if you didn't understand the answer you could have said something instead of playing around for a month... :) Tom Duerbusch wrote: After enough playing around, I finally stubbed my foot on the solution. From SUSE's home directory (/home/suse) which is on a FTP server; mkdir sdk cd sdk mkdir CD1 mkdir CD2 mkdir CD3 mkdir CD4 cd .. mount -o loop,ro SLE-10-SDK-s390x-GMC-CD1.iso sdk/CD1 mount -o loop,ro SLE-10-SDK-s390x-GMC-CD2.iso sdk/CD2 mount -o loop,ro SLE-10-SDK-s390x,GMC-CD3.iso sdk/CD3 mount -o loop,ro SLE-10.SDK-s390x-GMC-CD4.iso sdk/CD4 And from Yast on the machine that wants the SDK: 1. Forget about the Add-on Product. 2. Under "Installation Source": specify Protocol: FTP Server name: 192.168. Directory on server: sdk/CD1 User name: suse Password: x Now "Software Management" now picks up all four SDK CDs. Yea, I know. Everyone else "knows" this stuff . Tom Duerbusch THD Consulting -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2008 - Chattanooga - April 18-22, 2008 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: linux performance behind load balancer
Forgive the soap box. This is old news. Linux process data in any virtual environment is wrong. This was measured and presented in a production environment as off by order of magnitude. This is true for all releases and distributions of linux. ibm claims there is a fix in sles10, this has never been validated in any presentation. i don't like claims that sound suspiciously like vaporware. Why is this data bad? it's useless. 1) imagine someone doing application tuning and using this data and thinking they've improved their app performance - and their data is wrong, leads to wrong conclusion 2) system utilization high, logon to any linux using linux tools, you might think top is the hog, but if the system utilization is high, you will make very poor choices of what processes or linux server to kill 3) if you are making poc decisions based on this data, you will think the mainframe is dog slow. this is bad for all of us and leads to poor financial decisions. This gives a very good platform a bad image. 6 years ago when velocity software analyzed this, we found a way to correct and record the process data. (for all linux releases and distributions) thus this data is useful for all of the above. no other vendor (other than velocity software) has presented a solution for this problem - and validated in any public forum. So when i hear about installations planning on dependancies on garbage data, i think about how many people would drive cars without gas gauges or speedometers? was the used car salesperson ethical in taking advantage of the naive buyer? Evans, Kevin R wrote: Rob, As we are just switching to Omegamon and almost up to implementation of our first user to come into a new zLinux front end, can you give ant further details on your comment below? Thanks Kevin -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij Sent: Thursday, September 13, 2007 4:07 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: linux performance behind load balancer On 9/13/07, Alan Altmark <[EMAIL PROTECTED]> wrote: Finishing the thought, IBM's OMEGAMON comes to mind as well. There's more than one "decent" performance monitor Out There, so shop and compare. But since that will present incorrect CPU breakdown per Linux process, it may lead to wrong conclusions. ESALPS will correct the CPU usage for virtualization effects. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 begin:vcard fn:Barton Robinson n:Robinson;Barton adr;dom:;;PO 390640;Mountain View;CA;94039-0640 email;internet:[EMAIL PROTECTED] title:Sr. Architect tel;work:650-964-8867 note:If you can't measure it, I'm just not interested x-mozilla-html:FALSE url:http://velocitysoftware.com version:2.1 end:vcard
Re: SLES10 SDK Installation Server
Hi Rich I looked back at the August 14th topicwrong topic. The August 14th wasn't about SDK but about the install images and mksles10root, which based on advise, I went with the DVD flavor. I agree, the DVD is much, much easier. In the SDK part, what I was doing wrong, was mounting CD1, CD2, CD3 and CD4 directly on the home directory (/home/suse/CD1 /home/suse/CD2 etc.). The SDK CD1 was found, but it couldn't find the other CDs. When I updated Yast to directly look for CD2, I got a "media not available" message. Anyway, the key seemed to be "/home/suse/sdk/CD1 etc". But what still bothers me, is that in "Installation Source", I still specify "sdk/CD1", which finds "sdk/CD2 etc". But with the prior mount structure "/home/suse/CD1", specifying the "Installation Source" of "CD1", wouldn't find "CD2 etc..". But, with the different tangents I was on, there might have been something else not setup correctly. Anyway, I had a request for "subversion", which was on the SDK. The rest of the time was spent with DB2/UDB 9.1 under SLES10 SP1 with the beta of the new DB2/VSE. Tom Duerbusch THD Consulting FELINE PHYSICS: Law of Cat Inertia A cat at rest will tend to remain at rest, unless acted upon by some outside force - such as the opening of cat food, or a nearby scurrying mouse. >>> Rich Smrcina <[EMAIL PROTECTED]> 9/14/2007 11:43 AM >>> Which is what I suggested on August 14 (but in a much more general sense). Tom, if you didn't understand the answer you could have said something instead of playing around for a month... :) Tom Duerbusch wrote: > After enough playing around, I finally stubbed my foot on the solution. > >>From SUSE's home directory (/home/suse) which is on a FTP server; > > mkdir sdk > cd sdk > mkdir CD1 > mkdir CD2 > mkdir CD3 > mkdir CD4 > cd .. > mount -o loop,ro SLE-10-SDK-s390x-GMC-CD1.iso sdk/CD1 > mount -o loop,ro SLE-10-SDK-s390x-GMC-CD2.iso sdk/CD2 > mount -o loop,ro SLE-10-SDK-s390x,GMC-CD3.iso sdk/CD3 > mount -o loop,ro SLE-10.SDK-s390x-GMC-CD4.iso sdk/CD4 > > And from Yast on the machine that wants the SDK: > > 1. Forget about the Add-on Product. > 2. Under "Installation Source": > specify Protocol: FTP > Server name: 192.168. > Directory on server: sdk/CD1 > User name: suse > Password: x > > Now "Software Management" now picks up all four SDK CDs. > > Yea, I know. Everyone else "knows" this stuff . > > Tom Duerbusch > THD Consulting -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2008 - Chattanooga - April 18-22, 2008 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: linux performance behind load balancer
There are some issues with WAS right now that seriously impact Linux under z/VM. Rob's out of town, he can explain better. The problem is that the current JDK polls every 10ms. this means the WAS servers stay in queue. We have been seeing the total to virtual storage over allocation ratios that sites can attain have been dropping, traced it down to servers not dropping from queue. Rob tracked it down to the WAS polling. We're hoping for relief next year. So be careful about the performance feecher of 6.1. Marcy Cortes wrote: (Hi Mark!) I'm pretty sure all of production will be sles9x within the next 2 months - woo hoo! The promise of better performance from WAS6.1 and sles9x saving them a few IFLs is finally getting their attention. (see you next week). Marcy Cortes -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Friday, September 14, 2007 9:20 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] linux performance behind load balancer On Fri, Sep 14, 2007 at 6:48 AM, in message <[EMAIL PROTECTED]>, "Evans, Kevin R" <[EMAIL PROTECTED]> wrote: Rob, As we are just switching to Omegamon and almost up to implementation of our first user to come into a new zLinux front end, can you give ant further details on your comment below? Prior to the kernels used in SLES10 and RHEL5, the way CPU consumption was tracked by the Linux kernel didn't take into account that the system may be running in a shared/virtualized environment. The (valid until LPARs, z/VM, VMware, and Xen) assumption in place was that the kernel was in complete control of the hardware, so any passage of time between the last clock value taken, and the current one, was assigned to whatever process was dispatched in the interval. The problem being, of course, that the virtual machine/LPAR might not have been running at all during that time. So, Linux could report that the CPU was 100% busy, when in fact it was only being dispatched, for example, 3% of the time. Of the various performance monitors that were being marketed for mainframe Linux, only Velocity Software's product combined the Linux data with the z/VM monitor data, and normalized the Linux values to be correct. (Obviously this only worked in an environment where z/VM was being used as the hypervisor.) This was a big factor in many cases of which monitor to choose. Since the release of the "cpu accounting" patches, and incorporation into SLES and RHEL, that's no longer the case, unless you're still running SLES8 (Hi, Marcy!) and SLES9 (Hi, almost everyone else!), or RHEL3 or 4. Now the decision is based on more traditional criteria, as opposed to being right or very wrong. If you have a userid and password to access the SHARE proceedings, you can see Martin Schwidefsky's presentation on this at http://www.share.org/member_center/open_document.cfm?document=proceeding s/SHARE_in_Seattle/S9266XX172938.pdf (I have no idea why I didn't ask Martin for a copy of that for the linuxvm.org web site. Rats.) Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 begin:vcard fn:Barton Robinson n:Robinson;Barton adr;dom:;;PO 390640;Mountain View;CA;94039-0640 email;internet:[EMAIL PROTECTED] title:Sr. Architect tel;work:650-964-8867 note:If you can't measure it, I'm just not interested x-mozilla-html:FALSE url:http://velocitysoftware.com version:2.1 end:vcard
Re: linux performance behind load balancer
>>> On Fri, Sep 14, 2007 at 4:11 PM, in message <[EMAIL PROTECTED]>, barton <[EMAIL PROTECTED]> wrote: > There are some issues with WAS right now that seriously impact Linux under > z/VM. Rob's > out of town, he can explain better. The problem is that the current JDK > polls every > 10ms. this means the WAS servers stay in queue. We have been seeing the > total to virtual > storage over allocation ratios that sites can attain have been dropping, > traced it down to > servers not dropping from queue. Rob tracked it down to the WAS polling. > We're hoping for > relief next year. So be careful about the performance feecher of 6.1. It was Rob working with me on the Linux/390 wiki system that led him to the discovery that the IBM JDK was issuing 10ms sleeps. It wasn't just in the newer versions of the JDK, it was in the 1.4.2 ones as well. So, upgrading to a newer version of WAS and it's associated Java, shouldn't be any worse in that regard. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: linux performance behind load balancer
Production I'm not so worried about because it has adequate capacity (no paging) and the servers run all the time anyway so don't drop from queue because of real work. They've benchmarked and measured (with Velocity tools :) the differences betweens sles9x/was6 and sles8/was5 and see significant differences. We'll let you know for sure next week with the real workload going through. But this might explain the increased paging load on our test system, which already was bursting at the seams. Do you know what level of the JDK that started in? Marcy Cortes "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of barton Sent: Friday, September 14, 2007 1:12 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] linux performance behind load balancer There are some issues with WAS right now that seriously impact Linux under z/VM. Rob's out of town, he can explain better. The problem is that the current JDK polls every 10ms. this means the WAS servers stay in queue. We have been seeing the total to virtual storage over allocation ratios that sites can attain have been dropping, traced it down to servers not dropping from queue. Rob tracked it down to the WAS polling. We're hoping for relief next year. So be careful about the performance feecher of 6.1. Marcy Cortes wrote: > (Hi Mark!) > > I'm pretty sure all of production will be sles9x within the next 2 > months - woo hoo! The promise of better performance from WAS6.1 and > sles9x saving them a few IFLs is finally getting their attention. > > (see you next week). > > Marcy Cortes > > > -Original Message- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of > Mark Post > Sent: Friday, September 14, 2007 9:20 AM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: [LINUX-390] linux performance behind load balancer > > On Fri, Sep 14, 2007 at 6:48 AM, in message > > <[EMAIL PROTECTED]>, > "Evans, Kevin R" <[EMAIL PROTECTED]> wrote: > >>Rob, >> >>As we are just switching to Omegamon and almost up to implementation >>of our first user to come into a new zLinux front end, can you give >>ant further details on your comment below? > > > Prior to the kernels used in SLES10 and RHEL5, the way CPU consumption > was tracked by the Linux kernel didn't take into account that the > system may be running in a shared/virtualized environment. The (valid > until LPARs, z/VM, VMware, and Xen) assumption in place was that the > kernel was in complete control of the hardware, so any passage of time > between the last clock value taken, and the current one, was assigned > to whatever process was dispatched in the interval. The problem > being, of course, that the virtual machine/LPAR might not have been > running at all during that time. So, Linux could report that the CPU > was 100% busy, when in fact it was only being dispatched, for example, 3% of the time. > > Of the various performance monitors that were being marketed for > mainframe Linux, only Velocity Software's product combined the Linux > data with the z/VM monitor data, and normalized the Linux values to be > correct. (Obviously this only worked in an environment where z/VM was > being used as the hypervisor.) This was a big factor in many cases of > which monitor to choose. Since the release of the "cpu accounting" > patches, and incorporation into SLES and RHEL, that's no longer the > case, unless you're still running SLES8 (Hi, Marcy!) and SLES9 (Hi, > almost everyone else!), or RHEL3 or 4. Now the decision is based on > more traditional criteria, as opposed to being right or very wrong. > > If you have a userid and password to access the SHARE proceedings, you > can see Martin Schwidefsky's presentation on this at > http://www.share.org/member_center/open_document.cfm?document=proceedi > ng > s/SHARE_in_Seattle/S9266XX172938.pdf > > (I have no idea why I didn't ask Martin for a copy of that for the > linuxvm.org web site. Rats.) > > > Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: linux performance behind load balancer
>>> On Fri, Sep 14, 2007 at 4:57 PM, in message <[EMAIL PROTECTED]>, Marcy Cortes <[EMAIL PROTECTED]> wrote: -snip- > Do you know what level of the JDK that started in? It's been around for a while. The version I was running at the time Rob first investigated was an older 1.4.2 release. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: LDAP & BUS ERROR
Alan Altmark wrote: On Friday, 09/14/2007 at 06:40 EDT, "Goodwin, Derric" <[EMAIL PROTECTED]> wrote: I think it is under 200 groups he belongs to. He is one of our security people and I think he is a member of almost all groups. The weird thing is other info security people (with large group memberships) can login and SU over just fine. The number of groups on setgroups() cannot exceed NGROUPS. (And I don't know where NGROUPS is set.) 07:57 [EMAIL PROTECTED] ~]$ find /usr/include/ -type f | xargs egrep 'define.*\<(NGROUPS|NGROUPS_MAX)\>' /usr/include/sys/param.h:# define NGROUPS NGROUPS_MAX /usr/include/bits/posix1_lim.h:# define NGROUPS_MAX 8 /usr/include/X11/Xos.h:#define NGROUPS 16 /usr/include/linux/limits.h:#define NGROUPS_MAX65536/* supplemental group IDs are available */ 07:57 [EMAIL PROTECTED] ~]$ -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Please do not reply off-list -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: linux performance behind load balancer
barton wrote: Forgive the soap box. This is old news. Linux process data in any virtual environment is wrong. This was measured and presented in a production environment as off by order of magnitude. This is true for all releases and distributions of linux. ibm claims there is a fix in sles10, this has never been validated in any presentation. i don't like claims that sound suspiciously like vaporware. Your own comments don't sound any better, to me. Are you claiming that the accounting patches mentioned elsewhere don't work as claimed? Can you support that claim? -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Please do not reply off-list -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
