z/VM 5.4 TCP/IP stack name
Yesterday I tried to rename one of my two TCPIP Stacks. I have TCPIP and TCPIP02 and wanted to rename TCPIP to TCPIP01. After doing that with the appropiate file and parameter updates, I was not able to do a NETSTAT command against TCPIP01, I got VM-Intercommunication errors. Maybe a silly question, but before I go into deeper investigation, I want to know if it is necessary to have the first stack named TCPIP. Going back from TCPIP01 to TCPIP: both stacks work well. Ewald Roller
Re: z/VM 5.4 TCP/IP stack name
The name of the default TCPIP stack is in a CMS file named TCPIP DATA. So, what's in yours? (and I guess that if there is no TCPIP DATA, TCPIP is the default stack name). 2011/5/27 E. Roller ewald.rol...@rolf-benz.com Yesterday I tried to rename one of my two TCPIP Stacks. I have TCPIP and TCPIP02 and wanted to rename TCPIP to TCPIP01. After doing that with the appropiate file and parameter updates, I was not able to do a NETSTAT command against TCPIP01, I got VM-Intercommunication errors. Maybe a silly question, but before I go into deeper investigation, I want to know if it is necessary to have the first stack named TCPIP. Going back from TCPIP01 to TCPIP: both stacks work well. Ewald Roller -- Kris Buelens, IBM Belgium, VM customer support
z/VM 5.4 TCP/IP stack name
Thank you Kris, the wrong TCPIP DATA has been active... I felt that this was a silly question ... :-) But I have had a long evening yesterday
Re: z/VM 5.4 TCP/IP stack name
On Friday, 05/27/2011 at 07:48 EDT, E. Roller ewald.rol...@rolf-benz.com wrote: Yesterday I tried to rename one of my two TCPIP Stacks. I have TCPIP and TCPIP02 and wanted to rename TCPIP to TCPIP01. After doing that with the appropiate file and parameter updates, I was not able to do a NETSTAT command against TCPIP01, I got VM-Intercommunication errors. Maybe a silly question, but before I go into deeper investigation, I want to know if it is necessary to have the first stack named TCPIP. It's not necessary, no, but you are going to create more trouble for yourself than you need. - Since the user ID is provided by IBM, you will have to do a PPF override so that SERVICE and PUT2PROD know what you've done. - Create :Type.SERVER entries in SYSTEM DTCPARMS for all servers and specify the :Stack. tag as appropriate. (Warning: Do not change IBM DTCPARMS and do not perform a mass copy of IBM DTCPARMS to SYSTEM DTCPARMS.) - Change TCPIP DATA to include the TCPIPUSERID statement to point to your stack You may want to leave TCPIP in the directory (NOLOG) in order to provide indirect minidisk links to the 198, 591, and 592 just in case someone says LINK TCPIP instead of LINK TCPMAINT. The maxim that you don't change or delete what IBM provides, but only add to it, is a good one. While PPF overrides work well for service, there is no generally accessible system registry (e.g. some form of system environment variables) to let the rest of the system know what it is you've done. My recommendation: Create all the stacks you want, but leave TCPIP Co. alone. Use the suite as your master TCP/IP instance, even if you don't bring them up. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
VMWorkshop the 2011 version
Friends of z/VM and LINUX There has been a lot of interest in the VM Workshop planned for JULY. For those wishing to present at the VM Workshop we have threads for vendors and customers; three(3) threads total. The vendor thread allows for sessions that are ?educational?, but somewhat product related. The customer and open threads are strictly educational and not product specific. Sponsors are free to submit abstracts for the vendor thread and anyone can submit an abstract for the open or customer threads. If you are interested, please send your abstract to worksho...@aol.com, with the type of session you are submitting in the subject line. For example: Subject: Abstract for Vendor Sessions (name and company name) or, Subject: Abstract for Customer or Open Session (name and company name). Bill Munson 201-418-7588 VM Workshop http://www.VMWorkshop.org/ *** IMPORTANT NOTE*-- The opinions expressed in this message and/or any attachments are those of the author and not necessarily those of Brown Brothers Harriman Co., its subsidiaries and affiliates (BBH). There is no guarantee that this message is either private or confidential, and it may have been altered by unauthorized sources without your or our knowledge. Nothing in the message is capable or intended to create any legally binding obligations on either party and it is not intended to provide legal advice. BBH accepts no responsibility for loss or damage from its use, including damage from virus.
Re: HMC security (was: zvm directions)
On Thursday, 05/26/2011 at 11:10 EDT, David Boyes dbo...@sinenomine.net wrote: But it's certainly a common one. I can think of at least a dozen sites that have heard this requirement from IBMers. I've always thought the proper solution to this was to add a badge reader to the HMC to allow IBMers to enable these ids only when they are physically present (and responsible for them). I will try to find out where this is coming from and see if there are some adjustments that can be made. I note that the checklist in 4.6.5 of the SAPR Guide only says Requirements for passwords and userids for the Hardware Management Console and Support Element of the 2817 Server have been determined. And herein lies some of the resistance. Agreed, this is the Right and Proper Way. If I am to operate in this way, I need to engineer Yet Another identity management system (at best a plugin to an existing one, at worst an entire new system). There is not a single commercially available identity management system (including Tivoli products) that would know what a HMC is if it bit them in the rear. None of them understand any of the roles you describe, and none of the IT security weenies who run this stuff day to day have any grasp of this. It doesn't show up in their point-to-click-to-manage world -- you're dealing with people who think AD is the be-all, end-all, not RACF. After all, it's just a PC, right? (*snort*) -- doesn't work with *their* tool, doesn't happen. I concede the point that that will change over time, since this is more likely to impact z/OS sites and thus actually cause money to be spent, but you're moving too fast for the real world here. (I made this point in the design discussions about ensembles in Research; clearly I didn't have a big enough tantrum to crack the light of reality over this horizon). Local password management? I'm not following you on this. My client has all 'normal' HMC IDs authenticated with the corporate directory server (Active Directory). See above. AD integration for an HMC requires modifying the default AD schema to allow somewhere to store all those nifty new attributes, which is a one-way street. You can't go back. Windows admins (unless they are very very good) flee screaming from this, as it's an irrevocable step and it changes the support posture for a lot of other products, including some ones that have nothing to do with System Z (try calling Microsoft with a Exchange problem if you have a modified AD schema. You won't like it. Trust me.) This isn't a z-specific issue. Further, Microsoft says that AD Lightweight Directory Service (AD LDS) can be used in such a way that it isn't necessary to extend the AD schema. http://www.microsoft.com/windowsserver2008/en/us/ad-main.aspx Not being an AD admin, I can admit that the subtleties escape me. They may not need them, but setting up a separate provisioning process with all the attendant auditing, etc to manage them in a responsible way (let alone letting a non-human agent do anything to configurations without having exits for MY change management system (whatever that may be), as some of the ensemble code proposes to require in the near future) is pretty much a non-starter. Separation of powers, if nothing else -- if I can change the hardware configuration, I'm not allowed to change the user authorizations, and otherwise, WYSIWG wrt HMC management, and that doesn't include letting automation tinker with it. I guess the message we're trying to convey is that if this thing is to become the management endpoint for the System Z, a lot more thought needs to be put into deployment integration with other parts of the environment before people are going to be comfortable with the level of power that this thing has over the crown jewels. If it's treated as the control point, it's got to play nice with OUR control points. IBM can't revoke support for it when we install the stuff that makes it work for our businesses. The current message from IBM is a little too blue-centric for that to be realistic. Stay your sword, good man! The good news is that the z196 introduced a way for you to do that. It is no longer required to pre-define HMC users to the HMC. 1. Create one or more User Templates. These are model user IDs that can be associated with an HMC user for whom no User Profile exists. Except for the fact you can't use them for authentication purposes, they are conceptually the same as user profiles. 2. Create one or more User Patterns. This is a pattern that, when matched against a login ID (for example, u...@company.com) for which no user profile exists, identifies how to decide if the user can log in and, if so, what user template should be associated with them. Hopefully that will take a big bite out of the problem. Alan Altmark z/VM and Linux on System z Consultant
