A doubt: z/VM and Linux

2011-08-18 Thread Carlos Bodra - Pessoal 

Cross posted in VM and Linux390 lists.

A question arrised to me yesterday:

If I have and installation running z/VM (with no VSE or Z/OS guests),
but with DB2 and VisualAge I need an engine configured as CP or I can
run these workload under IFL?
Question arrised since customer should have some Linux on Z guests
accessing DB2 too (running in z/VM). IFL engine is cheaper than CP
(mips) engines and this difference could be a plus to him decide about
move from mainframe to open plataform (read Intel for front ends and a
Risc as DB server).

Thanks for comments about legal (IBM agreements) is this and if this
scenario will run ok.

--
Carlos Bodra
IBM Certified Specialist System z   
Sao Paulo - Brazil


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: A doubt: z/VM and Linux

2011-08-18 Thread Fernando Gieseler 
Carlos,

What is the Release of your VM?

Rgs,


Fernando Gieseler
f...@br.ibm.com
+55 51 9988 8177

-- mens. original --
Assunto: A doubt: z/VM and Linux
De: "Carlos Bodra - Pessoal" 
Data: 18/08/2011 09:13

Cross posted in VM and Linux390 lists.

A question arrised to me yesterday:

If I have and installation running z/VM (with no VSE or Z/OS guests),
but with DB2 and VisualAge I need an engine configured as CP or I can
run these workload under IFL?
Question arrised since customer should have some Linux on Z guests
accessing DB2 too (running in z/VM). IFL engine is cheaper than CP
(mips) engines and this difference could be a plus to him decide about
move from mainframe to open plataform (read Intel for front ends and a
Risc as DB server).

Thanks for comments about legal (IBM agreements) is this and if this
scenario will run ok.

--
Carlos Bodra
IBM Certified Specialist System z
Sao Paulo - Brazil


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

z114

2011-08-18 Thread Robert J Molerio 
We may be getting a z114 to test the feasibility of z/VM/Linux on Z for our
shop.

I'm not a mainframer but I'd like to know what storage devices can be
provisioned for the z114 and what the preferred method is to accomplish
this.
--
Thank you,

Bob Molerio
Systems Administrator
New York University
ITS Computer Facilities Services/Infrastructure
Level C-2
75 Third Avenue
New York NY 10003-5527
email:robert.mole...@nyu.edu 

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

udevd-349-: nss_ldap: failed to bind to LDAP server ldap:// . . .

2011-08-18 Thread Peter E. Abresch Jr. - at Pepco 
We finally have RACF LDAP server running on z/OS with the TDBM backend and
native authentication. We thought we were done as all our testing
completed successfully. However, when the operator booted Linux, the
console is flooded with the following messages on the shutdown and
startup. It is very difficult to catch a real error with these flood of
messages. Also, these messages are somewhat misleading as the LDAP server
is up and running and available. I am thinking that these messages are
produced as some service is shutdown and before some service starts. Here
is the challenge: How can we eliminate these messages during shutdowns and
boots?  There are all coming from udevd. Thanks in advance.

Peter

udevd-349-: nss_ldap: failed to bind to LDAP server ldap://contest: Can't
contact LDAP server
udevd-349-: nss_ldap: failed to bind to LDAP server ldap://contest: Can't
contact LDAP server
udevd-349-: nss_ldap: could not search LDAP server - Server is unavailable
udevd-349-: nss_ldap: failed to bind to LDAP server ldap://contest: Can't
contact LDAP server
udevd-349-: nss_ldap: failed to bind to LDAP server ldap://contest: Can't
contact LDAP server
udevd-349-: nss_ldap: could not search LDAP server - Server is unavailable
udevd-349-: nss_ldap: failed to bind to LDAP server ldap://contest: Can't
contact LDAP server
udevd-349-: nss_ldap: failed to bind to LDAP server ldap://contest: Can't
contact LDAP server

This Email message and any attachment may contain information that is
proprietary, legally privileged, confidential and/or subject to copyright
belonging to Pepco Holdings, Inc. or its affiliates ("PHI").  This Email is
intended solely for the use of the person(s) to which it is addressed.  If
you are not an intended recipient, or the employee or agent responsible for
delivery of this Email to the intended recipient(s), you are hereby notified
that any dissemination, distribution or copying of this Email is strictly
prohibited.  If you have received this message in error, please immediately
notify the sender and permanently delete this Email and any copies.  PHI
policies expressly prohibit employees from making defamatory or offensive
statements and infringing any copyright or any other legal right by Email
communication.  PHI will not accept any liability in respect of such
communications.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

patching frequency

2011-08-18 Thread Levy, Alan 
How often do you patch your linux servers. I have been patching once every 3-4 
months (over 100 servers - sles 9 thru 11) and have been told that I had to 
start patching much more frequently. I'd like to find out what other people are 
doing.

Thank you



--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: A doubt: z/VM and Linux

