INFO-VAX Wed, 03 Sep 2008 Volume 2008 : Issue 483 Contents: Archive strategy Re: Can you record DVDs on 7.2.1? Re: Can you record DVDs on 7.2.1? Re: Can you record DVDs on 7.2.1? Re: Can you record DVDs on 7.2.1? Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Google Chrome, VMS, and Tier3 Re: Loose Cannon-dian (was: Re: DEFCON 16 and Hacking OpenVMS) Re: Loose Cannon-dian (was: Re: DEFCON 16 and Hacking OpenVMS) Re: Loose Cannon-dian (was: Re: DEFCON 16 and Hacking OpenVMS) Re: Loose Cannon-dian (was: Re: DEFCON 16 and Hacking OpenVMS) Re: Loose Cannon-dian (was: Re: DEFCON 16 and Hacking OpenVMS) Re: Loose Cannon-dian (was: Re: DEFCON 16 and Hacking OpenVMS) Re: Note to Island Computers customers Re: OT: SYSMAN Equiv. on AIX? Re: SMGRTL patch available on ITRC ftp site Re: switch vs. hub for hobbyist cluster Re: switch vs. hub for hobbyist cluster Re: switch vs. hub for hobbyist cluster ---------------------------------------------------------------------- Date: Wed, 3 Sep 2008 09:25:04 -0700 (PDT) From: tadamsmar Subject: Archive strategy Message-ID: <666f157e-6477-4c2b-94d8-c98adb52efaa@p25g2000hsf.googlegroups.com> I ask about putting a DVD on an Alphaserver DS10 runing 7.2-1. Never did get a clear answer on that. I am not sure anyone can point me to the software and hardware I need to get, at least not explicitly like a recipe in a cookbook. But, now I am thinking about some sort of removable disk solution. An external SCSI enclosure that can hold at least 2 removal disks. Got any suggestions on that? I figure removable disks are easier to recheck periodically since they should have a higher capacity than a DVD. ------------------------------ Date: Wed, 3 Sep 2008 01:29:49 -0700 (PDT) From: vaxinf@chemie.uni-konstanz.de Subject: Re: Can you record DVDs on 7.2.1? Message-ID: <680bdced-e7f3-43dc-b429-e07b6f309b38@k30g2000hse.googlegroups.com> On 3 Sep., 04:42, David J Dachtera wrote: > tadamsmar wrote: > > > On Aug 29, 10:30 am, koeh...@eisner.nospam.encompasserve.org (Bob > > Koehler) wrote: > > > In article <5bd7d4a4-6846-4b35-9765-8948b9db7...@25g2000prz.googlegro= ups.com>,tadamsmar writes: > > > > > Can you record DVDs or CDs using 7.2.1? > > > > =A0 =A0If you have and use the correct software and hardware tools, I= 'm > > > =A0 =A0fairly sure you can do it. > > > > =A0 =A0Did you want to record data CDs or music? > > > > =A0 =A0Of course, by "7.2.1" in c.o.v I'm assuming you mean VMS 7.2-1= . > > > Yes. VMS 7.2-1. > > > Just want to do data backups on DVD preferably., > > > Does anyone know a specific hardware and software solution for an > > AlphaServer DS10? > > > I suppose I can just stumble though it as try stuff. I posted on > > this earlier and got some leads, but I was not really confident > > that it can be done on 7.2-1. > > > 7.2.-1 does not have CDRECORD in SYS$MANAGER, but it is there > > on our 7.3-2 systems. > > CDRECORD is freeware. Build it from source on the target system, if > needed. > > Remember that CDWRITE, CDRECORD, DVDWRITE and others require that the > data be staged to a disk image file; then, the image file is burned to > the target media. > > I'm likely wrong, but I've not (yet) heard of DVD/RW software support > for VMS as yet, only DVD-R and DVD+R. > > D.J.D. DJD, this is not correct. The OpenVMS burning program that comes with V 8.3 burns DVD+R/DVD+RW and CD+R/CD-RW. cdrecord is much more flexible: CD-R/CD-RW, DVD-R/DVD-RW, DVD+R/DVD+RW. Dual layer DVD+-R burning with cdrecord does not work under OpenVMS. The newest cdrecord even supports Blu-Ray but produces error messages during the burning process. Nevertheless the result is fine. cdrecord has no option to check the burning result (this is important, because data verification does not take place automatically.). Finally: DVDwrite supports all media known at the moment: CD-R/CD-RW, DVD-R/DVD-RW, DVD+R/DVD+RW, DVD-R DL, DVD+R DL, DVD-RAM, BD-R/BD-RE, BD-R DL/BD-RE DL (~45 GB/disk!). The program optionally verifies the data after the burning process. If a big stock exchange company in Germany has a site contract to use DVDwrite you'll can't be wrong. One additional remark to the 7.2-1 problem: The difficulties arise from the fact that there is only SCSI in order to access a burner. Under 7.3-2 IDE/SATA is possible und V8.3 adds USB for I64 (not for cdrecord). regards Eberhard ------------------------------ Date: Wed, 03 Sep 2008 07:47:56 -0400 From: "Richard B. Gilbert" Subject: Re: Can you record DVDs on 7.2.1? Message-ID: Bob Koehler wrote: > In article , tadamsmar writes: >> Digital Equipment Corporation's Open Virtual Memory System Version >> 7.2.1, which is now owned by Compaq. > > Nope. There's no 7.2.1. And VMS is owned by HP. I still think > you mean 7.2-1. > Just beat it to death Bob!! I had no trouble figuring out what he meant! ------------------------------ Date: 3 Sep 2008 07:51:54 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Can you record DVDs on 7.2.1? Message-ID: In article , "Richard B. Gilbert" writes: > > Just beat it to death Bob!! I had no trouble figuring out what he meant! Hey, it's a technical newgroup. Either 0 or 1. ------------------------------ Date: Wed, 03 Sep 2008 17:05:26 +0200 From: "P. Sture" Subject: Re: Can you record DVDs on 7.2.1? Message-ID: In article <9eb7ef69-4037-4a7e-93a0-7f574ff5bf68@j22g2000hsf.googlegroups.com>, johnwallace4@yahoo.co.uk wrote: > Mind you, when your archival contractor decides that their long term > storage format for CD/DVD "ISO" images is a hard drive on a server, > and then the server is sold with an intact unerased hard drive on > eBay... best say no more, lawyers may be reading: > http://www.theregister.co.uk/2008/08/26/more_details_lost/ I couldn't help a cynical smile at one of the comments to that article at: http://www.theregister.co.uk/2008/08/26/more_details_lost/comments/ "Now I have no need to buy a shredder. Why bother shredding sensitive data when the banks give it away!" But on a more practical note, I have had substantial problems in the past with data entrusted to third parties for forwarding to customers / suppliers (tape conversions etc) or for safe keeping (legal requirements), as the data often gets mangled along the way. Some of those third parties were just a different department in the same company BTW. -- Paul Sture ------------------------------ Date: Wed, 3 Sep 2008 04:06:58 -0700 (PDT) From: Neil Rieck Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <66f66f7c-d89d-46a7-8fcb-7e69bfe47f2d@c58g2000hsc.googlegroups.com> On Sep 2, 8:18=A0pm, FrankS wrote: > On Sep 2, 7:56=A0am, Neil Rieck wrote: > [...snip...] > > It would be shameful if an HP sales person drove this decision. > > One of my large clients was practically being begged by HP to move > their VAX/Alpha systems (four big-iron VAXes and two big-iron GS-class > Alphas) to Itanium. =A0There were tons of incentives, including free > license upgrades as well as dramatic discounts on the equipment. =A0The > perception was that HP is looking everywhere for large enterprises > that are migrating OpenVMS to Itanium instead of jumping to Windows or > Unix (particularly on something other than HP hardware), > > Somebody did not do their homework. =A0Given that the source code is > available and a migration to Alpha was already tested it's insane to > go with Charon. =A0Even used Alphas was a better solution, and HP still > offers discounts on VAX->Alpha upgrade licenses. > I agree, but since middle management made the decision (think Dilbert) without discussing it with the people who have been in the industry for 30+ years, we=92ll never know. Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada. http://www3.sympatico.ca/n.rieck/ ------------------------------ Date: 3 Sep 2008 07:40:51 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <72gBnYP0iveq@eisner.encompasserve.org> In article , Johnny Billquist writes: > > Well, it is a hardware design thing, you know... It's up to VMS as to how to use the space it was allowed. I'm not sure VAXeln or ULTRIX used it the same way. > The P0 and P1 related registers are a part of the context of the process, and > are also given as virtual addresses within S0 space, while S0 space itself is > pointed to by a table at physical address. P0 and P1 registers like PR$_P0BR started in early models as privileged CPU registers. Many of the privileged CPU registers actually were implemented in RAM in later models. But I don't think there's anything in the VAX architecture that says what values they can take on. An OS can pretty much set them as it needs. S0 space is pointed to by page tables the same as any other space. Only the highest level S0 page table pointing to the second S0 level page tables has to be at a known RAM location, and even that location is variable and found in the SCB, which in turn is located via the PR$_SCBB. But I'm not sure the VMS kernel ever outgrew a single level of page tables. It's pretty small. ------------------------------ Date: 3 Sep 2008 07:43:43 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: In article , Johnny Billquist writes: > > Not true. On the VAX, S1 space is reserved, and you can never write any code > that access it. it will always give you a fatal trap. The hardware do know this, > and cares very much. There is in fact no way to create a page table for S1 space. > When the VAX physical and virtual addresses were expanded the virtual addresses originally reserved for S1 space were appended to S0 space. So on those models you certainly can create a page table for those addresses even though they became known as S0 space. The difference is academic. ------------------------------ Date: 3 Sep 2008 07:46:52 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: In article , Johnny Billquist writes: > > The 11/70 don't have SBI, or anything close to it. > Odd that all my block diagrams from DEC for the 11/70 show CPU, memory, UNIBUS adapters, and MASSBUS adapters hanging off of it, then. DEC even wrote up how they were not abandoning the UNIBUS just because they came out with a system that didn't use it for the system bus. ------------------------------ Date: Wed, 3 Sep 2008 06:54:26 -0700 (PDT) From: johnwallace4@yahoo.co.uk Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: On Sep 3, 1:46 pm, koeh...@eisner.nospam.encompasserve.org (Bob Koehler) wrote: > In article , Johnny Billquist writes: > > > The 11/70 don't have SBI, or anything close to it. > > Odd that all my block diagrams from DEC for the 11/70 show CPU, > memory, UNIBUS adapters, and MASSBUS adapters hanging off of it, then. > > DEC even wrote up how they were not abandoning the UNIBUS just > because they came out with a system that didn't use it for the > system bus. Just like in your diagrams, the 11/70 I worked on had CPU, memory, UNIBUS adapers and MASSBUS adapters. I don't remember it having an SBI. As far as I know, you're the (only?) one that says the 11/70 had an SBI. I'd be surprised if you can find anything public which shows SBI in any PDP11. Afaik the SBI as commonly understood first came in with the 11/780 (which like other early VAXes also had UNIBUS for slower "legacy" stuff). My (admittedly vague) recollection of various other aspects of PDPs ties in with Johnny's rather than yours, but comp.sys.dec might well be more definitive than me. > But I'm not sure the VMS kernel ever outgrew a single level of page tables. It's pretty small. The kernel code may have started small and may well not have grown hugely. The same cannot be said of kernel data structures, which needed to be rather bigger in a system with maybe hundreds of GB of memory and hundreds of devices (and users, and processes), than they were in the first VMS systems with a few MB of memory and a handful of devices (and users, and processes). Where do you think these data structures are found? Rather than summarise badly, I'll refer to (e.g.) http://www.openvms.compaq.com/openvms/journal/v5/removing-32-bit-limit.html which may refresh folks' memory. ------------------------------ Date: 3 Sep 2008 12:30:19 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: In article , johnwallace4@yahoo.co.uk writes: > On Sep 3, 1:46 pm, koeh...@eisner.nospam.encompasserve.org (Bob > Koehler) wrote: >> In article , Johnny Billquist writes: >> >> > The 11/70 don't have SBI, or anything close to it. >> You can see discussed as the "backplane" at http://www.pdp11.nl/pdp11-70/startpage.html . I don't recall where I first saw the 11/70 backplane called an SBI, but it must have been close to the SBI on the 11/780 because a lot of the I/O bus adapters on the earliest 11/780 had the same model numbers as those on the 11/70. I think DEC did very little re-engineering in those parts of the computer while working to build the first VAX. > >> But I'm not sure the VMS kernel ever outgrew a single level of page tables. It's pretty small. > > The kernel code may have started small and may well not have grown > hugely. The same cannot be said of kernel data structures, which > needed to be rather bigger in a system with maybe hundreds of GB of > memory and hundreds of devices (and users, and processes), than they > were in the first VMS systems with a few MB of memory and a handful of > devices (and users, and processes). Where do you think these data > structures are found? Rather than summarise badly, I'll refer to > (e.g.) http://www.openvms.compaq.com/openvms/journal/v5/removing-32-bit-limit.html > which may refresh folks' memory. Yes, now that I think of it, there would be no point in growing S0 space to cover that which had been reserved for S1 if it was so small as to fit in on layer of page tables. ------------------------------ Date: Wed, 3 Sep 2008 20:30:03 +0800 From: "Richard Maher" Subject: Google Chrome, VMS, and Tier3 Message-ID: Hi, It's not DECforms, DECWindows, or even EDT on RSX-11, so no one here's probably too interested (certainly none of the wankers employed at HP/VMS that are chewing up the license fees on WSIT and gSOAP) but for those of you who have downloaded the beta of Google's new Chrome WebBrowser and are looking at the Tier3 Java Applet client examples, then please let me inform you that you also need to download the latest (also beta) Java plugin: - http://www.google.com/support/chrome/bin/answer.py?answer=95697&topic=14687 (You may recall some of the wiz-bang features of Java 1.6_10 mentioned here recently? Separate JVMs? JNLP-like deployment?) So as soon as you're kitted up with Chrome, Flex and Java plugins then please, once again, try: - http://manson.vistech.net/t3$examples/demo_client_web.html and http://manson.vistech.net/t3$examples/demo_client_flex.html Username: TIER3_DEMO Password: QUEUE Please also report any problems here, or to me directly. Cheers Richard Maher PS. I know it's based on the same engine as that piece o' shit Safari, but I really like what I've seen of Chrome so far, and it is FAST! I also *really* like the application-shortcuts and the almost *non-existent* browser footprint!!! (Separate Task-Manager also good!) PPS. Ooops! I've just realized that it's currently only available in BILLelzibub, microslop/shit, blah, blah, blah versions, so most here (along with their pretentious-fuck soul-mates at HP/VMS Middle-Management) will refuse to even glance at it out of principle. Imagine: - . Rock Solid VMS performance, disaster tolerance, and security . Huge heritage of business-rules, data, and 3GL code . Internet- Explorer, FireFox, Chrome, (and the also rans) as a launch-agent . (JavaScript, HTML, Java, Flex) as your GUI and the world is yours!!! . VMS applications fully integrated with your web-facing *nix or IIS infrastructure Nah, on second thoughts give the incumbents (you know who) *yet another* promotion :-( I tell ya what; when it comes to WebSockets and HTML5, why don't you wait 10 years (like Java) and then you can *safely* implement something thats waning? Full steam ahead - you're all doing very well! ------------------------------ Date: 3 Sep 2008 11:27:41 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Loose Cannon-dian (was: Re: DEFCON 16 and Hacking OpenVMS) Message-ID: <6i7aldFpf853U2@mid.individual.net> In article , DaveG writes: > On Sep 2, 2:37 pm, JF Mezei wrote: >> b...@signedness.org wrote: >> > Brad, I think it is safe to say that the patch has nothing to do with >> > comp.os.vms. I believe some people noted that the patches were created >> > a month before we did the talk. >> >> I think this is speculation. >> >> Once we got over the language barrier on c.o.v., you'll notice that it >> was only then that SMG was declared guilty, and someone from HP posted >> some PATCH code to patch the SMGSHR image and not long after an official >> patch came out, and not long later, it was elevated to MUP. >> >> Had there not been a public discussion on c.o.v. that fully described >> how to trigger this vulnerability, I think HP would have waited a lot >> longer to release the patch, and may not have elevated it to MUP status. >> >> Had HP keep in contact with you, you may not have come here and the >> outcome may have been different. But you say that HP stopped replying to >> you and that *may* mean that this was not given the priority it deserved. >> >> By going public, it elevated the priority of the issue. >> >> (In case you are not aware, VMS is the black sheep of HP family, and HP >> is not really interested in VMS. It has suffered greater number of >> layoffs than other products at HP hand they shoved the remaining VMS >> staff into smaller premieses in a diffferent city. (this move happened >> during this @bug@ event) > Before you get too score a back from all the self inflicted pats its > getting..... > There were some concerned paying customers that had a dialogue with > the OpenVMS powers that be about the Install 1 Vs MUP SMG thingie, > after which it was decided that it would indeed become a MUP. It was > then buried on the last page (#5) of the 732 list and I assume other > versions as well, on the ITRC patch list because the software didn't > know where to put a MUP. When this was discovered, again a dialogue > between paying customers and HP, led to a promised fix to the ITRC to > place MUPs in a higher position ( page 1). > As others have mentioned, there are probably few from OpenVMS land > that bother to read this newsgroup anymore, so to think that this > place drives decisions in Marlboro is ludicrous. Which is, by the way, exactly what I said when suggesting this stuff really should be sent to CERT, But hen you couldn't claim never having an CERT vulnerabilities, could you? I still think this stuff should be reported to CERT, even now, as I am sure there are still VMS users who will not learn about these vulnerabilities from any other source. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 3 Sep 2008 11:36:30 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Loose Cannon-dian (was: Re: DEFCON 16 and Hacking OpenVMS) Message-ID: <6i7b5uFpf853U3@mid.individual.net> In article <48be1d20$0$9641$c3e8da3@news.astraweb.com>, JF Mezei writes: > bugs@signedness.org wrote: > >> trouble of finding all the relevant dates, I estimate that HP had a >> patch linked around 6 weeks before it was even clear to the majority >> of comp.os.vms that it was a real issue and exploitable. > > You need to wonder why HP would have sat on that patch so long without > telling you the problem was fixed and without releasing the patch. Is it > really a coincidence that it was released very shortly after people on > C.O.V. were given proper details to understand *and reproduce* this > serious vulnerability ? > > I'd be willing to bet there was nobody from the VMS group at the DEFCON > conference. So the fact that you published a vulnerability there would > not have made a difference. > > > The VMS community knows very well that the "newer" software like the > TCPIP stack or anything ported from Unix is riddled with bugs and buffer > overflow risks because it is not really "native" VMS software. The > POP/IMAP and XDM servers do not honour VMS intrusion detection for > instance. That is a serious security weakness since it allows > brute-force attacks that do not generate alarms. Anbd this has been > present for years. Oh, cut the crap. It isn't Unix's fault that there are bugs in VMS. One of the reported exploits is in SMG which is pure VMS. Not only that, it was written in Bliss, not C. No language or OS is immune to bad programming. > > Your vulnerability surprised many because it affected software that > dates back to the glory days of VMS when software quality and security > was job #1 at Digital and Digital really prided itself on having > experienced coders that wouldn't make such mistakes (especially since > most system services provide buffer limits to prevent buffer overflows). Or maybe it just destroyed that myth, too. Programmers are programmers. Some are good and some are bad and any idea that DEC never hired a bad programmer is just plain ludicrous. The fact that these bugs remnained (apparently) undetected just further proves how long ago VMS became insignificant in the IT world and thus never saw the scrutiny other systems saw. > > And since the "legacy" portions of VMS such as SMG haven't been actively > developped/improved in over a decade, so we would have still expected > this software to date back to the days of the high quality standards. And yet, there they are. Bugs, just like in everything else. Go figure! bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 3 Sep 2008 11:38:03 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Loose Cannon-dian (was: Re: DEFCON 16 and Hacking OpenVMS) Message-ID: <6i7b8qFpf853U4@mid.individual.net> In article <00A7F0AF.1BB9D4C5@sendspamhere.org>, VAXman- @SendSpamHere.ORG writes: > In article <5419cbb0-8494-4f1e-a28e-180c7b7ff072@m36g2000hse.googlegroups.com>, bugs@signedness.org writes: >>On Sep 2, 8:37=A0pm, JF Mezei wrote: >>> b...@signedness.org wrote: >>> > Brad, I think it is safe to say that the patch has nothing to do with >>> > comp.os.vms. I believe some people noted that the patches were created >>> > a month before we did the talk. >>> >>> I think this is speculation. >>> >>> Once we got over the language barrier on c.o.v., you'll notice that it >>> was only then that SMG was declared guilty, and someone from HP posted >>> some PATCH code to patch the SMGSHR image and not long after an official >>> patch came out, and not long later, it was elevated to MUP. >>> >> >>Well maybe if you had read my entire post you wouldn't say that. >>Someone wrote somewhere that link date on the patch pre-dates our talk >>by over a month. The "real" discussion started here probably a week >>after our talk, and then it took several days before it was >>"independently reproduced". So without actually going through all the >>trouble of finding all the relevant dates, I estimate that HP had a >>patch linked around 6 weeks before it was even clear to the majority >>of comp.os.vms that it was a real issue and exploitable. >> >>> Had there not been a public discussion on c.o.v. that fully described >>> how to trigger this vulnerability, I think HP would have waited a lot >>> longer to release the patch, and may not have elevated it to MUP status. >>> >> >>I would have thought the material being presented at the largest >>security conference in the world would have been enough incentive to >>release a patch. Or at least answer our emails and ask for more time >>before going public with our rather limited disclosure (given the >>timeline we could have just as well released an working exploit at the >>talk and still complied to most accepted disclosure policies!).. And >>don't forget HP did have a complete description how to trigger the >>vulnerability. >> >>> Had HP keep in contact with you, you may not have come here and the >>> outcome may have been different. But you say that HP stopped replying to >>> you and that *may* mean that this was not given the priority it deserved. >>> >> >>Again patch dates seems to tell a different story. We provided them >>with details how to reproduce the issue and explained the >>vulnerabilities had be sucessfully exploited. It seems they took it >>serious enough to produce patches but not serious enough to answer our >>emails.. People here have pointed out they were moving offices etc and >>I realise mistakes happens etc.. So we'll give them the benefit of >>doubt and report the other issues to them too. >> >>I don't want to make it sound like I have a massive problem with SSRT >>because I don't. It may very well be that our emails got lost in the >>move or something else happned to them, but if they just couldn't be >>bothered replying then I think that is pretty disrespectful and >>arrogant considering the circumstances. >> >>> By going public, it elevated the priority of the issue. >>> >> >>Most likely but it wasn't made public here, it was made public at >>defcon.. I think any argument that comp.os.vms speeded up the >>development of a patch falls pretty flat. But we did pick up some vms >>terminology here that provided us with useful information when we >>googled it.. And on that note I again want to encourage the VMS >>experts here to be a bit more sceptical when they read documentation. >>Several times reading up on things in order to write the proof of >>concept exploits we found ourselves saying "that can not possibly be >>right (from a security perspective)".. I'm pretty sure if the vms >>experts look at things with sceptical eyes a lot more bugs (and not >>just memory corruption bugs) will be uncovered. >> >>Hopefully the bugs and the discussion here created some awareness to >>make that happen. >> >> >>> (In case you are not aware, VMS is the black sheep of HP family, and HP >>> is not really interested in VMS. It has suffered greater number of >>> layoffs than other products at HP hand they shoved the remaining VMS >>> staff into smaller premieses in a diffferent city. (this move happened >>> during this @bug@ event) > > Wow! If you approached HP with the same sort of arrogance you've just > demonstrated in this posting, it is no wonder they might have ignored > you? Now that's funny. A VMS fanatic accusing someone else of arrogance. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Wed, 03 Sep 2008 08:08:39 -0400 From: "Richard B. Gilbert" Subject: Re: Loose Cannon-dian (was: Re: DEFCON 16 and Hacking OpenVMS) Message-ID: Michael Kraemer wrote: > Rich Jordan schrieb: > >> >> And the way its been reported to happen sometimes. >> >> Customer: Hello, HP! I want to buy a VMS system >> HP: VMS Windows? >> Customer: No, VMS. Ok, OpenVMS. >> HP: What version of windows is that? >> Customer: Its no any version of windows. Its OpenVMS >> HP: Hmm, Well does it run on a proliant? We sell those. >> Customer: No, it runs on Alphaservers, and on the new Itanium >> systems. >> HP: Itanium. Oh, I know. Hey, we sell those with windows too! >> Customer.... *click* Hello, IBM? > > IBM as second source for VMS ? > Well, if you can't get VMS from HP. . . . ------------------------------ Date: 3 Sep 2008 16:04:03 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Loose Cannon-dian (was: Re: DEFCON 16 and Hacking OpenVMS) Message-ID: <6i7qriFpf59iU1@mid.individual.net> In article , Jan-Erik Söderholm writes: >> In article <6i7b8qFpf853U4@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes: >>> In article <00A7F0AF.1BB9D4C5@sendspamhere.org>, >>> VAXman- @SendSpamHere.ORG writes: >>>> In article <5419cbb0-8494-4f1e-a28e-180c7b7ff072@m36g2000hse.googlegroups.com>, bugs@signedness.org writes: >>>>> On Sep 2, 8:37=A0pm, JF Mezei wrote: >>>>>> b...@signedness.org wrote: >>>>>>> Brad, I think it is safe to say that the patch has nothing to do with >>>>>>> comp.os.vms. I believe some people noted that the patches were created >>>>>>> a month before we did the talk. >>>>>> I think this is speculation. >>>>>> >>>>>> Once we got over the language barrier on c.o.v., you'll notice that it >>>>>> was only then that SMG was declared guilty, and someone from HP posted >>>>>> some PATCH code to patch the SMGSHR image and not long after an official >>>>>> patch came out, and not long later, it was elevated to MUP. >>>>>> >>>>> Well maybe if you had read my entire post you wouldn't say that. >>>>> Someone wrote somewhere that link date on the patch pre-dates our talk >>>>> by over a month. The "real" discussion started here probably a week >>>>> after our talk, and then it took several days before it was >>>>> "independently reproduced". So without actually going through all the >>>>> trouble of finding all the relevant dates, I estimate that HP had a >>>>> patch linked around 6 weeks before it was even clear to the majority >>>>> of comp.os.vms that it was a real issue and exploitable. >>>>> >>>>>> Had there not been a public discussion on c.o.v. that fully described >>>>>> how to trigger this vulnerability, I think HP would have waited a lot >>>>>> longer to release the patch, and may not have elevated it to MUP status. >>>>>> >>>>> I would have thought the material being presented at the largest >>>>> security conference in the world would have been enough incentive to >>>>> release a patch. Or at least answer our emails and ask for more time >>>>> before going public with our rather limited disclosure (given the >>>>> timeline we could have just as well released an working exploit at the >>>>> talk and still complied to most accepted disclosure policies!).. And >>>>> don't forget HP did have a complete description how to trigger the >>>>> vulnerability. >>>>> >>>>>> Had HP keep in contact with you, you may not have come here and the >>>>>> outcome may have been different. But you say that HP stopped replying to >>>>>> you and that *may* mean that this was not given the priority it deserved. >>>>>> >>>>> Again patch dates seems to tell a different story. We provided them >>>>> with details how to reproduce the issue and explained the >>>>> vulnerabilities had be sucessfully exploited. It seems they took it >>>>> serious enough to produce patches but not serious enough to answer our >>>>> emails.. People here have pointed out they were moving offices etc and >>>>> I realise mistakes happens etc.. So we'll give them the benefit of >>>>> doubt and report the other issues to them too. >>>>> >>>>> I don't want to make it sound like I have a massive problem with SSRT >>>>> because I don't. It may very well be that our emails got lost in the >>>>> move or something else happned to them, but if they just couldn't be >>>>> bothered replying then I think that is pretty disrespectful and >>>>> arrogant considering the circumstances. >>>>> >>>>>> By going public, it elevated the priority of the issue. >>>>>> >>>>> Most likely but it wasn't made public here, it was made public at >>>>> defcon.. I think any argument that comp.os.vms speeded up the >>>>> development of a patch falls pretty flat. But we did pick up some vms >>>>> terminology here that provided us with useful information when we >>>>> googled it.. And on that note I again want to encourage the VMS >>>>> experts here to be a bit more sceptical when they read documentation. >>>>> Several times reading up on things in order to write the proof of >>>>> concept exploits we found ourselves saying "that can not possibly be >>>>> right (from a security perspective)".. I'm pretty sure if the vms >>>>> experts look at things with sceptical eyes a lot more bugs (and not >>>>> just memory corruption bugs) will be uncovered. >>>>> >>>>> Hopefully the bugs and the discussion here created some awareness to >>>>> make that happen. >>>>> >>>>> >>>>>> (In case you are not aware, VMS is the black sheep of HP family, and HP >>>>>> is not really interested in VMS. It has suffered greater number of >>>>>> layoffs than other products at HP hand they shoved the remaining VMS >>>>>> staff into smaller premieses in a diffferent city. (this move happened >>>>>> during this @bug@ event) > >>>> Wow! If you approached HP with the same sort of arrogance you've just >>>> demonstrated in this posting, it is no wonder they might have ignored >>>> you? > >>> Now that's funny. A VMS fanatic accusing someone else of arrogance. > > What *was* funny (or whatever you'd like to call it) is that there > wasn't anything arrogant in "bugs" comments in the first place. > He's quite resonable, as far as I can tell. > > VAXman's (and others, incl mine!) *first* reactions when this > thread started a couple of weeks ago was what might be > called arrogant... I guess that's what one is to expect when they gore someone else's ox. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 3 Sep 2008 16:52:27 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Loose Cannon-dian (was: Re: DEFCON 16 and Hacking OpenVMS) Message-ID: <6i7tmaFpe9kaU1@mid.individual.net> In article <00A7F14A.4F01987B@sendspamhere.org>, VAXman- @SendSpamHere.ORG writes: > In article , =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= writes: >>> In article <6i7b8qFpf853U4@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes: >>>> In article <00A7F0AF.1BB9D4C5@sendspamhere.org>, >>>> VAXman- @SendSpamHere.ORG writes: >>>>> In article <5419cbb0-8494-4f1e-a28e-180c7b7ff072@m36g2000hse.googlegroups.com>, bugs@signedness.org writes: >>>>>> On Sep 2, 8:37=A0pm, JF Mezei wrote: >>>>>>> b...@signedness.org wrote: >>>>>>>> Brad, I think it is safe to say that the patch has nothing to do with >>>>>>>> comp.os.vms. I believe some people noted that the patches were created >>>>>>>> a month before we did the talk. >>>>>>> I think this is speculation. >>>>>>> >>>>>>> Once we got over the language barrier on c.o.v., you'll notice that it >>>>>>> was only then that SMG was declared guilty, and someone from HP posted >>>>>>> some PATCH code to patch the SMGSHR image and not long after an official >>>>>>> patch came out, and not long later, it was elevated to MUP. >>>>>>> >>>>>> Well maybe if you had read my entire post you wouldn't say that. >>>>>> Someone wrote somewhere that link date on the patch pre-dates our talk >>>>>> by over a month. The "real" discussion started here probably a week >>>>>> after our talk, and then it took several days before it was >>>>>> "independently reproduced". So without actually going through all the >>>>>> trouble of finding all the relevant dates, I estimate that HP had a >>>>>> patch linked around 6 weeks before it was even clear to the majority >>>>>> of comp.os.vms that it was a real issue and exploitable. >>>>>> >>>>>>> Had there not been a public discussion on c.o.v. that fully described >>>>>>> how to trigger this vulnerability, I think HP would have waited a lot >>>>>>> longer to release the patch, and may not have elevated it to MUP status. >>>>>>> >>>>>> I would have thought the material being presented at the largest >>>>>> security conference in the world would have been enough incentive to >>>>>> release a patch. Or at least answer our emails and ask for more time >>>>>> before going public with our rather limited disclosure (given the >>>>>> timeline we could have just as well released an working exploit at the >>>>>> talk and still complied to most accepted disclosure policies!).. And >>>>>> don't forget HP did have a complete description how to trigger the >>>>>> vulnerability. >>>>>> >>>>>>> Had HP keep in contact with you, you may not have come here and the >>>>>>> outcome may have been different. But you say that HP stopped replying to >>>>>>> you and that *may* mean that this was not given the priority it deserved. >>>>>>> >>>>>> Again patch dates seems to tell a different story. We provided them >>>>>> with details how to reproduce the issue and explained the >>>>>> vulnerabilities had be sucessfully exploited. It seems they took it >>>>>> serious enough to produce patches but not serious enough to answer our >>>>>> emails.. People here have pointed out they were moving offices etc and >>>>>> I realise mistakes happens etc.. So we'll give them the benefit of >>>>>> doubt and report the other issues to them too. >>>>>> >>>>>> I don't want to make it sound like I have a massive problem with SSRT >>>>>> because I don't. It may very well be that our emails got lost in the >>>>>> move or something else happned to them, but if they just couldn't be >>>>>> bothered replying then I think that is pretty disrespectful and >>>>>> arrogant considering the circumstances. >>>>>> >>>>>>> By going public, it elevated the priority of the issue. >>>>>>> >>>>>> Most likely but it wasn't made public here, it was made public at >>>>>> defcon.. I think any argument that comp.os.vms speeded up the >>>>>> development of a patch falls pretty flat. But we did pick up some vms >>>>>> terminology here that provided us with useful information when we >>>>>> googled it.. And on that note I again want to encourage the VMS >>>>>> experts here to be a bit more sceptical when they read documentation. >>>>>> Several times reading up on things in order to write the proof of >>>>>> concept exploits we found ourselves saying "that can not possibly be >>>>>> right (from a security perspective)".. I'm pretty sure if the vms >>>>>> experts look at things with sceptical eyes a lot more bugs (and not >>>>>> just memory corruption bugs) will be uncovered. >>>>>> >>>>>> Hopefully the bugs and the discussion here created some awareness to >>>>>> make that happen. >>>>>> >>>>>> >>>>>>> (In case you are not aware, VMS is the black sheep of HP family, and HP >>>>>>> is not really interested in VMS. It has suffered greater number of >>>>>>> layoffs than other products at HP hand they shoved the remaining VMS >>>>>>> staff into smaller premieses in a diffferent city. (this move happened >>>>>>> during this @bug@ event) >> >>>>> Wow! If you approached HP with the same sort of arrogance you've just >>>>> demonstrated in this posting, it is no wonder they might have ignored >>>>> you? >> >>>> Now that's funny. A VMS fanatic accusing someone else of arrogance. >> >>What *was* funny (or whatever you'd like to call it) is that there >>wasn't anything arrogant in "bugs" comments in the first place. >>He's quite resonable, as far as I can tell. >> >>VAXman's (and others, incl mine!) *first* reactions when this >>thread started a couple of weeks ago was what might be >>called arrogant... > > My reaction was how the hell to initiate the stack dump from the CLI. > > The initial reports here were sketchy. Reproducing the stack dump with > the described procedure did not work. The videos were not viewable and, > after being attacked for not viewing them and even when I did view them, > they were misleading (for instance, why the SHELLCODE>> prompt change?). > The FILE.EXE program to write PRIVS.TXT, etc. also clouded the view. > > As for taking several days for independent verification, it only took me > about an hour to hack up a PoC once I was able to produce a stack dump. > Mine didn't require any logical name red-herring nor did it require any > special show privies hack. > > Bugs writes: > > Several times reading up on things in order to write the proof of > concept exploits we found ourselves saying "that can not possibly be > right (from a security perspective)".. I'm pretty sure if the vms > experts look at things with sceptical eyes a lot more bugs (and not > just memory corruption bugs) will be uncovered. > > What was it from a security perspective that was not right? I viewed > their slides and there are several things on them that are not correct > from a VMS perspective, so I find it rather arrogant to make the above > statement and then not elaborate with at least one example. > > As for the importance of c.o.v. I notified several customers about the > current vulnerability and the patches which HP finally made available. > These customsers didn't get any information from HP, they got it from > c.o.v. indirectly via me. Which is why I, once again, reiterate why is this not being sent to CERT for the widest possible disemination? bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Wed, 3 Sep 2008 09:35:14 -0400 From: "David" Subject: Re: Note to Island Computers customers Message-ID: Tee hee -- David B Turner ============================================= Island Computers US Corp PO Box 86 Tybee GA 31328 Toll Free: 1-877 636 4332 x201, Mobile x251 Email: dturner@islandco.com International & Local: (001)- 404-806-7749 Fax: 912 786 8505 Web: www.islandco.com ============================================= "FrankS" wrote in message news:ddbecb28-3201-456e-b8bd-30101b9d35ae@k37g2000hsf.googlegroups.com... On Sep 2, 11:41 am, bob.bi...@gmail.com wrote: > Bight per Dictionary of Nautical Terms: > A recess in a coastline or river. > Thought you'll use Byte ;-) > My guess a cat 1 or 2 you'll be ok, Cat 3 iffy, > Cat 4 or 5 your toast. > Been thru 12 of em' If we're correcting: Paraphrased from dictionary.com (and any English language reference): YOUR: 1) A form of the possessive case of you used as an attributive adjective. "Your jacket is in that closet." 2) Used to indicate that one belonging to oneself or any other person, "The library is on your left." 3) Used informally to indicate all members of a group, or things of a particular type. "Take your factory worker, for instance." YOU'RE: 1) Contraction of you are. "You're toast." 'EM: 1) Contraction of them. "Been thru 12 of 'em." ------------------------------ Date: 3 Sep 2008 11:15:42 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: OT: SYSMAN Equiv. on AIX? Message-ID: <6i79uuFpf853U1@mid.individual.net> In article <48BDF6D4.42504333@spam.comcast.net>, David J Dachtera writes: > sol gongola wrote: >> >> David J Dachtera wrote: >> > "Steven M. Schweda" wrote: >> >> From: David J Dachtera >> >> >> >>> Is anyone aware of a SYSMAN-like utility for AIX? I need to be able to >> >>> execute the same command on multiple LPARs, HACMP not withstanding. >> >> Don't know aboit the multiple hosts part, but SMIT was the handy tool >> >> for system management when I was young. (Sure miss the SMIT dude >> >> falling on his face when a command failed.) >> > >> > Well, SMIT(TY) is whole different critter from SYSMAN. SMIT(TY) is a >> > screen-oriented interface to various system management task, but AFAIK >> > does not provide for operations within a group of nodes or a cluster. >> > SMITTY is the character-cell version. SMIT is the X version, but >> > defaults to SMITTY if X is not setup in the process environment or >> > otherwise not available. >> >> AIX has a slew of commands to performs the system functions that are >> performed by sysman. If you know the commands man files are there >> for you but difficult for the uninitiated. SMIT makes it easier. >> >> AIX System Management Interface Tool (SMIT) lets you build an activity >> through its menu interface. Before issuing the execute you can use F6 >> to view the command to be executed, save it and use it elsewhere. You >> can also look in the /smit.script file for a list of previously executed >> commands to copy and use elsewhere. > > Acknowledged (again). > > The hard part - and the reason for the initial post - is to execute > those commands on multiple LPARs so you only have one management point > instead of 10, 100, 1000, .... Are you limited to only things that come with AIX? CFEngine might be what you need but it is one of those dreaded OpenSource thingies. :-) bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Wed, 03 Sep 2008 10:31:26 -0700 From: Marty Kuhrt Subject: Re: SMGRTL patch available on ITRC ftp site Message-ID: FrankS wrote: > On Aug 23, 7:15 am, VAXman- @SendSpamHere.ORG wrote: >> My Rx was a little more than cheap reading glasses... not at $400! > > Yeah, the prescription glasses cost me $600, and I never use them. > They had a "progressive" lens and my eyes just never got used to > them. The cheapo reading glasses do a great job. I'm going to try > traditional bifocals for driving and flying because the gps and > instruments are starting to enter the fuzzy viewing range. My FAA medical is stamped with "HOLDER SHALL POSSESS GLASSES WHICH CORRECT NEAR", thus I keep a pair in my flight bag along with the medical certificate. Seems they've been printing the sectional charts with fuzzy ink of late... ;^) ------------------------------ Date: Wed, 03 Sep 2008 09:19:42 -0600 From: Keith Parris Subject: Re: switch vs. hub for hobbyist cluster Message-ID: Bob Koehler wrote: > Switching over dumb hub helps, but your cluster traffic and some of > the other protocols you're using is broadcast, so you won't see > much improvement going from 10Mb/s hub to a switch. OpenVMS Clusters don't use broadcast. They do use Multicast to a specific multicast address (based on the Cluster Group Number) for Hello packets (which are sent every 1.5 to 3 seconds from each LAN port enabled for cluster traffic, and are used for path discovery and for tracking path status and latency and packet size capability) but all the real inter-node cluster traffic is unicast. LAT also does not use broadcast, but uses Multicast to a specific multicast address about once a minute for service advertistments. All the real data is carried via unicast packets. As I understand it, the TCP/IP protocol may use some Ethernet broadcasts. I would advise trying an inexpensive switch. The cost is so low these days that it's worth trying. Here I've seen 5-port 10/100 switches for US$10 or even less. You can use the LOCKTIME.COM procedure from the V6 OpenVMS Freeware CD to measure lock request latencies before and after the introduction of a switch, and get an idea of the difference that way. Shadow copies would certainly be helped by going from 10 megabits to 100 megabits. With Gigabit Ethernet you can also use Jumbo Frames to do shadow copy work with fewer packets, and thus lower CPU interrupt-state load on the hosts. ------------------------------ Date: Wed, 03 Sep 2008 17:09:25 +0200 From: "P. Sture" Subject: Re: switch vs. hub for hobbyist cluster Message-ID: In article , helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) wrote: > In article > <7a547be2-8437-42ba-955e-9377f0e224d4@k30g2000hse.googlegroups.com>, > "Bart.Zorn@gmail.com" writes: > > > Is it worthwhile to keep the 3000/600 when you have a 1200? I can > > imagine that it consumes more power than the 1200, but I am not sure. > > Substantially more; that's the reason it is configured as a satellite. > > > I do not think that the 3000/600 does 100 Mb/s, so the speed of the > > 1200 does not really matter. > > Suppose the 1200 is accessing some web page through the DSL router. I > was hoping it could get more bandwidth through a switch. (Of course, > this would be an advantage only if the content weren't buffered to the > user disk, since this is a shadow set with a member on each of the > VAXes.) > > > That said, you may still gain something from a switch over the hub, > > especially when you are doing shadow copy/merge actions. > > Does anyone have a quantitative estimate? > > > Also note that the 1200 is the only one that could potentially use the > > full speed of your DSL connection, but only if you have a switch. > > Right; see above. Though with a switch, several machines at the same > time could use more of the DSL bandwidth (one doing email, one an FTP > transfer, one browsing the web etc). FWIW I always suffered from auto-negotiation problems when running my Alpha PWS on a hub. Changing to a switch solved those. -- Paul Sture ------------------------------ Date: Wed, 3 Sep 2008 16:46:56 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: switch vs. hub for hobbyist cluster Message-ID: In article , Keith Parris writes: > I would advise trying an inexpensive switch. The cost is so low these > days that it's worth trying. Here I've seen 5-port 10/100 switches for > US$10 or even less. I think I'll spend about EUR 80 on a 16-port 10/100 switch. All of the 8 ports on my hub are full now (3 active machines, uplink to the DSL connection, laptop, 1200 satellite, port for test machines, and currently inactive 3000/300 LX) so that should give me some extra room. (By the way, although I never INSTALLED VMS 7.3-2 on the 3000/300 LX (but rather on the 3000/600 then swapped in the system disk), I actually RAN 7.3-2 on it, even though it has only 48 MB. However, when that machine had the TCPIP cluster alias, the resources were maxed out. I really like its small size, though.) ------------------------------ End of INFO-VAX 2008.483 ************************