PR: SuSE Linux Enterprise Server Validated for Latest Version of DB2
See: http://linuxtoday.com/news_story.php3?ltsn=2002-11-08-004-26-NW-BZ-SS; SuSE Linux Enterprise Server is the first distribution to be validated on all hardware platforms supported by DB2 for Linux (including IBM zSeries mainframes) and validated to run DB2 Enterprise Server Edition. SuSE`s success story of enterprise products builds on the validated distributions, including SLES 7, SLES 8 on Intel 32 and 64 bit, and SLES 7 on zSeries (and SLES 8 on zSeries when available). SuSE Linux assures enterprise customers running database workloads in a tested Linux environment. SLES is a proven Enterprise Solution and one of the most secure, affordable and reliable operating systems in the world. 'IBM's DB2 database software is a leader in database scalability, reliability, multimedia extensibility, and Web enablement needed for the most demanding e-business applications,' said Boris Nalbach, CTO SuSE Linux AG. 'This latest validation is proof of the successful cooperation between IBM and SuSE and our determination to deliver Linux-based Enterprise Solutions for the data center...'
More NSS Info
I don't have the faintest idea why IBM claims that you have to have an identical DASD layout on all machines that share an NSS. Admittedly cursory testing seems to show that your NSS will have whatever parameter line you burned into it, which does specify a range of devices. But not only can those devices change size (I tested this with an ext3 and a swap filesystem), if you boot without a listed device, the only problem you will have that I could find was that you may trip over it in /etc/fstab. But if you have a disk that's not in /etc/fstab, which you detach before IPL, you can re-link and then access that disk pefectly normally from Linux (using the console or hcp to perform the link). So it's looking to *me* like you should pick a lowest-common-denominator disk layout (for most of our guests, that'd be / on 150, swap on VDISK on 151, and /usr on 152), build the NSS with as small a storage size as you can (24M works for us) and then not worry about it. If anyone can tell me why I'm wrong, and that, although I have mounted differently-sized disks, I'm heading for fatal filesystem corruption just around the corner, I'd appreciate it. Adam
Virtual network topology questions...
Given an IFL running zVM and several Linux/390 images, is it better to fan out to all the Linux images from zVM's TCPIP, or should TCPIP talk to a selection of images, with these images each handling several end machines, more like a tree structure? What would be the advantages and disadvantages of either method, and is there a break-even point below which you'd want to fan from TCPIP, but above which you'd want helper images? If two images have a need to talk to each other, is it better to connect them directly, or just allow them to converse through zVM's TCPIP? And lastly: When I install SuSE, it lists the IUCV driver as experimental. Is it experimental, but stable, and I should take a look at it, or is it experimental, and unstable, and I should stick to the vCTCA's I'm currently using? Thanks in advance for any and all opinions. Robert P. Nixinternet: [EMAIL PROTECTED] Mayo Clinic phone: 507-284-0844 200 1st St. SW page: 507-255-3450 Rochester, MN 55905 In theory, theory and practice are the same, but in practice, theory and practice are different.
Re: Virtual network topology questions...
On Fri, Nov 08, 2002 at 08:44:20AM -0600, Nix, Robert P. wrote: Given an IFL running zVM and several Linux/390 images, is it better to fan out to all the Linux images from zVM's TCPIP, or should TCPIP talk to a selection of images, with these images each handling several end machines, more like a tree structure? What would be the advantages and disadvantages of either method, and is there a break-even point below which you'd want to fan from TCPIP, but above which you'd want helper images? I'd say that the answer is none of the above. Which version of z/VM? If at all possible, use a guest LAN. It makes your life a *whole* lot simpler. If you can't, I'd say use about six downstream Linux images per upstream router; IUCV is theoretically faster, but I have found CTC somewhat easier to configure. Now, you're using SuSE, so that may be a stumbling block too. IIRC, the totally-free version (beer, not speech, for those of you keeping score at home) of SuSE doesn't do HiperSockets. But if you have either the $500 trial or a support contract then you have access to the service releases, which do let you use HiperSockets. And if you don't, then (IMHO) you shouldn't be using SuSE--if you're going to be your own support, you may as well be your own support with a less antiquated distribution. I'm going to surprise exactly no one by saying here, Debian. Largely because I haven't played with RH in a long time, and I know that Debian works just fine (albeit taintedly) with the qeth drivers and guest LANs. To wit: debian:~# uname -a Linux debian 2.4.19 #1 SMP Thu Nov 7 13:33:12 CST 2002 s390 unknown debian:~# ifconfig hsi0 hsi0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:192.168.129.7 Mask:255.255.255.0 inet6 addr: fe80::200:ff:fe00:0/10 Scope:Link UP RUNNING NOARP MULTICAST MTU:8192 Metric:1 RX packets:228 errors:0 dropped:0 overruns:0 frame:0 TX packets:143 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:20515 (20.0 KiB) TX bytes:22262 (21.7 KiB) Interrupt:15 debian:~# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 192.168.131.65 0.0.0.0 255.255.255.255 UH0 00 ctc0 192.168.129.0 0.0.0.0 255.255.255.0 U 0 00 hsi0 0.0.0.0 192.168.129.1 0.0.0.0 UG0 00 hsi0 debian:~# You'll notice that I'm routing through the HiperSockets connection, not the ctc. Adam
Re: Virtual network topology questions...
9672, so no hiper-sockets. In trial mode, so no money to buy a distribution or support, but with the potential to do so if / when it goes into production. Potentially running DB2 and WebSphere, so SuSE instead of RedHat, as IBM supports SuSE more so than RedHat, in our experience. I'd like to work within the confines I have. Robert P. Nixinternet: [EMAIL PROTECTED] Mayo Clinic phone: 507-284-0844 200 1st St. SW page: 507-255-3450 Rochester, MN 55905 In theory, theory and practice are the same, but in practice, theory and practice are different. -Original Message- From: Adam Thornton [SMTP:[EMAIL PROTECTED]] Sent: Friday, November 08, 2002 9:59 AM To: [EMAIL PROTECTED] Subject: Re: Virtual network topology questions... On Fri, Nov 08, 2002 at 08:44:20AM -0600, Nix, Robert P. wrote: Given an IFL running zVM and several Linux/390 images, is it better to fan out to all the Linux images from zVM's TCPIP, or should TCPIP talk to a selection of images, with these images each handling several end machines, more like a tree structure? What would be the advantages and disadvantages of either method, and is there a break-even point below which you'd want to fan from TCPIP, but above which you'd want helper images? I'd say that the answer is none of the above. Which version of z/VM? If at all possible, use a guest LAN. It makes your life a *whole* lot simpler. If you can't, I'd say use about six downstream Linux images per upstream router; IUCV is theoretically faster, but I have found CTC somewhat easier to configure. Now, you're using SuSE, so that may be a stumbling block too. IIRC, the totally-free version (beer, not speech, for those of you keeping score at home) of SuSE doesn't do HiperSockets. But if you have either the $500 trial or a support contract then you have access to the service releases, which do let you use HiperSockets. And if you don't, then (IMHO) you shouldn't be using SuSE--if you're going to be your own support, you may as well be your own support with a less antiquated distribution. I'm going to surprise exactly no one by saying here, Debian. Largely because I haven't played with RH in a long time, and I know that Debian works just fine (albeit taintedly) with the qeth drivers and guest LANs. To wit:
Re: CPU Arch Security [was: Re: Probably the first published shel l code]
Folks, This is known territory, both in implementation and literature. Both Multics and MTS implemented a similar architecture to what Linus V. is describing, and Apollo did an implementation with distributed memory in NCS. I'd suggest doing some reading before you go off to design a CPU -- we've solved this problem several times before. -- db David Boyes Sine Nomine Associates
Re: Virtual network topology questions...
Given an IFL running zVM and several Linux/390 images, is it better to fan out to all the Linux images from zVM's TCPIP, or should TCPIP talk to a selection of images, with these images each handling several end machines, more like a tree structure? If you have a version of z/VM that supports guest LANs, you should be using guest LANs and eliminating the point-to-point links wherever possible, if nothing else to keep from going insane handling the addressing. This provides a third option: using VM TCP (or a Linux TCP stack) to control a physical adapter and connecting to multiple guest LANs acting as a router. Guests on the LAN talk directly to each other (just as the do on an external network) and only inter-segment traffic passes through the router. And lastly: When I install SuSE, it lists the IUCV driver as experimental. Is it experimental, but stable, and I should take a look at it, or is it experimental, and unstable, and I should stick to the vCTCA's I'm currently using? Get rid of the CTCs as fast as you can. If you don't have a guest LAN capable VM, then the IUCV stuff is about as stable as the CTC driver.
Re: Virtual network topolgy questions...
On Fri, Nov 08, 2002 at 09:12:32AM -0600, Nix, Robert P. wrote: 9672, so no hiper-sockets. In trial mode, so no money to buy a distribution or support, but with the potential to do so if / when it goes into production. Potentially running DB2 and WebSphere, so SuSE instead of RedHat, as IBM supports SuSE more so than RedHat, in our experience. I'd like to work within the confines I have. Virtual HiperSockets work fine on a 9672 if you have z/VM 4.2 (or even heavily-patched 4.1, I think) or later. You do not need hardware HiperSocket support to emulate HiperSockets under z/VM. You *really* don't want to build a penguin colony on CTCs. Fork over $500 (am I right about the price?) to SuSE for *their* trial so you can get access to their patches (for 30? 90? days, which should be enough to build a network), and configure guest LANs. Find that $500 somewhere. You'll make up the difference in labor costs pretty much immediately. If you insist on using multiple point-to-point connections, I'd still say six boxes per router, but be aware that it's going to be much more fragile and difficult to configure and manage, and the performance will probably be worse. Adam
Re: Virtual network topology questions...
If at all possible, use the Guest LAN. It gets past all of this point to point stuff and for all the reasons that Adam mentioned. On Friday 08 November 2002 08:44 am, you wrote: Given an IFL running zVM and several Linux/390 images, is it better to fan out to all the Linux images from zVM's TCPIP, or should TCPIP talk to a selection of images, with these images each handling several end machines, more like a tree structure? What would be the advantages and disadvantages of either method, and is there a break-even point below which you'd want to fan from TCPIP, but above which you'd want helper images? If two images have a need to talk to each other, is it better to connect them directly, or just allow them to converse through zVM's TCPIP? And lastly: When I install SuSE, it lists the IUCV driver as experimental. Is it experimental, but stable, and I should take a look at it, or is it experimental, and unstable, and I should stick to the vCTCA's I'm currently using? Thanks in advance for any and all opinions. Robert P. Nixinternet: [EMAIL PROTECTED] Mayo Clinic phone: 507-284-0844 200 1st St. SW page: 507-255-3450 Rochester, MN 55905 In theory, theory and practice are the same, but in practice, theory and practice are different. -- Rich Smrcina Sytek Services, Inc. Milwaukee, WI [EMAIL PROTECTED] [EMAIL PROTECTED] Catch the WAVV! Stay for Requirements and the Free for All! Update your S/390 skills in 4 days for a very reasonable price. WAVV 2003 in Winston-Salem, NC. April 25-29, 2003 For details see http://www.wavv.org
Re: Virtual network topology questions...
No hardware hipersockets doesn't necessarily mean that you can't use the guest LAN. Are you using the evaluation version of SuSE 7.2 or are you using the old SuSE with the 2.2.16 kernel? If the former you can define a guest LAN and set up SuSE to use it. If the latter, then you are definitely stuck using point to point. On Friday 08 November 2002 09:12 am, you wrote: 9672, so no hiper-sockets. In trial mode, so no money to buy a distribution or support, but with the potential to do so if / when it goes into production. Potentially running DB2 and WebSphere, so SuSE instead of RedHat, as IBM supports SuSE more so than RedHat, in our experience. I'd like to work within the confines I have. Robert P. Nixinternet: [EMAIL PROTECTED] Mayo Clinic phone: 507-284-0844 200 1st St. SW page: 507-255-3450 Rochester, MN 55905 In theory, theory and practice are the same, but in practice, theory and practice are different. -Original Message- From: Adam Thornton [SMTP:[EMAIL PROTECTED]] Sent: Friday, November 08, 2002 9:59 AM To: [EMAIL PROTECTED] Subject: Re: Virtual network topology questions... On Fri, Nov 08, 2002 at 08:44:20AM -0600, Nix, Robert P. wrote: Given an IFL running zVM and several Linux/390 images, is it better to fan out to all the Linux images from zVM's TCPIP, or should TCPIP talk to a selection of images, with these images each handling several end machines, more like a tree structure? What would be the advantages and disadvantages of either method, and is there a break-even point below which you'd want to fan from TCPIP, but above which you'd want helper images? I'd say that the answer is none of the above. Which version of z/VM? If at all possible, use a guest LAN. It makes your life a *whole* lot simpler. If you can't, I'd say use about six downstream Linux images per upstream router; IUCV is theoretically faster, but I have found CTC somewhat easier to configure. Now, you're using SuSE, so that may be a stumbling block too. IIRC, the totally-free version (beer, not speech, for those of you keeping score at home) of SuSE doesn't do HiperSockets. But if you have either the $500 trial or a support contract then you have access to the service releases, which do let you use HiperSockets. And if you don't, then (IMHO) you shouldn't be using SuSE--if you're going to be your own support, you may as well be your own support with a less antiquated distribution. I'm going to surprise exactly no one by saying here, Debian. Largely because I haven't played with RH in a long time, and I know that Debian works just fine (albeit taintedly) with the qeth drivers and guest LANs. To wit: -- Rich Smrcina Sytek Services, Inc. Milwaukee, WI [EMAIL PROTECTED] [EMAIL PROTECTED] Catch the WAVV! Stay for Requirements and the Free for All! Update your S/390 skills in 4 days for a very reasonable price. WAVV 2003 in Winston-Salem, NC. April 25-29, 2003 For details see http://www.wavv.org
Re: Virtual network topology questions...
9672, so no hiper-sockets. In trial mode, so no money to buy a distribution or support, but with the potential to do so if / when it goes into production. Potentially running DB2 and WebSphere, so SuSE instead of RedHat, as IBM supports SuSE more so than RedHat, in our experience. Guest LANs do not require hardware hipersockets. They use the same driver, but do not require the hardware. I'd like to work within the confines I have. If x/VM 4.2 or higher runs on your box, you have the support you need. -- db
Re: Virtual network topology questions...
Nix, Robert P. writes: 9672, so no hiper-sockets. In trial mode, so no money to buy a distribution or support, but with the potential to do so if / when it goes into production. Potentially running DB2 and WebSphere, so SuSE instead of RedHat, as IBM supports SuSE more so than RedHat, in our experience. I'd like to work within the confines I have. You don't need physical hiper-sockets hardware for the GuestLAN and virtual hipersockets provided by z/VM 4.3. GuestLAN (or virtual hsi) simplifies many things. Unless there's absolutely no way for you to use z/VM 4.3, you're good to go. Part 2 of the ...zSeries... Large Scale Linux Deployment redbook (SG246824) covers these sorts of issues and includes chapters on Hipersockets and z/VM GuestLAN, TCP/IP direct connection and TCP/IP routing. --Malcolm -- Malcolm Beattie [EMAIL PROTECTED] Linux Technical Consultant IBM EMEA Enterprise Server Group... ...from home, speaking only for myself
Re: Virtual network topology questions...
I think that as long as your distribution of Linux supports QDIO (which 2.2.16 does) you can define a qdio (instead of a hipers one) guest lan under zVM 4.3 and use qdio/qeth. (I think! haven't tried it) Carlos :-) Saying goes: Great minds think alike - I say: Great minds think for themselves! Carlos A. Ordonez IBM Corporation Server Consolidation |-+--- | | Rich Smrcina| | | [EMAIL PROTECTED]| | | com| | | Sent by: Linux | | | on 390 Port | | | [EMAIL PROTECTED]| | | RIST.EDU | | | | | | | | | 11/08/2002 10:23| | | AM | | | Please respond | | | to Linux on 390 | | | Port| | | | |-+--- ---| | | |To: [EMAIL PROTECTED] | |cc: | | From: | | Subject: Re: Virtual network topology questions... | | | ---| No hardware hipersockets doesn't necessarily mean that you can't use the guest LAN. Are you using the evaluation version of SuSE 7.2 or are you using the old SuSE with the 2.2.16 kernel? If the former you can define a guest LAN and set up SuSE to use it. If the latter, then you are definitely stuck using point to point. On Friday 08 November 2002 09:12 am, you wrote: 9672, so no hiper-sockets. In trial mode, so no money to buy a distribution or support, but with the potential to do so if / when it goes into production. Potentially running DB2 and WebSphere, so SuSE instead of RedHat, as IBM supports SuSE more so than RedHat, in our experience. I'd like to work within the confines I have. Robert P. Nixinternet: [EMAIL PROTECTED] Mayo Clinic phone: 507-284-0844 200 1st St. SW page: 507-255-3450 Rochester, MN 55905 In theory, theory and practice are the same, but in practice, theory and practice are different. -Original Message- From: Adam Thornton [SMTP:[EMAIL PROTECTED]] Sent: Friday, November 08, 2002 9:59 AM To: [EMAIL PROTECTED] Subject: Re: Virtual network topology questions... On Fri, Nov 08, 2002 at 08:44:20AM -0600, Nix, Robert P. wrote: Given an IFL running zVM and several Linux/390 images, is it better to fan out to all the Linux images from zVM's TCPIP, or should TCPIP talk to a selection of images, with these images each handling several end machines, more like a tree structure? What would be the advantages and disadvantages of either method, and is there a break-even point below which you'd want to fan from TCPIP, but above which you'd want helper images? I'd say that the answer is none of the above. Which version of z/VM? If at all possible, use a guest LAN. It makes your life a *whole* lot simpler. If you can't, I'd say use about six downstream Linux images per upstream router; IUCV is theoretically faster, but I have found CTC somewhat easier to configure. Now, you're using SuSE, so that may be a stumbling block too. IIRC, the totally-free version (beer, not speech, for those of you keeping score at home) of SuSE doesn't do HiperSockets. But if you have either the $500 trial or a support contract then you have access to the service releases, which do let you use HiperSockets. And if you don't, then (IMHO) you shouldn't be using SuSE--if you're going to be your own support, you may as well be your own support with a less antiquated distribution. I'm going to surprise exactly no one by saying here, Debian. Largely because I haven't played with RH in a long time, and I know that Debian works just fine (albeit taintedly) with the qeth drivers and guest LANs. To wit: -- Rich Smrcina Sytek Services, Inc. Milwaukee, WI [EMAIL
Re: Virtual network topology questions...
So according to the statements below...I CAN use SUSE SLES7 to play the guest lan game, using QDIO instead of virtual hipersockets? Am I correct in this assumption? Any testimony from someone who has setup guest lans with SUSE SLES7? Tia Dave Myers Adam said... Now, you're using SuSE, so that may be a stumbling block too. IIRC, the totally-free version (beer, not speech, for those of you keeping score at home) of SuSE doesn't do HiperSockets. But if you have either the $500 trial or a support contract then you have access to the service releases, which do let you use HiperSockets. And if you don't, then (IMHO) you shouldn't be using SuSE--if you're going to be your own support, you may as well be your own support with a less antiquated Rober said... No hardware hipersockets doesn't necessarily mean that you can't use the guest LAN. Are you using the evaluation version of SuSE 7.2 or are you using the old SuSE with the 2.2.16 kernel? If the former you can define a guest LAN and set up SuSE to use it. If the latter, then you are definitely stuck using point to point. Carlos said: I think that as long as your distribution of Linux supports QDIO (which 2.2.16 does) you can define a qdio (instead of a hipers one) guest lan under zVM 4.3 and use qdio/qeth. (I think! haven't tried it) Carlos :-)
Re: More NSS Info
Would it not be sufficient to create the NSS with just the boot disk and maybe swap configured in on the kernel parameter line, and then using something very early on in the boot process to add the other disks using /proc/dasd/devices? It might take some work to get the NSS and RO boot disk just right for this to work, but it would make it a lot more flexible. Kris On Fri, Nov 08, 2002 at 10:43:15AM -0500, Adam Thornton wrote: I don't have the faintest idea why IBM claims that you have to have an identical DASD layout on all machines that share an NSS. Admittedly cursory testing seems to show that your NSS will have whatever parameter line you burned into it, which does specify a range of devices. But not only can those devices change size (I tested this with an ext3 and a swap filesystem), if you boot without a listed device, the only problem you will have that I could find was that you may trip over it in /etc/fstab. But if you have a disk that's not in /etc/fstab, which you detach before IPL, you can re-link and then access that disk pefectly normally from Linux (using the console or hcp to perform the link). So it's looking to *me* like you should pick a lowest-common-denominator disk layout (for most of our guests, that'd be / on 150, swap on VDISK on 151, and /usr on 152), build the NSS with as small a storage size as you can (24M works for us) and then not worry about it. If anyone can tell me why I'm wrong, and that, although I have mounted differently-sized disks, I'm heading for fatal filesystem corruption just around the corner, I'd appreciate it. Adam -- Never underestimate a Mage with: - the Intelligence to cast Magic Missile, - the Constitution to survive the first hit, and - the Dexterity to run fast enough to avoid being hit a second time.
Re: Questions about accessing DASD
Working with a RH 7.2 image in an LPAR, which currently accesses 3390-3 volumes (over ESCON?). I remember hearing that linux s/390 can handle 3390-9 volumes, can it handle 3390-27's? It should -- I don't have any to test it, but the Linux DASD drivers are pretty tolerant of odd sizes. They don't tolerate PAV (at least for booting) yet, though. Also, the shark is being used to share dasd with open systems over fiber. Would it be possible to have the linux image connect (over FICON?) to access that same data? For example, to mount the same file-system an NT server is hitting? You would need the FCP microcode for the FICON adapter (which effectively turns it into a FCP adapter and you lose the ability to access FICON-connected disks) and the FCP disk device driver for your Linux system. See your CE or IBM rep for the former, the developerworks WWW site for the latter. Note that when you convert the FICON adapter to FCP, you need to plug it into a FCP port on the ESS, not a FICON port. -- db
Re: Questions about accessing DASD
Daniel, Linux/390 should be able to handle mod 27's with no problem. I don't think FICON support is there (but I could be wrong), but I know (from Neale Ferguson) that FCP support works pretty well. When we were at the VM/VSE tech conference, he showed me a 200GB file system (yes, that's Giga, not Mega) he created using just such a setup. Mark Post -Original Message- From: [EMAIL PROTECTED] [mailto:daniel.jarboe;custserv.com] Sent: Friday, November 08, 2002 11:00 AM To: [EMAIL PROTECTED] Subject: Questions about accessing DASD Let me start with: I do not have a mainframe background, and I'm still trying to get my head around the concepts. Working with a RH 7.2 image in an LPAR, which currently accesses 3390-3 volumes (over ESCON?). I remember hearing that linux s/390 can handle 3390-9 volumes, can it handle 3390-27's? Also, the shark is being used to share dasd with open systems over fiber. Would it be possible to have the linux image connect (over FICON?) to access that same data? For example, to mount the same file-system an NT server is hitting? I'm sorry if my wording is all off and I am talking about jamming square blocks into round holes. Thanks a lot for any answers, ~ Daniel
Re: More NSS Info
You would need at least one non-root/swap address mounted as /config or something for storing the configuration of what goes where, and you'd have to move at least a few of the utilities (eg mount, ifconfig, etc) from /usr to /sbin (generating statically linked versions) and include /sbin in the root filesystem. Much as I dislike Solaris, their diskless workstation filesystem layout is a pretty good model for this. We should use that as a model for ideas. -- db David Boyes Sine Nomine Associates -Original Message- From: Linux on 390 Port [mailto:LINUX-390;VM.MARIST.EDU]On Behalf Of Kris Van Hees Sent: Friday, November 08, 2002 11:00 AM To: [EMAIL PROTECTED] Subject: Re: More NSS Info Would it not be sufficient to create the NSS with just the boot disk and maybe swap configured in on the kernel parameter line, and then using something very early on in the boot process to add the other disks using /proc/dasd/devices? It might take some work to get the NSS and RO boot disk just right for this to work, but it would make it a lot more flexible. Kris On Fri, Nov 08, 2002 at 10:43:15AM -0500, Adam Thornton wrote: I don't have the faintest idea why IBM claims that you have to have an identical DASD layout on all machines that share an NSS. Admittedly cursory testing seems to show that your NSS will have whatever parameter line you burned into it, which does specify a range of devices. But not only can those devices change size (I tested this with an ext3 and a swap filesystem), if you boot without a listed device, the only problem you will have that I could find was that you may trip over it in /etc/fstab. But if you have a disk that's not in /etc/fstab, which you detach before IPL, you can re-link and then access that disk pefectly normally from Linux (using the console or hcp to perform the link). So it's looking to *me* like you should pick a lowest-common-denominator disk layout (for most of our guests, that'd be / on 150, swap on VDISK on 151, and /usr on 152), build the NSS with as small a storage size as you can (24M works for us) and then not worry about it. If anyone can tell me why I'm wrong, and that, although I have mounted differently-sized disks, I'm heading for fatal filesystem corruption just around the corner, I'd appreciate it. Adam -- Never underestimate a Mage with: - the Intelligence to cast Magic Missile, - the Constitution to survive the first hit, and - the Dexterity to run fast enough to avoid being hit a second time.
Lotus Notes on Linux
We currently run Lotus Notes on AIX. We intend to up grade to the next release when it comes available for some desired feature which escapes me at the moment and is not part of this query anyway. We currently have a 60GB application which is comprised of Clerk of the Courts transactions from which our folks read through and adjust property records to reflect the new ownership and such changes. There about 600 data bases comprising from 500 to 2000 tiff images each. My question; Is this a likely candidate for a Linux Lotus Notes application. There are about 30 active users accessing images all day long. There is active loading and unloading of images into new data bases and old data bases being moved to CD-ROM. The Notes server is also handling e-mail for about 75 users. Are there any significant look and or feel differences and are the release levels current from platform to platform. Are there any significant cost differences. The hardware is not a problem. I'm running a 2066-001 so theirs plenty of power. Steve Domarski Property Appraisers Office Marion County Florida USA
Re: More NSS Info
If you put something like cmsfs or hcp on the root disk, you should have enough to read a config file from the CMS A-disk and use information in there to do the dynamic configuration of the disks. Despite what Sun Microsystems did with linking /usr/bin and /usr/sbin into the root filesystem as /bin and /sbin, a more sensible setup is still to have the core utilities that are required to boot a system (and to do basic maintenance) as part of the actual root partition. I've banged my head against that stupidity in Solaris more than once when a disk that held /usr happened to die. Especially when you do not have a CDROM to boot the install media from. Kris On Fri, Nov 08, 2002 at 11:23:25AM -0500, David Boyes wrote: You would need at least one non-root/swap address mounted as /config or something for storing the configuration of what goes where, and you'd have to move at least a few of the utilities (eg mount, ifconfig, etc) from /usr to /sbin (generating statically linked versions) and include /sbin in the root filesystem. Much as I dislike Solaris, their diskless workstation filesystem layout is a pretty good model for this. We should use that as a model for ideas. -- db David Boyes Sine Nomine Associates -Original Message- From: Linux on 390 Port [mailto:LINUX-390;VM.MARIST.EDU]On Behalf Of Kris Van Hees Sent: Friday, November 08, 2002 11:00 AM To: [EMAIL PROTECTED] Subject: Re: More NSS Info Would it not be sufficient to create the NSS with just the boot disk and maybe swap configured in on the kernel parameter line, and then using something very early on in the boot process to add the other disks using /proc/dasd/devices? It might take some work to get the NSS and RO boot disk just right for this to work, but it would make it a lot more flexible. Kris On Fri, Nov 08, 2002 at 10:43:15AM -0500, Adam Thornton wrote: I don't have the faintest idea why IBM claims that you have to have an identical DASD layout on all machines that share an NSS. Admittedly cursory testing seems to show that your NSS will have whatever parameter line you burned into it, which does specify a range of devices. But not only can those devices change size (I tested this with an ext3 and a swap filesystem), if you boot without a listed device, the only problem you will have that I could find was that you may trip over it in /etc/fstab. But if you have a disk that's not in /etc/fstab, which you detach before IPL, you can re-link and then access that disk pefectly normally from Linux (using the console or hcp to perform the link). So it's looking to *me* like you should pick a lowest-common-denominator disk layout (for most of our guests, that'd be / on 150, swap on VDISK on 151, and /usr on 152), build the NSS with as small a storage size as you can (24M works for us) and then not worry about it. If anyone can tell me why I'm wrong, and that, although I have mounted differently-sized disks, I'm heading for fatal filesystem corruption just around the corner, I'd appreciate it. Adam -- Never underestimate a Mage with: - the Intelligence to cast Magic Missile, - the Constitution to survive the first hit, and - the Dexterity to run fast enough to avoid being hit a second time. -- Never underestimate a Mage with: - the Intelligence to cast Magic Missile, - the Constitution to survive the first hit, and - the Dexterity to run fast enough to avoid being hit a second time.
Re: Virtual network topology questions...
On Fri, Nov 08, 2002 at 10:57:41AM -0500, Dave Myers wrote: So according to the statements below...I CAN use SUSE SLES7 to play the guest lan game, using QDIO instead of virtual hipersockets? Am I correct in this assumption? Any testimony from someone who has setup guest lans with SUSE SLES7? Tia Dave Myers Yeah, as long as you're running one of the more recent patches that fixes virtual qeth support, it works fine. On a virtual LAN, the only difference is whether you specify it as type QDIO or leave it unset (in the VM LAN definition statment). Then if it's a qdio LAN, you define your virtual NIC to the guest as TYPE QDIO (which really means OSA, since both HiperSockets and OSA are QDIO devices). Virtual OSAs support broadcast (under z/VM 4.3). HiperSockets don't. That's pretty much the difference between them. They use the same driver, but OSA is aliased to interface ethX and HiperSockets to hsiX. Here's something from an SLES-based guest... r2:~ # ifconfig eth2 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:192.168.130.67 Mask:255.255.255.192 inet6 addr: fe80::200:ff:fe00:0/10 Scope:Link UP RUNNING NOARP MULTICAST MTU:1492 Metric:1 RX packets:473155 errors:0 dropped:0 overruns:0 frame:0 TX packets:553105 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:45294696 (43.1 Mb) TX bytes:161088571 (153.6 Mb) Interrupt:17 eth2:0Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:192.168.130.68 Mask:255.255.255.192 UP RUNNING NOARP MULTICAST MTU:1492 Metric:1 Interrupt:17 hsi0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:192.168.129.4 Mask:255.255.255.0 inet6 addr: fe80::200:ff:fe00:0/10 Scope:Link UP RUNNING NOARP MULTICAST MTU:8192 Metric:1 RX packets:2517010 errors:0 dropped:0 overruns:0 frame:0 TX packets:1719082 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:1009596522 (962.8 Mb) TX bytes:276571455 (263.7 Mb) Interrupt:11 hsi0:0Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:192.168.129.5 Mask:255.255.255.0 UP RUNNING NOARP MULTICAST MTU:8192 Metric:1 Interrupt:11 hsi1 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:192.168.130.2 Mask:255.255.255.192 inet6 addr: fe80::200:ff:fe00:0/10 Scope:Link UP RUNNING NOARP MULTICAST MTU:8192 Metric:1 RX packets:1660330 errors:0 dropped:0 overruns:0 frame:0 TX packets:2378314 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:211072990 (201.2 Mb) TX bytes:977121122 (931.8 Mb) Interrupt:14 hsi1:0Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:192.168.130.4 Mask:255.255.255.192 UP RUNNING NOARP MULTICAST MTU:8192 Metric:1 Interrupt:14 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Notice that I have one eth device and two hsi devices. These are all virtual; this router lives on two HiperSockets and one OSA segment. Also note the dummy addresses (XXXN:0): this is VRT in action; r1 contains the other side of the pair, but r2 is currently holding the virtual addresses. Here's the routing table... r2:~ # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 192.168.131.0 192.168.130.10 255.255.255.192 UG0 00 hsi1 192.168.131.64 192.168.130.10 255.255.255.192 UG0 00 hsi1 192.168.130.0 0.0.0.0 255.255.255.192 U 0 00 hsi1 192.168.130.64 0.0.0.0 255.255.255.192 U 0 00 eth2 192.168.129.0 0.0.0.0 255.255.255.0 U 0 00 hsi0 0.0.0.0 192.168.129.1 0.0.0.0 UG0 00 hsi0 Adam
Re: Lotus Notes on Linux
You'll have to wait for Lotus to be released for Linux/390. If this is something you want to do _now_, then you're out of luck. If you can wait, it sounds like something that would be fairly reasonable since most of what is going on is moving data around. Mark Post -Original Message- From: Steve Domarski [mailto:sdom;PROPAPPR.MARION.FL.US] Sent: Friday, November 08, 2002 11:18 AM To: [EMAIL PROTECTED] Subject: Lotus Notes on Linux We currently run Lotus Notes on AIX. We intend to up grade to the next release when it comes available for some desired feature which escapes me at the moment and is not part of this query anyway. We currently have a 60GB application which is comprised of Clerk of the Courts transactions from which our folks read through and adjust property records to reflect the new ownership and such changes. There about 600 data bases comprising from 500 to 2000 tiff images each. My question; Is this a likely candidate for a Linux Lotus Notes application. There are about 30 active users accessing images all day long. There is active loading and unloading of images into new data bases and old data bases being moved to CD-ROM. The Notes server is also handling e-mail for about 75 users. Are there any significant look and or feel differences and are the release levels current from platform to platform. Are there any significant cost differences. The hardware is not a problem. I'm running a 2066-001 so theirs plenty of power. Steve Domarski Property Appraisers Office Marion County Florida USA
Re: Questions about accessing DASD
On Fri, Nov 08, 2002 at 11:00:19AM -0500, [EMAIL PROTECTED] wrote: Also, the shark is being used to share dasd with open systems over fiber. Would it be possible to have the linux image connect (over FICON?) to access that same data? For example, to mount the same file-system an NT server is hitting? I'm sorry if my wording is all off and I am talking about jamming square blocks into round holes. There is a zfcp driver in the 2.4.19 kernel on developerworks. So, in theory this should be fine. I don't know how the data-sharing issues work, although I think you wouldn't risk filesystem corruption, only cache coherency problems, if you mounted, say, an NTFS volume read-only over FCP. Adam
Re: CPU Arch Security [was: Re: Probably the first published shell code]
On Thu, 2002-11-07 at 19:11, John Summerfield wrote: On IA32, if it's not in the code segment, you can't execute it. The code segment _can_ be ro, so presumably a return to arbitrary code can be prevented. I dont need to modify any of the code segment to exploit your machine. In fact several exploits work on the basis they overrun a stack section with a complete return sequence including variables to cause an execlp(/bin/sh, ...) to occur. No code changes needed
[ANNOUNCE] Systems/C, Systems/C++ and Systems/ASM for z/Linux
Just a quite note to announce the new versions of Systems/C, Systems/C++ and Systems/ASM. What makes this pertinent to this mailing list is the new 64-bit support, including z/Linux. All of the Dignus tools now run on z/Linux, as well as generating code for z/Linux. We have also delivered the first 64-bit complete C/C++ development environment for z/OS, as well as new utility programs, ANSI C99 features, etc... That seems about as long a message as I should allow, I'll just add that those who are interested should visit our web page for more information - http://www.dignus.com. - Thanks! - - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com
Re: CPU Arch Security [was: Re: Probably the first published shell code]
Linas Vepstas wrote: Sorry I used the word semaphore. Using pipes shmem is hard. Well, using them is easy, using them and creating something that's extenisble, maintainble, lacks race conditions and other bugs ... that's a lot harder. If it's so easy, why didn't ssh do it years ago? The hard stuff is to design your application so that it *can* be separated into multiple protection domains. The actual *implementation* of that separation via multiple processes is easy (trivial in comparison). Security is hard, and trying to implement some sort of framework that will allow even inexperienced programmers to magically only produce secure code strikes me as somewhat naive ;-) One main point why just function calls are so much easier to use than IPC is that you can pass pointers to complex data structures back and forth. If you really implement some sort of strict memory protection, that won't work any more. Huh? why not? Because those pointers will point to memory the callee is not allowed to access? To define a library interface, traditionally, one defines some functin prototypes, and then writes the code to make them do something. To pass data on a socket, you need to define the structure of the data passing through the socket. And you need to define at least two subroutines, one to pack the data into the pipe, one to pull it out. Hm? read () and write () should do just fine ... OK, so there are tools that can automate a lot of this, such as RPC's and stub generators and IDL's, or you can code in Java or scheme or C# or some language that provides native support for this (introspection, or ability to marshall/unmarshall itself). Or use .net so that you can be a stupid programmer creating incredibly complex systems. But these are all very complex mechanisms if your goal is merely to be a lowly library trying to prevent someone from meddling with your innards. You need all this only if the data you send over the pipe is supposed to be platform-independent. If you only communicate locally between two processes guaranteed to run on the same machine, just send the raw binary image of your data structures over the pipe and you're done. Bye, Ulrich -- Dr. Ulrich Weigand [EMAIL PROTECTED]
Re: More NSS Info
On Fri, 8 Nov 2002, David Boyes wrote: Much as I dislike Solaris, their diskless workstation filesystem layout is a pretty good model for this. We should use that as a model for ideas. They also demonstrated the first shared /usr implementation. They also do something I call folding (for lack of terminology) of /bin and /lib into /usr which works nicely for Linux (with care). There is a lot we can learn from Sun. But speaking of all this config and NSS and booting, I'm going to say it again: we need the STM trick in the kernel start. Sometime AFTER the stop at 0x01 STM 0,15,VMPARM then shortly later read from sacred 64-byte area VMPARM in the regular parm processing. (the VMPARM chunk is guaranteed to be EBCDIC, translate to ASCII, override that which the bootstrap loaded (that is, the parm *file*)) It is positively insane that we do not have this support already. Some examples: # adjust your DASD addresses from default hcp ipl linux dasd=400-40f # select a different root from the default hcp ipl linux root=/dev/dasdc1 # prep to load a DCSS maybe hcp def stor 512M ipl linux mem=256M While non-VM Linux cannot use this, it is no harm to have the support in there.
Re: More NSS Info
You mean set up a Linux NSS like we do a CMS NSS? When you IPL the CMS NSS it expects 190 to be the boot disk, 19E to be the CMS equivalent of /usr and 191 to contain the configuration files. When it comes up the first thing CMS does is to run the PROFILE EXEC on the 191 disk. The commands to access any other disks and load any needed extensions are in that file. You can place any CP or CMS commands you want to in the PROFILE EXEC and they will be run whenever CMS starts up in that virtual machine. Stephen Frazier Oklahoma Department of Corrections -Original Message- From: [EMAIL PROTECTED] [mailto:owner-linux-390;VM.MARIST.EDU]On Behalf Of Kris Van Hees Sent: Friday, November 08, 2002 10:00 AM To: Linux on 390 Port Subject: Re: More NSS Info Would it not be sufficient to create the NSS with just the boot disk and maybe swap configured in on the kernel parameter line, and then using something very early on in the boot process to add the other disks using /proc/dasd/devices? It might take some work to get the NSS and RO boot disk just right for this to work, but it would make it a lot more flexible. Kris On Fri, Nov 08, 2002 at 10:43:15AM -0500, Adam Thornton wrote: I don't have the faintest idea why IBM claims that you have to have an identical DASD layout on all machines that share an NSS. Admittedly cursory testing seems to show that your NSS will have whatever parameter line you burned into it, which does specify a range of devices. But not only can those devices change size (I tested this with an ext3 and a swap filesystem), if you boot without a listed device, the only problem you will have that I could find was that you may trip over it in /etc/fstab. But if you have a disk that's not in /etc/fstab, which you detach before IPL, you can re-link and then access that disk pefectly normally from Linux (using the console or hcp to perform the link). So it's looking to *me* like you should pick a lowest-common-denominator disk layout (for most of our guests, that'd be / on 150, swap on VDISK on 151, and /usr on 152), build the NSS with as small a storage size as you can (24M works for us) and then not worry about it. If anyone can tell me why I'm wrong, and that, although I have mounted differently-sized disks, I'm heading for fatal filesystem corruption just around the corner, I'd appreciate it. Adam -- Never underestimate a Mage with: - the Intelligence to cast Magic Missile, - the Constitution to survive the first hit, and - the Dexterity to run fast enough to avoid being hit a second time.
Re: More NSS Info
If you use the cmsfs stuff, that information can all be on the 191 disk and read by the startup scripts. What about a CMSFS that can do directories and specials (device files) akin to the UMSDOS hack?
Re: More NSS Info
On Fri, 8 Nov 2002, Kris Van Hees wrote: Despite what Sun Microsystems did with linking /usr/bin and /usr/sbin into the root filesystem as /bin and /sbin, a more sensible setup is still to have the core utilities that are required to boot a system (and to do basic maintenance) as part of the actual root partition. Yes and no. I mean, you are most certainly correct that we need these core utilities in the root. But I suggest that we have them placed under their /usr paths where /usr will get overmounted later. I've done this for years and never had problems from Linux with it. I've banged my head against that stupidity in Solaris more than once when a disk that held /usr happened to die. What a shame. I can see how frustrating that would be! Still, the scheme itself is good. It's just the implementation that fell apart. In the case you mention having something more than an empty directory at /usr in the root should make your problem go away.
Re: Virtual network topology questions...
This has gone completely off track, and in no way resembles or answers my original questions. We're running zVM 4.2, not 4.2. We're on a 9672, not a z-series, we have a single OSA interface, shared with a zOS image, and no option for adding hardware interfaces, and we don't have any money budgeted for the trial, not even the $500 for the true trial from SuSE. Answers that involve any of the things we don't have don't help. Sorry to be blunt, but I was really looking for which way I should be going, within the walls I have around me. The answers have been fairly much the same as Put out your resume, and find a job at a company with a different system... Robert P. Nixinternet: [EMAIL PROTECTED] Mayo Clinic phone: 507-284-0844 200 1st St. SW page: 507-255-3450 Rochester, MN 55905 In theory, theory and practice are the same, but in practice, theory and practice are different. -Original Message- From: Adam Thornton [SMTP:[EMAIL PROTECTED]] Sent: Friday, November 08, 2002 11:38 AM To: [EMAIL PROTECTED] Subject: Re: Virtual network topology questions... On Fri, Nov 08, 2002 at 10:57:41AM -0500, Dave Myers wrote: So according to the statements below...I CAN use SUSE SLES7 to play the guest lan game, using QDIO instead of virtual hipersockets? Am I correct in this assumption? Any testimony from someone who has setup guest lans with SUSE SLES7? Tia Dave Myers Yeah, as long as you're running one of the more recent patches that fixes virtual qeth support, it works fine. On a virtual LAN, the only difference is whether you specify it as type QDIO or leave it unset (in the VM LAN definition statment). Then if it's a qdio LAN, you define your virtual NIC to the guest as TYPE QDIO (which really means OSA, since both HiperSockets and OSA are QDIO devices). Virtual OSAs support broadcast (under z/VM 4.3). HiperSockets don't. That's pretty much the difference between them. They use the same driver, but OSA is aliased to interface ethX and HiperSockets to hsiX. Here's something from an SLES-based guest... r2:~ # ifconfig eth2 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:192.168.130.67 Mask:255.255.255.192 inet6 addr: fe80::200:ff:fe00:0/10 Scope:Link UP RUNNING NOARP MULTICAST MTU:1492 Metric:1 RX packets:473155 errors:0 dropped:0 overruns:0 frame:0 TX packets:553105 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:45294696 (43.1 Mb) TX bytes:161088571 (153.6 Mb) Interrupt:17 eth2:0Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:192.168.130.68 Mask:255.255.255.192 UP RUNNING NOARP MULTICAST MTU:1492 Metric:1 Interrupt:17 hsi0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:192.168.129.4 Mask:255.255.255.0 inet6 addr: fe80::200:ff:fe00:0/10 Scope:Link UP RUNNING NOARP MULTICAST MTU:8192 Metric:1 RX packets:2517010 errors:0 dropped:0 overruns:0 frame:0 TX packets:1719082 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:1009596522 (962.8 Mb) TX bytes:276571455 (263.7 Mb) Interrupt:11 hsi0:0Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:192.168.129.5 Mask:255.255.255.0 UP RUNNING NOARP MULTICAST MTU:8192 Metric:1 Interrupt:11 hsi1 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:192.168.130.2 Mask:255.255.255.192 inet6 addr: fe80::200:ff:fe00:0/10 Scope:Link UP RUNNING NOARP MULTICAST MTU:8192 Metric:1 RX packets:1660330 errors:0 dropped:0 overruns:0 frame:0 TX packets:2378314 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:211072990 (201.2 Mb) TX bytes:977121122 (931.8 Mb) Interrupt:14 hsi1:0Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:192.168.130.4 Mask:255.255.255.192 UP RUNNING NOARP MULTICAST MTU:8192 Metric:1 Interrupt:14 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Notice that I have one eth device and two hsi devices. These are all virtual; this router lives on two HiperSockets and one OSA segment. Also note the dummy addresses (XXXN:0): this is VRT in action; r1 contains the other side of the pair, but r2 is currently holding the virtual addresses. Here's the
Re: More NSS Info
On Fri, Nov 08, 2002 at 10:58:30AM -0600, Rick Troth wrote: If you use the cmsfs stuff, that information can all be on the 191 disk and read by the startup scripts. What about a CMSFS that can do directories and specials (device files) akin to the UMSDOS hack? If you create a CMS file called PROGRA~1 DIR I'll have to murder you. Just so you know. Other than that, sure, sounds like a plan--I assume you mean that you use some filesystem convention like a file which always has some particular name, which contains a CMS filename to Unix directory mapping? Adam
Re: Virtual network topology questions...
In a message dated 11/8/2002 10:14:42 AM Mountain Standard Time, [EMAIL PROTECTED] writes: The answers have been fairly much the same as Put out your resume, and find a job at a company with a different system... h...then you either haven't been reading them carefully...or you don't understand the technology concepts yet?? these answers seem very helpful for your situation Dave
Re: More NSS Info
On Fri, Nov 08, 2002 at 01:15:01PM -0500, Adam Thornton wrote: On Fri, Nov 08, 2002 at 10:58:30AM -0600, Rick Troth wrote: If you use the cmsfs stuff, that information can all be on the 191 disk and read by the startup scripts. What about a CMSFS that can do directories and specials (device files) akin to the UMSDOS hack? If you create a CMS file called PROGRA~1 DIR I'll have to murder you. Just so you know. Other than that, sure, sounds like a plan--I assume you mean that you use some filesystem convention like a file which always has some particular name, which contains a CMS filename to Unix directory mapping? Perhaps (though it might be more work) use the same naming convention as is used to encode long filenames on the ISO9660 filesystem, just to stick to a well known and accepted convention? I would *love* to see a CMSFS that can support things like device files so we can finally put /dev somewhere other than the root filesystem, so / can truly be made RO. I worked on that using initrd, but cmsfs would be so much nicer (as long as it is efficient). Then again, if devfs keeps going the way it is, the need for a writable /dev may finally disappear! I do fear though that it won't go all the way :( Kris
Re: More NSS Info
David Boyes writes: You would need at least one non-root/swap address mounted as /config or something for storing the configuration of what goes where, and you'd have to move at least a few of the utilities (eg mount, ifconfig, etc) from /usr to /sbin (generating statically linked versions) and include /sbin in the root filesystem. The basevol+guestvol environment I describe in the ...zSeries...Large Scale Linux Deployment redbook (SG246824) (I really ought to bind that phrase to a single keystroke :-) lets you have a readonly root filesystem which is linked to (readonly) and booted by any number of clones. The boot process then mounts a (potentially very) small guest-specific readwrite volume (whatever disk is at devno 777) and binds all the necessary writable directories into the filesystem. Other parts of the redbook then describe how you can then bootstrap yourself to get other information (via a PROP guest and then via LDAP). We can do better than Sun since we have shared disks in known, manageable namespaces at boot time and since we have Al Viro's namespace support in Linux for bind mounts (again, described in the redbook for those unfamiliar with the concept). [Next is updates-in-place with CLONE_NEWNS and pivot_root() and/or immediate kernel-to-kernel reboots when kexec() is stable...] I'll set up the NSS stuff on my own VM system and get it to work nicely with basevol+guestvol (which I've just got working properly with SuSE SLES7; the original redbook environment having some dependencies on the RedHat boot scripts). --Malcolm -- Malcolm Beattie [EMAIL PROTECTED] Linux Technical Consultant IBM EMEA Enterprise Server Group... ...from home, speaking only for myself
Re: Virtual network topology questions...
Robert, About the only thing you can't get out of this thread is broadcast support on your Guest LAN. Everything else should be available to you as you sit now with z/VM 4.2 and a 9672. No new hardware, etc. Further, there is another option from SuSE. For free, they will send you CDs with their GA code on them. You just don't get any support during the trial. That meets your $0 budget constraints as well, if you want to go that route. But, even if you don't, you should be able to succeed in implementing a Guest LAN. Mark Post -Original Message- From: Nix, Robert P. [mailto:Nix.Robert;mayo.edu] Sent: Friday, November 08, 2002 12:09 PM To: [EMAIL PROTECTED] Subject: Re: Virtual network topology questions... This has gone completely off track, and in no way resembles or answers my original questions. We're running zVM 4.2, not 4.2. We're on a 9672, not a z-series, we have a single OSA interface, shared with a zOS image, and no option for adding hardware interfaces, and we don't have any money budgeted for the trial, not even the $500 for the true trial from SuSE. Answers that involve any of the things we don't have don't help. Sorry to be blunt, but I was really looking for which way I should be going, within the walls I have around me. The answers have been fairly much the same as Put out your resume, and find a job at a company with a different system... Robert P. Nixinternet: [EMAIL PROTECTED] Mayo Clinic phone: 507-284-0844 200 1st St. SW page: 507-255-3450 Rochester, MN 55905 In theory, theory and practice are the same, but in practice, theory and practice are different. -Original Message- From: Adam Thornton [SMTP:[EMAIL PROTECTED]] Sent: Friday, November 08, 2002 11:38 AM To: [EMAIL PROTECTED] Subject: Re: Virtual network topology questions... On Fri, Nov 08, 2002 at 10:57:41AM -0500, Dave Myers wrote: So according to the statements below...I CAN use SUSE SLES7 to play the guest lan game, using QDIO instead of virtual hipersockets? Am I correct in this assumption? Any testimony from someone who has setup guest lans with SUSE SLES7? Tia Dave Myers Yeah, as long as you're running one of the more recent patches that fixes virtual qeth support, it works fine. On a virtual LAN, the only difference is whether you specify it as type QDIO or leave it unset (in the VM LAN definition statment). Then if it's a qdio LAN, you define your virtual NIC to the guest as TYPE QDIO (which really means OSA, since both HiperSockets and OSA are QDIO devices). Virtual OSAs support broadcast (under z/VM 4.3). HiperSockets don't. That's pretty much the difference between them. They use the same driver, but OSA is aliased to interface ethX and HiperSockets to hsiX. Here's something from an SLES-based guest... r2:~ # ifconfig eth2 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:192.168.130.67 Mask:255.255.255.192 inet6 addr: fe80::200:ff:fe00:0/10 Scope:Link UP RUNNING NOARP MULTICAST MTU:1492 Metric:1 RX packets:473155 errors:0 dropped:0 overruns:0 frame:0 TX packets:553105 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:45294696 (43.1 Mb) TX bytes:161088571 (153.6 Mb) Interrupt:17 eth2:0Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:192.168.130.68 Mask:255.255.255.192 UP RUNNING NOARP MULTICAST MTU:1492 Metric:1 Interrupt:17 hsi0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:192.168.129.4 Mask:255.255.255.0 inet6 addr: fe80::200:ff:fe00:0/10 Scope:Link UP RUNNING NOARP MULTICAST MTU:8192 Metric:1 RX packets:2517010 errors:0 dropped:0 overruns:0 frame:0 TX packets:1719082 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:1009596522 (962.8 Mb) TX bytes:276571455 (263.7 Mb) Interrupt:11 hsi0:0Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:192.168.129.5 Mask:255.255.255.0 UP RUNNING NOARP MULTICAST MTU:8192 Metric:1 Interrupt:11 hsi1 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:192.168.130.2 Mask:255.255.255.192 inet6 addr: fe80::200:ff:fe00:0/10 Scope:Link UP RUNNING NOARP MULTICAST MTU:8192 Metric:1 RX packets:1660330 errors:0 dropped:0 overruns:0 frame:0 TX packets:2378314 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:211072990 (201.2 Mb) TX bytes:977121122 (931.8 Mb) Interrupt:14 hsi1:0Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:192.168.130.4 Mask:255.255.255.192 UP RUNNING NOARP MULTICAST MTU:8192
Kernel Compilation Options
I was compiling a 2.4.19 kernel this week, and I was presented with some options for Journalling Flash File System and Journalling Flash File System2 support. Being curious, I selected to have them built as modules. Once the kernel was compiled and IPLed, I was getting unresolved symbol errors for the two modules. It turns out the symbols were related to Memory Technology Device (MTD) support. There is no way to select for MTD support, since that's not something that can be installed on a mainframe (I imagine). So, given that a pre-requisite for the JFFS/JFFS2 code is not available, should they be selectable options on a Linux/390 kernel configuration? I would think not, but I wanted to make sure I was understanding this correctly. Is this something that should be fixed, or not? Mark Post
Re: Virtual network topology questions...
In a message dated 11/8/2002 10:37:37 AM Mountain Standard Time, [EMAIL PROTECTED] writes: Further, there is another option from SuSE. For free, they will send you CDs with their GA code on them. You just don't get any support during the trial. There is? I thought sles7 was all i can get for free? What's this option. Dave
Re: Virtual network topology questions...
This has gone completely off track, and in no way resembles or answers my original questions. Huh? We're running zVM 4.2, not 4.2. OK, you have guest LAN support, just no broadcast support. We're on a 9672, not a z-series, Guest LANs work fine on 9672s. we have a single OSA interface, shared with a zOS image, and no option for adding hardware interfaces, You don't need to add interfaces. and we don't have any money budgeted for the trial, not even the $500 for the true trial from SuSE. Considering that there are other fixes you need to make the rest of your trial viable, then you are unlikely to be able to succeed with your goals if you can't get even the limited support. What part of that is non helpful? Sorry to be blunt, but I was really looking for which way I should be going, within the walls I have around me. The answers have been fairly much the same as Put out your resume, and find a job at a company with a different system... Please look at the responses again. The responses you got are that you are making this unnecessarily difficult for youself when you have other alternatives that are vastly simpler than the one you are using. The support issue is one you're going to have to solve if you want to use any of the commercial products you mentioned in earlier postings; most simply don't work correctly without patches. Sorry if it's not what you wanted to hear, but that's the way it is.
Re: Virtual network topology questions...
http://www.marist.edu/htbin/wlvtype?LINUX-VM.23045 http://www.marist.edu/htbin/wlvtype?LINUX-VM.24840 http://www.marist.edu/htbin/wlvtype?LINUX-VM.25835 Mark Post -Original Message- From: Dave Myers [mailto:dave.myers;twcable.com] Sent: Friday, November 08, 2002 12:47 PM To: [EMAIL PROTECTED] Subject: Re: Virtual network topology questions... In a message dated 11/8/2002 10:37:37 AM Mountain Standard Time, [EMAIL PROTECTED] writes: Further, there is another option from SuSE. For free, they will send you CDs with their GA code on them. You just don't get any support during the trial. There is? I thought sles7 was all i can get for free? What's this option. Dave
root filesystem on RAID0
I've been trying to setup the ability to run the root filesystem on a RAID0 array. I've been using the Software-RAID HOWTO as a guide. I've had no luck at all. Before I spend anymore time on this project does anyone know if this is really possible with s390? I don't mind working on it and figuring it our if it will work. But if there is some fundamental reason why it won't work I would like to know that now so I won't keep banging my head into the wall. Thanks very much for insights. Mark D Pace Senior Systems Engineer Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317 [EMAIL PROTECTED] Office: 850.219.5184 Fax: 850.219.5050 http://www.mainline.com
Re: Lotus Notes on Linux
Steve, You may not have to wait that long. Look at Jim Elliott's post, on this db, from Wed, 21 Aug 2002 14:58:35. Regards, Paul = From: Post, Mark K [EMAIL PROTECTED] mailto:mark.post;eds.com Subject: Re: Lotus Notes on Linux You'll have to wait for Lotus to be released for Linux/390. If this is something you want to do _now_, then you're out of luck. If you can wait, it sounds like something that would be fairly reasonable since most of what is going on is moving data around. Mark Post -Original Message- From: Steve Domarski [mailto:sdom;PROPAPPR.MARION.FL.US] mailto:Steve%20Domarski%20%5Bmailto:sdom;PROPAPPR.MARION.FL.US%5D Sent: Friday, November 08, 2002 11:18 AM To: [EMAIL PROTECTED] Subject: Lotus Notes on Linux We currently run Lotus Notes on AIX. We intend to up grade to the next release when it comes available for some desired feature which escapes me at the moment and is not part of this query anyway. We currently have a 60GB application which is comprised of Clerk of the Courts transactions from which our folks read through and adjust property records to reflect the new ownership and such changes. There about 600 data bases comprising from 500 to 2000 tiff images each. My question; Is this a likely candidate for a Linux Lotus Notes application. There are about 30 active users accessing images all day long. There is active loading and unloading of images into new data bases and old data bases being moved to CD-ROM. The Notes server is also handling e-mail for about 75 users. Are there any significant look and or feel differences and are the release levels current from platform to platform. Are there any significant cost differences. The hardware is not a problem. I'm running a 2066-001 so theirs plenty of power. Steve Domarski Property Appraisers Office Marion County Florida USA
Re: More NSS Info
On Fri, Nov 08, 2002 at 11:23:25AM -0500, David Boyes wrote: You would need at least one non-root/swap address mounted as /config or something for storing the configuration of what goes where, and you'd have to move at least a few of the utilities (eg mount, ifconfig, etc) from /usr to /sbin (generating statically linked versions) and include /sbin in the root filesystem. What distribution are you using which places these utilities in /usr? Those utilities are (or may be) required in order to mount /usr. Also, they should not need to be statically linked, as they should only be linked with libraries in /lib. -- - mdz
Re: More NSS Info
On Fri, Nov 08, 2002 at 10:52:52AM -0600, Rick Troth wrote: On Fri, 8 Nov 2002, David Boyes wrote: Much as I dislike Solaris, their diskless workstation filesystem layout is a pretty good model for this. We should use that as a model for ideas. They also demonstrated the first shared /usr implementation. They also do something I call folding (for lack of terminology) of /bin and /lib into /usr which works nicely for Linux (with care). There is a lot we can learn from Sun. This folding, as far as I know, is just a couple of symlinks, from /bin to /usr/bin and from /lib to /usr/lib. Doing the same thing on a typical Linux system would be problematic, since generally /bin and /lib are expected to be present on the root filesystem (mount, for example, is typically in /bin). -- - mdz
Re: More NSS Info
On Fri, Nov 08, 2002 at 12:24:13PM -0500, Kris Van Hees wrote: I would *love* to see a CMSFS that can support things like device files so we can finally put /dev somewhere other than the root filesystem, so / can truly be made RO. I worked on that using initrd, but cmsfs would be so much nicer (as long as it is efficient). Then again, if devfs keeps going the way it is, the need for a writable /dev may finally disappear! I do fear though that it won't go all the way :( /dev doesn't prevent / from being read-only. devfs sidesteps this problem entirely, and with a normal /dev, device nodes are generally static. If you consider it to be useful, it is not too complex to run Linux with a read-only root filesystem. -- - mdz
Re: Kernel Compilation Options
On Fri, Nov 08, 2002 at 12:35:55PM -0500, Post, Mark K wrote: So, given that a pre-requisite for the JFFS/JFFS2 code is not available, should they be selectable options on a Linux/390 kernel configuration? I would think not, but I wanted to make sure I was understanding this correctly. Is this something that should be fixed, or not? I would say that perhaps MTD should be enabled instead, because there are MTD drivers such as blkmtd and mtdram, which can be used without any physical flash memory devices. -- - mdz
Re: More NSS Info
You would need at least one non-root/swap address mounted as /config or something for storing the configuration of what goes where, and you'd have to move at least a few of the utilities (eg mount, ifconfig, etc) from /usr to /sbin (generating statically linked versions) and include /sbin in the root filesystem. What distribution are you using which places these utilities in /usr? Sorry, finger check. I date back far enough that everything was in or near /usr... thanks. Meant to say from their default location. Also, they should not need to be statically linked, as they should only be linked with libraries in /lib. This I would argue about. Why should I need /lib and dynamic library support at a point where the system is still initializing? What if I want to mount /lib from another disk? If I have the absolutely critical utilities available in a statically linked version, I need only a root file system containing the critical static binaries and a kernel and minimal configuration info. -- - mdz
Re: Virtual network topology questions...
On Fri, Nov 08, 2002 at 11:09:02AM -0600, Nix, Robert P. wrote: This has gone completely off track, and in no way resembles or answers my original questions. We're running zVM 4.2, not 4.2. We're on a 9672, not a z-series, we have a single OSA interface, shared with a zOS image, and no option for adding hardware interfaces, and we don't have any money budgeted for the trial, not even the $500 for the true trial from SuSE. Answers that involve any of the things we don't have don't help. Then I would suggest you haven't been reading very carefully. Point the First: You do not need any additional hardware or a newer release of VM. You can do guest LANs just fine. Point the Second: If you cannot get anything newer from SuSE, then you will have to build your own kernel. SuSE will not support this kernel, but since SuSE isn't supporting you *anyway*, it doesn't matter. When you get a support contract, then you can get a SuSE-supported kernel that will support HiperSockets. *VIRTUAL* HiperSockets. For which you *DO NOT NEED ANY MORE PHYSICAL HARDWARE THAN WHAT YOU ALREADY HAVE*. Here's how: go get the virgin 2.4.19 kernel sources from kernel.org. Go get the s390-may2002, s390-1-may2002, and timer-1-may2002 patches from IBM Developerworks, and apply them in that order. Also get the qeth driver from there. Build a kernel. Build your modules. Copy the qeth driver somewhere under your modules directory. Run depmod -a. Edit zipl.conf to boot from your new kernel, and run zipl. ReIPL your Linux image--into CMS, if you can. Add a guest LAN to VM. Add a VIRTUAL HiperSocket NIC to your Linux image. Couple B to A. IPL Linux on your guest. Screw around with /etc/chandev.conf until your new virtual OSA works. Clone this image. Change IP address and hostname for each clone. Couple it to the same LAN. You're all done. It didn't cost you a penny. You don't need to fool with a point-to-point routing structure. Adam
Re: Kernel Compilation Options
Matt, I had considered that also, but wasn't sure about the availability of such things as blkmtd and mtdram. I'm not at all familiar with that area. But, either way is fine with me, I guess. I just think you shouldn't be able to select things that you can't get to work. Mark Post -Original Message- From: Matt Zimmerman [mailto:mdz;debian.org] Sent: Friday, November 08, 2002 2:23 PM To: [EMAIL PROTECTED] Subject: Re: Kernel Compilation Options On Fri, Nov 08, 2002 at 12:35:55PM -0500, Post, Mark K wrote: So, given that a pre-requisite for the JFFS/JFFS2 code is not available, should they be selectable options on a Linux/390 kernel configuration? I would think not, but I wanted to make sure I was understanding this correctly. Is this something that should be fixed, or not? I would say that perhaps MTD should be enabled instead, because there are MTD drivers such as blkmtd and mtdram, which can be used without any physical flash memory devices. -- - mdz
Re: Kernel Compilation Optionsy
On Fri, 8 Nov 2002, Post, Mark K wrote: I was compiling a 2.4.19 kernel this week, and I was presented with some options for Journalling Flash File System and Journalling Flash File System2 support. Being curious, I selected to have them built as modules. Once the kernel was compiled and IPLed, I was getting unresolved symbol errors for the two modules. It turns out the symbols were related to Memory Technology Device (MTD) support. There is no way to select for MTD support, since that's not something that can be installed on a mainframe (I imagine). So, given that a pre-requisite for the JFFS/JFFS2 code is not available, should they be selectable options on a Linux/390 kernel configuration? I would think not, but I wanted to make sure I was understanding this correctly. Is this something that should be fixed, or not? It sounds to me the sort of thing that should be fixed; it ought not be possible to create a misconfigured kernel as you have done. If this is a vendor kernel, report the matter to your vendor. If not, check the MAINTAINERS file and report it to the maintainer, and to lkml. If you have the time, check it with the latest 2.5 kernel too. The will want you .config, but would probably prefer not tho have the comments. They can be stripped with a little creative grepping. -- Cheers John. Please, no off-list mail. You will fall foul of my spam treatment. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: More NSS Info
On Fri, Nov 08, 2002 at 02:16:47PM -0500, Matt Zimmerman wrote: On Fri, Nov 08, 2002 at 12:24:13PM -0500, Kris Van Hees wrote: I would *love* to see a CMSFS that can support things like device files so we can finally put /dev somewhere other than the root filesystem, so / can truly be made RO. I worked on that using initrd, but cmsfs would be so much nicer (as long as it is efficient). Then again, if devfs keeps going the way it is, the need for a writable /dev may finally disappear! I do fear though that it won't go all the way :( /dev doesn't prevent / from being read-only. devfs sidesteps this problem entirely, and with a normal /dev, device nodes are generally static. If you consider it to be useful, it is not too complex to run Linux with a read-only root filesystem. I worked on a RO / before (presented briefly at SHARE in TN), and unfortunately Linux has (or had - they may have fixed it) a C library that usesthe Unix domain socket /dev/log for syslog handling, and that one is created dynamically at each boot. The introduction of devfs and possible changes to glibc may have removed that limitation (which would be a GOOD thing). Kris
mono RPMs
For those who'd like to play with the C# open-source package mono, the necessary RPMs can be downloaded from http://go-mono.com/download;. I don't think you need the -devel RPMs if you just want to play. You will need to do the following as root: ln -s /usr/bin/mint /usr/bin/mono. Neale
Re: More NSS Info
On Fri, Nov 08, 2002 at 03:09:54PM -0500, Kris Van Hees wrote: I worked on a RO / before (presented briefly at SHARE in TN), and unfortunately Linux has (or had - they may have fixed it) a C library that usesthe Unix domain socket /dev/log for syslog handling, and that one is created dynamically at each boot. The introduction of devfs and possible changes to glibc may have removed that limitation (which would be a GOOD thing). devfs solves this of course, but even without it, there are other ways to approach the problem. For example, using a ramdisk or other storage for the full /dev, keeping only a minimal, static /dev on the real root filesystem. devfs seems to work fine on s390, though, so that seems like the most straightforward solution. -- - mdz
Re: More NSS Info
If you create a CMS file called PROGRA~1 DIR I'll have to murder you. ;-) Just so you know. Other than that, sure, sounds like a plan--I assume you mean that you use some filesystem convention like a file which always has some particular name, which contains a CMS filename to Unix directory mapping? Yep.
Re: More NSS Info
On Fri, Nov 08, 2002 at 02:44:19PM -0500, David Boyes wrote: What distribution are you using which places these utilities in /usr? Sorry, finger check. I date back far enough that everything was in or near /usr... thanks. Meant to say from their default location. I do not date back very far in UN*X years, so I do not speak from first-hand experience, but I have the distinct impression that /bin predates /usr/bin. SunOS/Solaris, though, has lacked a separate /bin for a long time, but I believe even it originally had one. Also, they should not need to be statically linked, as they should only be linked with libraries in /lib. This I would argue about. Why should I need /lib and dynamic library support at a point where the system is still initializing? What if I want to mount /lib from another disk? If I have the absolutely critical utilities available in a statically linked version, I need only a root file system containing the critical static binaries and a kernel and minimal configuration info. You don't need shared libraries to run your system at all. However, they are beneficial for many reasons, and most of those reasons hold for things which live on the root filesystem. If you want to mount /lib from another disk, you must (at least) be sure that you don't require _any_ loadable kernel modules to get to that point, and that every executable along the way is statically linked. If you are willing to pay the price in maintainability, it is of course possible. If you have the absolutely critical utilities available in a dynamically linked version, you need only a root filesystem containing the critical static binaries and a kernel and minimal configuration info and the shared libraries (usually only libc). Personally, my preference is to run with dynamically linked executables, and to use a statically linked copy of busybox or sash for recovery purposes. One can boot such a system using only the kernel and a single user executable if necessary. -- - mdz
Re: More NSS Info
This folding, as far as I know, is just a couple of symlinks, from /bin to /usr/bin and from /lib to /usr/lib. Doing the same thing on a typical Linux Specifically, running 'ls -l' in root, you see bin - usr/bin lib - usr/lib If memory serves, you do NOT usually see sbin - usr/sbin. system would be problematic, since generally /bin and /lib are expected to be present on the root filesystem (mount, for example, is typically in /bin). No. Not a problem. It DOES work. I've done it. What you do is have /usr populated with bin and lib and minimal contents. Those are available at boot time. Later, when /usr is mounted over this non-empty directory, life continues without catastrophe and the new files are used when next invoked. (The old copies are hidden and can no longer be referenced. But no one misses them!) It works.
Re: Yet More NSS Info
Rick Troth [EMAIL PROTECTED] wrote: If you create a CMS file called PROGRA~1 DIR I'll have to murder you. ;-) Just so you know. Other than that, sure, sounds like a plan--I assume you mean that you use some filesystem convention like a file which always has some particular name, which contains a CMS filename to Unix directory mapping? Yep. Well it's called TRANS.TBL on an ISO-9660 CD, so, perhaps there's something to be gained by grabbing the parser for iso9660's VFS and, handling the EBCDIC--ASCII translation (and back again) this could get interesting. Of course extending this so that it could fake multi-level directories in a CMS disk wouldn't hurt either. -- John R. Campbell Speaker to Machines [EMAIL PROTECTED] - As a SysAdmin, yes, I CAN read your e-mail, but I DON'T get that bored! It is impossible for ANY man to learn about impotence the hard way. - me ZIF is not a desirable trait when selecting a spouse. - me
Googlism.com
Googlism is the best search engine ever. Some of our luminaries There's the predictable, if kind of boring: neale ferguson is a longtime ibm s/390 system administrator with over nineteen years of experience with vm/esa There's the random: rick troth is a part of the science department There's the surreal: harry williams is reliable harry williams is preaching harry williams is thrown harry williams is 507 harry williams is alleged to have said that the song was never intended to be about tipperary at all There's the kind-of-alarming: phil payne is clearly a god phil payne is another good wrestler who the new expects good things from phil payne is a guy who will be world champ And then there's the frankly frightening: ross patterson is extremly hot you should put the picture of him in the movie at the very very end with his tongue outlol Adam
One more Googlism:
And then there's the just-plain-odd: mark post is a senior infrastructure specialist in eds' mainframe platforms operating systems repository support group mark post is mentioned in the mark post is 40p away on 318 mark post is the director of the car mark post is recovering from a bad case of the flu mark post is running down the hallway trying to catch up with omega mark post is back there trying to find uzu or tanaka mark post is not clg's official policy
Re: One more Googlism:
And then again: adam thornton is awarded a #1 textfire investigator badge adam thornton is awarded a #1 textfire investigator badge adam thornton is awarded a #1 textfire investigator badge; april 22 adam thornton is a funny guy adam thornton is a member of the 14th public affairs detachment adam thornton is really worth visiting adam thornton is still slowed by a pre adam thornton is providing the technical expertise adam thornton is sincere in his denials adam thornton is running well adam thornton is awarded a #1 textfire investigator badge -Original Message- From: Adam Thornton [SMTP:[EMAIL PROTECTED]] Sent: Friday, November 08, 2002 6:37 PM To: [EMAIL PROTECTED] Subject: One more Googlism: And then there's the just-plain-odd: mark post is a senior infrastructure specialist in eds' mainframe platforms operating systems repository support group mark post is mentioned in the mark post is 40p away on 318 mark post is the director of the car mark post is recovering from a bad case of the flu mark post is running down the hallway trying to catch up with omega mark post is back there trying to find uzu or tanaka mark post is not clg's official policy
Re: One more Googlism:
I don't know which is odder. The things you're finding, or that you're looking for them in the first place! Just out of curiosity, what was the link for that first one (since that really is me)? Mark Post -Original Message- From: Adam Thornton [mailto:athornton;sinenomine.net] Sent: Friday, November 08, 2002 6:37 PM To: [EMAIL PROTECTED] Subject: One more Googlism: And then there's the just-plain-odd: mark post is a senior infrastructure specialist in eds' mainframe platforms operating systems repository support group mark post is mentioned in the mark post is 40p away on 318 mark post is the director of the car mark post is recovering from a bad case of the flu mark post is running down the hallway trying to catch up with omega mark post is back there trying to find uzu or tanaka mark post is not clg's official policy
Re: One more Googlism:
On Fri, Nov 08, 2002 at 05:49:02PM -0500, Post, Mark K wrote: I don't know which is odder. The things you're finding, or that you're looking for them in the first place! Just out of curiosity, what was the link for that first one (since that really is me)? No idea--Googlism just spits out a bunch of text of the for X is... -- [EMAIL PROTECTED] My eyes say their prayers to her / Sailors ring her bell / Like a moth mistakes a light bulb / For the moon and goes to hell. -- Tom Waits
Re: One more Googlism:
It actually would appear to spit out information that it finds based on web searches - try it for someone you know who doesn't have a web site or postings and it reports that it doesn't know you 'yet'. Lionel B. Dyck, Systems Software Lead Kaiser Permanente Information Technology 25 N. Via Monte Ave Walnut Creek, Ca 94598 Phone: (925) 926-5332 (tie line 8/473-5332) E-Mail:[EMAIL PROTECTED] Sametime: (use Lotus Notes address) AIM:lbdyck Linux on 390 Port [EMAIL PROTECTED] wrote on 11/08/2002 02:52:07 PM: On Fri, Nov 08, 2002 at 05:49:02PM -0500, Post, Mark K wrote: I don't know which is odder. The things you're finding, or that you're looking for them in the first place! Just out of curiosity, what was the link for that first one (since that really is me)? No idea--Googlism just spits out a bunch of text of the for X is... -- [EMAIL PROTECTED] My eyes say their prayers to her / Sailors ring her bell / Like a moth mistakes a light bulb / For the moon and goes to hell. -- Tom Waits
Re: CPU Arch Security [was: Re: Probably the first published shell code]
At 17:09 11/08/2002 +, Alan Cox wrote: In fact several exploits work on the basis they overrun a stack section with a complete return sequence including variables to cause an execlp(/bin/sh, ...) to occur. Yup, that was exactly the case in the Phrack article that started this whole topic. It's actually the most common of the buffer overrun exploitation techniques. Ross strpcy() considered harmful Patterson
Re: Googlism.com
At 18:35 11/08/2002 -0500, Adam Thornton wrote: And then there's the frankly frightening: Watch it, cough-syrup boy! ross patterson is extremly hot you should put the picture of him in the movie at the very very end with his tongue outlol Yup, I am SO hot! Vote for me: http://www.hotornot.com/r/?eid=KEALE8Skey=TQC :-) Ross
Re: More NSS Info
Hello from Gregg C Levine And if you murder him, I'll be forced to use my Jedi Knight functions to send you to Kessel. Just going along with it, Rick. --- Gregg C Levine [EMAIL PROTECTED] The Force will be with you...Always. Obi-Wan Kenobi Use the Force, Luke. Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) -Original Message- From: Linux on 390 Port [mailto:LINUX-390;VM.MARIST.EDU] On Behalf Of Rick Troth Sent: Friday, November 08, 2002 4:42 PM To: [EMAIL PROTECTED] Subject: Re: [LINUX-390] More NSS Info If you create a CMS file called PROGRA~1 DIR I'll have to murder you. ;-) Just so you know. Other than that, sure, sounds like a plan--I assume you mean that you use some filesystem convention like a file which always has some particular name, which contains a CMS filename to Unix directory mapping? Yep.
Re: One more Googlism:
On Friday 08 November 2002 15:52, Adam Thornton wrote: On Fri, Nov 08, 2002 at 05:49:02PM -0500, Post, Mark K wrote: I don't know which is odder. The things you're finding, or that you're looking for them in the first place! Just out of curiosity, what was the link for that first one (since that really is me)? No idea--Googlism just spits out a bunch of text of the for X is... delurk However, since it's based on what's findable in Google, take the phrase X is ... and pop it into Google. :) /delurk Chris Craft (Who has interesting googlisms of his own.)
Re: CPU Arch Security [was: Re: Probably the first published shell code]
On Fri, Nov 08, 2002 at 05:50:56PM +0100, Ulrich Weigand was heard to remark: Linas Vepstas wrote: Sorry I used the word semaphore. Using pipes shmem is hard. Well, using them is easy, using them and creating something that's extenisble, maintainble, lacks race conditions and other bugs ... that's a lot harder. If it's so easy, why didn't ssh do it years ago? The hard stuff is to design your application so that it *can* be separated into multiple protection domains. The actual *implementation* of that separation via multiple processes is easy (trivial in comparison). Sorta. It depends. One should also distinguish between app developers and library developers. For example, and maybe this is a bad example, but we had a library developer who wanted to create the ultimate dBaseIII/foxbase comaptbile database library. The traditional problem with dbase is that if the app goes crazy, it corrupts not only the data, but the structure itself, making it hard/impossible to recover. But in my storage-key world, I can imagine spearating the strcture from the data, and putting the structure in read-only memory, where the app can see it but not corrupt it, and putting the data in a read-write key, where the app can do whatever it wants. Part of the power of a dbase-like thing is that one memory-mapped the db file, and thus you could just pick through it. It was memory-mapped because this access was a *lot* faster (orders of magnitude, even on linux), than using ordinary file-io routines. In this kind of app, if you had to hide the data behind a socket, I claim you would get performance roughly comparable to ordinary file-io, and nowhere near the speed of memory-mapped io. To get decent performance out of a database that's hidden behind a socket, you have to invent something like SQL, and that gets hard. Even a super-minature, homebrew query-object is still harder than just memory-mapping some data structure. Theres an analogous situation with languages that support persistent objects (e.g. python, or maybe some form of java). The problem becomes one of how can python (the language itself) save the object to a file, and resotre it later, without risking corruption from the app itself? This is solved in part by e.g. having a java vm which can't be corrupted (in theory) by plain-old java code. But back in the early days of java, there were all sort os applets that could break of of the JVM. (Since java today is used mostly for servlets, and since we implicitly trust servlets, this is less of a problem).But if you were a JVM, and you might be buggy, and you wanted to run an untrusted java applet, it sure would be nice to put the applets memory pool in a different storage key than the JVM, so that if it did try to break you, it couldn't write to your storage. I don't see how to turn this problem into a I'll just use sockets to protect me problem. Security is hard, and trying to implement some sort of framework that will allow even inexperienced programmers to magically only produce secure code strikes me as somewhat naive ;-) Don't try to misunderstand me on purpose. Programmer A might be be a very sophisticated developer of libraries, and able to go to some lengths to do a good job. Programmer F might be trying to create an app using A's library. But F is a ninny, and A would like to protect against F's pratfalls, and maintain a semblence of data integrity in the face of F's bad programming style. Giving A a mechanism like storage keys gives A a chance to do well. One main point why just function calls are so much easier to use than IPC is that you can pass pointers to complex data structures back and forth. If you really implement some sort of strict memory protection, that won't work any more. Huh? why not? Because those pointers will point to memory the callee is not allowed to access? Huh? why not? Socekts also have some severe performance problems in certain domains. For example, the XShm extension to X11 uses shared memory to communicate stuff (pixmaps) with the X server, in order to avoid a rather sever penalty of cramming it through a socket. By contrast, X11 itself was designed as a client-server system precisly in order to prevent one crazy window client from corrupting the entire display and all other windows. Imagine how much easier it would have been (it could be?) to implement a windowing system as a library, not as a client-server with the associated protocol, encode/decodde layers, yadda yadda, if one could only gaurentee that one crazy app wouldn't spoil the entire display. Sadly, this is almost a lament (I worked on X11 for years): storage keys, where wer't thou when you were needed? What we did instead was to build some very special graphics hardware that had the equivelent of storage keys in the hardware. To get high performance, we doled out a key to a particular rectangular area of the screen, and a client could doodle directly
