date:20110520

Re: FCXPER315A message

2011-05-20 Thread Scott Rohling

You might want to see this thread:
http://www.mail-archive.com/ibmvm@listserv.uark.edu/msg16088.html

Scott
Rohling

On Fri, May 20, 2011 at 1:56 PM, Matos, Oswaldo <
oswaldo.ma...@br.experian.com> wrote:

> Hi,
>
>
> We recently began receiving this message,
> FCXPER315A Cl1 time slice 2.211 exceeds limit 1.000 (Q1=01 Qx=25)
> I don´t know exactly what its significance might be, someone can help me ?
> Thanks.
>
>
>
> 
> This email and any attachments are for the exclusive and confidential use
> of the named intended recipient(s) and may be legally privileged. Any
> review, re-transmission, dissemination or any other use of its contents, or
> taking of any action in reliance upon this information by persons and/or
> entities other than the named intended recipient(s) is strictly prohibited.
> If you have received this communication in error, please send this
> communication back to the sender, disregard its contents, and promptly
> delete the original message and any copy of it from your computer systems.
> The misuse of this message will be dealt according to company rules and
> current legislation. This message expresses the sender's point of view about
> the topics described and not necessarily expresses Serasa Experian's opinion
> about them.
>
> As informações contidas nesta mensagem e no(s) arquivo(s) anexo(s) são
> endereçadas exclusivamente à(s) pessoa(s) e/ou instituição(ões) acima
> indicada(s), e podem conter dados confidenciais. É expressamente proibido a
> pessoas não autorizadas, sob qualquer forma ou pretexto, utilizá-las,
> divulgá-las, alterá-las, de forma impressa ou copiada, total ou
> parcialmente. Caso tenha recebido esta mensagem erroneamente, por favor,
> notifique o remetente e providencie imediata exclusão da original e de
> qualquer cópia. O uso impróprio será tratado conforme as normas da empresa e
> da legislação em vigor. Esta mensagem expressa o posicionamento pessoal do
> subscritor e não reflete necessariamente a opinião da Serasa Experian.
>
> --
> 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: zFCP disk issue on linux system z

2011-05-20 Thread Steffen Maier


Hi Scott,

with RHEL(5), the persistent zfcp lun configuration is in the simple 
text file /etc/zfcp.conf. I don't know of any tools to manage this file 
except during the installation (with anaconda). Hence, any text editor 
will do.
See also 
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Installation_Guide/s1-s390info-zfcp.html 
which does describe post-installation configuration despite being part 
of the install guide.


Steffen

Linux on System z Development

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

On 05/20/2011 09:55 PM, Shumate, Scott wrote:

Sorry.  Im running red hat version 5.4



-Original Message-
From: Mark Post
Sent: Friday, May 20, 2011 3:49 PM



On 5/20/2011 at 02:59 PM, "Shumate, Scott"

wrote:

I ran into something interesting today with zFCP disk.  I've assigned
a LUN to a linux server and it worked great.  I did the following.

1.  Set the adapter on line with chccwdev -e command
2.  Added target port to FCP adapter by echoing port_add into wwpn.
ex.  echo 0x50060e800571f007>  port_add
3.  I cd to new port directory and added FCP LUN to that port by
echoing unit_add into new port directory.\
ex. Echo 0x000b>  unit_add
4.  SCSI disk was available.  I validated it with lsscsi command.

I noticed that the LUN size was incorrect so I wanted to change the
adapter to use a different LUN.  In this case 0x0007. I
removed the old LUN and changed added the new LUN with the following
script.

#!/bin/bash
OLD_PWD=`pwd`
DIR=/sys/bus/ccw/drivers/zfcp
DROP=0x000b
ADD=0x0007
PORT1=0x50060e800571f007
PORT2=0x50060e800571f017
PORT3=0x50060e800571f006
PORT4=0x50060e800571f016
echo 1>  /sys/bus/scsi/devices/0\:0\:0\:1/delete
echo 1>  /sys/bus/scsi/devices/1\:0\:0\:1/delete
echo 1>  /sys/bus/scsi/devices/2\:0\:0\:1/delete
echo 1>  /sys/bus/scsi/devices/3\:0\:0\:1/delete
echo $DROP>  $DIR/0.0.dc00/$PORT1/unit_remove echo $DROP>
$DIR/0.0.dd00/$PORT2/unit_remove echo $DROP>
$DIR/0.0.de00/$PORT3/unit_remove echo $DROP>
$DIR/0.0.df00/$PORT4/unit_remove echo $ADD>
$DIR/0.0.dc00/$PORT1/unit_add echo $ADD>
$DIR/0.0.dd00/$PORT2/unit_add echo $ADD>
$DIR/0.0.de00/$PORT3/unit_add echo $ADD>
$DIR/0.0.df00/$PORT4/unit_add

