INFO-VAX Tue, 25 Mar 2008 Volume 2008 : Issue 169 Contents: Re: Divining the full pathname of a file, all logicals translated Re: Please critique my backup practices Re: Please critique my backup practices Re: Please critique my backup practices Re: Please critique my backup practices Re: Please critique my backup practices Re: Please critique my backup practices Re: RX3600 and VMS 8.3 Re: Shadow set problem finally solved Thanx for the assistance wtih VMS security questions in general Re: Thanx for the assistance wtih VMS security questions in general Re: Thanx for the assistance wtih VMS security questions in general Re: Thanx for the assistance wtih VMS security questions in general Re: Tripwire on OpenVMS Best Practices? ---------------------------------------------------------------------- Date: Mon, 24 Mar 2008 13:27:48 -0700 (PDT) From: Rich Jordan Subject: Re: Divining the full pathname of a file, all logicals translated Message-ID: <480e0851-d3d2-4fe1-83dd-6d0a14770417@n75g2000hsh.googlegroups.com> On Mar 22, 11:29 pm, Hein RMS van den Heuvel wrote: > On Mar 22, 9:42 pm, Rich Jordan wrote: > > > On Mar 20, 5:16 pm, AEF wrote: > > > On Mar 19, 5:41 pm, Rich Jordan wrote: > > > > > I'm looking at ways to generate the full "low level" pathname to a > > > > file with no logicals, concealed, terminal, or otherwise involved, and > > > > in standard format. > > I hear that and believe it to be a flawed requirement which will lead > bad decision. > concealed logical are defined for a reason. Respect that. > Specifically you do NOT want to go back down to the physical device... > IMHO of course. > What if the DKA controller is gonzo but DKB works fine? > What if you restore the data to a different place? > Maybe to a DGA or DRA? I guess you could restore to $x$DGA1234: > [DKA100] and then define a (concealed! :-) logical DKA100 to point to > that huh? > > > > > NODE$DKA0:[SYS0.SYSCOMMON.][SYSMGR]LOGIN.COM;12 > > > > NODE$DKA0:[SYS0.SYSCOMMON.SYSMGR]LOGIN.COM;12 > > > Why, pray tell? If you *really* need it this way, just subtract all > > > possible combinations of square and angle brackets. > > Just subtract the "][" if you have to. > > I uses to be one of the first to shout 'not clean: what about the "<>" > directories', trying to show off. > Nonsense. nobody uses that, and you know whether your target system > uses them. It doesn't. > If some application actually does use those, then it deserves to > fail.... IMHO of course. > > > > > I can put in conditional code to clean up the f$parse output but I'd > > > > rather find a way to have the clean pathname returned. Is there a way > > > > to do this using normal lexical functions? > > An unconditional - "][" on the same line as the parse, right after it > will do fine. > > > > > One other alternative seems to be to use one of the FID to NAME > > > > programs; since I can locate the file in question I have its FID and > > I don't think that is reasonable. > FID_TO_NAME is a 'best effort'. > It does not know how the script foudn the file, it only tries to > figure out how somene could find the file. > To wit: > > $ dir /file/nohead/notrail/wid=file=40 sys$system:show.exe > SYS$COMMON:[SYSEXE]SHOW.EXE;1 (37406,57,0) > $ WRITE SYS$OUTPUT F$FID_TO_NAME("SYS$SYSDEVICE","(37406,57,0)") > DISK$ALPHASYS:[VMS$COMMON.SYSEXE]SHOW.EXE;1 > $ WRITE SYS$OUTPUT F$PARSE(F$FID_TO_NAME("SYS > $SYSDEVICE","(37406,57,0)"),,,,"NO_CONCEAL") > EISNER$DRA0:[VMS$COMMON.SYSEXE]SHOW.EXE;1 > $ WRITE SYS$OUTPUT F$PARSE(f$search("sys > $system:show.exe"),,,,"NO_CONCEAL") - "][" > EISNER$DRA0:[SYS0.SYSCOMMON.SYSEXE]SHOW.EXE;1 > > > > > can run it through a program (seen online here in COV, also perhaps on > > > > freeware) and get the full raw pathname back. That would be > > > > acceptable too but if anyone's done it and has recommendations I'd > > > > appreciate hearing back. It would mean many thousands of image > > > > activations running the FID to Name program. > > I made a program to do just that. Included below. > The bigger performance overhead is more likely from back-tracing > FID --> header: DID --> directory header.DID ... --> DID = (4,4,0) > The program is in C, so its activation will be more work than a simple > MACRO version. > I almost started to recode. However: "Anything not worth doing is not > worth doing well" > > > prospective program that uses the archives may not, especially if its > > used or needed by people unfamiliar with VMS filename syntax. > > I fear you'll end up with something neither the OpenVMS folks, nor the > new guard understands. > my sample FID_TO_NAME program below. > In the context I needed it, I had the FID pieces already. so it takes > those as seperate arguments. > Wouldn't take too long to make it parse '(x,y,z)'. > > $fid_name :== "$my_tools:fid_to_name " ! ** CHANGE ** > : > $ file_name=f$fid_name(FILE_ID_DEVICE,file_id) ! V8 > $!7.3-2 fid_to_name 'FILE_ID_DEVICE' 'file_id_low' 'file_id_mid' > 'file_id_hi' file_name > > Cheers, > Hein. > > /* > ** fid_to_name.c Hein van den Heuvel, 2007 > ** > ** Usage: Define as external DCL command and pass filespec as param. > ** Result: DCL Symbol defined with filename as value > ** $fid_to_name device index-lo sequence index-hi symbol > */ > > #include > #include > #include > > void set_symbol(char *symbol, char *value) > { > void lib$set_symbol(); > struct {int len; char *addr;} symbol_desc, value_desc; > symbol_desc.addr = symbol; > symbol_desc.len = strlen(symbol); > value_desc.addr = value; > value_desc.len = strlen (value); > lib$set_symbol ( &symbol_desc, &value_desc); > > } > > main (int argc, char *argv[]) > { > > char device_name[128],file_name[256]; > int i, s, lib$fid_to_name(); > short fid[4]; > struct {int len; char *addr;} device_name_desc, file_name_desc; > if (6 != argc) { > printf ("Usage: $fid_to_name device index-lo sequence index-hi > symbol\n"); > printf (" index-lo : fid-word-0, 16 lsb bits for file-id\n"); > printf (" index-hi : fid-word-2, 8 msb bits for file-id plus rvn > byte\n"); > printf (" Symbol : DCL symbol to be defined with resulting > filespec\n"); > exit (16); > } > device_name_desc.addr = argv[1]; > device_name_desc.len = strlen(argv[1]); > file_name_desc.addr = file_name; > file_name_desc.len = sizeof file_name - 1; > fid[0] = atoi ( argv[2] ); > fid[1] = atoi ( argv[3] ); > fid[2] = atoi ( argv[4] ); > s = lib$fid_to_name ( &device_name_desc, &fid, &file_name_desc, > &fid[3] ); > file_name[ fid[3] ] = 0; > set_symbol ( argv[5], file_name ); > > } Hein, first, thanks for responding! T The fact of a location/device change would be considered noteworthy in this environment. A concealed logical would normally hide the fact that SYS$SYSDEVICE (and all the other SYS$... logicals) are now pointing somewhere else, as well as make the File ID also being stored useless for tracking that change, but with the device (part of that full path) those who wish to know will be informed by the programs' operation that: image yadayada.exe, File ID {12345,6,7), location changed; old location: NODE$DKA0:[SYS0.SYSCOMMON.SYSEXE] new location: NODE$DKB0:[SYS0.SYSCOMMON.SYSEXE] Only the generated database of file info has the full (canonical) path name of the file, and it also stores the file ID. The file ID is not of much use unless the base device is also identified, which mandates cutting through some concealed logicals (such as SYS$SYSROOT or SYS $COMMON, down to at least SYS$SYSDEVICE in the example above) in any case. The config file that tells the program which directories to scan uses normal syntax with logicals and all, so comparing a changed 'live' system to the stored info would catch the device name change and report it as required. If it scanned SYS$SYSTEM:*.EXE it could get the file IDs, pull that record from the database, compare the stored to the current path, and report the variance. If we stored only the logical path SYS$COMMON:[SYSEXE] or even SYS$SYSDEVICE: [SYS0.SYSCOMMON.SYSEXE] then we would not know that there had been a change (unless some other piece of stored and compared data showed that up). Having the F$FID_TO_NAME lexical return different results from using the FID versus the filename is interesting (and unfortunate, honestly) but its not an immediate issue since the system we're building on doesn't have that lexical. Too old. I believe the program you thoughtfully included is different from the other 'C' version I found; we'll give it a try. I appreciate your input, and in general agree with it, but in this specific case I really do need to get the raw pathnames. OBTW the comment about people unfamiliar with VMS syntax; I expect they'd know enough about dev:[dir1.dir2.dir3]file.name to be able to follow it since we'd be telling them. I'd prefer not to give them variances that might be confusing (extra "][" and missing ".") so it makes sense to use the most basic and consistent syntax in the stored information. Thanks! Rich ------------------------------ Date: Mon, 24 Mar 2008 20:00:23 +0000 (UTC) From: moroney@world.std.spaamtrap.com (Michael Moroney) Subject: Re: Please critique my backup practices Message-ID: We have heard many time: "Thou shalt not use BACKUP/IGNORE=INTERLOCK". But I have an application that runs continuously and doesn't close its files, so the alternative is no backup of them. I had the idea of doing two incremental backups, the first being a BACKUP/MOD/SINCE=BACKUP/RECORD of the disk, and the second being BACKUP/MOD/SINCE=BACKUP/IGNORE=INTERLOCK (note: no /RECORD) of the disk. The first is a "clean" incremental backup of the disk, and the second, since it is run immediately after the first, will contain only open files plus perhaps a few modified very recently. It would only be used in emergencies. The lack of /RECORD is so the files backed up on the second backup are not considered properly backed up, and any file closed before the next pass of incremental backups will be properly backed up during the next pass. Comments? ------------------------------ Date: Mon, 24 Mar 2008 17:24:42 -0400 From: "Richard B. Gilbert" Subject: Re: Please critique my backup practices Message-ID: <47E81C1A.2070300@comcast.net> Michael Moroney wrote: > We have heard many time: "Thou shalt not use BACKUP/IGNORE=INTERLOCK". > But I have an application that runs continuously and doesn't close its > files, so the alternative is no backup of them. I had the idea of doing > two incremental backups, the first being a BACKUP/MOD/SINCE=BACKUP/RECORD > of the disk, and the second being BACKUP/MOD/SINCE=BACKUP/IGNORE=INTERLOCK > (note: no /RECORD) of the disk. The first is a "clean" incremental backup > of the disk, and the second, since it is run immediately after the first, > will contain only open files plus perhaps a few modified very recently. > It would only be used in emergencies. The lack of /RECORD is so the files > backed up on the second backup are not considered properly backed up, and > any file closed before the next pass of incremental backups will be > properly backed up during the next pass. Comments? > If you can't stop the application, you can't guarantee a consistent backup! Some applications, such as databases, provide a means to get a consistent backup. If yours does not, you could ask the vendor how to back up those files in such a way that a restore will be valid and usable. If the answer is "No way!" then you need to think carefully about your options. As I see them, they are: 1. Live with the risk! 2. Shut the application down while its files are being backed up. 3. Get a different application that both meets your needs as an application and also allows a consistent backup. ------------------------------ Date: Mon, 24 Mar 2008 22:03:43 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: Please critique my backup practices Message-ID: <3zVFj.5254$R_4.4593@newsb.telia.net> Richard B. Gilbert wrote: > If you can't stop the application, you can't guarantee a consistent > backup! Some applications, such as databases, provide a means to get a > consistent backup. And some databases (read "Rdb") does it in a much easier and cleaer way then the rest. Using Rdb, online backup of "data" is an absolute no-brainer, just add /ONLINE to the RMU/BACKUP command. No nead to do anything with the application. Jan-Erik. ------------------------------ Date: Mon, 24 Mar 2008 22:17:42 -0000 From: "John Wallace" Subject: Re: Please critique my backup practices Message-ID: <13uga49iackqv29@corp.supernews.com> "Michael Moroney" wrote in message news:fs918n$qf8$1@pcls4.std.com... > We have heard many time: "Thou shalt not use BACKUP/IGNORE=INTERLOCK". > But I have an application that runs continuously and doesn't close its > files, so the alternative is no backup of them. I had the idea of doing > two incremental backups, the first being a BACKUP/MOD/SINCE=BACKUP/RECORD > of the disk, and the second being BACKUP/MOD/SINCE=BACKUP/IGNORE=INTERLOCK > (note: no /RECORD) of the disk. The first is a "clean" incremental backup > of the disk, and the second, since it is run immediately after the first, > will contain only open files plus perhaps a few modified very recently. > It would only be used in emergencies. The lack of /RECORD is so the files > backed up on the second backup are not considered properly backed up, and > any file closed before the next pass of incremental backups will be > properly backed up during the next pass. Comments? > What do you know about the relationship between the continuously-running application's in-memory copy of the file (which the application will see), and the on-disk copy of the file (which BACKUP will see)? Without that kind of knowledge, comments on the efficacy of /IGNORE=INTERLOCK are likely nothing more than speculation (unless the comment is "it's pointless", which isn't news to you). And/or, asking a slightly different question, how do the commercial products which claim to do "open file backup" get around this problem (if indeed there are any such products on VMS?). ------------------------------ Date: Mon, 24 Mar 2008 16:54:06 -0700 (PDT) From: AEF Subject: Re: Please critique my backup practices Message-ID: On Mar 21, 11:41 am, David J Dachtera wrote: > Dale Dellutri wrote: > > > On Thu, 20 Mar 2008 12:36:19 -0700 (PDT), tadamsmar wrote: > > > On Mar 20, 2:36?pm, Dale Dellutri wrote: > > > > On Thu, 20 Mar 2008 07:02:14 -0700 (PDT), tadamsmar wrote: > > > > > To do a backup, I pop a drive out of a shadowset, back it up and put > > > > > it back. > > > > > I assume you're talking about VMS Volume Shadowing. ?As far as I know, > > > > taking a drive out of a shadowset causes the drive to look the same as > > > > if there'd been a power failure. ?In other words, it does not properly > > > > close open files. > > > > > I assume that you take image backups. ?If so, there's no benefit to > > > > taking the drive out of the shadowset to take the image backup. > > > > According to service techs that I talked to when I first set up > > > > volume shadowing, there's no advantage over taking an image backup > > > > of the volume set (the DSA device). > > > > > I assume that this is still true. > > > > > > The problem is, I don't record the backup dates. > > > > > You could record backup dates if you simply took an image backup > > > > of the volume set. > > > > Don't I have to shutdown my system to do that? > > > I finally found the relevant item in "HP Volume Shadowing for > > OpenVMS", v7.3-2. Chapter 7, Section titled "Data Consistency > > Requirements": "Removal of a shadow set member results in what > > is called a crash-consistent copy. That is, the copy of the > > data on the removed member is of the same level of consistency > > as what would result if the system had failed at that instant." > > (pg 124 in my copy). > > > Actually, reading the entire section titled "Guidelines for > > for Using a Shadow Member for Backup" would be very useful. > > The usual technique is to quiesce the application (cause it to close its > files), THEN split the shadow-sets. We do something similar with BCVs on > an EMC DMX array. This minimizes your "backup window". Why not... shut the app check that no files are open (except for INDEXF.SYS by the system) dismount the shadows set entirely remount with one less member backup the removed member put the removed member back in the save set In fact, this is what it says in the manual. (See http://h71000.www7.hp.com/doc/732FINAL/aa-pvxmj-te/aa-pvxmj-te.HTML Performing System Management Tasks on Shadowed Systems, Performing Backup Operations on a Shadow Set Record the time you dismounted the shadow set and use that time with / MODI/SINC=that_time for subsequent incremental backups, or use your method with DFU to update the backup dates of backed up files AEF > > Once upon many moons ago, I developed some code that would take a > BACKUP/LIST file and produce a file list for use with DFU's SET command > such that backup dates could be recorded after a shadow-set split > backup. > > I could probably resurrect that, if needed. It uses SEARCH to reduce the > data to the list of files and EDT in batch(!!) to perform the final > edits and cleanup. The result gets fed to the SET command in DFU: > > $ MCR DFU SET/BACKUP='date' "@filespec" > > Use SET PROC/PRIO=0 before invoking DFU to minimize impact on > production. > > David J Dachtera > (formerly dba) DJE Systems ------------------------------ Date: Tue, 25 Mar 2008 02:11:49 +0000 (UTC) From: moroney@world.std.spaamtrap.com (Michael Moroney) Subject: Re: Please critique my backup practices Message-ID: "John Wallace" writes: >"Michael Moroney" wrote in message >news:fs918n$qf8$1@pcls4.std.com... >> We have heard many time: "Thou shalt not use BACKUP/IGNORE=INTERLOCK". >> But I have an application that runs continuously and doesn't close its >> files, so the alternative is no backup of them. I had the idea of doing >> two incremental backups, the first being a BACKUP/MOD/SINCE=BACKUP/RECORD >> of the disk, and the second being BACKUP/MOD/SINCE=BACKUP/IGNORE=INTERLOCK >> (note: no /RECORD) of the disk. The first is a "clean" incremental backup >> of the disk, and the second, since it is run immediately after the first, >> will contain only open files plus perhaps a few modified very recently. >> It would only be used in emergencies. The lack of /RECORD is so the files >> backed up on the second backup are not considered properly backed up, and >> any file closed before the next pass of incremental backups will be >> properly backed up during the next pass. Comments? >> >What do you know about the relationship between the continuously-running >application's in-memory copy of the file (which the application will see), >and the on-disk copy of the file (which BACKUP will see)? Without that kind >of knowledge, comments on the efficacy of /IGNORE=INTERLOCK are likely >nothing more than speculation (unless the comment is "it's pointless", which >isn't news to you). The application maps data files via $CRMPSC/$MGBLSC and generally forces a writeback ($UPDSEC) when something important changes. The application is homegrown and plays *very* fast and loose with the data, but due to the nature of this beast, that's not as bad as it sounds. ------------------------------ Date: Mon, 24 Mar 2008 20:59:45 -0400 From: Robert Deininger Subject: Re: RX3600 and VMS 8.3 Message-ID: In article , Chuck Aaron wrote: > If anyone is running the RX3660 or better server with VMS 8.3, can you share > your experience and comments. I am considering moving from an Alpha DS25 > running > vms 8.3 to the Itanium. > > Thank you in Advance, > > Chuck The title of your post says rx3600, but the body says rx3660. There's no such thing as an Integrity rx3660 server. You probably meant rx3600, but you might have meant rx2660. Both systems are similar. The rx3600 has more I/O slots and more memory capacity. You might get better advice if you tell us more about your current DS25 system. How many CPUs? How much memory? What sort of I/O adapters? Size and number of disks? Are there any performance bottlenecks on the current system that you'd like to eliminate? Any 3rd-party software dependencies? We recommend V8.3-1H1, not V8.3, on the Integrity servers, unless you have some particular dependence on V8.3. You can order new systems with either version. Both versions interoperate with V8.3 alpha. You should plan for an extra network drop and tcpip address for each Integrity server's Management Processor (MP). This gives the most flexibility. (Access via serial port is also possible.) The MP provides system monitoring and control (power control, hardware status logs, etc.) as well as console access to the EFI shell and OPA0: on VMS. It's like the SRM console on an Alpha system, with the added benefit of network access, multiple simultaneous connections, and (limited) web access. If you have clusters now, you can add Integrity servers to your existing cluster to ease migration. If you don't have clusters, I believe there is a migration program that can provide you temporary cluster licenses, for both the old and new system, at no cost. (I don't have any ordering information for this.) -- Robert (rx3600 project leader for OpenVMS) ------------------------------ Date: Mon, 24 Mar 2008 16:07:04 -0600 From: Keith Parris Subject: Re: Shadow set problem finally solved Message-ID: Keith Parris wrote: > You can overwrite unallocated blocks on the disk (including the ones > with forced-error flags set on them) by simply writing a temporary file > that takes up all the remaining space on the disk. For example: > > $ COPY/ALLOC={#-of-free-blocks-on-disk} _NLA0: disk:[000000]TEMP.FILE > $ DELETE disk:[000000]TEMP.FILE; A friend kindly points out that my suggestion actually only overwrites the data if high-water marking is enabled for the disk, or if high-water marking is disabled, only if you you do: $ SET FILE/END disk:[000000]TEMP.FILE $ DELETE disk:[000000]TEMP.FILE; $ DELETE/ERASE disk:[000000]TEMP.FILE; instead of just the DELETE. Without high-water marking, the COPY/ALLOC only allocates an empty file of the specified size; it does not write data to the blocks. ------------------------------ Date: Mon, 24 Mar 2008 11:53:30 -0700 (PDT) From: rfc2307@gmail.com Subject: Thanx for the assistance wtih VMS security questions in general Message-ID: <39288283-1d6f-4af5-a87f-694ab5af9197@e23g2000prf.googlegroups.com> Good Morning, Thanx to the folks that provided usefull information. Some of your feedback was quite helpfull, and much appreciated. My requirements for research were fairly broad: (1) The capability to generate and compare mathematical hash's of files and/or directories; (2) the ability to store system specific configuration meta-data and compare; (3) the ability to store ACL meta-data and compare. Exactly WHAT files, directories, etc...to monitor and comply with the requirements against was not specified. Thus my questions. "TripWire" (to the best of my understanding) is both a commercial product offering, and a SourceForge Open Source tool that has the capability of computing, storing and comparing a mathematical hash of a file, directory of BLOB object. Not so many thanx to the folks that superior attitude, thinly veiled as knowledge. It is this behavior that gives the technologist such a bad reputation to the business side of the house. ------------------------------ Date: 24 Mar 2008 16:45:12 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: Thanx for the assistance wtih VMS security questions in general Message-ID: In article <39288283-1d6f-4af5-a87f-694ab5af9197@e23g2000prf.googlegroups.com>, rfc2307@gmail.com writes: > Thanx to the folks that provided usefull information. Some of your > feedback was quite helpfull, and much appreciated. My requirements > for research were fairly broad: (1) The capability to generate and > compare mathematical hash's of files and/or directories; (2) the > ability to store system specific configuration meta-data and compare; As you saw from the checklists at the URLs I posted, LJK/Security does those two steps. > (3) the ability to store ACL meta-data and compare. Exactly WHAT > files, directories, etc...to monitor and comply with the requirements > against was not specified. Thus my questions. Devising general rules for ACL contents is a tough task, whereas simply recording the values and looking for changes is trivial (SHOW SECURITY/OUTPUT=, followed by DIFFERENCES ). What files are worthy of your consideration depends entirely on the use to which the target system is put. For a production system, hashes of all executable image should remain invariant as should hashes of all command procedures. For a development system, that would be an intolerable set of rules. But looking for changes in files is really useless on a VMS system unless you have first taken care of all the possible configuration errors that might enable an unauthorized person to make changes. > "TripWire" (to the best of my understanding) is both a commercial > product offering, and a SourceForge Open Source tool that has the > capability of computing, storing and comparing a mathematical hash of > a file, directory of BLOB object. I have never heard of someone using that on VMS. Perhaps someone else has. ------------------------------ Date: Mon, 24 Mar 2008 20:57:44 GMT From: John Santos Subject: Re: Thanx for the assistance wtih VMS security questions in general Message-ID: rfc2307@gmail.com wrote: > Good Morning, > > Thanx to the folks that provided usefull information. Some of your > feedback was quite helpfull, and much appreciated. My requirements > for research were fairly broad: (1) The capability to generate and > compare mathematical hash's of files and/or directories; (2) the > ability to store system specific configuration meta-data and compare; > (3) the ability to store ACL meta-data and compare. Exactly WHAT > files, directories, etc...to monitor and comply with the requirements > against was not specified. Thus my questions. > > "TripWire" (to the best of my understanding) is both a commercial > product offering, and a SourceForge Open Source tool that has the > capability of computing, storing and comparing a mathematical hash of > a file, directory of BLOB object. > > Not so many thanx to the folks that superior attitude, thinly veiled > as knowledge. It is this behavior that gives the technologist such a > bad reputation to the business side of the house. > Since you explained exactly none of this in your original post, I think the superior attitude was entirely appropriate. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Mon, 24 Mar 2008 17:29:38 -0400 From: "Richard B. Gilbert" Subject: Re: Thanx for the assistance wtih VMS security questions in general Message-ID: <47E81D42.8030403@comcast.net> John Santos wrote: > rfc2307@gmail.com wrote: > >> Good Morning, >> >> Thanx to the folks that provided usefull information. Some of your >> feedback was quite helpfull, and much appreciated. My requirements >> for research were fairly broad: (1) The capability to generate and >> compare mathematical hash's of files and/or directories; (2) the >> ability to store system specific configuration meta-data and compare; >> (3) the ability to store ACL meta-data and compare. Exactly WHAT >> files, directories, etc...to monitor and comply with the requirements >> against was not specified. Thus my questions. >> >> "TripWire" (to the best of my understanding) is both a commercial >> product offering, and a SourceForge Open Source tool that has the >> capability of computing, storing and comparing a mathematical hash of >> a file, directory of BLOB object. >> >> Not so many thanx to the folks that superior attitude, thinly veiled >> as knowledge. It is this behavior that gives the technologist such a >> bad reputation to the business side of the house. >> > > > Since you explained exactly none of this in your original post, I > think the superior attitude was entirely appropriate. > I think it would have been approriate to provide this link: How To Ask Questions The Smart Way http://catb.org/~esr/faqs/smart-questions.html ------------------------------ Date: 24 Mar 2008 16:29:51 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: Tripwire on OpenVMS Best Practices? Message-ID: In article , tadamsmar writes: > On Mar 22, 6:14=A0pm, Kilgal...@SpamCop.net (Larry Kilgallen) wrote: >> In article <75da0787-9aa4-4eef-96eb-8d9ae220f...@s8g2000prg.googlegroups.c= > om>, rfc2...@gmail.com writes: >> >> > Good Morning, I'm looking for any information on best practices on >> > what to monitor, that is Operating System specific on the OpenVMS >> > platform. =A0Any information or lessons learned would be appreciated. >> >> Your use of the term "Tripwire" in the title is not clear, >> but for the body of your post, consider: >> >> =A0 =A0 =A0 =A0http://www.ljk.com/ljk/checklists.html >> > > Why are thos checklists .COM files? Because they are primarily created for use with the LJK/Security tool that reads the commands and tests the system to see if it is configured in a secure fashion. The checklists express that notion of security in terms used by NIST Special Publication 800-53, but that is a good general use document. If you insist on having a checklist that is totally in prose format, there is one at http://iase.disa.mil/stigs/checklist/openvms-srrchklst-v2r2-3.zip but in my highly biased opinion it does not represent a good rendition into the VMS environment of the actual needs are for security according to DoD Instruction 8500.2. Of course if you are subject to DoD Instruction 8500.2, adhering to that DISA list might be important, but people in such circumstances already knew that. The corresponding LJK/Security checklist for use with DoD Instruction 8500.2 is not public. ------------------------------ End of INFO-VAX 2008.169 ************************