On 07/14/2012 01:38 PM, Luis Ibanez wrote:
On Sat, Jul 14, 2012 at 12:10 PM, Andreas Tille <[email protected]
<mailto:[email protected]>> wrote:
I confirm that the questions Nicolas Barbier has asked in his replay to
your mail are the same questions which are somehow bothering me as well
(so I will not repeat these here).
> /var/lib/vista/
> /var/lib/vista/r
> /var/lib/vista/o
> /var/lib/vista/g
> /var/lib/vista/j
> /var/lib/vista/logs
> /var/lib/vista/inetd
> /var/lib/vista/profile
>
>
> The directories "j" and "logs" were added during the Code Convergence
> conference call last Thursday, to accommodate for Journaling and
Logs.
There is no precedence for storing Journals as far as I know
Ok, I'll ignore the Journaling by now,...
Maybe Bhaskar can advise on what is
the right thing to do with that directory.
[KSB] I am puzzled as to the lack of precedents for journals in Debian,
but OK.
Like many database engines, GT.M writes information to a journal file as
well as to a database file. In the event of a system crash, GT.M uses
the journal files to recover the database file. On large systems, it is
traditional to put the journal file for a database file on a different
hard drive, and even a different controller. In the default
installation, the "gtm" script simply puts the journal file for the
single database file in the g/ subdirectory of the version specific
subdirectory, e.g., V5.5-000_x86_64/g/, and that's what I recommend for
the Debian package.
but
regarding the logs, I'd definitely move these to
/var/log/vista
Ok,
I just did this.
We now have
/var/log/vista
/var/log/vista/inet
[KSB] Since we are talking about GT.M log files and since GT.M processes
may run processes other than VistA processes, I suggest something like
/var/log/fis-gtm/<gtmver>/
and this could be "hidden" from the VistA code by a simple
ln -s ../../log/vista /var/lib/vista/logs
Since all these directories are pointed to by environment variables,
we don't quite have to put them under /var/lib/vista, and therefore,
I'm placing them directly where Debian policies will guide us to put
them. So,... the good news is that we won't need the symbolic links.
We just need to make sure that we set the environment variables
to point to the new locations of these directories.
[KSB] Yes
to fake your suggested directory layout (which is OK in principle).
> The inetd directory hosts two files with configuration for CPRS /
xinetd.
Uhhmmm, please don't put configuration outside /etc! Also here the
solution will be something like
/etc/vista/inetd
ln -s /etc/vista/inetd /var/lib/vista/
or something like this.
Ok,
The configuration file is now going to:
/etc/xinetd.d
the full path is :
/etc/xinetd.d/cprs_vista_xinetd
The other file is the shell script that plays the role of a callback when
a user of CPRS (the GUI client) talks to the port (9430 in this case).
That shell script triggers a VistA routine via gtm commands.
This shell script is now in
/var/lib/vista/inet
and it is called:
/var/lib/vista/inet/cprs_vista_rpcbroker.sh
it probably should be associated with the user rather than being in
a system wide location. Particularly because it sets the environment
variables that, as Bhaskar pointed out in on of his recent emails,
define the tree-like environment.
(I'll revisit this...)
[KSB] Since the desired VistA environment cannot be determined by xinetd
(e.g., from the IP address- a user connecting from the same client may
want to connect to different environments), each VistA environment is
likely to be listening at a different port.
> The profile directory host an example profile file, that a user
could copy
> to set up the environment with the proper environment variables
pointing
> to the VistA instance.
Examples should rather go to
/usr/share/doc/vista
Ok,
I just did this with auto_install...
We now have:
/usr/share/doc/vista/vista_profile
and you can use dh_installexamples to do so.
and now I'm reading on how to do it with dh_installexamples,
that definitely looks cleaner.
Please use the file
debian/README.Debian to explain what the user is supposed to do
with the
examples.
Yes,
I added some instructions to README.Debian,
along the lines of "what to do just after you installed the vista package".
It makes me think that we should add more of a 101 Tutorial
in the directory:
/usr/share/doc/vista
Something like
/usr/share/doc/vista/GettingStartedWithVistA.txt
intended for full beginners that are prospective developers.
I'll see what I can put together....
> If I'm following correctly, it seems that we should have in this
path the
> version name/number of the fis-gtm that was used to create the
instance.
>
> Maybe something like:
>
> /var/lib/vista/V5.5-000_x86_64
> /var/lib/vista/V5.5-000_x86_64/r
> /var/lib/vista/V5.5-000_x86_64/o
> /var/lib/vista/V5.5-000_x86_64/g
> /var/lib/vista/V5.5-000_x86_64/j
> /var/lib/vista/V5.5-000_x86_64/logs
> /var/lib/vista/V5.5-000_x86_64/inetd
> /var/lib/vista/V5.5-000_x86_64/profile
>
>
> Would this make sense ?
Yes as far as it regards the version number. I do not really see the
need of specifying the architecture here and would rather drop this.
What I wrote above with the unversioned dir should be easily applicable
to the versioned dir.
Sounds reasonable, and easy to do.
I'll take a crack at this directory renaming,
as soon as I get CPRS to work with the
installed package.
[KSB] Please do use the architecture when specifying GT.M release
specific subdirectories. GT.M users occasionally install 32- and 64-bit
flavors of the same GT.M release on a 64-bit system computer, and they
are different.
Regards
-- Bhaskar
Thanks
Luis
--
GT.M - Rock solid. Lightning fast. Secure. No compromises.
_____________
The information contained in this message is proprietary and/or confidential.
If you are not the intended recipient, please: (i) delete the message and all
copies; (ii) do not disclose, distribute or use the message in any manner; and
(iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by persons
other than the intended recipient. Thank you.
