We do not have an ESM in place at the moment.  We are still new to zLinux and 
still getting out feet wet. 



-----Original Message-----
From: The IBM z/VM Operating System [mailto:[email protected]] On Behalf 
Of Mike Walter
Sent: Tuesday, March 01, 2011 4:43 PM
To: [email protected]
Subject: Re: zLinux OS disk read-only

Good ideas!

> Again, the console log would lead to the footprint of the perp that
would tell all.

Which leads to another place that might tell... if you have an ESM 
(External Security Manager) it might have an audit file showing LINK 
attempts. 
For example, VM:Secure writes its audit file to the VMSECURE 1D0 mdisk.

Mike Walter
Aon Corporation
The opinions expressed herein are mine alone, not my employer's.



RPN01 <[email protected]> 

Sent by: "The IBM z/VM Operating System" <[email protected]>
03/01/2011 04:28 PM
Please respond to
"The IBM z/VM Operating System" <[email protected]>



To
[email protected]
cc

Subject
Re: zLinux OS disk read-only






You said you ended up with the disk in read-only mode, but M would imply 
that if you couldn?t get it in read-write mode, you wouldn?t get it at 
all. This would lead me to believe that there might have been fingers at 
work on the console after the log-in and before the boot that might have 
subsequently linked the disk, possibly with a ?LINK * 200 200 MR?, maybe? 
Again, the console log would lead to the footprint of the perp that would 
tell all.

Another fine way to handle the situation and allow some control would be 
to IPL the guest into CMS before starting the Linux guest. Set up the 
machine using the CMS profile and do your sanity checks there, then IPL 
the Linux boot disk when you know things will go well. Given our two CEC 
environment, and our history before going into CSE, we use this method to 
check that the image was last run on the current LPAR before IPLing the 
Linux image, to be sure that it can?t be running in the other CEC. We had 
the same image booted on both systems at the same time once too often, 
destroying the image (i.e... Once) We use a read-only CMS 191 with a 
profile to perform this vital sanity check (for us) before allowing the 
Linux image to start. (In fact, all our linux images share the same 191 
minidisk.) Checking the Linux disks to be sure they are RW certainly 
wouldn?t hurt as well. It would be a simple task, especially if you stuck 
to a standard addressing scheme for all your images.

Just an idea to think about. 

-- 
Robert P. Nix          Mayo Foundation        .~.
RO-OC-1-18             200 First Street SW    /V\
507-284-0844           Rochester, MN 55905   /( )\
-----                                        ^^-^^
"In theory, theory and practice are the same, but
 in practice, theory and practice are different."



On 3/1/11 3:40 PM, "Perez, Steve S" <[email protected]> wrote:

I issued a LINK RR against it and did a Q LINKS and it shows no other link 
access to that disk.  Would it be possible that when we paused PPRC and 
suspended Global Mirror on the z/OS LPAR (shared volumes between all 
LPARS) that it may have accessed the dasd the minidisk is on in write mode 
and caused the access mode on the z/VM LPAR to go into a READ-MODE?   Is 
that probable?



Steve. 
From: The IBM z/VM Operating System [mailto:[email protected]] On 
Behalf Of Mark Pace
Sent: Tuesday, March 01, 2011 2:57 PM
To: [email protected]
Subject: Re: zLinux OS disk read-only

M Multiple-write access. Write access is established unless another user 
holds
a write, a stable (SR, SW, SM) or an exclusive (ER, EW) mode access to
the disk.

Looks like some other VM has that disk linked in write mode.

On Tue, Mar 1, 2011 at 3:53 PM, Perez, Steve S <[email protected]> 
wrote:
The  disk is defined as follows. This is an excerpt from the CP directory:

IPL 200
.....
LINK RHMASTER 199 199 RR
MDISK 200  3390 1 10016 LX53B5 M