2011-08-18 Thread Bruce . Lightsey 
DB2 LUW runs quite well on Linux under z/VM and, for us at least, requires
fewer resources per server than the AIX boxes we came off of. Our VM LPAR
has no CPs defined to it - only IFLs. For us, the only need for CPs is to
run z/OS and to pay CA.  If I could get the WebSphere crew to move off of
AIX then we could take advantage of the hipersocket connections and really
cut down the network time - but that is a different fight..




 Carlos Bodra -
 Pessoal
   LINUX-390@VM.MARIST.EDU
 Sent by: Linux on  cc
 390 Port
   A doubt: z/VM and Linux


 08/18/2011 07:11
 AM


 Please respond to
 Linux on 390 Port
 






Cross posted in VM and Linux390 lists.

A question arrised to me yesterday:

If I have and installation running z/VM (with no VSE or Z/OS guests),
but with DB2 and VisualAge I need an engine configured as CP or I can
run these workload under IFL?
Question arrised since customer should have some Linux on Z guests
accessing DB2 too (running in z/VM). IFL engine is cheaper than CP
(mips) engines and this difference could be a plus to him decide about
move from mainframe to open plataform (read Intel for front ends and a
Risc as DB server).

Thanks for comments about legal (IBM agreements) is this and if this
scenario will run ok.

--
Carlos Bodra
IBM Certified Specialist System z
Sao Paulo - Brazil


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Really dumb basic zLinux DB2 LUW question

2011-08-18 Thread Bruce . Lightsey 
Hard part is done.
Now become the instance owner ( or dbadm or secadm  depending on how your
security is configured ) and grant the user connect on the database and any
other useful things they need ( like, maybe, select on a table or two).
If the user will actually be logging on to the Linux guest and making the
queries from the command line, then you need to add this line into the
users .profile :

//sqllib/db2profile

this will insure that all of the DB2 "stuff" is defined to the user session

Oh - welcome to my world since the description "our Mainframe DBA's who
have had DB2 LUW thrust upon them" fits me some few years ago.



   
 Tony Saul 
 To
 Sent by: Linux on LINUX-390@VM.MARIST.EDU 
 390 Port   cc
   Subject
   Really dumb basic zLinux DB2 LUW
   question
 08/17/2011 06:57  
 PM
   
   
 Please respond to 
 Linux on 390 Port 
   
   
   




This is from our Mainframe DBA's who have had DB2 LUW thrust upon them.

---
I am new to zLinux and DB2 LUW. I have to create a user and give them
select permissions to various tables.
I believe I need to do a
useradd -G  username -p password
So I have done that no problems.
How to get that username known to DB2 LUW, so that the user can connect and
do their SELECT queries?
(Told you it was basic!).
--

Regards,
Tony

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: z114

2011-08-18 Thread Martha McConaghy 
Bob,

I assume you are interested in SAN based storage, not direct attached
(System z can do it either way).  I'm only familiar with IBM storage, so
the others on the list will have to chime in on other vendors.  The FICON
adapters in the z114 can run in either FICON or FCP mode.  In FCP mode, they
can talk to any SCSI based SAN.  We use Cisco at Marist, but I'm pretty
certain that it can talk to the others as well.  On the storage side, we
use DS8000s for both direct attached (FICON) and SAN storage.  Most of the
cheaper IBM boxes such as DS4000s and DS5000s cannot talk directly to a System
z as they do not have the emulation code.  However, if you have an SVC, System
z can talk to it and any storage behind it.  (SVC does the emulation.)  There
is also the newer IBM XIV storage, which System z should be able to handle
without an SVC.  (We don't have one but that is what I've been told.)

Martha McConaghy
System Architect/Technical Lead
Marist College

On Thu, 18 Aug 2011 08:29:32 -0400 Robert J Molerio said:
>We may be getting a z114 to test the feasibility of z/VM/Linux on Z for our
>shop.
>
>I'm not a mainframer but I'd like to know what storage devices can be
>provisioned for the z114 and what the preferred method is to accomplish
>this.
>--
>Thank you,
>
>Bob Molerio
>Systems Administrator
>New York University
>ITS Computer Facilities Services/Infrastructure
>Level C-2
>75 Third Avenue
>New York NY 10003-5527
>email:robert.mole...@nyu.edu 
>
>--
>For LINUX-390 subscribe / signoff / archive access instructions,
>send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
>http://www.marist.edu/htbin/wlvindex?LINUX-390
>--
>For more information on Linux on System z, visit
>http://wiki.linuxvm.org/

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: z114

2011-08-18 Thread Raymond Higgs 
Linux on 390 Port  wrote on 08/18/2011 10:10:16
AM:

> From: Martha McConaghy 
> To: LINUX-390@vm.marist.edu
> Date: 08/18/2011 10:20 AM
> Subject: Re: z114
> Sent by: Linux on 390 Port 
>
> Bob,
>
> I assume you are interested in SAN based storage, not direct attached
> (System z can do it either way).  I'm only familiar with IBM storage, so
> the others on the list will have to chime in on other vendors.  The
FICON
> adapters in the z114 can run in either FICON or FCP mode.  In FCP mode,
they
> can talk to any SCSI based SAN.  We use Cisco at Marist, but I'm pretty
> certain that it can talk to the others as well.  On the storage side, we
> use DS8000s for both direct attached (FICON) and SAN storage.  Most of
the
> cheaper IBM boxes such as DS4000s and DS5000s cannot talk directly to a
System
> z as they do not have the emulation code.  However, if you have an SVC,
System
> z can talk to it and any storage behind it.  (SVC does the emulation.)
There
> is also the newer IBM XIV storage, which System z should be able to
handle
> without an SVC.  (We don't have one but that is what I've been told.)
>
> Martha McConaghy
> System Architect/Technical Lead
> Marist College



DS4000s and DS5000s can be hooked up without an SVC when the chpid
type=FCP.  We just haven't tested it very well.  So to be a supported
config., we say put an SVC in the middle.  SVC has been tested very well
with DS4000s and DS5000s by some other people in IBM.  We've tested SVC
very well with our FCP channel firmware.

DS4000s, DS5000s, and SVC can never be used if the chpid type=fc (ficon).

Regards,

Ray Higgs
System z FCP Firmware Development
Bld. 706, B42
2455 South Road
Poughkeepsie, NY 12601
(845) 435-8666,  T/L 295-8666
rayhi...@us.ibm.com

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: patching frequency

2011-08-18 Thread Marcy Cortes 
Monthly.


Marcy 

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@vm.marist.edu] On Behalf Of Levy, Alan
Sent: Thursday, August 18, 2011 6:22 AM
To: LINUX-390@vm.marist.edu
Subject: [LINUX-390] patching frequency

How often do you patch your linux servers. I have been patching once every 3-4 
months (over 100 servers - sles 9 thru 11) and have been told that I had to 
start patching much more frequently. I'd like to find out what other people are 
doing.

Thank you



--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Rhnsd?

2011-08-18 Thread Bauer, Bobby (NIH/CIT) [E] 
In our RHEL 6, there is an RHNSD task that the man page says queries 'Red Hat 
Network for updates and information'. It is suppose to check in every 4 hours, 
the default, this is also specified in /etc/sysconfig/rhn/rhnsd. 
According to /etc/init.d/rhnsd it uses /etc/sysconfig/rhn/up2date as its config 
file. In here specifies logging as /var/log/up2date

Looking at /var/log/up2date it appears the 4 hour default is ignored. In fact, 
I'm not sure what interval it is using:

[Thu Aug 18 02:21:30 2011] up2date logging into up2date server
[Thu Aug 18 02:21:34 2011] up2date successfully retrieved authentication token 
from up2date server
[Thu Aug 18 03:51:26 2011] up2date logging into up2date server
[Thu Aug 18 03:51:29 2011] up2date successfully retrieved authentication token 
from up2date server
[Thu Aug 18 06:21:30 2011] up2date logging into up2date server
[Thu Aug 18 06:21:33 2011] up2date successfully retrieved authentication token 
from up2date server
[Thu Aug 18 09:54:50 2011] up2date logging into up2date server
[Thu Aug 18 09:54:54 2011] up2date successfully retrieved authentication token 
from up2date server   
 
The RHN web page indicates the server "Checked In: 8/18/11 10:21:34 AM EDT"


Using the RHN web page, I specified 4 fixes to be pushed to this server and I 
expected it to happen when the server checked in. It didn't.

So can anybody explain the time that time intervals we are seeing and when RHN 
will actually push fixes to a server?
  
Thanks
Bobby Bauer
Center for Information Technology
National Institutes of Health
Bethesda, MD 20892-5628
301-594-7474
 

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: patching frequency

2011-08-18 Thread Patrick Spinler 
We only patch twice a year, unless there's a specific security fix we
need before then.

-- Pat

On 08/18/2011 10:24 AM, Marcy Cortes wrote:
> Monthly.
>
>
> Marcy
>
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@vm.marist.edu] On Behalf Of Levy, 
> Alan
> Sent: Thursday, August 18, 2011 6:22 AM
> To: LINUX-390@vm.marist.edu
> Subject: [LINUX-390] patching frequency
>
> How often do you patch your linux servers. I have been patching once every 
> 3-4 months (over 100 servers - sles 9 thru 11) and have been told that I had 
> to start patching much more frequently. I'd like to find out what other 
> people are doing.
>
> Thank you
>
>
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: patching frequency

2011-08-18 Thread Scott Rohling 
If someone told me to patch more frequently - I would make them explain
exactly how often and why.   For convenience sake, patching every x weeks or
months might be nice .. but there should be policies in place that
distinguish between security fixes and other types, and give
rules/guidelines for how soon such patches should be applied.   If these
policies don't exist - they should be developed - so I would be working to
define that.

There are so many approaches to patching..  'if it ain't broke, don't fix
it' - 'stay a release behind current' - 'apply security fixes immediately'
.. that being told 'patch more frequently' doesn't really give you much to
go on.  What is your strategy when it comes to software maintenance?  What
are the policies that must be adhered to?  What are the maintenance windows
that allow you to patch servers? Those seem like better indicators then
'frequency'.

