VOTE NOW for VistA Standard Base (VSB) <base-dir>

[Ignacio Valdes]

Please vote now on this below. A major decision before this community
is the base directory for a VSB installation. Many have been proposed
and there has been much discussion on this. It is desired by
management tool creators that this reside in a specific, appropriate
sub directory of Linux according to this:
http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard and other
LSB documentation. Choosing a preference for <base-dir> rather than
multiple locations gives valuable feedback for management tool writers
and ease of understandability. Therefore pick your first and second
preferences. Answers like 'Some' or 'All' or 'None' does not help to
improve the standard so do not vote in this manner if you do not have
a preference. Voting can be done publicly to this list or privately,
anonymously to Nancy Anthracite. Do a 'view profile' on Nancy
Anthracite's profile to obtain her email and register your vote
privately to Nancy Anthracite.

Here is a summary of the arguments for and against each place for a
VSB installation to reside:
1) <base-dir> scenarios:
1.1) /opt - Pros: simple, brief, understandable. Cons: May be less
robust if not split across physical devices, may not strictly
adhere to Linux Standard Base.
1.2) /var/opt - Pros: Strict adherence to Linux Standard Base,
possibly more robust with splitting across physical devices.
Cons: More complexity, more difficult to create management
tools, more difficult to understand.
1.3) /opt/mumps - Pros: All mumps applications in one place. Cons: All
mumps applications in one place.
1.4) /home/<userid> - 'Single-user mode' Pros: Possible security
advantages and some understandability. Cons: Variable location, less
organized.
1.5) /srv - Pros: The new thing. Cons: Doesn't already exist on some
distributions.

VOTE:

Please indicate your preference for Base Directory <base-dir> for
VistA Standard Base Specifications/Guidelines Version 0.9
a) /opt/mumps
b) /opt
c) /var/opt
d) /srv
e) /home/<userid>

Again, answers like some, all or none are not helpful, simply do not
vote if you have no preference.
1st choice for preferred directory (answer only with one): ____
2nd choice for preferred directory (answer only with one): _____

Proposal for VistA Standard Base (VSB) Specification/Guidelines
Version 0.9 Release Candidate 1

Purpose: To enable and facilitate the creation of standard VistA
management methods and tools for machines that contain approximately 1
to 10 instances of VistA on the same machine.

Caveats: If more efficient utilization of disk space and greater
uptime during gtm update per instance is desired such as for a
Application Service Provider(ASP) type installation please see the
VistA ASP Base(VAB) specification:
http://docs.google.com/View?docid=dd5f3337_232jhhvdvdj

Attempted completion date: 01/30/2009, aka pull the bandaid off as
quickly as possible.

Changes: Added language and referral to VistA ASP Base(VAB)
specification for more efficient disk space use.

Simple Install:

/opt/lsb-gtm/<version>_<platform> # default for gtm,
owned by bin, all uppercase routines.
/<base-dir>/<branding>vista/<instance>
/<base-dir>/<branding>vista/<instance>/doc # all documentation resides here.
/<base-dir>/<branding>vista/<instance>/g<lobals> # Can be a mount
point to a different physical device.
/<base-dir>/<branding>vista/<instance>/web # Future web items.
/<base-dir>/<branding>vista/<instance>/backup # Can be mount
point. Backups that are not journals.
/<base-dir>/<branding>vista/<instance>/j<ournals> # Can be a mount
point to a different physical device.
/<base-dir>/<branding>vista/<instance>/r<outines> # Usually mumps
routines, see additional heirarchy 13) below
/<base-dir>/<branding>vista/<instance>/etc # Version, release
and other configuration information.
/<base-dir>/<branding>vista/<instance>/etc/vista.conf # contains
version, release and other config information.
/<base-dir>/<branding>vista/<instance>/etc/patch_listing.txt #
Optional listing of patches for this instance.
/<base-dir>/<branding>vista/<instance>/o<bjects> # Object files.
/<base-dir>/<branding>vista/<instance>/images # Can be mount point
for patient photos, scanned documents.
/<base-dir>/<branding>vista/<instance>/env # for gtm/VistA
environment variables.
/<base-dir>/<branding>vista/<instance>/bin # for server controller
type software.
/<base-dir>/<branding>vista/<instance>/bin/run # Bhaskar'sconvention,
run an instance.
/<base-dir>/<branding>vista/<instance>/bin/vistastart # Bhaskar's convention.
/<base-dir>/<branding>vista/<instance>/bin/vistastop # Bhaskar's convention.
/etc/init.d/vista-<instance> # Automatic start stop startup
handling. Bhaskar's convention.
/etc/xinetd.d/vista-<instance> # setup listening port for
client such as CPRS for <instance>.

