Re: iucvconn setup on SLES 12
Still having issues. I have upgraded both the terminal server and test guest to SLES 12 SP4 which gives a s390tools version of 2.1 or so. Our requirements are to be able to view the console log during shutdown and startup since we no longer have access to a 3270 console or HMC. If you have this working what are your grub parms or terminal server setup. For the terminal server, the only changes I made are to define the guests to be monitored and a password. I can get to the logon prompt or emergency repair prompt but the console display keeps disconnecting with only a few messages displayed. Here is /proc/cmdline root=UUID=ad5a0c5a-1372-474b-97a6-a07ba754a36a hvc_iucv=2 showopts TERM=dumb crashkernel=102M console=ttyS0 console=hvc0 Do these look correct? Anyone using something different that works? Chris Will From: Linux on 390 Port on behalf of Mark Post Sent: Wednesday, June 5, 2019 4:48 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: iucvconn setup on SLES 12 ALERT This email was sent from a source external to BCBSM/BCN. DO NOT CLICK links or attachments unless you recognize the sender and trust the content. On 5/30/19 1:15 PM, Will, Chris wrote: > I have this sort of working. It will display a few messages and then close > the connection. I connect again and it will display a few messages, close, > etc. -snip- > # ssh nbxdv392@slxmfdev3 > Password: > Last login: Thu May 30 11:45:26 2019 from 10.96.1.149 > This is a private system. Unauthorized use is prohibited. > iucvconn_on_login: Connecting to nbxdv392 (terminal ID: lnxhvc0) > > iucvconn: Connecting to the z/VM guest virtual machine failed: Connection > refused > Connection to slxmfdev3 closed. > (root@slxmfdev3:~) There are a number of things that might be going here, but it's hard to tell. One thing is that the cookbook shows "ssh -t" and not just "ssh". The -t forces allocation of a pseudo-terminal, which might be necessary here. I looked back through my old emails, and the problem that I vaguely remembered was from SLES11, and a kernel change was needed to fix it. I'm pretty certain that's not the problem you're experiencing. ;) 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://www2.marist.edu/htbin/wlvindex?LINUX-390 The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: iucvconn setup on SLES 12
On 5/30/19 1:15 PM, Will, Chris wrote: > I have this sort of working. It will display a few messages and then close > the connection. I connect again and it will display a few messages, close, > etc. -snip- > # ssh nbxdv392@slxmfdev3 > Password: > Last login: Thu May 30 11:45:26 2019 from 10.96.1.149 > This is a private system. Unauthorized use is prohibited. > iucvconn_on_login: Connecting to nbxdv392 (terminal ID: lnxhvc0) > > iucvconn: Connecting to the z/VM guest virtual machine failed: Connection > refused > Connection to slxmfdev3 closed. > (root@slxmfdev3:~) There are a number of things that might be going here, but it's hard to tell. One thing is that the cookbook shows "ssh -t" and not just "ssh". The -t forces allocation of a pseudo-terminal, which might be necessary here. I looked back through my old emails, and the problem that I vaguely remembered was from SLES11, and a kernel change was needed to fix it. I'm pretty certain that's not the problem you're experiencing. ;) 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://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: iucvconn setup on SLES 12
Darn, here is what we are running. s390-tools-1.34.0-65.5.1.s390x Chris Will Enterprise Linux/UNIX (ELU) (313) 549-9729 Cell cw...@bcbsm.com -Original Message- From: Linux on 390 Port On Behalf Of Mark Post Sent: Thursday, May 30, 2019 3:42 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: iucvconn setup on SLES 12 ALERT This email was sent from a source external to BCBSM/BCN. DO NOT CLICK links or attachments unless you recognize the sender and trust the content. On 5/30/19 1:15 PM, Will, Chris wrote: > I have this sort of working. It will display a few messages and then close > the connection. I connect again and it will display a few messages, close, > etc. That sounds vaguely familiar to me. Let me ask the obligatory question: are you up to date on maintenance for both systems on either side of that connection? 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://www2.marist.edu/htbin/wlvindex?LINUX-390 The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: iucvconn setup on SLES 12
We are at SLES 12 SP3 ~ sept 2018 patch level Information for package s390-tools: --- Repository : SLES12-SP3-Updates:testing Name : s390-tools Version: 1.34.0-65.20.1 Chris Will Enterprise Linux/UNIX (ELU) (313) 549-9729 Cell cw...@bcbsm.com -Original Message- From: Linux on 390 Port On Behalf Of Mark Post Sent: Thursday, May 30, 2019 3:42 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: iucvconn setup on SLES 12 ALERT This email was sent from a source external to BCBSM/BCN. DO NOT CLICK links or attachments unless you recognize the sender and trust the content. On 5/30/19 1:15 PM, Will, Chris wrote: > I have this sort of working. It will display a few messages and then close > the connection. I connect again and it will display a few messages, close, > etc. That sounds vaguely familiar to me. Let me ask the obligatory question: are you up to date on maintenance for both systems on either side of that connection? 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://www2.marist.edu/htbin/wlvindex?LINUX-390 The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: iucvconn setup on SLES 12
On 5/30/19 1:15 PM, Will, Chris wrote: > I have this sort of working. It will display a few messages and then close > the connection. I connect again and it will display a few messages, close, > etc. That sounds vaguely familiar to me. Let me ask the obligatory question: are you up to date on maintenance for both systems on either side of that connection? 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://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: iucvconn setup on SLES 12
I have this sort of working. It will display a few messages and then close the connection. I connect again and it will display a few messages, close, etc. Here is my cmdline root=UUID=ad5a0c5a-1372-474b-97a6-a07ba754a36a hvc_iucv=8 TERM=dumb crashkernel=102M console=ttyS0 console=hvc0 Similar with or without running this with the terminal server. # ssh nbxdv392@slxmfdev3 Password: Last login: Thu May 30 11:45:26 2019 from 10.96.1.149 This is a private system. Unauthorized use is prohibited. iucvconn_on_login: Connecting to nbxdv392 (terminal ID: lnxhvc0) iucvconn: Connecting to the z/VM guest virtual machine failed: Connection refused Connection to slxmfdev3 closed. (root@slxmfdev3:~) # ssh nbxdv392@slxmfdev3 Password: Last login: Thu May 30 11:45:39 2019 from 10.96.1.149 This is a private system. Unauthorized use is prohibited. iucvconn_on_login: Connecting to nbxdv392 (terminal ID: lnxhvc0) Connection to slxmfdev3 closed. (root@slxmfdev3:~) # (root@slxmfdev3:~) # ssh nbxdv392@slxmfdev3 Password: Last login: Thu May 30 11:45:45 2019 from 10.96.1.149 This is a private system. Unauthorized use is prohibited. iucvconn_on_login: Connecting to nbxdv392 (terminal ID: lnxhvc0) [ OK ] Found device /dev/user-vg/app-lv. Connection to slxmfdev3 closed. (root@slxmfdev3:~) # ssh nbxdv392@slxmfdev3 Password: Last login: Thu May 30 11:45:56 2019 from 10.96.1.149 This is a private system. Unauthorized use is prohibited. iucvconn_on_login: Connecting to nbxdv392 (terminal ID: lnxhvc0) [ OK ] Started File System Check on /dev/user-vg/ibmitm-lv. Connection to slxmfdev3 closed. on /dev/user-vg/app-lv (21s / no limit) (root@slxmfdev3:~) # exit logout Connection to slxmfdev3 closed. Chris Will Enterprise Linux/UNIX (ELU) (313) 549-9729 Cell cw...@bcbsm.com -Original Message- From: Linux on 390 Port On Behalf Of David Boyes Sent: Saturday, May 25, 2019 3:01 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: iucvconn setup on SLES 12 ALERT This email was sent from a source external to BCBSM/BCN. DO NOT CLICK links or attachments unless you recognize the sender and trust the content. On 5/24/19, 9:16 AM, "Linux on 390 Port on behalf of Alan Altmark" wrote: >While I've always wanted to see it virtualized and the VM telnet server >given a way to connect to it (meaning no client/host translations or >conversions) Amen to both. Constructing an analogue to a classic terminal server UI as a VM application wouldn't be that hard to do if we set our minds to it. Would be a clever use of the RSK toolkit or PIPEs. > I've never heard of a problem with the HMC ASCII console. > What's the issue? It's not necessarily a problem with the console function per se, but a differing set of expectations on how to use it and how it's expected to function when presented to a person familiar with the idea of a serial console attached to a terminal server as the default behavior. It's an unusual setup in that it a) has to be set up within every virtual system rather than being the default behavior out of the box (the discrete box console/terminal server approach requires no modification to how the target system is configured at all, allowing moving between physical and virtual environments transparently), b) has been unevenly supported by distribution releases over time (in terms of what you have to do being different on RH/SuSE/Ubuntu) which has occasionally been a PITA, and c) at various points in time it could only be effectively used with one virtual machine at a time. All are fixable (with c) being an issue with your HMC ucode level), but they're not the out-of-the-box default and it's another gratuitous difference that hostile folks use to claim the platform is somehow less appropriate; the fact you can accomplish the same goal isn't the same thing as "it can be done the same way you manage all your other systems" and it's a lot harder to sell if you have to sell a "this is different, so you need to accommodate it" solution to system management. The Linux-based terminal server is closer to how the other platforms behave, and most of the common management solutions Just Work with how it operates (with some minor tweaks to UI text and behavior, it's a drop-in; changing the prompts to be compatible with the default Cisco/Livingston terminal server dialog is a fairly minor step and can be done once in a central place). Integrating this with things like Kafka and other mass log/event analysis tools is a lot easier, which reduces the cost of operation by allowing more common investments to cover more infrastructure. Authentication issues (like the one with 2-factor auth recently discussed here) can be completely consistent across platforms, and support common solutions that don't require acquiring additional commercial tooling. -- For L
Re: iucvconn setup on SLES 12
On 5/24/19, 9:16 AM, "Linux on 390 Port on behalf of Alan Altmark" wrote: >While I've always wanted to see it virtualized and the VM telnet server >given a way to connect to it (meaning no client/host translations or >conversions) Amen to both. Constructing an analogue to a classic terminal server UI as a VM application wouldn't be that hard to do if we set our minds to it. Would be a clever use of the RSK toolkit or PIPEs. > I've never heard of a problem with the HMC ASCII console. > What's the issue? It's not necessarily a problem with the console function per se, but a differing set of expectations on how to use it and how it's expected to function when presented to a person familiar with the idea of a serial console attached to a terminal server as the default behavior. It's an unusual setup in that it a) has to be set up within every virtual system rather than being the default behavior out of the box (the discrete box console/terminal server approach requires no modification to how the target system is configured at all, allowing moving between physical and virtual environments transparently), b) has been unevenly supported by distribution releases over time (in terms of what you have to do being different on RH/SuSE/Ubuntu) which has occasionally been a PITA, and c) at various points in time it could only be effectively used with one virtual machine at a time. All are fixable (with c) being an issue with your HMC ucode level), but they're not the out-of-the-box default and it's another gratuitous difference that hostile folks use to claim the platform is somehow less appropriate; the fact you can accomplish the same goal isn't the same thing as "it can be done the same way you manage all your other systems" and it's a lot harder to sell if you have to sell a "this is different, so you need to accommodate it" solution to system management. The Linux-based terminal server is closer to how the other platforms behave, and most of the common management solutions Just Work with how it operates (with some minor tweaks to UI text and behavior, it's a drop-in; changing the prompts to be compatible with the default Cisco/Livingston terminal server dialog is a fairly minor step and can be done once in a central place). Integrating this with things like Kafka and other mass log/event analysis tools is a lot easier, which reduces the cost of operation by allowing more common investments to cover more infrastructure. Authentication issues (like the one with 2-factor auth recently discussed here) can be completely consistent across platforms, and support common solutions that don't require acquiring additional commercial tooling. -- 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
Re: iucvconn setup on SLES 12
On Thursday, 05/23/2019 at 07:38 GMT, David Boyes wrote: > IBM tried to introduce an HMC feature to provide a character-mode > console, but it never worked the way most people wanted it to work, so this is > the result. While I've always wanted to see it virtualized and the VM telnet server given a way to connect to it (meaning no client/host translations or conversions), I've never heard of a problem with the HMC ASCII console. What's the issue? Alan Altmark Senior Managing z/VM and Linux Consultant IBM Systems Lab Services IBM Z Delivery Practice ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott -- 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
Re: iucvconn setup on SLES 12
On 5/23/19, 11:18 AM, "Linux on 390 Port on behalf of Will, Chris" wrote: >Is there any advantage to setting up a terminal server Yes. Think of it as analogous to attaching the console ports of your discrete servers without built-in management processors to a hardware terminal server so you can connect to them before networking is working. The original purpose of the terminal server code was to deal with the case where you bork the network and thus can't do anything without dealing with CMS's occasionally weird antics wrt terminal access. It lets you use the editors and environment you're familiar with in the Unix world to fix what you broke, without learning ed in TTY mode. IBM tried to introduce an HMC feature to provide a character-mode console, but it never worked the way most people wanted it to work, so this is the result. > and how is this accomplished? Cookbook at http://public.dhe.ibm.com/software/dw/linux390/docu/l4n0ht01.pdf -- 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
iucvconn setup on SLES 12
Currently we have had good success using iucvconn on our SLES 11 SP4 servers. We use it mostly for a server that goes into emergency repair mode and we need a console. Based on some one of the newer z/VM cookbooks, I thought this was already setup for SLES 12 and there are hvc terminals allocated on the grub config file. However, it looks like we still need to define a "console=hvc0" on the /etc/default/grub file. Is there any advantage to setting up a terminal server and how is this accomplished? The most important feature we need is console access (i.e. be able to view boot messages, emergency repair mode, etc.). Chris Will Enterprise Linux/UNIX (ELU) (313) 549-9729 Cell cw...@bcbsm.com The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association. -- 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