It shows the new LUN.  I validated it with the lszfcp -D command.
Output below:
0.0.dc00/0x50060e800571f007/0x0007 0:0:0:1
0.0.dd00/0x50060e800571f017/0x0007 1:0:0:1
0.0.de00/0x50060e800571f006/0x0007 2:0:0:1
0.0.df00/0x50060e800571f016/0x0007 3:0:0:1

So you can see that the lun is now 0X0007.  When I reboot, it goes
back to 0x000b.  What am I missing?  To get around this issue, I had
to move LUNs around on the disk subsystem side.  Can someone give me a



good process of removing LUNs and then readd them or tell me what I'm
missing.


You didn't say what distribution you're running.  That's not relevant to
why you're seeing this happen, but it is relevant to how you fix it.

Essentially, every command you issued is a dynamic change to the system.
Nothing was done to tell the system to do anything different on the next
boot.  If you are running SLES, then the answer is to either:
1. Use YaST to do this work.
2. Use zfcp_host_configure and zfcp_disk_configure 3. Manually update
all the necessary configuration files yourself.

I would pick option #1 or #2.  :)


--
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: zFCP disk issue on linux system z

2011-05-20 Thread Shumate, Scott

Sorry.  Im running red hat version 5.4 


Thanks
Scott

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
Mark Post
Sent: Friday, May 20, 2011 3:49 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: zFCP disk issue on linux system z

>>> On 5/20/2011 at 02:59 PM, "Shumate, Scott" 
wrote: 
> I ran into something interesting today with zFCP disk.  I've assigned 
> a LUN to a linux server and it worked great.  I did the following.
> 
> 1.Set the adapter on line with chccwdev -e command
> 2.Added target port to FCP adapter by echoing port_add into wwpn.
>   ex.  echo 0x50060e800571f007 > port_add
> 3.I cd to new port directory and added FCP LUN to that port by
> echoing unit_add into new port directory.\
>   ex. Echo 0x000b > unit_add
> 4.SCSI disk was available.  I validated it with lsscsi command.
> 
> I noticed that the LUN size was incorrect so I wanted to change the 
> adapter to use a different LUN.  In this case 0x0007. I 
> removed the old LUN and changed added the new LUN with the following 
> script.
> 
> #!/bin/bash
> OLD_PWD=`pwd`
> DIR=/sys/bus/ccw/drivers/zfcp
> DROP=0x000b
> ADD=0x0007
> PORT1=0x50060e800571f007
> PORT2=0x50060e800571f017
> PORT3=0x50060e800571f006
> PORT4=0x50060e800571f016
> echo 1 > /sys/bus/scsi/devices/0\:0\:0\:1/delete
> echo 1 > /sys/bus/scsi/devices/1\:0\:0\:1/delete
> echo 1 > /sys/bus/scsi/devices/2\:0\:0\:1/delete
> echo 1 > /sys/bus/scsi/devices/3\:0\:0\:1/delete
> echo $DROP > $DIR/0.0.dc00/$PORT1/unit_remove echo $DROP > 
> $DIR/0.0.dd00/$PORT2/unit_remove echo $DROP > 
> $DIR/0.0.de00/$PORT3/unit_remove echo $DROP > 
> $DIR/0.0.df00/$PORT4/unit_remove echo $ADD > 
> $DIR/0.0.dc00/$PORT1/unit_add echo $ADD > 
> $DIR/0.0.dd00/$PORT2/unit_add echo $ADD > 
> $DIR/0.0.de00/$PORT3/unit_add echo $ADD > 
> $DIR/0.0.df00/$PORT4/unit_add
> 
> It shows the new LUN.  I validated it with the lszfcp -D command.
> Output below:
>   0.0.dc00/0x50060e800571f007/0x0007 0:0:0:1
>   0.0.dd00/0x50060e800571f017/0x0007 1:0:0:1
>   0.0.de00/0x50060e800571f006/0x0007 2:0:0:1
>   0.0.df00/0x50060e800571f016/0x0007 3:0:0:1
> 
> So you can see that the lun is now 0X0007.  When I reboot, it goes 
> back to 0x000b.  What am I missing?  To get around this issue, I had 
> to move LUNs around on the disk subsystem side.  Can someone give me a