Where:

<base-dir> -- Preferred base-dir default to be voted on about Friday.
Can be /opt, /var/opt, /opt/mumps as well as 'single-user' mode
/home/<userid>, /opt/mumps (see 1 below)
<branding> -- 'world', 'open', 'vx' etc, MUST be preceeded or followed
by 'vista' as in <branding>vista.
<instance> -- can be multiple instances. Parent and child instances
via symlink okay. See 4) below for default names.
g<lobals>, r<outines>, o<bjects>, j<ournals> are defaulted to g, r, o
with full name available only if the vista release supports it.

1) <base-dir> scenarios:
1.1) /opt - Pros: simple, brief, understandable. Cons: May be less
robust if not split across physical devices, may not strictly
adhere to Linux Standard Base.
1.2) /var/opt - Pros: Strict adherence to Linux Standard Base and with
splitting across physical devices, possibly more robust.
Cons: More complexity, more difficult to create management
tools, more difficult to understand.
1.3) /opt/mumps - Pros: All mumps applications in one place. Cons: All
mumps applications in one place.
1.4) /home/<userid> - 'Single-user mode' Pros: Possible security
advantages and some understandability. Cons: Variable location,
less organized.
1.5) /srv - Pros: The new thing. Cons: Doesn't already exist on some
distributions.

2) Good practice for /backup and j<ournals> is that they should be
symlink or a mount point on a different physical media. Directories
that can be mount points are:
a) /<base-dir>/<branding>vista/<instance>/g<lobals>
b) /<base-dir>/<branding>vista/<instance>/backup # Backups that
are not journals.
c) /<base-dir>/<branding>vista/<instance>/j<ournals> # Can be a mount
point to a different physical device.
d) /<base-dir>/<branding>vista/<instance>/images # Can be mount
point for patient photos, scanned documents.

3) Default port for clients such as CPRS listening: 9260 Production,
9261 Training, 9262 Development

4) Defaults names for <instance>: production, training, development,
<customer name>

5) All documentation explicitly converted from Microsoft format cr/lf
to Unix/Linux format before posting to

6) Standard use of tar.gz format for bundling of files and residing on
Sourceforge.

7) Default user id: vista, default group id: vista

8) /var/log for logs

9) /tmp for temp files

10) Use /etc/skel and /etc/profile.d for global environment settings
where appropriate.

11) Use the suffix .sh on scripts that are shell scripts.

12) GT.M journal files are written to the j<ournals> directory.

13) If supported by VistA release, additional r<outines>
subdirectories first proposed by J. Tai with modifications:

The routines directory contains MUMPS routines (.m files). No
routines are stored in the routines directory itself; the routines
are stored in subdirectories that reflect the origin of the routine.

/<base-dir>/<branding>vista/<instance>/r<outines>/development
/<base-dir>/<branding>vista/<instance>/r<outines>/hotfixes
/<base-dir>/<branding>vista/<instance>/r<outines>/customer
/<base-dir>/<branding>vista/<instance>/r<outines>/vendor
/<base-dir>/<branding>vista/<instance>/r<outines>/foia

Where:
* development – code that is under development; this directory
should always be empty in production environments
* hotfixes – code not yet part of any Kernel Installation and
Distribution System (KIDS) build or other distribution
* customer –code that is part of a customer-specific KIDS build
* vendor – code from third-party vendors, e.g., the Victory
Programming Environment
* foia – unmodified code from the U.S. Department of Veterans Affairs (VA)
* version_patch_info -- Information on versions and patches on the system.

[ival...@gmail.com]

My vote:

Please indicate your preference for Base Directory <base-dir> for
VistA Standard Base Specifications/Guidelines Version 0.9
a) /opt/mumps
b) /opt
c) /var/opt
d) /srv
e) /home/<userid>

Again, answers like some, all or none are not helpful, simply do not
vote if you have no preference.

1st choice for preferred directory (answer only with one): __b) /opt_
2nd choice for preferred directory (answer only with one): _c) /var/
opt__

Thank you for playing!

[Greg Woodhouse]

I vote none of the above, but of the available choices /opt is the only one that really makes sense. If it were up to me, I would "opt" for /usr/local/gtm or even /usr/gtm and place it on a separate filesystem.