Scott Rohling

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: patching frequency

2011-08-18 Thread Marcy Cortes 
I should explain further.  There is a group that evaluates everything put out 
by the support providers.
They categorize them into criticial, urgent, and standard.
There is an install time frame for each level of severity.
For all intents and purposes, it usually ends up monthly here.

Marcy 

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@vm.marist.edu] On Behalf Of Scott 
Rohling
Sent: Thursday, August 18, 2011 9:16 AM
To: LINUX-390@vm.marist.edu
Subject: Re: [LINUX-390] patching frequency

If someone told me to patch more frequently - I would make them explain
exactly how often and why.   For convenience sake, patching every x weeks or
months might be nice .. but there should be policies in place that
distinguish between security fixes and other types, and give
rules/guidelines for how soon such patches should be applied.   If these
policies don't exist - they should be developed - so I would be working to
define that.

There are so many approaches to patching..  'if it ain't broke, don't fix
it' - 'stay a release behind current' - 'apply security fixes immediately'
.. that being told 'patch more frequently' doesn't really give you much to
go on.  What is your strategy when it comes to software maintenance?  What
are the policies that must be adhered to?  What are the maintenance windows
that allow you to patch servers? Those seem like better indicators then
'frequency'.

Scott Rohling

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: patching frequency

2011-08-18 Thread David Stuart 
And one other thing. 

It doesn't matter what organization the patch is from, or what it's for, I 
always apply it in a Test/Dev environment to make sure it does no harm. 

Even 'super critical, got to have it now' patches go onto a Test/Dev 
environment, if only for a few days. 


Dave 



Dave Stuart
Prin. Info. Systems Support Analyst
County of Ventura, CA
805-662-6731
david.stu...@ventura.org
 


>>> "Scott Rohling"  8/18/2011 9:16 AM >>>
If someone told me to patch more frequently - I would make them explain
exactly how often and why.   For convenience sake, patching every x weeks or
months might be nice .. but there should be policies in place that
distinguish between security fixes and other types, and give
rules/guidelines for how soon such patches should be applied.   If these
policies don't exist - they should be developed - so I would be working to
define that.

There are so many approaches to patching..  'if it ain't broke, don't fix
it' - 'stay a release behind current' - 'apply security fixes immediately'
.. that being told 'patch more frequently' doesn't really give you much to
go on.  What is your strategy when it comes to software maintenance?  What
are the policies that must be adhered to?  What are the maintenance windows
that allow you to patch servers? Those seem like better indicators then
'frequency'.

Scott Rohling

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390 
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/ 

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

RACF and sysprog ID

2011-08-18 Thread Troy A Slaughter 
Hi all,

I'm trying to figure out the best way to define authority to a SYSPROG
group under RACF/VM.  I don't want SYSPROG members to have all authority
so I don't want to just add SPECIAL and OPERATION attributes to the group.
 But they should be able to perform system-wide list operations and such.
I also want them to have certain system display capabilities.  It seems
the only way to do that is via privilege classes.  If I'm right, it looks
like I will be doing a combination of RACF alterations to the SYSPROG
group as well as privilege class changes to the individual system IDs.


___
Troy Slaughter | Software Consultant | Mainframe Platform Engineering
50 South Lasalle Street, LQ 11SE, Chicago, Illinois, 60603 | Phone
312-557-6322 | Cell 312-208-3735 | t...@ntrs.com
Please visit northerntrust.com
CONFIDENTIALITY NOTICE: This communication is confidential, may be
privileged and is meant only for the intended recipient. If you are not
the intended recipient, please notify the sender ASAP and delete this
message from your system.

IRS CIRCULAR 230 NOTICE: To the extent that this message or any attachment
concerns tax matters, it is not intended to be used and cannot be used by
a taxpayer for the purpose of avoiding penalties that may be imposed by
law. For more information about this notice, see
http://www.northerntrust.com/circular230

P Please consider the environment before printing this e-mail.<>

Re: z114

2011-08-18 Thread David Boyes 
> We may be getting a z114 to test the feasibility of z/VM/Linux on Z for our
> shop.
> I'm not a mainframer but I'd like to know what storage devices can be
> provisioned for the z114 and what the preferred method is to accomplish
> this.

The usual suspects all work if you have FICON storage available. If you're 
looking to go totally low cost, use FCP storage exclusively. 

The only catch right now for a FCP-only system is that there is no support for 
SCSI tape for the base VM system, which means that you can't back up spool/NSS 
files using SPXTAPE. Everything else you can work around using disk-based 
methods. 

If you want to go completely tape-free, you probably should talk to CA about a 
copy of V/SEG. That gives you a way to deal with NSS files, and there are 
open-source utilities that can deal with normal spool files. 

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: RACF and sysprog ID