> good process of removing LUNs and then readd them or tell me what I'm
> missing.   

You didn't say what distribution you're running.  That's not relevant to
why you're seeing this happen, but it is relevant to how you fix it.

Essentially, every command you issued is a dynamic change to the system.
Nothing was done to tell the system to do anything different on the next
boot.  If you are running SLES, then the answer is to either:
1. Use YaST to do this work.
2. Use zfcp_host_configure and zfcp_disk_configure 3. Manually update
all the necessary configuration files yourself.

I would pick option #1 or #2.  :)


Mark Post

--
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/

FCXPER315A message

2011-05-20 Thread Matos, Oswaldo

Hi,


We recently began receiving this message,
FCXPER315A Cl1 time slice 2.211 exceeds limit 1.000 (Q1=01 Qx=25)
I don´t know exactly what its significance might be, someone can help me ?
Thanks.




This email and any attachments are for the exclusive and confidential use of 
the named intended recipient(s) and may be legally privileged. Any review, 
re-transmission, dissemination or any other use of its contents, or taking of 
any action in reliance upon this information by persons and/or entities other 
than the named intended recipient(s) is strictly prohibited. If you have 
received this communication in error, please send this communication back to 
the sender, disregard its contents, and promptly delete the original message 
and any copy of it from your computer systems. The misuse of this message will 
be dealt according to company rules and current legislation. This message 
expresses the sender's point of view about the topics described and not 
necessarily expresses Serasa Experian's opinion about them.

As informações contidas nesta mensagem e no(s) arquivo(s) anexo(s) são 
endereçadas exclusivamente à(s) pessoa(s) e/ou instituição(ões) acima 
indicada(s), e podem conter dados confidenciais. É expressamente proibido a 
pessoas não autorizadas, sob qualquer forma ou pretexto, utilizá-las, 
divulgá-las, alterá-las, de forma impressa ou copiada, total ou parcialmente. 
Caso tenha recebido esta mensagem erroneamente, por favor, notifique o 
remetente e providencie imediata exclusão da original e de qualquer cópia. O 
uso impróprio será tratado conforme as normas da empresa e da legislação em 
vigor. Esta mensagem expressa o posicionamento pessoal do subscritor e não 
reflete necessariamente a opinião da Serasa Experian.

--
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: zFCP disk issue on linux system z

2011-05-20 Thread Mark Post

