CD-ROM media to check relocatable content
Brought to you by:
gerbier
Menu
▾
▴
#7 CD-ROM media to check relocatable content
I would like to be able to write AFICK, Perl, the afick database, and the afick configuration file to a CD-ROM and use a copy of the CD to check file content on other similarly configured machines. I would check only files/directories we create, not operating system files/dirs. The goal is to allow personnel in remote locations to compare some static content on each remote machine to a baseline which was created on a known secure machine, even if the remote machine has those files installed in a different directory than the original machine. Have you ever considered providing an option to write the db using unexpanded environmental variables instead of hard-coded full pathnames and to allow afick -k to substitute a new local value for that environmental variable? Any insights would be appreciated.
there are not so many hard-coded pathnames, and all should be configured from afick config file ( I use this feature to test development code)
you may provide a script check.sh which contains
perl ./afick.pl -k -c afick.conf
with in afick.conf :
database := ./base/your_base
history := ./base/history
archive :=
to my mind, the main problem will be to have a full perl with all modules on the CD
An example of what could be done to the dbm
Your tip to use dot-slash naming for database and history locations in conf file was very helpful. Here is a further clarification of the issue. The dbm that gets written still has full hardcoded pathnames reflecting where the files live on the current server (my PC). However, the remote machines I want to check with media may have had those files installed in other dirs. Let's imagine that outside of afick I can modify the dbm keypairs so that, instead of full pathnames from my machine, the keys now show an environmental variable. A sample line from afick -p now looks like below (pardon the line breaks; this is one line extracted from afick -p and is for a file named interpreter.zip):
file $ENV{MYINSTALLDIR1}/interpreter.zip|53ccc751ebc4ebe6363f396e3ebfa610|0|0|100666|0|0||16231436|0|0|0|0|0|0|
My question is: Can you suggest a way I could modify afick so that when afick -k is run on the remote machine with the cd-rom mounted, the value of the environmental variable --as currently set on the remote machine --would get substituted into the check? . Whether or not you can help, I want to say thanks for your prompt responses to my recent posts.
afick convert relative path to full path when it checks for afick changes.
there is a way to have it work . Say the cdrom mount point is /media/cdrom.
You will prepare on your server : perl, afick, database on this directory, then build the iso and the cd-rom
the database will contains path from /media/cdrom
other idea will need change in afick code : add an option to remove afick control, or use environment variables
hello
I have a beta code, which allow relative path for afick scripts and database.
Do you want to test it ?
Hi. I certainly didn't expect this! I would like to test the beta as much as I can. Here's where I have a limitation. Right now, I'm using a copy of afick.pl I revised so that it does NOT write data about afick programs or the db files to the database. In order to continue with my work, in the new beta version I think I'll ultimately have to comment out the part that inserts info about <dbm> and <dbm>.ctr into the database. The reason is that I cannot write the database to the cd-rom in the final form because I don't know where people at the remote sites have installed the files being checked. So, I'm allowing afick to create the database on the originating (trusted) server. It creates a database containing full pathnames for the keys. I then use a perl script to modify the database to change full pathnames to references to environmental variables. It's that modified version of the database referencing env. var. that will get written to CD-ROM. At the remote site, the person using afick will have to copy that <dbm> and <dbm>.ctr files from CD-ROM to a temporary location on the hard drive, then execute another perl script I provide that substitutes in the local values of the env vars. Since I cannot use afick to check the integrity of the modified database, the operator at the remote site will have to re-create the dbm using the CD-ROM and the extra script each time the verification is done. :-(
Let me know how I can obtain the beta version. Can it be posted on sourceforge or do you need an e-mail address?
Again, thanks a bunch. I'm learning a lot about perl by looking at your code and using online references, but I am unable to see how to make extensive changes in afick.pl to do what I need, and that is why I am using extra scripts.
to my analysis, there is 2 different path problems :
- path for afick script, config and database (on cdrom)
- path for relocatable files on hard disk
for the fisrt, I will add an option to allow relative path (instead absolute path)
for the second, my idea is to use a "chroot-like" feature : store path relative to a new root directory. This will be an environment variable.
this should be easy to code (the first is done), and be ready next week for tests.
Does it match your needs ?
I'm trying to understand your idea. Would the entries in the database just have an additional variable reference pre-pended to the FULL pathname? Or, would the existing environmental variables on the system where afick -i is run be taken into account? I need the latter. To give a unix-like example, let's say I use an environmental variable $MYDIR to refer to /opt/ABCorporation/folio1 and I use $MYDIR in the afick config file. If the files in $MYDIR are file1 and file2, I would need for the lines in the database to be written as $MYDIR/file1 and $MYDIR/file2 so that when the CD is used on another system where $MYDIR refers to something else -- for example, /usr/folio1-- then the checks would still work and would be looking at /usr/folio1/file1 and /usr/folio1/file2. I do not have the freedom to dictate to the users who run the remote machines they must install file1 and file2 in some full pathname that ends in opt/ABCorporation/folio1.
I will need to check with other people here, but, unfortunately, I think I may also have cases where the afick config file will have to refer to multiple environmental variables, all of which could have different values on the remote machine than they have on the machine where the database was initialized. I think I may not be able to assume that all the content I want to check will have a single parent directory, so that's where the "chroot" concept breaks down in my mind. I will post again once I have that aspect confirmed.
Thanks!
A follow-up to my last post.: It is NOT a big problem if we must be limited to just one starting directory -- i.e. one environmental variable.
I tried to patch afick to use several environmental variable, but is very difficult. The first release will only allow one directory relocation. The code is almost ready (in test). Send me your email adresse (to gerbier@users.sourceforge.net), so I can send you the code for your tests (a Readme will be provided)
the result is cdafick : a new packaging around afick dedicated to check with a CD