2011-08-18 Thread George, Kevin A 
On VM our SYSPROG users do not have any special RACF authority. We do have 
LOGONBY access to all of the maintenance machines including MAINT and TCPMAINT. 
This allows for any maintenance you may need to do. We also set the VM 
privileges to ABCDEFG for those users which allows them to see and control most 
things in VM.

-
Kevin George
U.S. Office of Personnel Management
1900 E Street NW
Room BH04L
Washington, DC 20415
(202) 606-1195 - Main
(202) 528-8215 - Cell

From: Linux on 390 Port [LINUX-390@VM.MARIST.EDU] On Behalf Of Troy A Slaughter 
[t...@ntrs.com]
Sent: Thursday, August 18, 2011 12:07 PM
To: LINUX-390@VM.MARIST.EDU
Subject: RACF and sysprog ID

Hi all,

I'm trying to figure out the best way to define authority to a SYSPROG group 
under RACF/VM.  I don't want SYSPROG members to have all authority so I don't 
want to just add SPECIAL and OPERATION attributes to the group.  But they 
should be able to perform system-wide list operations and such.  I also want 
them to have certain system display capabilities.  It seems the only way to do 
that is via privilege classes.  If I'm right, it looks like I will be doing a 
combination of RACF alterations to the SYSPROG group as well as privilege class 
changes to the individual system IDs.

[cid:_2_0F36822C0F367E5800589D60862578F0]
___
Troy Slaughter | Software Consultant | Mainframe Platform Engineering
50 South Lasalle Street, LQ 11SE, Chicago, Illinois, 60603 | Phone 312-557-6322 
| Cell 312-208-3735 | t...@ntrs.com 
Please visit northerntrust.com

CONFIDENTIALITY NOTICE: This communication is confidential, may be privileged 
and is meant only for the intended recipient. If you are not the intended 
recipient, please notify the sender ASAP and delete this message from your 
system.

IRS CIRCULAR 230 NOTICE: To the extent that this message or any attachment 
concerns tax matters, it is not intended to be used and cannot be used by a 
taxpayer for the purpose of avoiding penalties that may be imposed by law. For 
more information about this notice, see http://www.northerntrust.com/circular230

P Please consider the environment before printing this e-mail.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: udevd-349-: nss_ldap: failed to bind to LDAP server ldap:// . . .

2011-08-18 Thread Peter E. Abresch Jr. - at Pepco 
I have the following set in /etc/ldap.conf

bind_policy soft
nss_initgroups_ignoreusers
root,ldap,haldaemon,messagebus,dbus,bin,daemon,postfix,sshd,polkituser,uuidd,100,101

However, these messages are overwhelming. I get them for udevd and vol_id.
These might be a startup timing issue as soon as the network is available,
they go away. However, the nss_initgroups_ignoreusers should ignore this.
Am I still missing something?

/etc/nsswitch.conf contains:

passwd: ldap compat
shadow: ldap compat
group:  ldap compat


hosts:  files dns
networks:   files dns

services:   files
protocols:  files
rpc:files
ethers: files
netmasks:   files
netgroup:   files nis
publickey:  files

bootparams: files
automount:  files nis
aliases:files



From:   Peter E Abresch/EP/PEP
To: LINUX-390@vm.marist.edu
Date:   08/18/2011 09:00 AM
Subject:udevd-349-: nss_ldap: failed to bind to LDAP server
ldap:// . . .


We finally have RACF LDAP server running on z/OS with the TDBM backend and
native authentication. We thought we were done as all our testing
completed successfully. However, when the operator booted Linux, the
console is flooded with the following messages on the shutdown and
startup. It is very difficult to catch a real error with these flood of
messages. Also, these messages are somewhat misleading as the LDAP server
is up and running and available. I am thinking that these messages are
produced as some service is shutdown and before some service starts. Here
is the challenge: How can we eliminate these messages during shutdowns and
boots?  There are all coming from udevd. Thanks in advance.

Peter

udevd-349-: nss_ldap: failed to bind to LDAP server ldap://contest: Can't
contact LDAP server
udevd-349-: nss_ldap: failed to bind to LDAP server ldap://contest: Can't
contact LDAP server
udevd-349-: nss_ldap: could not search LDAP server - Server is unavailable
udevd-349-: nss_ldap: failed to bind to LDAP server ldap://contest: Can't
contact LDAP server
udevd-349-: nss_ldap: failed to bind to LDAP server ldap://contest: Can't
contact LDAP server
udevd-349-: nss_ldap: could not search LDAP server - Server is unavailable
udevd-349-: nss_ldap: failed to bind to LDAP server ldap://contest: Can't
contact LDAP server
udevd-349-: nss_ldap: failed to bind to LDAP server ldap://contest: Can't
contact LDAP server


This Email message and any attachment may contain information that is
proprietary, legally privileged, confidential and/or subject to copyright
belonging to Pepco Holdings, Inc. or its affiliates ("PHI").  This Email is
intended solely for the use of the person(s) to which it is addressed.  If
you are not an intended recipient, or the employee or agent responsible for
delivery of this Email to the intended recipient(s), you are hereby notified
that any dissemination, distribution or copying of this Email is strictly
prohibited.  If you have received this message in error, please immediately
notify the sender and permanently delete this Email and any copies.  PHI
policies expressly prohibit employees from making defamatory or offensive
statements and infringing any copyright or any other legal right by Email
communication.  PHI will not accept any liability in respect of such
communications.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: z114