>>> On 5/20/2011 at 02:59 PM, "Shumate, Scott"  wrote: 
> I ran into something interesting today with zFCP disk.  I've assigned a
> LUN to a linux server and it worked great.  I did the following.
> 
> 1.Set the adapter on line with chccwdev -e command
> 2.Added target port to FCP adapter by echoing port_add into wwpn.
>   ex.  echo 0x50060e800571f007 > port_add
> 3.I cd to new port directory and added FCP LUN to that port by
> echoing unit_add into new port directory.\
>   ex. Echo 0x000b > unit_add
> 4.SCSI disk was available.  I validated it with lsscsi command.
> 
> I noticed that the LUN size was incorrect so I wanted to change the
> adapter to use a different LUN.  In this case 0x0007. I
> removed the old LUN and changed added the new LUN with the following
> script.
> 
> #!/bin/bash
> OLD_PWD=`pwd`
> DIR=/sys/bus/ccw/drivers/zfcp
> DROP=0x000b
> ADD=0x0007
> PORT1=0x50060e800571f007
> PORT2=0x50060e800571f017
> PORT3=0x50060e800571f006
> PORT4=0x50060e800571f016
> echo 1 > /sys/bus/scsi/devices/0\:0\:0\:1/delete
> echo 1 > /sys/bus/scsi/devices/1\:0\:0\:1/delete
> echo 1 > /sys/bus/scsi/devices/2\:0\:0\:1/delete
> echo 1 > /sys/bus/scsi/devices/3\:0\:0\:1/delete
> echo $DROP > $DIR/0.0.dc00/$PORT1/unit_remove echo $DROP >
> $DIR/0.0.dd00/$PORT2/unit_remove echo $DROP >
> $DIR/0.0.de00/$PORT3/unit_remove echo $DROP >
> $DIR/0.0.df00/$PORT4/unit_remove echo $ADD >
> $DIR/0.0.dc00/$PORT1/unit_add echo $ADD > $DIR/0.0.dd00/$PORT2/unit_add
> echo $ADD > $DIR/0.0.de00/$PORT3/unit_add echo $ADD >
> $DIR/0.0.df00/$PORT4/unit_add
> 
> It shows the new LUN.  I validated it with the lszfcp -D command.
> Output below:
>   0.0.dc00/0x50060e800571f007/0x0007 0:0:0:1
>   0.0.dd00/0x50060e800571f017/0x0007 1:0:0:1
>   0.0.de00/0x50060e800571f006/0x0007 2:0:0:1
>   0.0.df00/0x50060e800571f016/0x0007 3:0:0:1
> 
> So you can see that the lun is now 0X0007.  When I reboot, it goes back
> to 0x000b.  What am I missing?  To get around this issue, I had to move
> LUNs around on the disk subsystem side.  Can someone give me a good
> process of removing LUNs and then readd them or tell me what I'm
> missing.   

You didn't say what distribution you're running.  That's not relevant to why 
you're seeing this happen, but it is relevant to how you fix it.

Essentially, every command you issued is a dynamic change to the system.  
Nothing was done to tell the system to do anything different on the next boot.  
If you are running SLES, then the answer is to either:
1. Use YaST to do this work.
2. Use zfcp_host_configure and zfcp_disk_configure
3. Manually update all the necessary configuration files yourself.

I would pick option #1 or #2.  :)


Mark Post

--
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/

zFCP disk issue on linux system z

2011-05-20 Thread Shumate, Scott

Thanks
Scott

-Original Message-
From: Shumate, Scott 
Sent: Friday, May 20, 2011 2:58 PM
To: 'Linux on 390 Port'
Subject: RE: cross compiling for s390

I ran into something interesting today with zFCP disk.  I've assigned a
LUN to a linux server and it worked great.  I did the following.

1.  Set the adapter on line with chccwdev -e command
2.  Added target port to FCP adapter by echoing port_add into wwpn.
ex.  echo 0x50060e800571f007 > port_add
3.  I cd to new port directory and added FCP LUN to that port by
echoing unit_add into new port directory.\
ex. Echo 0x000b > unit_add
4.  SCSI disk was available.  I validated it with lsscsi command.

I noticed that the LUN size was incorrect so I wanted to change the
adapter to use a different LUN.  In this case 0x0007. I
removed the old LUN and changed added the new LUN with the following
script.

#!/bin/bash
OLD_PWD=`pwd`
DIR=/sys/bus/ccw/drivers/zfcp
DROP=0x000b
ADD=0x0007
PORT1=0x50060e800571f007
PORT2=0x50060e800571f017
PORT3=0x50060e800571f006
PORT4=0x50060e800571f016
echo 1 > /sys/bus/scsi/devices/0\:0\:0\:1/delete
echo 1 > /sys/bus/scsi/devices/1\:0\:0\:1/delete
echo 1 > /sys/bus/scsi/devices/2\:0\:0\:1/delete
echo 1 > /sys/bus/scsi/devices/3\:0\:0\:1/delete
echo $DROP > $DIR/0.0.dc00/$PORT1/unit_remove echo $DROP >
$DIR/0.0.dd00/$PORT2/unit_remove echo $DROP >
$DIR/0.0.de00/$PORT3/unit_remove echo $DROP >
$DIR/0.0.df00/$PORT4/unit_remove echo $ADD >
$DIR/0.0.dc00/$PORT1/unit_add echo $ADD > $DIR/0.0.dd00/$PORT2/unit_add
echo $ADD > $DIR/0.0.de00/$PORT3/unit_add echo $ADD >
$DIR/0.0.df00/$PORT4/unit_add

