INFO-VAX Sat, 12 Jan 2008 Volume 2008 : Issue 23 Contents: Re: A brief history of NTP time Re: A brief history of NTP time Re: Anyone interested in building a vms-like OS? Cards you may want IA64 VMS installation DVD creation. Re: Island Computers is moving OT, but worth a look (UK: No Vista in schools) Re: OT, but worth a look (UK: No Vista in schools) Re: Security level of SET PASS /GENERATE ? Re: Security level of SET PASS /GENERATE ? Re: Security level of SET PASS /GENERATE ? Re: Security level of SET PASS /GENERATE ? Re: Security level of SET PASS /GENERATE ? Re: Security level of SET PASS /GENERATE ? Re: Security level of SET PASS /GENERATE ? Re: Security level of SET PASS /GENERATE ? Re: Security level of SET PASS /GENERATE ? Re: Security level of SET PASS /GENERATE ? Re: Security level of SET PASS /GENERATE ? Re: USB-stick Re: VMS - now with a hammer (was Re: Island Computers is moving) Re: VMS - now with a hammer (was Re: Island Computers is moving) ---------------------------------------------------------------------- Date: Fri, 11 Jan 2008 20:00:03 -0500 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: A brief history of NTP time Message-ID: <4788110f$0$90267$14726298@news.sunsite.dk> Bob Koehler wrote: > In article , Marc Van Dyck writes: >> For those interested by time management (NTP, et al), I suggest >> reading the paper "A brief history of NTP time" at >> http://www.cis.udel.edu/~mills/database/papers/history.pdf . >> It has nice references to Alpha systems being used systematically >> as time keepers because of the stability of their internal clock. >> I wonder which OS they are running and how they will be replaced >> once Alpha gets de-supported... > > Odd, I always found VAX clocks more reliable. Most Alpha used > a commercial clock chip that didn't run at a multiple of the > VMS clock lsb, so Alpha had to introduce a "leap tick" to keep > the time lsb right. I wonder which model Alpha they used and which > clock chip it employed. I have same experience. Alpha clocks needs NTP. VAX was more reliable. Arne ------------------------------ Date: Sat, 12 Jan 2008 01:33:38 GMT From: Tad Winters Subject: Re: A brief history of NTP time Message-ID: Arne Vajhøj wrote in news:4788110f$0$90267$14726298@news.sunsite.dk: > Bob Koehler wrote: >> In article , Marc Van Dyck >> writes: >>> For those interested by time management (NTP, et al), I suggest >>> reading the paper "A brief history of NTP time" at >>> http://www.cis.udel.edu/~mills/database/papers/history.pdf . >>> It has nice references to Alpha systems being used systematically >>> as time keepers because of the stability of their internal clock. >>> I wonder which OS they are running and how they will be replaced >>> once Alpha gets de-supported... >> >> Odd, I always found VAX clocks more reliable. Most Alpha used >> a commercial clock chip that didn't run at a multiple of the >> VMS clock lsb, so Alpha had to introduce a "leap tick" to keep >> the time lsb right. I wonder which model Alpha they used and >> which clock chip it employed. > > I have same experience. Alpha clocks needs NTP. VAX was more reliable. > > Arne > I seem to remember reading somewhere, there were some add-in (PCI slot) clocks for Alpha that were very accurate. Can anyone confirm this? ------------------------------ Date: Fri, 11 Jan 2008 19:44:20 -0600 From: pechter@pechter.dyndns.org (William Pechter) Subject: Re: Anyone interested in building a vms-like OS? Message-ID: In article , wrote: >In article <4783B4F2.3070807@comcast.net>, "Richard B. Gilbert" > writes: >>{...snip...} >> >>It's been done already. It was called PCVMS. It gave you a DCL shell >>and, IIRC, some VMS-like APIs. A toy, really. This was twelve or >>fifteen years ago. . . . > >Try 20! Wendin Associates in Wash. state. It was kind of slick. I had a copy in my Fort Monmouth days... I still have the docs but can't find the disks. > >The biggest issue, IMO, for PC-VMS at that time was the lack of a more >robust and sophisticated processor to run on. That was the era of the >80286 and, toward the end of the 80s, the 80386. I'd had a copy of it >back when I worked at Lakehurst NAEC. It was, like you've said, a toy >but fun to play with. CP/M ran on the box when there was something to >do beside see what would fail in PC-VMS DCL when you typed in a certain >command. Lakehurst, eh. I remember a figher jock tailgaiting me when I was down there fixing some PDP one afternoon. Shades of Top Gun. I thought I saw him laughing in the rear view mirror. In my Pre-DEC days I did newspapers for Leisure Village West and a couple of the other Leisure Village's. I always wanted to see the heavy lifting blimp-helocopter mix they were building there before the crash. You sound like a local... > >-- >VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM > > "Well my son, life is like a beanstalk, isn't it?" > >http://tmesis.com/drat.html Bill -- "When I think back on all the crap I learned in Vax school It's a wonder I fixed anything at all." (to the tune of Kodachrome) pechter-at-gmail.com ------------------------------ Date: Sat, 12 Jan 2008 00:07:01 GMT From: Tad Winters Subject: Cards you may want Message-ID: I have some items in my possession that I don't need (and just take up space.) I'd like them to avoid the landfill at this time. If you take care of the shipping, I'm happy to you the items you want. I can also email you a picture of any item, if that helps, but I have no hardware in which to test them. (Well, I do have a few MicroVAX 3100 boxes, but I'm sure they won't be of use testing most of these items.) Here's the list: . CQD-220/M (Qbus SCSI Disk controller, supported by MSCP?) . M7546 (Qbus TK50 tape controller) . 54-17131 (SLU converter board for VAXstation 2000) . 54-17230 (DSH32-AA/DST32 Sync driver/receiver) [2 of these] . 54-19830-01 (8MB memory option for MicroVAX 3100) . 54-16802 (2/4MB memory option, fully populated) . LPV11 clone as previously identified by Bill Gunshannon and pictured at the following URL: http://mysite.verizon.net/stafford.winters2/SIS-circuit-board.html . Unidentified board labeled as 6050-7009 rev. B that may be another SCSI controller, since the back side seems to have 6050-5001 rev. B. It has a CS-1 next to a logo and a couple prominent Cypress chips. Send me email if you'd like a picture of any of these items. To send me email, remove the obvious, leaving only a single period between the first and last name. ------------------------------ Date: Fri, 11 Jan 2008 23:49:16 -0600 (CST) From: sms@antinode.org (Steven M. Schweda) Subject: IA64 VMS installation DVD creation. Message-ID: <08011123491600_206002CA@antinode.org> Let's imagine that I have a file named I64083.BCK-GZ, which can be expanded into an image BACKUP save set of what looks like a real IA64 VMS installation DVD. Let us further imagine that I'm doing all this work on an Alpha system. If I were to create an LD container of an appropriate size, and restore (BACKUP /IMAGE) this save set onto the corresponding LD device, should I be able to use the resulting LD container to make a working installation DVD, or would the LD device first need to be fiddled using some exotic SET BOOTBLOCK command (which is, of course, "Valid on I64 systems only.")? Or (and especially if the answer to that last one was "yes"), does anyone have an actual IA64 DVD image lying about where I could stumble across it? (If IA64 fiddling is needed, I suppose that I could push everything up to an IA64 TestDrive system, fiddle as needed, and then pull the fiddled result back, but this seems less efficient than it might be. And what would the proper SET BOOTBLOCK command be?) Naturally, a VMS V8.3-1 kit would be preferred over the plain-old V8.3 kit which I have, so if anyone knows the secret file name for such a kit on the secret FTP server (or has a DVD image of that one), so much the better. It's not actually urgent, but there is a ZX2000 here just crying out for a good reason to run. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Fri, 11 Jan 2008 17:11:13 -0500 From: "Carl Friedberg" Subject: Re: Island Computers is moving Message-ID: <890539d90801111411o44bf230dr869e0a0e6c353bdc@mail.gmail.com> Paul, I've written modules in COBOL, BASIC, and FORTRAN which contain calls to VMS system services. BASIC has a nice collection of definition files from STARLET which make this a piece of cake (in most cases). The choice is usually made by the customer, who would prefer to see these things in a "native" language. Whatever floats your boat... Carl On Jan 11, 2008 4:01 AM, P. Sture wrote: > In article , > > "Tom Linden" wrote: > > > On Thu, 10 Jan 2008 11:43:04 -0800, Larry Kilgallen > > wrote: > > > > But they could be demonstrating, first hand, WASD/OpenVMS on HP hardware. > > Sort of, but if it's processing sales orders, I'd say definitely not. > > IIRC it was Hein who recently commented that COBOL wasn't the best > language to call system services from. My belated answer to that is if > you are a DSPP, yes you can maybe choose a more suitable language, but > if you are an end customer, COBOL may be all you have. > ------------------------------ Date: Fri, 11 Jan 2008 13:39:07 -0600 From: David J Dachtera Subject: OT, but worth a look (UK: No Vista in schools) Message-ID: <4787C5DB.7270D5DE@spam.comcast.net> Happened upon this in one of my daily e-mail newsletters: http://www.infoworld.com/article/08/01/11/Dont-upgrade-to-Vista_1.html The UK's schools people still see no compelling reason to move off of XP (Windows or Office), and still see a significant negative (ROI) in doing so, if I read this right. David J Dachtera DJE Systems ------------------------------ Date: Fri, 11 Jan 2008 15:30:32 -0500 From: JF Mezei Subject: Re: OT, but worth a look (UK: No Vista in schools) Message-ID: <4787d30a$0$16154$c3e8da3@news.astraweb.com> David J Dachtera wrote: > Happened upon this in one of my daily e-mail newsletters: > > http://www.infoworld.com/article/08/01/11/Dont-upgrade-to-Vista_1.html Microsoft used to have a "policy" of leaving in tons of bugs and requiring lots of reboots. This way, it was quite easy to motivate the masses to buy a new version of Windows that had improved stability. With XP, Microsoft achieved palatable stability and people no longer see such a great need to upgrade since Vista only brings on useless bells and whistles that require more powerful hardware. Had Microsoft not made XP so "stable", it would have lost a lot more market share to Apple and Linux. Apple is also stuck at pretty much the same place now with each new version just adding a couple of real stuff and a lot of bells and whistles. Where both need to go now is to work on the underpinnings and system management to make it far better in corporate environments and then, large corporate users will see a great advantage in upgrading. (for instance, getting real clustering etc etc). ------------------------------ Date: Fri, 11 Jan 2008 15:03:17 -0500 From: JF Mezei Subject: Re: Security level of SET PASS /GENERATE ? Message-ID: <4787cc31$0$15740$c3e8da3@news.astraweb.com> Slightly different slant to this issue: While any OS may have its own password policies for interactive logins, would it be correct to state that more and more, passwords are stored in some database along with user profile data ? Lets take EBAY or Paypal for instance. I doubt user profiles are stored in a unix authorisation file. So, if they handle passwords at the application level, it essentially means that they can implement whatever policy they want, but they might also have to re-invent the wheel. And consider ISPs where passwords are stored in a radius server, but they are changed via some web application. ------------------------------ Date: 11 Jan 2008 14:23:26 -0600 From: briggs@encompasserve.org Subject: Re: Security level of SET PASS /GENERATE ? Message-ID: In article <4786ee9e$0$16170$c3e8da3@news.astraweb.com>, JF Mezei writes: > AEF wrote: > >> Tell "them", whoever they are: LONGER IS STRONGER. PERIOD. COMPLEX IS >> MORE PAIN THAN GAIN. > > > Having a mandated password length is however a weakness since anyone > with some insider knowledge will know how to configure his password > guessing program to only try passwords of the mandated length. > > Having variable password lengths means that the hackers don't know how > long a password will be and thus greatly increases the number of > attempts they must make before they get to the password. That turns out not to be true. Given any alphabet, the number of variable length strings with maximum length n is no more than twice the number of fixed length strings with length exactly equal to n. To put it another way, variable length buys you at most one bit of entropy. [There are some assumptions of uniformity needed to formalize the latter statement properly] Consider a decimal alphabet. There's one possible string of length 0 There are ten possible strings of length 1 There are 100 possible strings of length 2 and so on. If you have a length 6 password and your attacker searches the variable length search space then on average he'll have to search through 111,111 possibilities with length <= 5 500,000 possibilities with length = 6 ------- 611,111 guesses on average before guessing right If the attacker knows that your password is length 6 then it takes him just 500,000 guesses on average. That's a 22% increase in work factor. About 1/4 of a bit of entropy. Not what I'd call a "great increase". Suppose you had to actually turn off your minimum password length to cost the attacker this penalty. And assume that 25% of your users take advantage of that to choose 5 character passwords. Then the attacker needs: 25% chance of needing 61,111 guesses on average to crack a 5 digit password + 75% chance of needing 611,111 guesses on average to crack a 6 digit password ------------------------------------------------------------------------------ 473,611 guesses on average. Variable length passwords don't make it harder on the attacker. They make it easier. ------------------------------ Date: Fri, 11 Jan 2008 15:23:02 -0500 From: JF Mezei Subject: Re: Security level of SET PASS /GENERATE ? Message-ID: <4787d148$0$16231$c3e8da3@news.astraweb.com> Used to run a private email system for some banking association. It was interesting to deal with individual members because password policies varied tremendously between banks. Some would be happy to not have anything, while others required that their password requirements on my system had to match those of their bank (and would ask me to set their expiry date to match that of their accounts at their bank as they had set a day each month to change all their passwords) When your employees access not only your own systems but external systems as well, having policies for password selection on the external systems is important as well. ------------------------------ Date: Fri, 11 Jan 2008 15:51:54 -0500 From: JF Mezei Subject: Re: Security level of SET PASS /GENERATE ? Message-ID: <4787d80c$0$16145$c3e8da3@news.astraweb.com> briggs@encompasserve.org wrote: > If you have a length 6 password and your attacker searches the variable > length search space then on average he'll have to search through > > 111,111 possibilities with length <= 5 > 500,000 possibilities with length = 6 > ------- > 611,111 guesses on average before guessing right I was thinking more in terms of comparing: you must have an 8 character password vs your password can be anywhere between 5 and 32 characters. If you know the length of a password, you start your password attacks at that length and it will complete faster (hence better odds of going undetected). Consider also email. Many may consider the ability to change the "From" in an email to be a security problem. But NOT changing it is also a security problem because it exposes your real username to the real world. aka: Bill.Clinton@lewinski.org is far safer than clinton06@lewinsky.org So having outgoing emails automatically use an alias instead of their real usernames should be a security requirement. ------------------------------ Date: Fri, 11 Jan 2008 21:03:15 GMT From: Tad Winters Subject: Re: Security level of SET PASS /GENERATE ? Message-ID: Kilgallen@SpamCop.net (Larry Kilgallen) wrote in news:YEXGxPGKTF4x@eisner.encompasserve.org: > In article , Tad > Winters writes: >> Kilgallen@SpamCop.net (Larry Kilgallen) wrote in >> news:ut2TZT1alcNx@eisner.encompasserve.org: >> >> [..snip..] >> >>> But for reasonable values on VMS, that doesn't matter. Breakin >>> evasion will protect you, except in the case of backup tape theft, >>> where nothing will protect you. >> >> Simple solution: Never backup the user authorization file to media >> that will leave the facility without first being physically >> destroyed. > > For a sufficiently large number of users that makes it intractable > to restore operations at the disaster recovery site. If the number of users is that large, security is that important, and disaster recovery needs to occur quickly, it seems to me there would be a cluster in place, spread across a large distance so that there would be no real down time. ------------------------------ Date: Fri, 11 Jan 2008 16:48:17 -0800 (PST) From: AEF Subject: Re: Security level of SET PASS /GENERATE ? Message-ID: <5a8447d4-af7d-42fa-907f-68b55658d93f@j78g2000hsd.googlegroups.com> On Jan 11, 1:25 pm, bri...@encompasserve.org wrote: > In article <9e570cc6-899d-4f7b-b5d1-4f650bf9a...@k39g2000hsf.googlegroups.com>, AEF writes: > > > > > On Jan 8, 9:24 am, Jan-Erik S=F6derholm > > wrote: > >> Richard B. Gilbert wrote: > >> > Jan-Erik S=F6derholm wrote: > >> >> In many places in the VMS docs one is recomended > >> >> to use the /GENERATE option of SET PASS (or the > >> >> correspending flag in SYSUAF). What is the current > >> >> view of these generated passwords ? How safe are they > >> >> against hacking/probing/directory-attacs ? > > >> >> Jan-Erik. > > >> > The generated passwords are as safe and secure as any other passwords. > > >> > Passwords are not the problem! Users are the problem!! > > >> Hold it ! > >> I know everything about all that. I was *specificaly* asking > >> about the builtin security of the *generated* passwords. > >> Nothing else... :-) > > > In some ways they're much safer as it avoids the problem of hackers > > guessing English words. That's the motivation. > > No. In my opinion, that's not the primary motivation. > > You defeat dictionary-based brute force attacks by reducing the rate > at which the adversary can test his password guesses. You do that by > using breakin evasion mode and login failure auditing. > > The primary motivation for generated passwords is to stop your users > from selecting passwords that are so weak that a brute force search > attack isn't needed. That's what I said. But I think you added some overkill. > It stops your users from using "password". That's included in what I said. > It stops your users from using the same password on every system they > use. That's different. > It stops your users from using "password1", "password2", "password3", > etc and having a crack reveal not just the one password but the user's > password selection scheme as well. That's also different. > > But it also increases > > the odds that users will write down the passwords. Then the danger > > with that depends on how dangerous the people who walk by are! > > Yes. That is a down side. Hence the motivation for things like tokens. > > > Cracking programs, I assume, start with easy things like patterns of > > letters and numbers and various combinations of English words. > > There's a danger in assuming that all attacks will proceed by > brute force search that is not tuned to the correct search space. I think we agree yet again. > > > Tell "them", whoever they are: LONGER IS STRONGER. PERIOD. COMPLEX IS > > MORE PAIN THAN GAIN. > > TheQuickBrownFoxJumpsOverTheLazyDog/Jan2008 > > Entropy in that password once you guess the password generation scheme > is almost negligible. Given a 90 day password expiration policy > you could brute-force the key space in four tries. Please clarify. > > Neither a requirement for complex passwords nor a requirement for > long passwords accomplishes the goal of having unpredictable passwords. Well, my point was that there is far greater gain from length vs. complexity (at least as is implemented in Windows XP, the only case in which I have direct experience). Please read the InfoWorld articles I posted links to. AEF ------------------------------ Date: 11 Jan 2008 19:04:02 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: Security level of SET PASS /GENERATE ? Message-ID: In article , Tad Winters writes: > Kilgallen@SpamCop.net (Larry Kilgallen) wrote in > news:YEXGxPGKTF4x@eisner.encompasserve.org: > >> In article , Tad >> Winters writes: >>> Kilgallen@SpamCop.net (Larry Kilgallen) wrote in >>> news:ut2TZT1alcNx@eisner.encompasserve.org: >>> >>> [..snip..] >>> >>>> But for reasonable values on VMS, that doesn't matter. Breakin >>>> evasion will protect you, except in the case of backup tape theft, >>>> where nothing will protect you. >>> >>> Simple solution: Never backup the user authorization file to media >>> that will leave the facility without first being physically >>> destroyed. >> >> For a sufficiently large number of users that makes it intractable >> to restore operations at the disaster recovery site. > > If the number of users is that large, security is that important, and > disaster recovery needs to occur quickly, it seems to me there would be a > cluster in place, spread across a large distance so that there would be no > real down time. That would be a good way to do it, but not in keeping with the economic model of outsourcing recovery site services which is so prevalent. ------------------------------ Date: Fri, 11 Jan 2008 17:09:23 -0800 (PST) From: AEF Subject: Re: Security level of SET PASS /GENERATE ? Message-ID: <006f275c-f86e-48f7-9b9f-96203bf35092@j78g2000hsd.googlegroups.com> On Jan 11, 3:23 pm, bri...@encompasserve.org wrote: > In article <4786ee9e$0$16170$c3e8...@news.astraweb.com>, JF Mezei writes: > > > AEF wrote: > > >> Tell "them", whoever they are: LONGER IS STRONGER. PERIOD. COMPLEX IS > >> MORE PAIN THAN GAIN. > > > Having a mandated password length is however a weakness since anyone > > with some insider knowledge will know how to configure his password > > guessing program to only try passwords of the mandated length. > > > Having variable password lengths means that the hackers don't know how > > long a password will be and thus greatly increases the number of > > attempts they must make before they get to the password. > > That turns out not to be true. > > Given any alphabet, the number of variable length strings with > maximum length n is no more than twice the number of fixed length > strings with length exactly equal to n. > > To put it another way, variable length buys you at most one bit of > entropy. > > [There are some assumptions of uniformity needed to formalize the > latter statement properly] > > Consider a decimal alphabet. > > There's one possible string of length 0 > There are ten possible strings of length 1 > There are 100 possible strings of length 2 > and so on. > > If you have a length 6 password and your attacker searches the variable > length search space then on average he'll have to search through > > 111,111 possibilities with length <= 5 Wouldn't that be 111,111/2 ? > 500,000 possibilities with length = 6 > ------- > 611,111 guesses on average before guessing right > > If the attacker knows that your password is length 6 then it > takes him just 500,000 guesses on average. > > That's a 22% increase in work factor. About 1/4 of a bit of entropy. > Not what I'd call a "great increase". > > Suppose you had to actually turn off your minimum password length to > cost the attacker this penalty. And assume that 25% of your users take > advantage of that to choose 5 character passwords. Then the attacker needs: > > 25% chance of needing 61,111 guesses on average to crack a 5 digit password > + 75% chance of needing 611,111 guesses on average to crack a 6 digit password > ------------------------------------------------------------------------------ > 473,611 guesses on average. > > Variable length passwords don't make it harder on the attacker. They > make it easier. What about passwords of exactly n characters vs. passwords with a min. of n? I'd think that at least some would be n+1 or n+2, but I don't know how many. AEF ------------------------------ Date: Fri, 11 Jan 2008 17:23:43 -0800 (PST) From: AEF Subject: Re: Security level of SET PASS /GENERATE ? Message-ID: <5d72821d-a29c-4d11-9f3f-78b029c92a38@n20g2000hsh.googlegroups.com> On Jan 11, 3:51 pm, JF Mezei wrote: > bri...@encompasserve.org wrote: > > If you have a length 6 password and your attacker searches the variable > > length search space then on average he'll have to search through > > > 111,111 possibilities with length <= 5 > > 500,000 possibilities with length = 6 > > ------- > > 611,111 guesses on average before guessing right > > I was thinking more in terms of comparing: > > you must have an 8 character password > vs > your password can be anywhere between 5 and 32 characters. Seems to me this would make things worse as few (non-admin) people would go for 8 or more. I'd expect a lot of 5-, 6-, and 7-char passwords and maybe a few 8-char ones. With the exception of the wacko secretary (or her wacko boss?) at my last job, no one is going to go anywhere near 32 chars. > > If you know the length of a password, you start your password attacks at > that length and it will complete faster (hence better odds of going > undetected). Not in your example. Do the math (assume 26-char space which means N=26^L): Length (L) N 5 12 E6 6 309 E6 7 8032 E6 8 208827 E6 So in your scheme, users would probably use 5, 6, and maybe 7 chars, the sum of which is much less than the case with 8. Again this demonstrates the power of length. So as Mr. Briggs already demonstrated, you could start with 1-char guesses all the way up to the max minus 1 with little extra effort and/or time. You really need to do the math. >---o---< I guess the ideal password is a generated one that's easy to remember with a long enough length for the given situation. [...] AEF ------------------------------ Date: Fri, 11 Jan 2008 21:50:49 -0500 From: "Richard B. Gilbert" Subject: Re: Security level of SET PASS /GENERATE ? Message-ID: <47882B09.6050607@comcast.net> Tad Winters wrote: > Kilgallen@SpamCop.net (Larry Kilgallen) wrote in > news:ut2TZT1alcNx@eisner.encompasserve.org: > > [..snip..] > > >>But for reasonable values on VMS, that doesn't matter. Breakin >>evasion will protect you, except in the case of backup tape theft, >>where nothing will protect you. > > > Simple solution: Never backup the user authorization file to media that > will leave the facility without first being physically destroyed. That's just fine as long as you are not faced with the problem of recreating three hundred user accounts following a disk crash. Of course you may also have to recreate some identifiers like OPERATOR, OUTBOUND_SALES, etc, and grant them to the appropriate people. . . . And you'd damn well better HAVE a record of what all those accounts and identifiers were! Never backing up the UAF is a possible solution but potentially an expensive one! ------------------------------ Date: Sat, 12 Jan 2008 04:16:03 GMT From: Tad Winters Subject: Re: Security level of SET PASS /GENERATE ? Message-ID: "Richard B. Gilbert" wrote in news:47882B09.6050607@comcast.net: > Tad Winters wrote: >> Kilgallen@SpamCop.net (Larry Kilgallen) wrote in >> news:ut2TZT1alcNx@eisner.encompasserve.org: >> >> [..snip..] >> >> >>>But for reasonable values on VMS, that doesn't matter. Breakin >>>evasion will protect you, except in the case of backup tape theft, >>>where nothing will protect you. >> >> >> Simple solution: Never backup the user authorization file to media >> that will leave the facility without first being physically >> destroyed. > > That's just fine as long as you are not faced with the problem of > recreating three hundred user accounts following a disk crash. Of > course you may also have to recreate some identifiers like OPERATOR, > OUTBOUND_SALES, etc, and grant them to the appropriate people. . . . > And you'd damn well better HAVE a record of what all those accounts > and identifiers were! > > Never backing up the UAF is a possible solution but potentially an > expensive one! > > Well a local backup is copy is okay, even to a floppy disk. Just don't lete it leave the facility. Actually, how about someone writing a script to copy the real SYSUAF and RIGHTSLIST, define logicals to point at the copies, set all the account passwords to some something straight from the dictionary, and then backup those files like they were the originals. If you ever have to recover from the copy, you'll be setting new passwords, but you'll still have all the other information. The benefit would be any accounts that had been deleted, disusered, or expired, would be getting new passwords as part of your recovery job. As it is, any adds or changes in the period between backup and recovery were already going to have to be performed again. ------------------------------ Date: Fri, 11 Jan 2008 15:17:16 -0500 From: JF Mezei Subject: Re: USB-stick Message-ID: <4787cfef$0$28279$c3e8da3@news.astraweb.com> Comment: The lack of such support on current VMS, and the total lack of any "roadmap" mention of such support show just how far behind VMS is lagging in todays's basic core features. FAT USB drives not only are used by a gazillion devices out there, but also used as today "sneaker net" data exchange (aka: replacing the diskette). ------------------------------ Date: Sat, 12 Jan 2008 11:41:16 +0800 From: "Richard Maher" Subject: Re: VMS - now with a hammer (was Re: Island Computers is moving) Message-ID: Hi Mark, > Hmmm. Perhaps > > Daughter-of-Tier3 - DoT3. > > or > > Tier3 Services Integration Toolkit - T3SIT > > :-) > > Something to keep the bloatware where it belongs - on *x - and leave VMS > an unsullied, peer-to-peer, binary interaction? > > Keep suggesting this sort of heterodox technology and you'll end up > finding yourself excommunicated from the Exclusive 3GL Brethren. My God, I'm transparent! How long has this been going on? Look, at the end of the day, I can't believe I'm having to defend the concept of "logging-on" to some people! Or the fact that having a 1:M relationship between Application Server Connections and Messages Exchanged is also a good thing. (Here's an idea for an additional stats field for WASD; "HTTP 1.1 requests per connection". (Internet bloody Explorer gives me 3 connections to receive a single Applet :-( bizarre)) The browser *is* the GUI (maybe even the OS?) but that does not mandate a http web-server being the application middleware back-bone! Expedient, ubiquitous, "easy" - yes, but "right" no way! (Leaving to one side security and high-performance for the moment) Just watch what Microsoft is doing with SilverLight and control of server interaction, and also Adobe, Oracle, IBM and BEA. Web-Servers are great at serving up files and pimping for applications, but once the introductions have been made, you should put the Sow's ear down and start sowing with silk! Whether you choose to call it a Portal, a Consolidator, or a Broker, your application server *is* something that you'll log-on and maintain a connection to. I just see no reason why that Application Server isn't VMS. VMS has the security, reliability, disaster tolerence, and clustering superiority that could give it the-edge in the server arena; it's just a shame it's not happening (and hasn't been for over 10 years :-() Call me crazy, but if Tier3 can give you Context-Rich, Connection-Oriented, client-interaction coupled with Transparent Load-Balancing and Network Communication, and Integrated VMS Authentication on the server-side, then I also think that's a good thing! All any Application Server that you write (in any 3GL) will consist of is 6 User Action Routines built into a Shareable Image - That's it! No aditional privileges reqd, your server(s) run a a VMS detached process under the username that you select, a Persona matching the client's credentials is made available to your 3GL routines in order to aid in access control, and full VMS Debugger faciliities are at your disposal. Add to that the fact that each Application can be tuned and configured independantly by your System Manager, and it's all gravy!!! Anyway, you and the cast of thousands at the IMM team are free to persue VMS Middle Management's "Year Zero" program and send all the corrupt legacy 3GL/DCL/SystemService/Macro coders out of the decadent cities and into the pure, unsullied, Java-OO-and-http paddy-fields. Sooner or later those wankers have to realize that it's the revenue that the cities generate that's keeping them, and VMS, afloat? Sadly, by that stage, I suspect we'll all be lying in those paddy fields with plastic bags over our heads :-( > (suggested in the Spirit of good humour - and making a *little* fun of > your sometime glossolalia Richard :-) I've found it best to err on the side of caution when it comes to slagging people off with your reckless throw away lines :-) A bit of empathy never hurt anyone you know. I'm mean next you'll be saying something like "Sachin's (pick a close relative)'s an Untouchable"; and where will it all end then eh? Cheers Richard Maher PS. I would have sworn that "glossolalia" was a word you just made up; and yet how appropriate, humorous,and still cutting on so many levels. I suggest you drink more and read less :-) "Mark Daniel" wrote in message news:13ob3863rj19iaf@corp.supernews.com... > Richard Maher wrote: > > Hi, > > > > Just curious as to how many commercial organizations are running VMS (+/- > > WASD,Apache,OSU) as their primary web-facing http server. Even if we limit > > to sample to "only those sites that already had VMS for other applications" > > I don't believe the percentage wpuld get anywhere near double figures, do > > you? > > > > But then again, if I was right, that would mean that the only reason anyone > > would be having for configuring and running the bloatware of Apache, Tomcat, > > Java, PHP, CGI, Perl, Axis2, WSIT on their VMS boxes would be because that's > > what someone thinks is the best middleware for communicating between a > > company's *nix web-servers and their tried and tested VMS applications. Do > > you not agree? > > > > Maybe in the States, companies are still strictly homogenous > > one-hardware-platform-only kinda people, but at least at the VMS sites where > > I've been, the internet facing web-servers are running on *nix boxes (and > > sadly the VMS data is being FTP'd over nightly - or similar). The > > hope/desire of these companies is that the VMS servers will disappear in the > > near future :-( > > > > Now the dream that the IMM people may have you believe is that the VMS > > resurgence will be based on it being the Web-Server of Choice for all > > companies in the future ("The thinking man's web-server" perhaps?) *Apache + > > security + disaster-tolerence + more* Sounds great! The one problem here is > > that I think that horse bolted long ago :-( How many conversions from Linux > > to VMS have you chalked up Kerry? > > > > I hope I'm wrong, but I tell you what; while we're waiting to find out, > > don't you think it would be prudent to give those existing VMS application > > servers at existing customer sites a way of integrating with the Linux > > Web-servers rather than replicating them? > > Hmmm. Perhaps > > Daughter-of-Tier3 - DoT3. > > or > > Tier3 Services Integration Toolkit - T3SIT > > :-) > > Something to keep the bloatware where it belongs - on *x - and leave VMS > an unsullied, peer-to-peer, binary interaction? > > Keep suggesting this sort of heterodox technology and you'll end up > finding yourself excommunicated from the Exclusive 3GL Brethren. > > (suggested in the Spirit of good humour - and making a *little* fun of > your sometime glossolalia Richard :-) > > > Cheers Richard Maher > > > > "Tom Linden" wrote in message > > news:op.t4n6x2aahv4qyg@murphus... > > > >>On Fri, 04 Jan 2008 04:26:05 -0800, David Turner, Island Computers > >> wrote: > >> > >> > >>>Thanks > >>> > >>>We are actually having our website redone. (No FLASH!) > >>>Thanks for the comments - we are updating the WINDOWS server from 2K to > >>>XP > >>>server as that is the webstore and the Ubuntu server is for the support > >>>site - these will be up soon. > >>> > >>>please excuse the mess - it ain't easy moving a company > >>> > >>>David > >>> > >> > >>Why not run VMS and WASD? > >> > >> > >> > >>-- > >>PL/I for OpenVMS > >>www.kednos.com > > -- > Credulity kills. > [Carl Sagan; The Demon-Haunted World] ------------------------------ Date: Sat, 12 Jan 2008 14:37:55 +1030 From: Mark Daniel Subject: Re: VMS - now with a hammer (was Re: Island Computers is moving) Message-ID: <13ogfb06mkbjv7e@corp.supernews.com> Richard Maher wrote: > Hi Mark, > > >>Hmmm. Perhaps >> >> Daughter-of-Tier3 - DoT3. >> >>or >> >> Tier3 Services Integration Toolkit - T3SIT >> >>:-) >> >>Something to keep the bloatware where it belongs - on *x - and leave VMS >>an unsullied, peer-to-peer, binary interaction? >> >>Keep suggesting this sort of heterodox technology and you'll end up >>finding yourself excommunicated from the Exclusive 3GL Brethren. > > > My God, I'm transparent! How long has this been going on? > > Look, at the end of the day, I can't believe I'm having to defend the > concept of "logging-on" to some people! Or the fact that having a 1:M > relationship between Application Server Connections and Messages Exchanged > is also a good thing. (Here's an idea for an additional stats field for > WASD; "HTTP 1.1 requests per connection". HTTPd ...uma.es:80 Server Statistics (HTTPe:80) Saturday, 12-JAN-2008 03:59:50 8< snip 8< Request Processing ------------------ 8< snip 8< Connection Request HTTP ---------- ------- ---- Total: 1956677 Total: 7625722 1.1: 5953591 (84%) Current: 7 Current: 1 1.0: 1133162 (16%) Peak: 735 Peak: 586 0.9: 91 (0%) 8< snip 8< Persistent /Total: 5219968 /Max: 509 Pipeline /Total: 12971 /Max: 60 8< snip 8< > (Internet bloody Explorer gives me > 3 connections to receive a single Applet :-( bizarre)) > The browser *is* the GUI (maybe even the OS?) but that does not mandate a > http web-server being the application middleware back-bone! Expedient, > ubiquitous, "easy" - yes, but "right" no way! (Leaving to one side security > and high-performance for the moment) > > Just watch what Microsoft is doing with SilverLight and control of server > interaction, and also Adobe, Oracle, IBM and BEA. Web-Servers are great at > serving up files and pimping for applications, but once the introductions > have been made, you should put the Sow's ear down and start sowing with > silk! Ok, you've mentioned Silverlight. Not trying to teach you how to suck eggs (not knowing myself) but you must have considered how a .NET Framework front-end might provide an infrastructure for all that Tier3 offers? Arguably it has a greater installed and developer base than Java. There are also open-source compatibility environments available and in-development. And it answers that ubiquitous question, "Is is supported on Win32?" Just my AU$0.05 FWIW. > Whether you choose to call it a Portal, a Consolidator, or a Broker, your > application server *is* something that you'll log-on and maintain a > connection to. I just see no reason why that Application Server isn't VMS. > VMS has the security, reliability, disaster tolerence, and clustering > superiority that could give it the-edge in the server arena; it's just a > shame it's not happening (and hasn't been for over 10 years :-() Call me > crazy, but if Tier3 can give you Context-Rich, Connection-Oriented, > client-interaction coupled with Transparent Load-Balancing and Network > Communication, and Integrated VMS Authentication on the server-side, then I > also think that's a good thing! All any Application Server that you write > (in any 3GL) will consist of is 6 User Action Routines built into a > Shareable Image - That's it! No aditional privileges reqd, your server(s) > run a a VMS detached process under the username that you select, a Persona > matching the client's credentials is made available to your 3GL routines in > order to aid in access control, and full VMS Debugger faciliities are at > your disposal. Add to that the fact that each Application can be tuned and > configured independantly by your System Manager, and it's all gravy!!! > > Anyway, you and the cast of thousands at the IMM team are free to persue VMS > Middle Management's "Year Zero" program and send all the corrupt legacy > 3GL/DCL/SystemService/Macro coders out of the decadent cities and into the > pure, unsullied, Java-OO-and-http paddy-fields. Sooner or later those > wankers have to realize that it's the revenue that the cities generate > that's keeping them, and VMS, afloat? Sadly, by that stage, I suspect we'll > all be lying in those paddy fields with plastic bags over our heads :-( > >>(suggested in the Spirit of good humour - and making a *little* fun of >>your sometime glossolalia Richard :-) > > I've found it best to err on the side of caution when it comes to slagging > people off with your reckless throw away lines :-) A bit of empathy never > hurt anyone you know. I'm mean next you'll be saying something like > "Sachin's (pick a close relative)'s an Untouchable"; and where will it all > end then eh? > > Cheers Richard Maher > > PS. I would have sworn that "glossolalia" was a word you just made up; and > yet how appropriate, humorous, and still cutting on so many levels. High praise indeed! Received with due humility. ;-) > I suggest you drink more and read less :-) Sage advice at the end of my annual leave! Prosit!! > "Mark Daniel" wrote in message > news:13ob3863rj19iaf@corp.supernews.com... 8< snip 8< >>Credulity kills. >>[Carl Sagan; The Demon-Haunted World] -- The suppression of uncomfortable ideas may be common in religion or in politics, but it is not the path to knowledge, and there's no place for it in the endeavor of science. We do not know beforehand where fundamental insights will arise from about our mysterious and lovely solar system. The history of our study of our solar system shows us clearly that accepted and conventional ideas are often wrong, and that fundamental insights can arise from the most unexpected sources. [Carl Sagan; quotation from the Cosmos television series] ------------------------------ End of INFO-VAX 2008.023 ************************