Re: best way to set up "alternate ipl packs" on z/VM 6.2?

[Thomas Kern]

If you don't need to run the alternate volume for long, you can live with a 1 
volume
(3390-9) RES pack, with spool and page on it. I built one to be able to IPL 
something
other than our production systems and use multiple VMs in that system to COPY 
our DASD (VM
and MVS) from one DASD subsystem to another. Later I even used a copy of that 
to do some
DDR restores on a very separate system.

My current RES pack even has an alternate CONFIG file that uses areas on the 
production
RES pack for PAGE & SPOOL for a Disaster Recovery scenario.

/Tom Kern
/on contract to US Dept of Energy
/301-903-2211 (Office)
/301-905-6427 (Mobile)

On 8/2/2012 09:01, Collinson.Shannon wrote:
> In z/VM 5.4, we had two set of packs (a set consisting of a "res" pack with 
> the code on it + a spool + a page volume) that we'd alternate between as we 
> brought up different levels of maintenance.  We'd IPL off of the "res" pack 
> for a set and it'd pop in the single spool and page volumes associated with 
> it--since we only need a single spool volume and we don't really care what's 
> on it from before the IPL, this seemed to work pretty easily to switch 
> between levels of code.  But either we need to add another volume to our sets 
> now, or I'm doing something funky with z/VM 6.2.  I looked at this layout and 
> put in my best guesses:
>
> RELVOL/620RL1 - looked like code, so I used my "res" pack here
> RES/M01RES  - actually appeared to contain lpar-specific 
> data, so I thought it wouldn't change and put an "lpar" volume name here
>
> When I first IPLed, though, it wanted that "lpar-specific" (RES) volume, 
> which I'm sure you guys all knew from the start.
>
> Should I use a 4-volume "pack set"--one release, one res, one spool and one 
> page--now that we're going to z/VM 6.2?  or can we do one release volume for 
> the release, period--maybe that never changes while we're on 6.2--and just 
> use 1 per release + the original "3-pack" set?  Does anyone else on z/VM 6.2 
> do the volume-switching for code method we're using who could perhaps 
> recommend something?
>
> Thanks!
>
> Shannon Collinson - Mainframe Engineer (OS) - SunTrust Banks, Inc - 404 
> 827-6070 (office) 404 642-1280 (cell) 
> shannon.collin...@suntrust.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: Synchronous option for chccwdev -- was there a resolution?

[Sebastian Ott]

On Tue, 31 Jul 2012, David Boyes wrote:
> Florian's original post.
> Corroborating posts from other users (Mark Post, etc)
> My data (on average 3 out of 100 tests fail)
>
> I'd be happy to send you more examples. Are you looking for something 
> specific? The script recently posted here (by you, I think) can generate as 
> much failure data as you like.
>
> To be clear, dasdfmt doesn't complain about other users, it fails because 
> there's no device for it to operate on (yet). Inserting a wait of a few 
> (variable between 1 and 30 seconds, depending on load) seconds reduces, but 
> does not eliminate, the failures. Introducing a 60-90 second wait produces a 
> fairly reliable operation, but still not 100%. Given the need for a reliable 
> test for use in automation and/or the number of devices that commonly need to 
> be processed to create large LVM collections, a minute and a half wait just 
> because we can't reliably depend on chccwdev to be atomic isn't acceptable.

Hm, ok. I think we are dealing with 3 different types of failures here:

* missing error handling in scripts

* failing to ensure exclusive usage
  * most of the tools needed to activate a device require exclusive usage
of the device
  * most of the tools needed to activate a device trigger additional
uevents which would lead udev to check this device out

so instead of:
chccwdev -e
dasdfmt
fdasd
mkswap
chccwdev -d

you need to do:
chccwdev -e
udevadm settle
dasdfmt
udevadm settle
fdasd
udevadm settle
mkswap
udevadm settle
chccwdev -d

And using the --exit-if-exists option is not enough here - you really need
udev to finish using the device.

* cases where udev settle is not enough
  * after udev settle no device node is created
  * after udev settle udev is still using the device

Since this thread is about the last class of failures I'd run a _lot_ of
tests over the last couple of days under various system loads to trigger
this specific error. I could not find one indication where udev settle did
not do its job.
However I found 2 possible related bugs: one in CIO where a device is left
in an unusable state and one in DASD which could lead to udev using the
device after settle returns (but I could not trigger this one).

Once I'm done with fixing this bugs I'll look into the distros to find out
if the fixes are applicable there and to look for other bugs lurking
there.

So I suspect that most of the things you observed are results of the 2nd
error class (but again I've not looked into the distros yet, maybe the
situation is different there).

Regards,
Sebastian

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

Today is the 40th anniversary of the announcement of VM/370

[Jim Elliott]

Today is the day! For those attending SHARE next week, we will have a
birthday party on Wednesday afternoon following my webcast live from
SHARE with my personal memories of 39 years working with the product.