2011-08-18 Thread O'Brien, Dennis L 
>> We may be getting a z114 to test the feasibility of z/VM/Linux on Z for our
>> shop.
>> I'm not a mainframer but I'd like to know what storage devices can be
>> provisioned for the z114 and what the preferred method is to accomplish
>> this.

>The usual suspects all work if you have FICON storage available. If you're 
>looking to go totally low cost, use FCP >storage exclusively. 

>The only catch right now for a FCP-only system is that there is no support for 
>SCSI tape for the base VM system, which >means that you can't back up 
>spool/NSS files using SPXTAPE. Everything else you can work around using 
>disk-based >methods.

The other catch is that if you want to use Single System Image (when it becomes 
available), you will need a 3390 for the shared cross-system serialization 
disk.  See presentation 9468 from the most recent SHARE for details. 


    
   Dennis O'Brien

"In case signals can neither be seen nor perfectly understood, no captain can 
do very wrong if he places his ship alongside that of an enemy."  -- Vice 
Admiral Lord Horatio Nelson's direction to his commanders prior to the Battle 
of Trafalgar

--
This message w/attachments (message) is intended solely for the use of the 
intended recipient(s) and may contain information that is privileged, 
confidential or proprietary. If you are not an intended recipient, please 
notify the sender, and then please delete and destroy all copies and 
attachments, and be advised that any review or dissemination of, or the taking 
of any action in reliance on, the information contained in or attached to this 
message is prohibited. 
Unless specifically indicated, this message is not an offer to sell or a 
solicitation of any investment products or other financial product or service, 
an official confirmation of any transaction, or an official statement of 
Sender. Subject to applicable law, Sender may intercept, monitor, review and 
retain e-communications (EC) traveling through its networks/systems and may 
produce any such EC to regulators, law enforcement, in litigation and as 
required by law. 
The laws of the country of each sender/recipient may impact the handling of EC, 
and EC may be archived, supervised and produced in countries other than the 
country in which you are located. This message cannot be guaranteed to be 
secure or free of errors or viruses. 

References to "Sender" are references to any subsidiary of Bank of America 
Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are 
Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a 
Condition to Any Banking Service or Activity * Are Not Insured by Any Federal 
Government Agency. Attachments that are part of this EC may have additional 
important disclosures and disclaimers, which you should read. This message is 
subject to terms available at the following link: 
http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you 
consent to the foregoing.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: RACF and sysprog ID

2011-08-18 Thread Clovis Pereira 
Hello, Troy.
Consider also give authority to individual userids, when justified. And
consider products self protection.
Example: DIRMAINT have his own mechanism to enable administrators
(AUTHUSER), RSCS have self protection for his commands, OPERATOR must be
managed by individuals defined into RTABLES, etc.,
For dangerous machines, use the LOGONBY option, enabling the individuals
to logon it, only when need. Example: Network (TCPIP) have the TCPMAINT
machine, RACF have AUDITOR, CP/CMS have MAINT. These machines  (MAINT,
AUDITOR, TCPMAINT) needs LOGONBY.
For the few powerful service machines, do not  enable them to logon
directly (TCPIP, RACFVM, OPERATOR): they must be managed by their partners
and must work disconnected. Or LOGONBY by a more restricted group, for
emergency only.
I know several customers that work this way, and they consider easy to
administer, after the first installation impact.
Regards,
__
Clovis



From:
"George, Kevin A" 
To:
LINUX-390@vm.marist.edu
Date:
18/08/2011 14:19
Subject:
Re: RACF and sysprog ID
Sent by:
Linux on 390 Port 



On VM our SYSPROG users do not have any special RACF authority. We do have
LOGONBY access to all of the maintenance machines including MAINT and
TCPMAINT. This allows for any maintenance you may need to do. We also set
the VM privileges to ABCDEFG for those users which allows them to see and
control most things in VM.

-
Kevin George
U.S. Office of Personnel Management
1900 E Street NW
Room BH04L
Washington, DC 20415
(202) 606-1195 - Main
(202) 528-8215 - Cell

From: Linux on 390 Port [LINUX-390@VM.MARIST.EDU] On Behalf Of Troy A
Slaughter [t...@ntrs.com]
Sent: Thursday, August 18, 2011 12:07 PM
To: LINUX-390@VM.MARIST.EDU
Subject: RACF and sysprog ID

Hi all,

I'm trying to figure out the best way to define authority to a SYSPROG
group under RACF/VM.  I don't want SYSPROG members to have all authority
so I don't want to just add SPECIAL and OPERATION attributes to the group.
 But they should be able to perform system-wide list operations and such.
I also want them to have certain system display capabilities.  It seems
the only way to do that is via privilege classes.  If I'm right, it looks
like I will be doing a combination of RACF alterations to the SYSPROG
group as well as privilege class changes to the individual system IDs.