It shows the new LUN.  I validated it with the lszfcp -D command.
Output below:
0.0.dc00/0x50060e800571f007/0x0007 0:0:0:1
0.0.dd00/0x50060e800571f017/0x0007 1:0:0:1
0.0.de00/0x50060e800571f006/0x0007 2:0:0:1
0.0.df00/0x50060e800571f016/0x0007 3:0:0:1

So you can see that the lun is now 0X0007.  When I reboot, it goes back
to 0x000b.  What am I missing?  To get around this issue, I had to move
LUNs around on the disk subsystem side.  Can someone give me a good
process of removing LUNs and then readd them or tell me what I'm
missing. 

Regards,

Scott Shumate
Software Systems Prog Spec
Branch Bank & Trust
Assistant Vice President
Mainframe Support
Mail Code: 100-99-09-10
Work:  (252) 246-2306
Cell:(252) 373-9605
--
 .~.
 /\/\
/(  )\
^^-^^
Linux on Systems Z
-

--
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: cross compiling for s390

2011-05-20 Thread Shumate, Scott

I ran into something interesting today with zFCP disk.  I've assigned a
LUN to a linux server and it worked great.  I did the following.

1.  Set the adapter on line with chccwdev -e command
2.  Added target port to FCP adapter by echoing port_add into wwpn.
ex.  echo 0x50060e800571f007 > port_add
3.  I cd to new port directory and added FCP LUN to that port by
echoing unit_add into new port directory.\
ex. Echo 0x000b > unit_add
4.  SCSI disk was available.  I validated it with lsscsi command.

I noticed that the LUN size was incorrect so I wanted to change the
adapter to use a different LUN.  In this case 0x0007. I
removed the old LUN and changed added the new LUN with the following
script.

#!/bin/bash
OLD_PWD=`pwd`
DIR=/sys/bus/ccw/drivers/zfcp
DROP=0x000b
ADD=0x0007
PORT1=0x50060e800571f007
PORT2=0x50060e800571f017
PORT3=0x50060e800571f006
PORT4=0x50060e800571f016
echo 1 > /sys/bus/scsi/devices/0\:0\:0\:1/delete
echo 1 > /sys/bus/scsi/devices/1\:0\:0\:1/delete
echo 1 > /sys/bus/scsi/devices/2\:0\:0\:1/delete
echo 1 > /sys/bus/scsi/devices/3\:0\:0\:1/delete
echo $DROP > $DIR/0.0.dc00/$PORT1/unit_remove
echo $DROP > $DIR/0.0.dd00/$PORT2/unit_remove
echo $DROP > $DIR/0.0.de00/$PORT3/unit_remove
echo $DROP > $DIR/0.0.df00/$PORT4/unit_remove
echo $ADD > $DIR/0.0.dc00/$PORT1/unit_add
echo $ADD > $DIR/0.0.dd00/$PORT2/unit_add
echo $ADD > $DIR/0.0.de00/$PORT3/unit_add
echo $ADD > $DIR/0.0.df00/$PORT4/unit_add

It shows the new LUN.  I validated it with the lszfcp -D command.
Output below:
0.0.dc00/0x50060e800571f007/0x0007 0:0:0:1
0.0.dd00/0x50060e800571f017/0x0007 1:0:0:1
0.0.de00/0x50060e800571f006/0x0007 2:0:0:1
0.0.df00/0x50060e800571f016/0x0007 3:0:0:1

So you can see that the lun is now 0X0007.  When I reboot, it goes back
to 0x000b.  What am I missing?  To get around this issue, I had to move
LUNs around on the disk subsystem side.  Can someone give me a good
process of removing LUNs and then readd them or tell me what I'm
missing. 






Regards,

Scott Shumate
Software Systems Prog Spec
Branch Bank & Trust
Assistant Vice President
Mainframe Support
Mail Code: 100-99-09-10
Work:  (252) 246-2306
Cell:(252) 373-9605
--
 .~.
 /\/\
/(  )\
^^-^^
Linux on Systems Z
-

