Re: Console Server equivalent for z/VM

2008-01-11 Thread Mark Post
>>> On Fri, Jan 11, 2008 at 12:15 PM, in message
<[EMAIL PROTECTED]>, David
Boyes <[EMAIL PROTECTED]> wrote: 
-snip-
> From a usability standpoint, it'd be my expectation to AT MINIMUM be
> able to do SSL-protected telnet to a concentrator of some time and
> select a connected system to interact with. 

Sounds like an opportunity for profit via a commercial product.


Mark Post

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390


Re: Console Server equivalent for z/VM

2008-01-11 Thread Jerry Whitteridge
> -Original Message-
> From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On 
> Behalf Of David Boyes
> Sent: Friday, January 11, 2008 9:16 AM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Console Server equivalent for z/VM
> 
> I guess I don't consider the HMC a component that common 
> citizens should
> be permitted to manipulate. It certainly isn't something that the
> unwashed masses should be permitted to touch, and it's not part of the
> VM environment. 

Agreed 

> 
> There are no tools within a VM system that can drive or 
> manipulate data
> streams to the virtualized VT220 console. The HMC is not a VM 
> component
> (in fact, it is deliberately OUTSIDE the scope of any operating system
> by design), and the assumption that anyone needing that VT220 console
> access should ALSO have either a) physical access to the HMC or b)
> network access to the HMC is optimistic, IMHO. 
> 


Exactly my problem

> It's not unusual these days for the machine to be several 
> hundred miles
> away from the people, and/or physically inaccessible to even 
> the systems
> people. ATTACHing a process that runs only on a closed box with no
> external integration points isn't (at least IMHO) 
> exploitable. I'd also
> really hesitate to allow your average Unix administrator access to
> something like the HMC; the access controls exposed in the HMC UI are
> just not manageable at any scale. If there's a way to integrate access
> control via external sources into the HMC *that IBM is willing to
> support*, I'd sure like to know where to read about it.
> 

Right on the money

> From a usability standpoint, it'd be my expectation to AT MINIMUM be
> able to do SSL-protected telnet to a concentrator of some time and
> select a connected system to interact with. 

Exactly what I was hoping someone could point me to. 


> 
> I don't disagree that the HMC has improved a LOT since the 
> MP2k days. I
> do contest that it constitutes a good design management goal 
> to have it
> in the loop for things that are in normal operations for virtual
> machines. An HMC can do way too much harm to have that be attractive. 

Agreed.


Thank you all for the differing suggestions, they all will be given some
thought.
Alan, if you need a request opened I'll be happy to work with you.

"Email Firewall" made the following annotations.
--

Warning: 
All e-mail sent to this address will be received by the corporate e-mail 
system, and is subject to archival and review by someone other than the 
recipient.  This e-mail may contain proprietary information and is intended 
only for the use of the intended recipient(s).  If the reader of this message 
is not the intended recipient(s), you are notified that you have received this 
message in error and that any review, dissemination, distribution or copying of 
this message is strictly prohibited.  If you have received this message in 
error, please notify the sender immediately.   
 
==

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390


Re: Starter System question

2008-01-11 Thread Marian Gasparovic
Thanks to everybody, documentation "error" is
explained, depends on platform you use for ftp client.

What about the other part of the question ? Has
anybody installed Linux from Starter System via NFS ?

Thank you

Marian

--- David Boyes <[EMAIL PROTECTED]> wrote:

> > I configured NOVSTART, everything went fine, the
> only
> > problem in documentation is missing "quote" in ftp
> > commands.
> 
> Could you be more specific? I'll be happy to fix it
> if I know where we
> missed something. 
> 
> > Now I try to install Linux using NFS, but I get an
> > error, it cannot initialize catalog (step just
> after
> > preparing DASDs and before timezone). 
> 
> What is the error message? 
> 
>
--
> For LINUX-390 subscribe / signoff / archive access
> instructions,
> send email to [EMAIL PROTECTED] with the
> message: INFO LINUX-390 or visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> 



  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390


Re: Console Server equivalent for z/VM

2008-01-11 Thread David Boyes
> > Except there's nothing supplied that's capable of exploiting it, so
it's
> > pretty useless. Attaching a virtualized VT220 to the HMC isn't all
that
> > useful either given the arcane and fragile nature of the HMC.
> 1. z/VM 5.3 allows you to ATTACH the real HMC ASCII console to a
guest. 

I guess I don't consider the HMC a component that common citizens should
be permitted to manipulate. It certainly isn't something that the
unwashed masses should be permitted to touch, and it's not part of the
VM environment. 

> I don't understand your point about nothing exploiting it;
> it's for people.  

There are no tools within a VM system that can drive or manipulate data
streams to the virtualized VT220 console. The HMC is not a VM component
(in fact, it is deliberately OUTSIDE the scope of any operating system
by design), and the assumption that anyone needing that VT220 console
access should ALSO have either a) physical access to the HMC or b)
network access to the HMC is optimistic, IMHO. 

It's not unusual these days for the machine to be several hundred miles
away from the people, and/or physically inaccessible to even the systems
people. ATTACHing a process that runs only on a closed box with no
external integration points isn't (at least IMHO) exploitable. I'd also
really hesitate to allow your average Unix administrator access to
something like the HMC; the access controls exposed in the HMC UI are
just not manageable at any scale. If there's a way to integrate access
control via external sources into the HMC *that IBM is willing to
support*, I'd sure like to know where to read about it.

>From a usability standpoint, it'd be my expectation to AT MINIMUM be
able to do SSL-protected telnet to a concentrator of some time and
select a connected system to interact with. 