Unfortunately, the console log did not get  spooled so I don't know what 
the log would have indicated for that disk when  the guest machine came 
up.  That's on my follow-up list.  The guest  machine is IPL'd off of its 
OS (disk 200) disk when it comes up (in its CP  Directory) so I need to 
find a way to spool the console when it starts and not  later after it has 
gone through its  initialization.


Thanks,
Steve

-----Original  Message-----
From: The IBM z/VM Operating System [mailto:[email protected]] On 
Behalf  Of RPN01
Sent: Tuesday, March 01, 2011 2:33 PM
To: [email protected]
Subject:  Re: zLinux OS disk read-only

How is the disk defined in the CP  Directory entry (i.e. What is the mode 
of the disk), and what is in the  console log when the user was logged in 
that could give a clue about the  status of the disk when the user was 
initialized?

The mode will tell  you the condition(s) that could lead to it being read 
only (other users having  it read/write or even read only), and the log 
may even tell you which or how  many users gummed up the works, or when 
things when oval on you.

In any  case, it had to have happened at some point, and there has to be a 
footprint,  if you keep your logs.

--
Robert P. Nix           Mayo Foundation        .~.
RO-OC-1-18              200 First Street SW     /V\
507-284-0844           Rochester, MN  55905   /( )\
-----                                          ^^-^^
"In theory, theory and practice are the same, but   in practice, theory 
and practice are different."



On  3/1/11 2:23 PM, "Steve Perez" <[email protected]>  wrote:

> Hello All,
>
> Has anyone run into a situation  where the zLinux OS disk has become
> READ-
>
> ONLY access?   We are running z/Linux under z/VM 5.4 Redhat 5.4.
>
> My  zLinux Admin were doing compares between the production  environment
>
> versus the Test D/R environment and noticed it.   He issued the
> following
>
> on the prod zLinux guest  environment:
>
> # mount -o remount,rw  /dev/VolGroup01/LogVol00
> mount: block device /dev/VolGroup01/LogVol00  is write-protected,
> mounting
>
> read-only
>
>  Since we are testing our D/R process at the moment for the z/VM LPAR
>  we
>
> are unsure at this point whether that is a contributing  factor.  It
> shoul d not be but we can't rule it out.  We  paused our PPRC/Global
> mirroring fro m the z/OS side before starting  the D/R activities to
> perform recovery of
>
> the z/VM  & z/Linux.  The problem was found while in the middle of
>  verifying/comparing environments on the zLinux side.  I can link  to
> the
>
> minidisk that is used to IPL that zLinux guest  and it shows R/W when I
>
> issue Q LINKS.   All other  minidisks owned by that zLinux guest are R/W 
a
> s
> well.   From my perspective (z/VM) all looks good.
>
> Any input  would be appreciated, if anything to rule out that PPRC/GM
> woul d have  contributed to this.
>
> Thanks.
>  Steve.
******************************************************************************************
This  message may contain confidential or proprietary information intended 
only for  the use of the
addressee(s) named above or may contain information that is  legally 
privileged. If you are
not the intended addressee, or the person  responsible for delivering it 
to the intended addressee,
you are hereby  notified that reading, disseminating, distributing or 
copying this message is  strictly
prohibited. If you have received this message by mistake, please 
immediately notify us by
replying to the message and delete the original  message and any copies 
immediately thereafter.

Thank  you.
******************************************************************************************
CLLD






The information contained in this e-mail and any accompanying documents may 
contain information that is confidential or otherwise protected from 
disclosure. If you are not the intended recipient of this message, or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message, including any attachments. Any 
dissemination, distribution or other use of the contents of this message by 
anyone other than the intended recipient is strictly prohibited. All messages 
sent to and from this e-mail address may be monitored as permitted by 
applicable law and regulations to ensure compliance with our internal policies 
and to protect our business. E-mails are not secure and cannot be guaranteed to 
be error free as they can be intercepted, amended, lost or destroyed, or 
contain viruses. You are deemed to have accepted these risks if you communicate 
with us by e-mail. 

Reply via email to