--
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: GPG Key Ring Generation on zLinux Fails

2011-05-20 Thread Philipp Kern

Hi,

am Fri, May 20, 2011 at 03:56:06PM +0100 hast du folgendes geschrieben:
> >I've tried everything I can think of, and my zLinux support team says
> >that this is a known problem with virtualized environments. Does anyone
> >have any suggestions on how to get key ring generation to reliably work
> >on zLinux?

you might want to use an Entropy Key on another !z machine and ship its entropy
to the z/Linux guests.

> A quick Google search didn't turn up any suggestion of how to trigger
> more entropy for /dev/random, or how to persuade gpg to read from
> sources other than /dev/random, unfortunately. Have you considered
> generating the keys on a different host/architecture?

For the truely insane ones you can bind-mount /dev/urandom over /dev/random in
a mount namespace to let GPG use it, but not to disturb other applications
relying on /dev/random being sane.  But then that's really not recommended for
secure key generation.

Kind regards,
Philipp Kern
-- 
 .''`.  Philipp KernDebian Developer
: :' :  http://philkern.de Stable Release Manager
`. `'   xmpp:p...@0x539.de Wanna-Build Admin
  `-finger pkern/k...@db.debian.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/


signature.asc
Description: Digital signature

Re: GPG Key Ring Generation on zLinux Fails

2011-05-20 Thread Philip Rowlands


On 20/05/2011 15:00, Mark Jacobs wrote:

I'm attempting to generate a key ring in a zLinux environment using gpg
but I can't get enough entropy to supply the generation process with
enough random bytes.

Not enough random bytes available. Please do some other work to give the
OS a chance to collect more entropy! (Need 284 more bytes)

I've tried everything I can think of, and my zLinux support team says
that this is a known problem with virtualized environments. Does anyone
have any suggestions on how to get key ring generation to reliably work
on zLinux?


How strict are you about using PRNG output, rather than collected
entropy? /dev/urandom, or CPACF's /dev/prandom (not certain whether this
one involves any hardware / environmental entropy) don't block on read.

A quick Google search didn't turn up any suggestion of how to trigger
more entropy for /dev/random, or how to persuade gpg to read from
sources other than /dev/random, unfortunately. Have you considered
generating the keys on a different host/architecture?


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/

Re: GPG Key Ring Generation on zLinux Fails

2011-05-20 Thread Richard Troth

Try creating a few large temporary files with random content.  Then
change them up (gzip, then gunzip, stuff like that).  The disk
activity is one way to generate entropy.

Better, configure GPG to use the crypto hardware.  (Assuming you do
have a crypto card.)  I used to know how to do this with SSH.  Haven't
found how to do it with GPG.

-- R;   <><
Rick Troth
Velocity Software
http://www.velocitysoftware.com/





On Fri, May 20, 2011 at 10:00, Mark Jacobs  wrote:
> I'm attempting to generate a key ring in a zLinux environment using gpg
> but I can't get enough entropy to supply the generation process with
> enough random bytes.
>
> Not enough random bytes available. Please do some other work to give the
> OS a chance to collect more entropy! (Need 284 more bytes)
>
> I've tried everything I can think of, and my zLinux support team says
> that this is a known problem with virtualized environments. Does anyone
> have any suggestions on how to get key ring generation to reliably work
> on zLinux?
>
> --
> Mark Jacobs
> Time Customer Service
> Tampa, FL
> 
>
> Some people are electrifying, they light up
> a room when they leave.
>
> --
> 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/

Red Hat Enterprise Linux 6.1 distribution-specific documentation available

2011-05-20 Thread Dorothea Matthaeus

The following Linux on System z publications are now available at:

http://www.ibm.com/developerworks/linux/linux390/documentation_red_hat.html



Device Drivers, Features, and Commands on Red Hat Enterprise Linux 6.1

Abstract
This document describes the device drivers, features, and commands
available to SUSE Linux Enterprise Server 11 SP1 for the control of  IBM
System z devices and attachments.

Part 1. General concepts
  Chapter 1. How devices are accessed by Linux
  Chapter 2. Devices in sysfs
Chapter 3. Kernel and module parameters