> 2. I don't understand the "arcane and fragile" comment.  [snip]
> Maybe you're referring to the "F-R-A-G-I-L-E" on the shipping
container?
> That's the country of origin, pronounced "fra-gee-lay".  :-)

Nyet. 

It is trivially easy to close a window and lose it in the HMC GUI. It is
trivially easy to generate a situation where you cannot open an
important HMC application you need to correct a problem because the HMC
GUI insists that a window for that application is already open
somewhere. It is trivially easy to cause assorted remote access failures
to the HMC GUI from external sources. It is trivially easy to replay
session streams back to an HMC if it is network accessible. I could
continue, but confusing UIs or those kinds of reliability issues
constitute fragility. 

I don't disagree that the HMC has improved a LOT since the MP2k days. I
do contest that it constitutes a good design management goal to have it
in the loop for things that are in normal operations for virtual
machines. An HMC can do way too much harm to have that be attractive. 

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390


IODF-HCD Defining FCP on a z9 for z/Linux

2008-01-11 Thread Sam Bass
I am trying to define FCP Channel, Controller and Unit so z/Linux native can 
use it.

The LPAR that we are using for z/Linux is defined as MVS.
HCD does not allow me to attach FCP units to an MVS LPAR.

If I define a new LPAR as VM and it allows me to attach it.

In order for z/Linux native to use FCP does the LPAR OS TYPE have to be defined 
as VM so I can attach the FCP Units to it or does z/Linux talk directly to the 
FCP channels?



Sam Bass
254-771-7212
Sr z/OS Systems Specialist

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390


Re: Console Server equivalent for z/VM

2008-01-11 Thread Adam Thornton

On Jan 11, 2008, at 9:12 AM, Alan Altmark wrote:


I understand that what people want is the ability to putty into the
*VM*
system and be able to use the VT220 suppport to login and access the
Linux
virtual machine console.  Oh, and you still want to be able to issue
#CP
commands, not just Linux hcp commands.  A worthy goal.


I'm happy to communicate with vmcp/hcp if I can have a VT220 console.

Adam

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390


Re: Console Server equivalent for z/VM

2008-01-11 Thread Alan Altmark
On Friday, 01/11/2008 at 09:27 EST, David Boyes <[EMAIL PROTECTED]>
wrote:
> > I think you can virtualize the VT220 console under z/VM 5.3, can't
> you?
>
> Except there's nothing supplied that's capable of exploiting it, so it's
> pretty useless. Attaching a virtualized VT220 to the HMC isn't all that
> useful either given the arcane and fragile nature of the HMC.

1. z/VM 5.3 allows you to ATTACH the real HMC ASCII console to a guest. We
do that so that you can test how things behave if you run that Linux guest
in an LPAR, or use it to repair a Linux guest with a damaged network
connection.  I don't understand your point about nothing exploiting it;
it's for people.  Login to your HMC and start the ASCII console for the
z/VM LPAR.  Then go to CP and ATTACH it to Linux.  Make sure your Linux
configuration includes enablement of BOTH the 3215 and the full-screen
mode h/w console, with the 3215 as the preferred console.  (If the ASCII
console isn't attached with Linux comes up, I don't know if you have to do
something to get him to initialize it on ATTACH or not.)

2. I don't understand the "arcane and fragile" comment.  Someone who
hasn't been educated on mainframe system architecture will be stymied by
the HMC, I'm sure, but it's all window-y and point & click.  How is that
arcane?  I never hear of an HMC failure, though I *do* hear of the
occassional Support Element (SE) failure, but that's why there are two SEs
in the box.  And I believe there's support for multiple HMCs as well.
Maybe you're referring to the "F-R-A-G-I-L-E" on the shipping container?
That's the country of origin, pronounced "fra-gee-lay".  :-)

I understand that what people want is the ability to putty into the *VM*
system and be able to use the VT220 suppport to login and access the Linux
virtual machine console.  Oh, and you still want to be able to issue #CP
commands, not just Linux hcp commands.  A worthy goal.

Alan Altmark
z/VM Development
IBM Endicott

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390


Re: Console Server equivalent for z/VM

2008-01-11 Thread David Boyes
> I think you can virtualize the VT220 console under z/VM 5.3, can't
you?

Except there's nothing supplied that's capable of exploiting it, so it's
pretty useless. Attaching a virtualized VT220 to the HMC isn't all that
useful either given the arcane and fragile nature of the HMC.

Suggestion:

Define a normal Linux guest as the SECUSER for all your guests. Install
the IUCV driver Neale and I wrote. Write a script called 'connect' that
takes a parameter of a virtual machine. Using the demo application to
accept SCIF output via IUCV, write the 'connect' script to loop,
accepting commands and feeding them to the selected guest via 'hcp' or
'vmcp CP SEND' and displaying the output, waiting for some signal magic
string to exit and end the command loop. That would be very similar to
the behavior they have with a typical console hydra setup, and not that
hard to do. 

Long term, I'd write a SVM that used the LAT support in Linux to map a
virtualized VT220 to a DECnet resource name, and then you'd be able to
do a proper console. I have the design done, but if someone wants that,
we need to discuss development costs. 

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390


Re: Console Server equivalent for z/VM

2008-01-11 Thread John Summerfield

Adam Thornton wrote:
\>

Which is why your rescue system OUGHT to be a one-volume, no live LVM,
sort of system.


And read-only so it can be shared, concurrently if needed, and not
changed by anyone but its owner.



--

Cheers
John

-- spambait
[EMAIL PROTECTED]  [EMAIL PROTECTED]
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390