[cid:_2_0F36822C0F367E5800589D60862578F0]
___
Troy Slaughter | Software Consultant | Mainframe Platform Engineering
50 South Lasalle Street, LQ 11SE, Chicago, Illinois, 60603 | Phone
312-557-6322 | Cell 312-208-3735 | t...@ntrs.com 
Please visit northerntrust.com

CONFIDENTIALITY NOTICE: This communication is confidential, may be
privileged and is meant only for the intended recipient. If you are not
the intended recipient, please notify the sender ASAP and delete this
message from your system.

IRS CIRCULAR 230 NOTICE: To the extent that this message or any attachment
concerns tax matters, it is not intended to be used and cannot be used by
a taxpayer for the purpose of avoiding penalties that may be imposed by
law. For more information about this notice, see
http://www.northerntrust.com/circular230

P Please consider the environment before printing this e-mail.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/




--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: patching frequency

2011-08-18 Thread Clovis Pereira 
Scott, only to feed this discussion:
Apply 5 patchs by month looks better than 15 by quarter or 30 by
half-year. Less corrections is faster, easy to analyze and less
problematic to fallback, if needed.
Is it a valid argument?
Regards,

PS. Only ideas, I don't work in the Linux team. Don't know the practical
issues...
__
Clovis



From:
Scott Rohling 
To:
LINUX-390@vm.marist.edu
Date:
18/08/2011 13:17
Subject:
Re: patching frequency
Sent by:
Linux on 390 Port 



If someone told me to patch more frequently - I would make them explain
exactly how often and why.   For convenience sake, patching every x weeks
or
months might be nice .. but there should be policies in place that
distinguish between security fixes and other types, and give
rules/guidelines for how soon such patches should be applied.   If these
policies don't exist - they should be developed - so I would be working to
define that.

There are so many approaches to patching..  'if it ain't broke, don't fix
it' - 'stay a release behind current' - 'apply security fixes immediately'
.. that being told 'patch more frequently' doesn't really give you much to
go on.  What is your strategy when it comes to software maintenance?  What
are the policies that must be adhered to?  What are the maintenance
windows
that allow you to patch servers? Those seem like better indicators then
'frequency'.

Scott Rohling

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/



--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: patching frequency

2011-08-18 Thread Scott Rohling 
Well - I mostly was objecting to the idea of 'patching more frequently'
without some structure and reasoning behind it.  Patching just to patch
isn't really a strategy.

But yes - I would agree that it is usually better to apply a few patches at
once rather than many, for the reasons you state.  So there is an argument
there for 'more frequently'.   But there's another argument, like stability
- which would rather reduce down times to the fewest instances possible --
and do a single large multiple patch rather then several small ones - to
reduce the number of potential outages.

Anyway - we need more info about the 'why' of being requested to patch more
frequently...   is there an intent or strategy behind it -- or is it coming
from someone who just thinks 'more is better'?   I still think a policy
needs to be defined and put in place if it is not already, and then talk
about frequency of patches in that context.

Scott Rohling


On Thu, Aug 18, 2011 at 12:37 PM, Clovis Pereira  wrote:

> Scott, only to feed this discussion:
> Apply 5 patchs by month looks better than 15 by quarter or 30 by
> half-year. Less corrections is faster, easy to analyze and less
> problematic to fallback, if needed.
> Is it a valid argument?
> Regards,
>
> PS. Only ideas, I don't work in the Linux team. Don't know the practical
> issues...
> __
> Clovis
>
>
>
> From:
> Scott Rohling 
> To:
> LINUX-390@vm.marist.edu
> Date:
> 18/08/2011 13:17
> Subject:
> Re: patching frequency
> Sent by:
> Linux on 390 Port 
>
>
>
> If someone told me to patch more frequently - I would make them explain
> exactly how often and why.   For convenience sake, patching every x weeks
> or
> months might be nice .. but there should be policies in place that
> distinguish between security fixes and other types, and give
> rules/guidelines for how soon such patches should be applied.   If these
> policies don't exist - they should be developed - so I would be working to
> define that.
>
> There are so many approaches to patching..  'if it ain't broke, don't fix
> it' - 'stay a release behind current' - 'apply security fixes immediately'
> .. that being told 'patch more frequently' doesn't really give you much to
> go on.  What is your strategy when it comes to software maintenance?  What
> are the policies that must be adhered to?  What are the maintenance
> windows
> that allow you to patch servers? Those seem like better indicators then
> 'frequency'.
>
> Scott Rohling
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
>
>
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
>

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: udevd-349-: nss_ldap: failed to bind to LDAP server ldap:// . . .

2011-08-18 Thread Patrick Spinler 
Your nsswitch says to search ldap before anything local.  I use "passwd:
files ldap" (same for shadow & group).  Thus, it never even tries ldap
if it finds a local entry.

This has also come in handy for a few weird exceptions where the
application absolutely had to do something weird and exceptional: I
could override it on the local box.

