Re: DNS question
Adam Thornton wrote: I haven't ever approached Theo about a 390 port. But with Hercules, you could get started for very very cheap Of course, Theo would probably sooner jump off a cliff than allow OCO stuff to intrude into his OS. Is it possible to put OBSD efficiently on VM without OCO blobs? I don't see why not. You could use IUCV support, same way as MUSIC does it. Main problem is you end up fighting over ports and having to use non-standard port numbers... -- Jack J. Woehr# If your neighbor prays too loud http://www.well.com/~jax # in church, go home and lock your http://www.softwoehr.com # smokehouse. - Harry S Truman __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: DNS question
PING does not run on the TCP/IP stack, it runs on the userid that issued the command. I would like to thank everyone who helped me understand the way PING and DNS work in CMS. :-) It's working fine! The only other thing I needed to fix was an incorrect DOMAINORIGIN statement, our network uses something weird. But having the wrong value *does* prevent me from pinging things. Thank you all! Shimon ._._._*_|_*_*_*_* -- Shimon Lebowitzmailto:[EMAIL PROTECTED] VM System Programmer . Israel Police National HQ. http://www.poboxes.com/shimonpgp Jerusalem, Israel phone: +972 2 530-9877 fax: 530-9308
Re: DNS question
bind is, these days, anything but minimal. We should port OpenBSD to the 390. You could probably run OpenBSD + bind in a 12MB VM. You can run Linux in a 12Mb VM just fine -- we do 16 and 32M Debian guests all the time. You just can't run *SuSE or RH as distributed* in that little memory. Different compile option choices, and different decisions on what is necessary. With a LOT of paring down, you can reduce SuSE or RH to something that will run in a 32M machine. It doesn't look much like the original, though. -- db
Re: DNS question
On 12/20/06, Shimon Lebowitz [EMAIL PROTECTED] wrote: The only other thing I needed to fix was an incorrect DOMAINORIGIN statement, our network uses something weird. But having the wrong value *does* prevent me from pinging things. The DNS lookup is only for fully qualified names like www.vm.ibm.com. If you give the resolver a hostname only (a single qualifier with no dots in it) the domain origin is appended to get a fully qualified name that can be looked up. An incorrect domain origin would give wrong names that cannot be looked up. Many large installations run their own DNS servers behind the firewall to let middle tiers resolve internal addresses. It's a good thing for such servers not to use external DNS because your application could be affected by tampering with that outside DNS. While it is possible to have such a DNS also resolve the address of hosts outside the firewall, some people sleep better by keeping it inside. You have to be aware what you want to resolve and which DNS to talk to. There may not be one that fits both needs. Rob
Re: DNS question
Of course, Theo would probably sooner jump off a cliff than allow OCO stuff to intrude into his OS. Is it possible to put OBSD efficiently on VM without OCO blobs? The only remaining OCO Linux on Z driver is the 3590 tape driver code, AFAIK.
Re: DNS question
The DNS protocol has been stretched and the de-facto standard extended beyond the RFCs. And bind happens to *be* the de-facto standard implementation. Another reason to run it instead of the VM DNS server code. And Microsoft Windows happens to *be* the de-facto standard implementation (of a GUI-driven computer system). Another reason to run it instead of (insert name here). Oh wait... it's not Friday yet is it... (Define de facto standard: http://www.learnthat.com/define/view.asp?id=2610 specifically the first sentence.) -- Rod - bad mood guy
Re: DNS question
On 12/20/06, Jack Woehr [EMAIL PROTECTED] wrote: bind is, these days, anything but minimal. We should port OpenBSD to the 390. You could probably run OpenBSD + bind in a 12MB VM. So on what measurements would you base such a claim? And what does it compare to with Linux on zSeries? I suppose we're talking about resident working set, not virtual machine size? My 64-bit (!) Linux virtual machine with bind and snmp in it (you have to measure it) uses 17 MB right now. Since the VM system is not tight on memory we cannot tell what part of that would really be needed to run. Probably less than half. And if we throw in shared kernel and libraries in DCSS, we probably can do with 1-2 MB. For comparison: apache is not minimal either but I ran 100 of them in a 128 MB z/VM system (and be limited by CPU rather than memory). Rob
Re: DNS question
Has anyone taken the time to come up with the minimal system requirements for a SLES installation? Even the minimal system selection on the software install panel seems a little over engineered. -- Mark Pace Mainline Information Systems
Re: DNS question
I bet that there is a vendor (not IBM) that would be glad to sell you a minimal DNS server in a small Linux. It would probably come in DDR format ready to load on a minidisk and run. Is a salesman at Sine Nomine listening? :) [EMAIL PROTECTED] wrote: On Dec 19, 2006, at 9:25 PM, Jack Woehr wrote: Adam Thornton wrote: Yes, unless you tossed in a minimal DNS server, say in a 16M Linux guest with, say, a tiny little filesystem in a shared segment. It's called 'Bind' Well, no. A minimal DNS server would be, say, tinydns. But then you'd have to deal with djbware. However, as Chuckie has pointed out, my post is moot because IBM is not going to get into the Linux distribution market. So...has anyone invested any time in a CMS port (OpenVM or otherwise) of one of the lightweight DNS servers? Adam -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: DNS question
In my low memory tests of SUSE, it would run fine in 12 MBs and no swapping, that is, until you want to do something (like YaST). joe works. kate works. The biggest difference I've seen in the low memory linux images, is method of communication. IUCV and VCTCA, works well in 12 MB. OSA and Hipersockets, 48 MB. Now back on tangent to the origional discussion... Tom Duerbusch THD Consulting [EMAIL PROTECTED] 12/20/2006 8:40 AM bind is, these days, anything but minimal. We should port OpenBSD to the 390. You could probably run OpenBSD + bind in a 12MB VM. You can run Linux in a 12Mb VM just fine -- we do 16 and 32M Debian guests all the time. You just can't run *SuSE or RH as distributed* in that little memory. Different compile option choices, and different decisions on what is necessary. With a LOT of paring down, you can reduce SuSE or RH to something that will run in a 32M machine. It doesn't look much like the original, though. -- db
Re: DNS question
SLES9 64 bit with OSA (OSA and Hipersockets have large buffer requirements) say they need 512MB. I've done installs in 256 MBs. I do get a message stating insufficient storage, but the install with only the normal base packages, works fine. During the installation, you don't have access to Linux swap disks. A Linux virtual disk is carved out of the storage you have, and the initial load/creation of a Linux system is done in memory. Then that system is, in effect, booted, and now a system is built on disk. Depending on what your options are, you will use different abouts of virtual disk. If you run out, your installation will fail (just looks like it stops at a point where it may be thinking about somethingnever comes back). If this is your first zLinux installation, then use their suggestions. No use throwing in a monkey wrench in to the works. Once you get use to zLinux installs, you can try things out. If you will be installing a memory intensive product (a database), you may want to plan for that memory, before you install. AND, it is easier to get better database performance, right out of the box, if, when you install the database, you give it the memory you will be running in. Some databases, at installation time, looks at the memory you have, and customizes certain memory related parms. A good DBA would know these and change them, but for the rest of usG Linux was designed for the fixed hardware crowd, that is PC, Servers, etc. You have non shared hardware dedicated to it. On the mainframe, a shared platform, we try to find best use for our resources. If you don't really need a GB of real memory, we will trim you down to give the memory to some other deserving system. Sure you may swap more, but we have one kick-a@@ I/O subsystem. To a point, we will trade more I/Os for less real memory requirements (kind of backwards from normal mainframe thinking). Tom Duerbusch THD Consulting [EMAIL PROTECTED] 12/20/2006 9:34 AM Has anyone taken the time to come up with the minimal system requirements for a SLES installation? Even the minimal system selection on the software install panel seems a little over engineered. -- Mark Pace Mainline Information Systems
Re: DNS question
I bet that there is a vendor (not IBM) that would be glad to sell you a minimal DNS server in a small Linux. It would probably come in DDR format ready to load on a minidisk and run. Is a salesman at Sine Nomine listening? :) When do you want it? 8-) -- db
Re: DNS question tangents to OpenBSD/390
On Dec 20, 2006, at 12:37 PM, Jack Woehr wrote: Tom Duerbusch wrote: IUCV and VCTCA, works well in 12 MB. OSA and Hipersockets, 48 MB. Now back on tangent to the origional discussion... Speaking of tangents There's OCO in Linux/390 ... is it *necessary* to run a guest OS or is it possible to run (and run efficiently?) a guest OS like, um, say, just hypothetically, OpenBSD/390 without any OCO? Sure. I don't know how much OCO there really is anymore, actually. The QDIO drivers are available now, and I think there's even a 3590 implementation. You could certainly get a Linux system, with networking, built without anything that isn't Free Software. Adam
Re: DNS question tangents to OpenBSD/390
On 12/20/06, Adam Thornton [EMAIL PROTECTED] wrote: I don't know how much OCO there really is anymore, actually. The QDIO drivers are available now, and I think there's even a 3590 implementation. You could certainly get a Linux system, with networking, built without anything that isn't Free Software. I suppose having source code that produces something that works in Linux is helpful to understand how it works, but I could not tell whether that's enough to implement the function in another operating system. Many moons ago I studied the lcs device driver to find the cause of a problem. I fear that when I had to learn general S/390 I/O from that, it might have made a big difference for the rest of my life ;-) Rob
Re: DNS question
various We should port BSD quotes Someone did a bunch of patches to one of the BSD's some years ago. I know, I saw it. I'm pretty sure I bookmarked it but as per usual, when I want to find the thing I can't... ah, there it is. Hmmm... it was the FreeBSD stuff. Maybe someone (else) can have a shufty and see if it's a good starting point. -- Rod
Re: DNS question tangents to OpenBSD/390
On Wednesday, 12/20/2006 at 09:07 CET, Rob van der Heij [EMAIL PROTECTED] wrote: On 12/20/06, Adam Thornton [EMAIL PROTECTED] wrote: I don't know how much OCO there really is anymore, actually. The QDIO drivers are available now, and I think there's even a 3590 implementation. You could certainly get a Linux system, with networking, built without anything that isn't Free Software. I suppose having source code that produces something that works in Linux is helpful to understand how it works, but I could not tell whether that's enough to implement the function in another operating system. As I see it, there are three categories of function: 1. machine interfaces that are document in the Principles of Operation or a Device Description book 2. machine interfaces that are not so documented, but whose existence is disclosed in, and behavior inferred from, the available source code (to the extent needed to replicate the functionality present in the source code) 3. machine interfaces that are neither documented nor used in open code An OCO module may use the above in any combination, so I'm not sure what Jack is asking about: OCO modules (none remain - the 3590 tape driver was open sourced back in May) or interfaces in category 2. Alan Altmark z/VM Development IBM Endicott
Re: DNS question tangents to OpenBSD/390
Alan Altmark wrote: An OCO module may use the above in any combination, so I'm not sure what Jack is asking about: OCO modules (none remain - the 3590 tape driver was open sourced back in May) or interfaces in category 2. I was really asking two questions (which now seem to be answered): 1. Is there anything proprietary clashing with the OpenBSD philosophy license required to create an OpenBSD guest? 2. Is there anything proprietary that's going to act as a technical brick wall if folks start coding towards OpenBSD on VM? Apparently the answer is no. It sounds like OpenBSD might serve certain requirements better than Linux in the VM environment. -- Jack J. Woehr# If your neighbor prays too loud http://www.well.com/~jax # in church, go home and lock your http://www.softwoehr.com # smokehouse. - Harry S Truman
Re: DNS question tangents to OpenBSD/390
There's OCO in Linux/390 ... is it *necessary* to run a guest OS or is it possible to run (and run efficiently?) a guest OS like, um, say, just hypothetically, OpenBSD/390 without any OCO? If you don't have or don't want to use 3590 tapes, yes.
Re: DNS question tangents to OpenBSD/390
Thanks, I was hoping that I wasn't dreaming it. Chuckie: please don't start any threads regarding dreams about Uli! Richard Heritage wrote: According to a presentation given by Ulrich Weigand at the last SHARE, the 3590 support went open source in March of this year, so there are no longer any OCO modules. Richard Heritage Lead Systems Software Engineer IT @ Johns Hopkins Rich Smrcina [EMAIL PROTECTED] 12/20/06 12:56 PM Only the 3590 tape driver (and I even thought that was being resolved). If you don't need 3590 support, it's all good. Rich Smrcina VM Assist, Inc. Cell: (414)491-6001 Catch the WAVV! http://www.wavv.org WAVV 2007 - Green Bay, WI - Original Message - From: Jack Woehr [EMAIL PROTECTED] Date: Wednesday, December 20, 2006 11:37 am Subject: DNS question tangents to OpenBSD/390 To: IBMVM@LISTSERV.UARK.EDU Tom Duerbusch wrote: IUCV and VCTCA, works well in 12 MB. OSA and Hipersockets, 48 MB. Now back on tangent to the origional discussion... Speaking of tangents There's OCO in Linux/390 ... is it *necessary* to run a guest OS or is it possible to run (and run efficiently?) a guest OS like, um, say, just hypothetically, OpenBSD/390 without any OCO? -- Jack J. Woehr# If your neighbor prays too loud http://www.well.com/~jax # in church, go home and lock your http://www.softwoehr.com # smokehouse. - Harry S Truman -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com Catch the WAVV! http://www.wavv.org WAVV 2007 - Green Bay, WI - May 18-22, 2007
Re: DNS question
On 12/19/06, Shimon Lebowitz [EMAIL PROTECTED] wrote: What am I forgetting? The TCPIP DATA goes on the 592 disk. It's the client code (e.g. PING, TELNET) that has to talk to the DNS to translate the host name into an IP address. The stack has no clue about that. We used to say that it was a good idea to run the cache-only resolver that comes with VM TCP/IP (i.e. NAMED) to avoid excessive DNS lookups going outside VM. Some installations also used it to prime the cache with a set of important host names (in case the outboard DNS was not available). But the VM DNS implementation has become a bit dated, so if you can you should probably avoid that route. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/
Re: DNS question
We used to say that it was a good idea to run the cache-only resolver that comes with VM TCP/IP (i.e. NAMED) to avoid excessive DNS lookups going outside VM. Some installations also used it to prime the cache with a set of important host names (in case the outboard DNS was not available). But the VM DNS implementation has become a bit dated, so if you can you should probably avoid that route. Or replace it with a minimal Linux guest.
Re: DNS question
PING does not run on the TCP/IP stack, it runs on the userid that issued the command. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Shimon Lebowitz Sent: December 19, 2006 12:59 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DNS question Quoting Rob van der Heij [EMAIL PROTECTED]: On 12/19/06, Shimon Lebowitz [EMAIL PROTECTED] wrote: What am I forgetting? The TCPIP DATA goes on the 592 disk. It's the client code (e.g. PING, TELNET) that has to talk to the DNS to translate the host name into an IP address. The stack has no clue about that. confused I don't think I understand what you are saying. I put the altered version of TCPIP DATA on TCPIP2's (my test stack userid) so that the stack would see the DNS lines, doesn't PING run in the TCPIP2 user itself? The 191 is accessed ahead of 592, so doesn't TCPIP2 know about the DNS? /confused We used to say that it was a good idea to run the cache-only resolver that comes with VM TCP/IP (i.e. NAMED) to avoid excessive DNS lookups going outside VM. Some installations also used it to prime the cache with a set of important host names (in case the outboard DNS was not available). But the VM DNS implementation has become a bit dated, so if you can you should probably avoid that route. H used to say it was a good idea you should probably avoid that route? I actually tried to start NAMSERV )or whatever the builtin DNS is called), including putting the two DNS server addresses in FORWARDERS(?), but it didn't help. I am home now, so I might not remember keywords correctly. Thanks for responding, Shimon ._._._*_|_*_*_*_* The information transmitted is intended only for the person 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 of any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot by guaranteed on the Internet. The Sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on basis of the information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is the property of the TTC and must not be altered or circumvented in any manner.
Re: DNS question
Shimon ... The stack does not perform DNS resolution. The applications handle it (even if by way of some library function). This is true in other TCP/IP implementations, not just VM TCP/IP: the apps resolve hostnames. -- R; Shimon Lebowitz [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 12/19/2006 12:59 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU From Shimon Lebowitz [EMAIL PROTECTED] To IBMVM@LISTSERV.UARK.EDU cc Subject Re: DNS question Quoting Rob van der Heij [EMAIL PROTECTED]: On 12/19/06, Shimon Lebowitz [EMAIL PROTECTED] wrote: What am I forgetting? The TCPIP DATA goes on the 592 disk. It's the client code (e.g. PING, TELNET) that has to talk to the DNS to translate the host name into an IP address. The stack has no clue about that. confused I don't think I understand what you are saying. I put the altered version of TCPIP DATA on TCPIP2's (my test stack userid) so that the stack would see the DNS lines, doesn't PING run in the TCPIP2 user itself? The 191 is accessed ahead of 592, so doesn't TCPIP2 know about the DNS? /confused We used to say that it was a good idea to run the cache-only resolver that comes with VM TCP/IP (i.e. NAMED) to avoid excessive DNS lookups going outside VM. Some installations also used it to prime the cache with a set of important host names (in case the outboard DNS was not available). But the VM DNS implementation has become a bit dated, so if you can you should probably avoid that route. H used to say it was a good idea you should probably avoid that route? I actually tried to start NAMSERV )or whatever the builtin DNS is called), including putting the two DNS server addresses in FORWARDERS(?), but it didn't help. I am home now, so I might not remember keywords correctly. Thanks for responding, Shimon ._._._*_|_*_*_*_*
Re: DNS question
On Tuesday, 12/19/2006 at 07:59 ZE2, Shimon Lebowitz [EMAIL PROTECTED] wrote: confused I don't think I understand what you are saying. I put the altered version of TCPIP DATA on TCPIP2's (my test stack userid) so that the stack would see the DNS lines, doesn't PING run in the TCPIP2 user itself? The 191 is accessed ahead of 592, so doesn't TCPIP2 know about the DNS? /confused No, PING does not run in the stack. There is a low-level ICMP ECHO (ping) function in the stack that is invoked by the PING program, but that interface expects an IP address as input. DNS resolution is always done in the client virtual machine. We used to say that it was a good idea to run the cache-only resolver that comes with VM TCP/IP (i.e. NAMED) to avoid excessive DNS lookups going outside VM. Some installations also used it to prime the cache with a set of important host names (in case the outboard DNS was not available). But the VM DNS implementation has become a bit dated, so if you can you should probably avoid that route. H used to say it was a good idea you should probably avoid that route? I actually tried to start NAMSERV )or whatever the builtin DNS is called), including putting the two DNS server addresses in FORWARDERS(?), but it didn't help. I am home now, so I might not remember keywords correctly. A caching-only DNS server is useful if you have a lot of CMS-based DNS lookups and you're having DNS-related performance problems. Other operating systems maintain their own caches, so pointing them to VM's DNS server doesn't have much value. It's far easier if you just point your NSINTERADDR entries to your normal DNS servers. Then, whatever the DNS problem du jour is, it isn't your fault. :-) Faster machines and faster networks have all done much to erase the benefit of a caching-only DNS server. Having said that, would there be torches and pitchforks awaiting us at the next conference if we chose to remove the VM DNS server from the suite of supported apps? (No plans...just a Grinchy idea.) Alan Altmark z/VM Development IBM Endicott
Re: DNS question
Having said that, would there be torches and pitchforks awaiting us at the next conference if we chose to remove the VM DNS server from the suite of supported apps? (No plans...just a Grinchy idea.) Mr. Grinch, We would not object to you removing the VM DNS server. We have always used NSINTERADDR to point to our local Windows name servers and have not ever seen any performance related issues. Ed Zell (309) 674-8255 x-107 [EMAIL PROTECTED] . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance.
Re: DNS question
We have not run the VM DNS server since z/VM 3.0. We are now on 5.1, wait ing for 5.3. We would not have any problem with the removal of the VM DNS ser vice. Are there other VM TCP/IP services that you would consider removing? /Tom Kern On Tue, 19 Dec 2006 14:03:37 -0500, Alan Altmark wrote: ...snipped... Faster machines and faster networks have all done much to erase the benefit of a caching-only DNS server. Having said that, would there be torches and pitchforks awaiting us at t he next conference if we chose to remove the VM DNS server from the suite o f supported apps? (No plans...just a Grinchy idea.) Alan Altmark z/VM Development IBM Endicott
Re: DNS question
And of course the programming needed to make this change would be known as The DaGrinchy Code. Laugh now, they don't get any better. Peter Having said that, would there be torches and pitchforks awaiting us at the next conference if we chose to remove the VM DNS server from the suite of supported apps? (No plans...just a Grinchy idea.) Alan Altmark z/VM Development IBM Endicott The information transmitted is intended only for the person 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 of any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot by guaranteed on the Internet. The Sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on basis of the information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is the property of the TTC and must not be altered or circumvented in any manner.
Re: DNS question
Quoting David Boyes [EMAIL PROTECTED]: We used to say that it was a good idea to run the cache-only resolver that comes with VM TCP/IP (i.e. NAMED) to avoid excessive DNS lookups going outside VM. Some installations also used it to prime the cache with a set of important host names (in case the outboard DNS was not available). But the VM DNS implementation has become a bit dated, so if you can you should probably avoid that route. Or replace it with a minimal Linux guest. How will that help? If the DNS didn't work using the servers in our LAN, why would it work better talking to a linux guest? And I would get the extra fun of building a linux DNS server instead of just forwarding all requests to the windows boxes? No thanks. What I still don't understand is why adding the addresses of the servers to the TCPIP DATA didn't have the expected result. Shimon
Re: DNS question
We have never used the VM DNS server, so we would not object too strongly. Laugh now, they don't get any better. And probably not any worse, either. :-) -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, December 19, 2006 11:14 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DNS question And of course the programming needed to make this change would be known as The DaGrinchy Code. Laugh now, they don't get any better. Peter Having said that, would there be torches and pitchforks awaiting us at the next conference if we chose to remove the VM DNS server from the suite of supported apps? (No plans...just a Grinchy idea.) Alan Altmark z/VM Development IBM Endicott The information transmitted is intended only for the person 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 of any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot by guaranteed on the Internet. The Sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on basis of the information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is the property of the TTC and must not be altered or circumvented in any manner.
Re: DNS question
Quoting Alan Altmark [EMAIL PROTECTED]: On Tuesday, 12/19/2006 at 07:59 ZE2, Shimon Lebowitz [EMAIL PROTECTED] wrote: confused I don't think I understand what you are saying. I put the altered version of TCPIP DATA on TCPIP2's (my test stack userid) so that the stack would see the DNS lines, doesn't PING run in the TCPIP2 user itself? The 191 is accessed ahead of 592, so doesn't TCPIP2 know about the DNS? /confused No, PING does not run in the stack. There is a low-level ICMP ECHO (ping) function in the stack that is invoked by the PING program, but that interface expects an IP address as input. DNS resolution is always done in the client virtual machine. OK, I have that straightened out in my mind now. :-) Thanks to all who helped with that. So, PING is a program that runs in *my* virtual machine. And my machine is linked to 592 in order to see the PING MODULE. And 592 has the production version of TCPIP DATA, with no NSINTERADDR records. It's far easier if you just point your NSINTERADDR entries to your normal DNS servers. Then, whatever the DNS problem du jour is, it isn't your fault. :-) So, I need to access the updated DATA file in MY virtual machine, so that PING will know where to do DNS. I will try all this tomorrow. THANKS Shimon ._._._*_|_*_*_*_*
Re: DNS question
On Dec 19, 2006, at 2:03 PM, Alan Altmark wrote: Having said that, would there be torches and pitchforks awaiting us at the next conference if we chose to remove the VM DNS server from the suite of supported apps? (No plans...just a Grinchy idea.) Yes, unless you tossed in a minimal DNS server, say in a 16M Linux guest with, say, a tiny little filesystem in a shared segment. Adam
Re: DNS question
I'd disagree with the assertion that you no longer need an internal DNS; there's still value to having the ability to not go out on the wire, and also to periodically lie to various things about the real setup for a subset of the environment. Remember, you're attaching network segments with the Linux stuff, and it's real handy to cache stuff in common for them. The antique CMS implementation is a royal PITA to do this with, however. Having said that, would there be torches and pitchforks awaiting us at the next conference if we chose to remove the VM DNS server from the suite of supported apps? (No plans...just a Grinchy idea.) Ditch the DB/2-requiring abomination. I'll create a small Linux appliance for the folks that need a real DNS server for VM systems.
Re: DNS question
On Dec 19, 2006, at 2:23 PM, Shimon Lebowitz wrote: Quoting David Boyes [EMAIL PROTECTED]: We used to say that it was a good idea to run the cache-only resolver that comes with VM TCP/IP (i.e. NAMED) to avoid excessive DNS lookups going outside VM. Some installations also used it to prime the cache with a set of important host names (in case the outboard DNS was not available). But the VM DNS implementation has become a bit dated, so if you can you should probably avoid that route. Or replace it with a minimal Linux guest. How will that help? If the DNS didn't work using the servers in our LAN, why would it work better talking to a linux guest? Because the Linux bind9 implementation is a modern implementation of DNS. Yes, for it to be a useful caching server it's still going to have to be able to talk to some other network servers. And I would get the extra fun of building a linux DNS server instead of just forwarding all requests to the windows boxes? The idea would be that *you* wouldn't have to do it. Just another virtual machine that you power on and something is providing name service to things on the VM host. Adam
Re: DNS question
Mr. Grinch - Cindy Loo Who asked if z/OS is using BIND now and if that could run on OpenVM. She's a bright kid! I was going to ask her more about the idea, but some Opie-looking guy kept yelling cut! cut! and chased us off the set. - ho ho ho - Sir Santa -- R;
Re: DNS question
We used to say that it was a good idea to run the cache-only resolver that comes with VM TCP/IP (i.e. NAMED) to avoid excessive DNS lookups going outside VM. Some installations also used it to prime the cache with a set of important host names (in case the outboard DNS was not available). But the VM DNS implementation has become a bit dated, so if you can you should probably avoid that route. Or replace it with a minimal Linux guest. How will that help? If the DNS didn't work using the servers in our LAN, why would it work better talking to a linux guest? In your case, it was actually a different problem (what interprets the NSINTERADDR lines is in the client VM, not the stack VM); I was commenting on Rob's comment about no longer running the caching server on VM. The reasons it helps with the issue of running the caching server on VM in that the Linux appliance allows you to cache efficiently (as the current code does), but also supply real usable DNS services that can supply answers different than the ones supplied by your external DNS for test or policy reasons, as well as support the latest security and authentication requirements. The biggest problems with the CMS DNS server are that it is based on really, really ancient interpretations of the DNS RFCs and that it requires DB/2 VM to provide anything more than caching services. Given the neglect of DB/2 VM over the past years and the cost, running DNS doesn't really work on CMS other than if it's absolutely required by some procurement wonk with a checklist. Can't do DNSSEC, can't do zone transfer restrictions, can't do DDNS, can't do a lot of things. All of which 'bind' on Linux does trivially at zero additional cost. It's handy for test purposes because you could force the Linux guest to give any answer you wanted w/o having to convince your Windows admins to break the real DNS for your purpose. It's also useful in the case where you're hosting Linux guests that provide network services to not have a dozen different systems beating the tar out of your external DNS servers; get one internal one set up, cache results, and have all the extras consult the internal one. Significantly less network traffic for busy services that way.
Re: DNS question
On 12/19/06, David Boyes [EMAIL PROTECTED] wrote: It's handy for test purposes because you could force the Linux guest to give any answer you wanted w/o having to convince your Windows admins to break the real DNS for your purpose. It's also useful in the case where you're hosting Linux guests that provide network services to not have a Yeah... depending on how fluent you are in DNS it will either bite you very soon or only later... The DNS protocol has been stretched and the de-facto standard extended beyond the RFCs. When you make your DNS claim authority over a domain that you don't own, real world effects may vary. Things like negative caching can make you go bold very fast. I learned a lot of those tricks when I did my own DNS server on CMS. And I learned from my network colleague that you can also contaminate the cache of the NAMESERV freebie with names that you made up yourself. Can do for several evenings happy searching. For an occasional telnet or ping command, the impact of going out to resolve the name is neglectable. The best case imho for having a DNS cache local on VM is for reverse lookup of client IP address when you run a web server on VM. The typical visit may contain several hits and going out to the LAN for each of them is a waste because probably the web server will wait for the response before serving the client. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/
Re: DNS question
On Tuesday, 12/19/2006 at 02:56 EST, Adam Thornton [EMAIL PROTECTED] wrote: Yes, unless you tossed in a minimal DNS server, say in a 16M Linux guest with, say, a tiny little filesystem in a shared segment. B. IBM is not a Linux distributor and it doesn't qualify as an imbedded system. You may take your seat now. Next, please! Alan Altmark z/VM Development IBM Endicott
Re: DNS question
On 12/19/06, David Boyes [EMAIL PROTECTED] wrote: It's handy for test purposes because you could force the Linux guest to give any answer you wanted w/o having to convince your Windows admins to break the real DNS for your purpose. It's also useful in the case where you're hosting Linux guests that provide network services to not have a Yeah... depending on how fluent you are in DNS it will either bite you very soon or only later... Life is seldom risk free; your gun, your foot. If you don't know what you're doing, you shouldn't play with sharp objects. Cache poisoning tools are a lot more difficult to control than zone files are. It's also a lot simpler to always list a local DNS server first in the standard list in your configuration and just shut it down when it's not in use. For caching purposes it works fine, and in test or DR situations, you bring it up with a minimal set of zone files, and DNS Just Works, the way it's supposed to -- long before any of the Windows guys have gotten past reinstalling to get a fresh SID. The VM resolver code is fine with retrying the next one in the list if the first one isn't there. The DNS protocol has been stretched and the de-facto standard extended beyond the RFCs. And bind happens to *be* the de-facto standard implementation. Another reason to run it instead of the VM DNS server code. For an occasional telnet or ping command, the impact of going out to resolve the name is neglectable. True. The best case imho for having a DNS cache local on VM is for reverse lookup of client IP address when you run a web server on VM. The typical visit may contain several hits and going out to the LAN for each of them is a waste because probably the web server will wait for the response before serving the client. Mail is another high volume one (also lots of reverse lookups, even if you just do outgoing from VM). Or LPR/LPD for heavily-used printers. Or any high-connection-volume service, really.
Re: DNS question
On Dec 19, 2006, at 9:25 PM, Jack Woehr wrote: Adam Thornton wrote: Yes, unless you tossed in a minimal DNS server, say in a 16M Linux guest with, say, a tiny little filesystem in a shared segment. It's called 'Bind' Well, no. A minimal DNS server would be, say, tinydns. But then you'd have to deal with djbware. Or, you know, several of the things listed at http://www.debianadmin.com/open-source-domain-name-systemdns- servers.html. bind is, these days, anything but minimal. Don't get me wrong--I like bind9 quite a bit. But it's kinda...well...it's gonna have to let that prom dress out a little, is what I mean. And I'd say it has a nice personality, only, um, it's only slightly less cranky than djbware, really. However, as Chuckie has pointed out, my post is moot because IBM is not going to get into the Linux distribution market. So...has anyone invested any time in a CMS port (OpenVM or otherwise) of one of the lightweight DNS servers? Adam
Re: DNS question
On Dec 19, 2006, at 11:01 PM, Jack Woehr wrote: Adam Thornton wrote: bind is, these days, anything but minimal. We should port OpenBSD to the 390. You could probably run OpenBSD + bind in a 12MB VM. Way back in '99 I suggested a port to the NetBSD guys (back when NetBSD's big claim to fame was its portability), and instead of saying hey, neat idea, or what would it take? they subjected me to a tirade about how much Linux sucked. That sort of soured me on finding BSD porters for the architecture. I haven't ever approached Theo about a 390 port. But with Hercules, you could get started for very very cheap Adam