Part 2. Storage
  Chapter 4. DASD device driver
  Chapter 5. SCSI-over-Fibre Channel device driver
  Chapter 6. Channel-attached tape device driver
  Chapter 7. XPRAM device driver

Part 3. Networking
  Chapter 8. qeth device driver for OSA-Express (QDIO) and HiperSockets
  Chapter 9. OSA-Express SNMP subagent support
  Chapter 10. LAN channel station device driver
  Chapter 11. CTCM device driver

Part 4. z/VM virtual server integration
  Chapter 12. z/VM concepts
  Chapter 13. Writing kernel APPLDATA records
  Chapter 14. Writing application APPLDATA records
  Chapter 15. Reading z/VM monitor records
  Chapter 16. z/VM recording device driver
  Chapter 17. z/VM unit record device driver
  Chapter 18. z/VM DCSS device driver
  Chapter 19. Shared kernel support
  Chapter 20. Watchdog device driver
Chapter 21. z/VM CP interface device driver
Chapter 22. Deliver z/VM CP special messages as uevents
Chapter 23. AF_IUCV address family support
  Chapter 24. Cooperative memory management

Part 5. System resources
  Chapter 25. Managing CPUs
  Chapter 26. Managing hotplug memory
  Chapter 27. Large page support
  Chapter 28. S/390 hypervisor file system
  Chapter 29. ETR and STP based clock synchronization

Part 6. Security
  Chapter 30. Generic cryptographic device driver
  Chapter 31. Pseudo-random number device driver
  Chapter 32. Data execution protection for user processes

Part 7. Booting and shutdown
  Chapter 33. Console device drivers
  Chapter 34. Initial program loader for System z - zipl
  Chapter 35. Booting Linux
Chapter 36. Suspending and resuming Linux
  Chapter 37. Shutdown actions

Part 8. Diagnostics and troubleshooting
Chapter 38. Logging I/0 subchannel status information
  Chapter 39. Channel measurement facility
  Chapter 40. Control program identification
Chapter 41. Activating automatic problem reporting
Chapter 42. Avoiding common pitfalls

Part 9. Reference
  Chapter 43. Commands for Linux on System z
  Chapter 45. Selected kernel parameters
  Chapter 46. Linux diagnose code use


Using the Dump Tools on Red Hat Enterprise Linux 6.1


Abstract: This document describes tools for obtaining dumps of Linux on
System z instances.

Table of Contents:
Chapter 1. Introduction
Chapter 2 Using a DASD dump device
Chapter 3. Using DASD devices for multi-volume dump
Chapter 4. Using a tape dump device
Chapter 5. Using a SCSI dump device
Chapter 6. Using VMDUMP
Chapter 7. Handling large dumps
Chapter 8. Sharing dump devices
Appendix A. Examples for initiating dumps
Appendix B. Obtaining a dump with limited size
Appendix C. Command summary
Appendix D. Preparing for analyzing a dump




Dorothea Matthaeus
Linux on System z Information Development
IBM Deutschland Research & Development GmbH

--
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/

GPG Key Ring Generation on zLinux Fails

2011-05-20 Thread Mark Jacobs


I'm attempting to generate a key ring in a zLinux environment using gpg
but I can't get enough entropy to supply the generation process with
enough random bytes.

Not enough random bytes available. Please do some other work to give the
OS a chance to collect more entropy! (Need 284 more bytes)

I've tried everything I can think of, and my zLinux support team says
that this is a known problem with virtualized environments. Does anyone
have any suggestions on how to get key ring generation to reliably work
on zLinux?

--
Mark Jacobs
Time Customer Service
Tampa, FL


Some people are electrifying, they light up
a room when they leave.

--
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: FCXPER315A message

Re: zFCP disk issue on linux system z

Re: zFCP disk issue on linux system z

FCXPER315A message

Re: zFCP disk issue on linux system z

zFCP disk issue on linux system z

Re: cross compiling for s390

Re: GPG Key Ring Generation on zLinux Fails

Re: GPG Key Ring Generation on zLinux Fails

Re: GPG Key Ring Generation on zLinux Fails

Red Hat Enterprise Linux 6.1 distribution-specific documentation available

GPG Key Ring Generation on zLinux Fails

12 matches

Site Navigation

Mail list logo

Footer information