[fred trotter]

/opt/

--
Fred Trotter
http://www.fredtrotter.com

[David Whitten]

I tend to think that the "root" of a VistA configuration should be in
an environment variable,
set by the config program, but if I have to vote, I'd vote for /opt
so that our common files
are stored in the same place that the other Linux systems use. I'm
sensitive to the fact
that Bill Ackerman has consistently suggested /mumps, and think he has
compromised
to agree to /opt/mumps. Perhaps the suggestion previously of using
some kind of Linux
configuration tool to define the base directory would make more sense.

That being said, I think that the files for the VistA system don't
really follow the model of
MySQL, Oracle etc. We have three levels when many people have only two:
the general case is that you don't have access to the programming language from
within the database system, so they have the compiled database system
and the applications
written to use the database system. From the Linux perspective, we
have the programming
language and the the database. The fact that VistA provides a virtual
operating system
(the VA Kernel) and applications within that system is usually opaque
to most Linux programs.
The idea of exposing the information inside the MUMPS system as a user mode file
system is very attractive, as it allows the true applications (Lab,
Pharmacy, etc) to be visible.

My two farthings worth,
Dave

[Jonathan Tai]

On Thu, 2009-01-29 at 13:50 -0800, Ignacio Valdes wrote:
> Please indicate your preference for Base Directory <base-dir> for
> VistA Standard Base Specifications/Guidelines Version 0.9
> a) /opt/mumps
> b) /opt
> c) /var/opt
> d) /srv
> e) /home/<userid>

While it does not strictly adhere to the FHS, I think /opt (without
moving globals and journals to /var/opt) is the simplest. In terms of
the FHS, I personally feel that /srv is better, but given that GT.M and
Mirth both install to /opt by default, it would probably be best to have
OpenVista default to /opt as well. Internally we've been using /opt, so
it's what we're used to, anyway. (I didn't read up on /srv until
someone here mentioned it.)

- Jon

[Brian Lord]

I vote for /opt/mumps to keep things in line but separate

[William Ackerman]

I vote the /opt/mumps

--
Bill Ackerman
bill...@gmail.com
Illegitimi non carborundum

[st...@stevenowen.com]

/opt/mumps for me as well.

[ssw0213]

1) /opt
2) /opt/mumps

Reasoning:

a) /opt/mumps as a base for VistA would mean putting the VistA core
AND the GT.M platform both in the ./mumps subdirectory. Since VistA is
an application engine and GT.M is a platform, and the two are
maintained by entirely different groups, it would seem odd to put them
both inside ./mumps. True, VistA is written in Mumps language, but I
think of them as parallel, or better yet "stacked": VistA-GT.M-Linux.
My mind thinks of "VistA" as what I'm working on, so that's the first
thing I want to see if I'm looking for something inside /opt.

b) Therefore I'd prefer to see (and Dr. X from Outer Mongolia also to
see) something like this:

~$ cd /opt
~/opt$ ls
lsb-gtm worldvista

c) I respectfully (emphasize that again: *very respectfully*) disagree
with Brian, Bill, and Steven on their preference for /opt/mumps. They
have deep experience with VA VistA, and perhaps they foresee some
serious axle-breaking potholes ahead if we go down the /opt road.
Nevertheless, I don't want to confuse the otherwise-computer-savvy
newcomer to VistA.

d) I still see myself as knowing just enough to cause trouble. But my
thinking lines up better with Fred, David, and Jonathan, who do have
more experience than I, and prefer /opt.

e) Finally, a word about personalities. "It's all about people", I say
-- life is, code is, computer networks, application development, you
name it. But once we get through grinding up against each other's
egos, I expect we will have something we can report out with NPOV
(Neutral Point Of View): we can say "we agreed to this standard".

Thanks to all for your input to this process.

--Steve

[Roy Gaber]

/opt/mumps

Timeless

[Fernando Telesca]

Please, get rid of "mumps" word. I love it, but the world doesn´t.

Sorry

> >> Dave- Ocultar texto entre aspas -
>
> - Mostrar texto entre aspas -

[Smith, Todd]

/opt 1st
/srv 2nd

Todd Smith

Confidentiality Note: The information contained in this message
may be privileged and confidential. If this e-mail contains
protected health information, you are hereby notified that any
dissemination, distribution or copying of this communication is
strictly prohibited,except as permitted by law. If you have
received this communication in error, please notify the sender
immediately by replying to this message and deleting it from your
computer. Thank you.