For example, two apps which absolutely had to use the same group name,
with different memberships.  Here, we have an enterprise oracle group
with dozens of hosts for which their dba's are all members of a common
group.  We also have a couple of one off oracle hosts for non-enterprise
groups who want the same names but different memberships.

It's a bit of a pain to manage those specific host exceptions, but at
least it's possible using 'files ldap'.

-- Pat

On 8/18/11 12:47 PM, Peter E. Abresch Jr. - at Pepco wrote:
> I have the following set in /etc/ldap.conf
>
> bind_policy soft
> nss_initgroups_ignoreusers
> root,ldap,haldaemon,messagebus,dbus,bin,daemon,postfix,sshd,polkituser,uuidd,100,101
>
> However, these messages are overwhelming. I get them for udevd and vol_id.
> These might be a startup timing issue as soon as the network is available,
> they go away. However, the nss_initgroups_ignoreusers should ignore this.
> Am I still missing something?
>
> /etc/nsswitch.conf contains:
>
> passwd: ldap compat
> shadow: ldap compat
> group:  ldap compat
>
>
> hosts:  files dns
> networks:   files dns
>
> services:   files
> protocols:  files
> rpc:files
> ethers: files
> netmasks:   files
> netgroup:   files nis
> publickey:  files
>
> bootparams: files
> automount:  files nis
> aliases:files
>
>
>
> From:   Peter E Abresch/EP/PEP
> To: LINUX-390@vm.marist.edu
> Date:   08/18/2011 09:00 AM
> Subject:udevd-349-: nss_ldap: failed to bind to LDAP server
> ldap:// . . .
>
>
> We finally have RACF LDAP server running on z/OS with the TDBM backend and
> native authentication. We thought we were done as all our testing
> completed successfully. However, when the operator booted Linux, the
> console is flooded with the following messages on the shutdown and
> startup. It is very difficult to catch a real error with these flood of
> messages. Also, these messages are somewhat misleading as the LDAP server
> is up and running and available. I am thinking that these messages are
> produced as some service is shutdown and before some service starts. Here
> is the challenge: How can we eliminate these messages during shutdowns and
> boots?  There are all coming from udevd. Thanks in advance.
>
> Peter
>
> udevd-349-: nss_ldap: failed to bind to LDAP server ldap://contest: Can't
> contact LDAP server
> udevd-349-: nss_ldap: failed to bind to LDAP server ldap://contest: Can't
> contact LDAP server
> udevd-349-: nss_ldap: could not search LDAP server - Server is unavailable
> udevd-349-: nss_ldap: failed to bind to LDAP server ldap://contest: Can't
> contact LDAP server
> udevd-349-: nss_ldap: failed to bind to LDAP server ldap://contest: Can't
> contact LDAP server
> udevd-349-: nss_ldap: could not search LDAP server - Server is unavailable
> udevd-349-: nss_ldap: failed to bind to LDAP server ldap://contest: Can't
> contact LDAP server
> udevd-349-: nss_ldap: failed to bind to LDAP server ldap://contest: Can't
> contact LDAP server
>
>
> This Email message and any attachment may contain information that is
> proprietary, legally privileged, confidential and/or subject to copyright
> belonging to Pepco Holdings, Inc. or its affiliates ("PHI").  This Email is
> intended solely for the use of the person(s) to which it is addressed.  If
> you are not an intended recipient, or the employee or agent responsible for
> delivery of this Email to the intended recipient(s), you are hereby notified
> that any dissemination, distribution or copying of this Email is strictly
> prohibited.  If you have received this message in error, please immediately
> notify the sender and permanently delete this Email and any copies.  PHI
> policies expressly prohibit employees from making defamatory or offensive
> statements and infringing any copyright or any other legal right by Email
> communication.  PHI will not accept any liability in respect of such
> communications.
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvi

Re: patching frequency

2011-08-18 Thread Philip Rowlands 

On 18/08/2011 14:22, Levy, Alan wrote:

How often do you patch your linux servers.


As often as necessary :)


I have been patching once every
3-4 months (over 100 servers - sles 9 thru 11) and have been told that I had
to start patching much more frequently. I'd like to find out what other
people are doing.


I wouldn't buy any arbitrary frequency for patching (unless I'm wearing a
Windows hat and it's Patch Tuesday).

A better question to answer, for sysadmins, security, and auditors, is "what
un-applied patches exist for our systems?"

You get this by combining discovery, triage, and patching itself. If you don't
do discovery for 3 months, how will you know about the next "critical" update?

Triage can be outsourced to an degree, if you take the vendor's metadata and the
CVSS rating, or something similar.

Policy then is an agreement of if/when to patch. Network attack from
unauthenticated user leading to root-level access? Maybe patch sooner. Fix that
corrects a memory leak in bash? Maybe patch later. Update to the latest version
of the printer database? Maybe patch never.

If you can state with certainly which patches remain unapplied, and point to the
policy that covers the patching priority for your organization, then you're in
good shape.


Cheers,
Phil

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/