On 07/14/2012 01:38 PM, Luis Ibanez
wrote:
On Sat, Jul 14, 2012 at 12:10 PM, Andreas
Tille <andreas@an3as.eu>
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
--
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.
|