http://www.vm.ibm.com/vm40bday.html

Jim

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

best way to set up "alternate ipl packs" on z/VM 6.2?

[Collinson.Shannon]

In z/VM 5.4, we had two set of packs (a set consisting of a "res" pack with the 
code on it + a spool + a page volume) that we'd alternate between as we brought 
up different levels of maintenance.  We'd IPL off of the "res" pack for a set 
and it'd pop in the single spool and page volumes associated with it--since we 
only need a single spool volume and we don't really care what's on it from 
before the IPL, this seemed to work pretty easily to switch between levels of 
code.  But either we need to add another volume to our sets now, or I'm doing 
something funky with z/VM 6.2.  I looked at this layout and put in my best 
guesses:

RELVOL/620RL1 - looked like code, so I used my "res" pack here
RES/M01RES  - actually appeared to contain lpar-specific 
data, so I thought it wouldn't change and put an "lpar" volume name here

When I first IPLed, though, it wanted that "lpar-specific" (RES) volume, which 
I'm sure you guys all knew from the start.

Should I use a 4-volume "pack set"--one release, one res, one spool and one 
page--now that we're going to z/VM 6.2?  or can we do one release volume for 
the release, period--maybe that never changes while we're on 6.2--and just use 
1 per release + the original "3-pack" set?  Does anyone else on z/VM 6.2 do the 
volume-switching for code method we're using who could perhaps recommend 
something?

Thanks!

Shannon Collinson - Mainframe Engineer (OS) - SunTrust Banks, Inc - 404 
827-6070 (office) 404 642-1280 (cell) 
shannon.collin...@suntrust.com

Please consider the cost of paper and the environment before printing this 
email!

LEGAL DISCLAIMER
The information transmitted is intended solely for the individual or entity to 
which it is addressed and may contain confidential and/or privileged material. 
Any review, retransmission, dissemination or other use of or taking action in 
reliance upon this information by persons or entities other than the intended 
recipient is prohibited. If you have received this email in error please 
contact the sender and delete the material from any computer.
By replying to this e-mail, you consent to SunTrust's monitoring activities of 
all communication that occurs on SunTrust's systems.
SunTrust is a federally registered service mark of SunTrust Banks, Inc. Live 
Solid. Bank Solid. is a service mark of SunTrust Banks, Inc.
[ST:XCL]

--
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: Firefox v10 on SLES11SP2 installed in /usr/lib64?

[Rob van der Heij]

On 1 August 2012 23:14, Alan Cox  wrote:

> The question is
>
> 'What CVE numbers are the flaws being logged and does your vendor release
> have those fixed according to the changelog and their security statements'
>
> Don't do security by version numbers, it's broken and anybody who simply
> says "oh you've got release X it must be busted" isn't properly trained
> to use the tools IMHO and shouldn't be doing the job. Security is
> important, doing it right is important. Learning to do the basics right is
> not that hard.

Most certainly. I've been fighting this in a previous life already.
Unfortunately the distributors start this by reporting the packages
from the "consumer grade" distribution that have the fix for the CVE
included. That's what gets recorded in the databases and appears to be
what security officers exchange in their private discussions. If the
company has a patch policy at all, this is typically the release
numbers you're ranked on. Following the model of US law enforcement
style, merely questioning the validity of the policy will make you the
main target of their concern...

So we had to "reverse engineer" every patch request that used terms
like "if installed, must have openssh-5.2p1-9.1 or higher" to dig up
the CVE that they were after, see whether the enterprise distribution
comes up in a few days with a new level of openssh maybe and see
whether openssh-5.1p1-41.51.1 mentions the same vulnaribility to be
fixed. This was a manual process because often the enterprise version
was not impacted and did not get a new package. With that information
we would request an excemption from the patch date requirement...
Tedious is an understatement.

A big win was to get rid of all extra software you don't need, as
discussed in the thread. Combined with a strict software management
policy that does not allow the local admin to install midnight
commander just becase he likes it...  We also started to build our own
security package that would carry the required levels as dependency,
so your security scan was reduced to just checking the level of that
package. Upgrade of that package would pull in the patches for openssh
etc.

> Enterprise vendors add fixes to old versions to minise the risk of other
> destabilizing changes. That is much of their entire business model.

Often you will even find that the vulnerability was introduced in a
level later than what we have in the enterprise distribution, so there
may never be an update that fixes that CVE for the enterprise distro.

The enterprise distributors could make our life simpler with a
security package as mentioned. You'd get an update of that package
every month or so, pulling in any updates to packages that fix
reported vulnerabilties, if any. So rpm -U of the latest update would
show me which real packages are affected (and plan an outage if
needed). The company security policy could be as simple that for
certain class of servers you need to have that package installed
within 2 months after it was released. Very simple to check.

Rob

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