Re: [Hardhats] Astronaut VistA Installers for Linux Beta 0.8-1 {astro-defaults ignored}

[JohnLeo Zimmer]

Has anyone had experience with the /astro-defaults feature of this
version of Astronaut?

In my hands
# dpkg -i astronaut-wv-server-beta-0.8.1.deb
ran but entirely ignored my /astro-defaults

GpZ


On Wed, Nov 4, 2009 at 3:27 PM, Ignacio Valdes <iva...@hal-pc.org> wrote:
>
> Astronaut VistA Installers for Linux Beta 0.8-1 (Tranquility base)
>
> Description: Installs WorldVistA EHR/VOE 1.0 via rpm (Fedora/RedHat)
> or dpkg (.deb file Ubuntu/Debian)
>
> Downloads: http://sourceforge.net/projects/worldvistaautoi/files/
>
> Changes: MSC Fileman 1036 has been installed for all you
> internationalization fans. Bug fix for incorrect gtm_log subdirectory
> in env, now reads: export gtm_log="$vista_path/log", removed stale ewd
> references that where causing backup problems. Taskman starts on
> install again. Overlooked VistA Standard Base $vista_path/images
> subdirectory is now created by default.
>
> Default ID's and passwords: System Linux id for an instance now follow
> the VistA Standard Base spec of <branding>vista<instance> to avoid
> conflict and allow multiple instances to run side by side. For example
> worldvistaEHR is the default Linux id for rpm install with password
> vista!123. The default VistA id is sys.admin vista!123.
>
> Author: Ignacio Valdes <iva...@hal-pc.org>
>
> Contributors of code, modules or other in Alphabetic order (Ommitted?
> Don't want to appear? Let me know.)
>
> Individuals:
> Anthracite, Nancy -- Original install document, general knowledge.
> Bodtke, Peter -- Testing, documentation.
> Bhaskar, KS -- GT.M, Acculturation documentation, architecture, shell scripts.
> Dorsey, Jon -- VistA Standard Base co-proposer.
> Hagood, Eddie -- TMG-GUI-Config and fixes, change_av.sh
> Habiel, Sam -- BMX functionality, GUI-Scheduling.
> Landis, "Gus" -- VistA Standard Base co-proposer.
> Noorden, Lars -- Mupip man page.
> Meiling, Ben -- VistA Standard Base co-proposer.
> Papillion, Anthony -- VistA Standard Base co-proposer.
> Pardue, Andy -- OVID.
> Self, Jim -- m2web
> Tai, Jonathan -- GT.M knowledge, VistA Standard Base, rpm wizardry.
> Timson, George -- Pointed out IHS fix for SSN problem.
> Toppenberg, Kevin -- TMG-CPRS, TMG-GUI-Config, TMGIDE, general knowledge.
> Trotter, Fred -- VistA Standard Base co-proposer.
> Trotter, Rick -- Assistance with Launchpad.
> Watson, Steve -- Testing, documentation, VistA Standard Base co-proposer.
> Whitby, Butch -- Testing, , VistA Standard Base co-proposer, Misc.
> Whitten, David -- Global expertise, debugging, architecture, IPv6 patch.
>
> Corporations:
> FIS -- GT.M
> Medsphere Systems Corp -- OVID, Other.
> M/Gateway Developments Ltd -- EWD
> WorldVistA -- Processed FOIA VistA/VOE.
>
> Government:
> Indian Health Service -- BMX, scheduling GUI.
> Veterans Affairs -- FOIA VistA.
>
> Problems, comments, bugs: Post problems or issues to the Hardhats
> group: http://groups.google.com/group/Hardhats or to
> <iva...@hal-pc.org>
>
> License: Installer: Affero GNU GPL version 3. No warranties expressed
> or implied, use at your own risk. (see WorldVistA license below)
>
> This installer has been tested on Fedora 10 and Ubuntu 9.
>
> To install on rpm based systems, log in as root:
>
> # yum install -y --nogpg astronaut-<version info>.rpm
>
> Will install all depencencies and then the rpm or somewhat independently:
>
> # rpm -i astronaut-wv-server-installer-XXX-0.X-X.i386.rpm
>
> IT IS NORMAL TO SEE A BUNCH OF ERROR MESSAGES DURING COMPILATION.
>
> To uninstall:
>
> # rpm -e astronaut-wv-server-installer-XXXX-0.X-X
>
> (NOTE: the absence of .i386.rpm for uninstalling)
>
> To install on .deb, dpkg apt-get based systems, use sudo or sudo su to
> log in as root:
>
> # dpkg -i astronaut-wv-server-installer-XXXX_0.X-0.X.deb
>
> IT IS NORMAL TO SEE A BUNCH OF ERROR MESSAGES DURING COMPILATION.
>
> To uninstall:
>
> # dpkg -r astronaut-wv-server-installer-XXXX_0.X-0.X.deb
>
> You can over-ride the default installation parameters: location, port,
> etc by creating a file called astro-defaults in /, (rpm apparently can
> only find it in /). You should probably only try to change the default
> vista_instance but all changeable defaults are:
>
> gtm_path="/opt/lsb-gtm/gtm"
> export gtm_dist=$gtm_path
> gtm_group="gtm"
> #gtm_path="/opt/lsb-gtm/V5.3-004A_i686"
> vista_instance="EHR"
> vista_path="/opt/worldvista/$vista_instance"
> VISTAUSER="worldvista$vista_instance"
> VISTAUSER_PASSWD="vista!123"
> VISTAGROUP="worldvista$vista_instance"
> TEXTUSER="text$vista_instance"
> TEXTUSER_PASSWD="not#1sostrong"
> instance_client_port=9260
> vista_port_old_rpc=9210
> vista_port_vistalink=8002
> astro_vers_release="0.7.5"
> gtm_vers_release="V5.3-004A"
>
> Alter the above parameters as desired before running the rpm and it
> will override the above defaults.
>
> Follow the next steps after the rpm install has run. This gets you to
> the point of being able to login as a text or CPRS client.  The
> pre-set Access Code is: sys.admin with Verify Code: vista!123. You
> will have to re-set the verify code upon first login. Download the
> Windows client installers which should all work out of the box with
> this server. The pre-set Linux id is worldvistaEHR password is
> vista!123 which you will also have to re-set on first login to the
> Linux worldvistaEHR id. To start m2web simply start or restart apache.
>
> Features:
>
> 1) Conforms to VistA Standard Base 0.9 RC 10.
> 2) Quick install.
> 3) Automatically sets BOX:VOLUME pair!
> 4) Creates a text<instance> id, automatically edits, compiles and
> installs Bhaskar's runzu so that text<instance> runs with no shell and
> no home directory.
> 5) Relatively smaller download size 155Mb complete package containing all files.
> 6) Controller software such as vistactl.sh start | stop | restart,
> xinetd listener automatically configured and installed.
> 7) Automatic vista startup with journaling on server start and
> graceful shutdown. Bhaskar's code.
> 8) Automatically opens CPRS port.
> 9) Has a backup solution (some assembly required).
> 10) Latest WorldVistA and gtm V53004A
> 11) Installs /opt/worldvista/EHR
> 12) Creates default vista id automatically.
> 13) Management commands: copy_this_vista_to.sh and
> change_client_port.sh and uninstall_this_vista.sh
> 14) Requires two-factor deletion to really delete an instance. rpm -e
> only removes symlinks to log files, text-client id and auto-start
> routines. Requires explicit rm -Rf to really delete it all. rpm -i
> --force will NOT over-write an existing instance.
> 15) Checks for file astro-defaults and overrides default install
> parameters for different locations for the install.
> 16) Port handling files correspond to worldvista name spaces.
> 17) Pre-installs m2web. Turn off and on SELinux between boots by:
> echo 0 >/selinux/enforce or echo 1 >/selinux/enforce
> 18) Refreshed: Pre-installs Kevin Toppenberg's debugger, see
> http://vistapedia.net for activation.
> 19) Pre-installs EWD (currently broken).
> 20) Pre-installs OVID.
> 21) Pre-installs Victory Programming Environment, see
> http://vistapedia.net for activation.
> 22) MSC Fileman 1036.
> 23) TMG-CPRS support with all associated bug fixes.
> 24) TMG-GUI-Config now supports user management.
> 25) BMX RPC broker and necessary parts pre-loaded.
> 26) GUI-Scheduling components pre-loaded.
> 27) Man page for mupip command.
>
> Caveats:
>
> 1) Beta installer.
>
>
>                WorldVistA EHR /VOE 1.0 Release 6-2008
>
> IMPORTANT FOR ALL PROVIDERS:
>
> All drugs that the provider may need must be entered into the database
> BEFORE THE PROVIDER PRESCIBES THEM from WorldVistA EHR.THE DRUG FILE
> INCLUDED HAS NOT BEEN PREVIOUSLY RELEASED. IT IS ALWAYS IMPERATIVE THAT
> ANY AND ALL DRUG ORDERS AND PRESCRIPTIONS BE CAREFULLY REVIEWED BY THE
> PRESCRIBING PHYSICIAN AND DISPENSING PHARMACIST TO INSURE ACCURACY.   IF
> PROBLEMS ARE FOUND, PLEASE REPORT THEM HERE
>
>        IN...@WORLDVISTA.ORG
>                OR
>        http://trac.opensourcevista.net/worldvistaehr
>
> Please see this link for information about entering new drugs and drug
> doseages:
>
> <http://worldvista.org/World_VistA_EHR/license-and-readme/ReadMe%20-%20Wor
> ldVistA%20Pharmacy%20Drug%20File%202008-01-31.pdf>
>
> Please look for additional information and updates about this release
> here:
>
>  <http://worldvista.org/World_VistA_EHR/license-and-readme>
>
> All portions of this release that are modified from the original Freedom
> of Informtion Act release provided by the Department of Veterans Affairs
> carry the GPL license and are Copyright WorldVistA.  See this URL for the
>
> full text of the license:
>
> http://worldvista.org/World_VistA_EHR/license-and-readme/WorldVistA%20EHR%
> 20GPL%20License.txt
>
> YOU SHOULD CAREFULLY READ THE FOLLOWING TERMS AND CONDITIONS BEFORE USING
> THIS PRODUCT.  DOWNLOADING OR USING ANY PART OF THE SOFTWARE AND
> DOCUMENTATION INDICATES THAT YOU ACCEPT THESE TERMS AND CONDITIONS.  IF
> YOU DO NOT AGREE TO THE TERMS AND CONDITIONS OF THIS AGREEMENT, DO NOT
> PROCEED.
>
>  A.  General Disclaimer.  THE WORLDVISTA-EHR (WV-EHR) SOFTWARE IS
> PROVIDED TO RECIPIENT HEREUNDER "AS IS" AND ANY USE OF WV-EHR SOFTWARE BY
> REQUESTOR SHALL BE AT ITS OWN RISK.  TO THE MAXIMUM EXTENT PERMITTED BY
> APPLICABLE LAW, WORLDVISTA AND ITS CONTRACTORS, EMPLOYEES AND AGENTS
> DISCLAIM ALL WARRANTIES WITH RESPECT TO WV-EHR SOFTWARE, EXPRESS, IMPLIED
> AND STATUTORY, INCLUDING WITHOUT LIMITATION ANY IMPLIED WARRANTIES OF
> MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, ACCURACY,
> COMPLETENESS, TIMELINESS, NON INFRINGEMENT OF THIRD-PARTY RIGHTS, NON
> INTERFERENCE, AND ERROR FREE SERVICE. WORLDVISTA TAKES NO RESPONSIBILITY
>
> FOR MONITORING OR REGULATING THE USE OR ACCURACY OF WV-EHR SOFTWARE.
> RECIPIENT ACKNOWLEDGES AND AGREES THAT WORLDVISTA IS UNDER NO OBLIGATION
> TO VERIFY THE ACCURACY OF OR OTHERWISE UPDATE WV-EHR SOFTWARE OR ANY
> CONTENT CONTAINED THEREIN OR TO NOTIFY RECIPIENT OF ANY INACCURACIES
> THEREIN OR UPDATES THERETO THAT MAY COME TO THE ATTENTION OF OR BE
> DEVELOPED BY WORLDVISTA. WV-EHR MAY BE UPDATED PERIODICALLY, AND IT IS
> THE RESPONSIBILITY OF THE RECIPIENT TO OBTAIN UPDATED VERSIONS OF THE
> WV-EHR RELEASE AS REQUIRED. WORLDVISTA BEARS NO RESPONSIBILITY FOR
> PROVIDING UPDATES TO RECIPIENTS. PASSWORD IS asdTYU
>
>  B.  LIMITATION OF LIABILITY.  TO THE MAXIMUM EXTENT PERMITTED BY
> APPLICABLE LAW, NEITHER WORLDVISTA NOR ANY OF ITS EMPLOYEES, AGENTS OR
> CONTRACTORS SHALL BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL,
> CONSEQUENTIAL OR PUNITIVE DAMAGES, INCLUDING WITHOUT LIMITATION DAMAGES
> FOR LOST PROFITS OR REVENUES, GOODWILL, WORK STOPPAGE, SECURITY BREACHES,
> VIRUSES, COMPUTER FAILURE OR MALFUNCTION, USE, DATA OR OTHER INTANGIBLE
> LOSSES OR COMMERCIAL DAMAGES, EVEN IF ANY OF SUCH PARTIES IS ADVISED OF
> THE POSSIBILITY OF SUCH LOSSES, ARISING UNDER OR IN CONNECTION WITH THIS
> AGREEMENT, COMPLIANCE EFFECTIVENESS STUDY TOOLS, THE USE OF OR INABILITY
> TO USE THE SAME, OR ANY OTHER SUBJECT MATTER HEREOF. IN ADDITION, TO THE
> MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, NEITHER WORLDVISTA NOR ANY OF
> ITS EMPLOYEES, AGENTS OR CONTRACTORS SHALL BE LIABLE FOR ANY LOSS OR
> DAMAGE SUFFERED BY RECIPIENT WHICH ARISES OUT OF OR IN CONNECTION WITH
> ANY INFORMATION OBTAINED BY RECIPIENT VIA OR IN CONNECTION WITH WV-EHR
> SOFTWARE.
>
> >
>

[I, Valdes]

Yes, I just checked and it was still looking for wv-rpm-defaults
instead of astro-defaults. It is fixed in 0.8.2 and will go up
possibly tonight. 0.8.2 will also have a big surprise :-) Stay tuned.
-- IV

On Nov 5, 11:45 am, JohnLeo Zimmer <johnleo...@gmail.com> wrote:
> Has anyone had experience with the /astro-defaults feature of this
> version of Astronaut?
>
> In my hands
> # dpkg -i astronaut-wv-server-beta-0.8.1.deb
> ran but entirely ignored my /astro-defaults
>
> GpZ
>

> On Wed, Nov 4, 2009 at 3:27 PM, Ignacio Valdes <ival...@hal-pc.org> wrote:
>
> > Astronaut VistA Installers for Linux Beta 0.8-1 (Tranquility base)
>
> > Description: Installs WorldVistA EHR/VOE 1.0 via rpm (Fedora/RedHat)
> > or dpkg (.deb file Ubuntu/Debian)
>
> > Downloads:http://sourceforge.net/projects/worldvistaautoi/files/
>
> > Changes: MSC Fileman 1036 has been installed for all you
> > internationalization fans. Bug fix for incorrect gtm_log subdirectory
> > in env, now reads: export gtm_log="$vista_path/log", removed stale ewd
> > references that where causing backup problems. Taskman starts on
> > install again. Overlooked VistA Standard Base $vista_path/images
> > subdirectory is now created by default.
>
> > Default ID's and passwords: System Linux id for an instance now follow
> > the VistA Standard Base spec of <branding>vista<instance> to avoid
> > conflict and allow multiple instances to run side by side. For example
> > worldvistaEHR is the default Linux id for rpm install with password
> > vista!123. The default VistA id is sys.admin vista!123.
>

> > Author: Ignacio Valdes <ival...@hal-pc.org>

> > <ival...@hal-pc.org>

> >http://vistapedia.netfor activation.

> > 19) Pre-installs EWD (currently broken).
> > 20) Pre-installs OVID.
> > 21) Pre-installs Victory Programming Environment, see

> >http://vistapedia.netfor activation.

> > 22) MSC Fileman 1036.
> > 23) TMG-CPRS support with all associated bug fixes.
> > 24) TMG-GUI-Config now supports user management.
> > 25) BMX RPC broker and necessary parts pre-loaded.
> > 26) GUI-Scheduling components pre-loaded.
> > 27) Man page for mupip command.
>
> > Caveats:
>
> > 1) Beta installer.
>
> >                WorldVistA EHR /VOE 1.0 Release 6-2008
>
> > IMPORTANT FOR ALL PROVIDERS:
>
> > All drugs that the provider may need must be entered into the database
> > BEFORE THE PROVIDER PRESCIBES THEM from WorldVistA EHR.THE DRUG FILE
> > INCLUDED HAS NOT BEEN PREVIOUSLY RELEASED. IT IS ALWAYS IMPERATIVE THAT
> > ANY AND ALL DRUG ORDERS AND PRESCRIPTIONS BE CAREFULLY REVIEWED BY THE
> > PRESCRIBING PHYSICIAN AND DISPENSING PHARMACIST TO INSURE ACCURACY.   IF
> > PROBLEMS ARE FOUND, PLEASE REPORT THEM HERE
>

> >        I...@WORLDVISTA.ORG

> >                OR
> >        http://trac.opensourcevista.net/worldvistaehr
>
> > Please see this link for information about entering new drugs and drug
> > doseages:
>

> > <http://worldvista.org/World_VistA_EHR/license-and-readme/ReadMe%20-%2...

> > ldVistA%20Pharmacy%20Drug%20File%202008-01-31.pdf>
>
> > Please look for additional information and updates about this release
> > here:
>
> >  <http://worldvista.org/World_VistA_EHR/license-and-readme>
>
> > All portions of this release that are modified from the original Freedom
> > of Informtion Act release provided by the Department of Veterans Affairs
> > carry the GPL license and are Copyright WorldVistA.  See this URL for the
>
> > full text of the license:
>

> >http://worldvista.org/World_VistA_EHR/license-and-readme/WorldVistA%2...

[JohnLeo Zimmer]

Sorry, Ignacio, it is NOT fixed.

From postinst:

# if a defaults file exists, then use those parameters instead of default.
echo "pwd: `pwd`"
if [ -f ./wv-rpm-defaults ]; then
 source ./wv-rpm-defaults
fi

GpZ

[I, Valdes]

JLZ, I'm puzzled as I show that it is definitely changed to astro-
defaults. Are you sure you downloaded and installed 0.8.2? It is
'barcoded' in the <instance>/bin/env file.

-- IV

On Nov 6, 1:05 pm, JohnLeo Zimmer <johnleo...@gmail.com> wrote:
> Sorry, Ignacio, it is NOT fixed.
>
> From postinst:
>
> # if a defaults file exists, then use those parameters instead of default.
> echo "pwd: `pwd`"
> if [ -f ./wv-rpm-defaults ]; then
>  source ./wv-rpm-defaults
> fi
>
> GpZ
>

[JohnLeo Zimmer]

I know I have something screwed up, but I'm not sure where.
I'm trying to dissect a .deb file, and a wire is crossed somewhere.

jl.z

[JohnLeo Zimmer]

Dear Ignacio,
OK, (as you know) I've been barking up the wrong tree.
I cleaned out my directories which had trash left from 0.8.1,
re-ran dpkg -e astronaut-wv-server-beta-0.8.2.deb,
and now I can see in postinst:

if [ -f ./astro-defaults ]; then

source ./astro-defaults

fi

But question:

Why ./astro-defaults, rather than just /astro-defaults? which would guarantee finding the file in root.

GpZ

just "checking for ticks".

[I, Valdes]

I'd have to re-test it to see if it breaks. BTW, we do have things up
in Launchpad if you want to roll your own... -- IV

On Nov 8, 6:48 am, JohnLeo Zimmer <johnleo...@gmail.com> wrote:
> Dear Ignacio,
> OK, (as you know) I've been barking up the wrong tree.
> I cleaned out my directories which had trash left from 0.8.1,
> re-ran dpkg -e astronaut-wv-server-beta-0.8.2.deb,
> and now I can see in postinst:
>
> if [ -f ./astro-defaults ]; then
>
> source ./astro-defaults
>
> fi
>
> But question:
>

> Why *./astro-defaults*, rather than just */astro-defaults*? which would

[Butch]

Ignacio,

IMHO, considering the progress and the speed at which you have
Astronaut moving, it would likely be ill advised for people to start
"rolling their own", unless it's to try and find the possible errors,
that people are having. It's better to support the programmer that is
actively working on the project. Although some more direct
collaboration would likely be beneficial.

JohnLeo,

I know that you use virtual machines for a lot of what you are doing.
Are you re-using the same virtual machine over and over? In my
experience I've found it's better to clone them, and use them for one
off testing, and then move to a new one when a new release comes out.
It's the easiest way to be sure you are starting with a fresh slate.
You may already know how to do it, but the quick and dirty way to do
it if your using VirtualBox is to create a new virtual machine,
however you want it configured, then clone the virtual disk:

user@comp$ > VBoxManage clonevdi

Then you can create a new virtual machine and use the cloned vdi file
for the hard disk. Every time you need a new one, clone the original,
make a new virt and away you go. When your done, either ignore it or
destroy it, depending on your storage and how much regression testing
your looking to be able to do. Hope this is useful to you.

--
Butch

[JohnLeo Zimmer]

Butch,

I am back home in Iowa after a month away. At the moment I am reconfiguring an old machine that has been a VistA server here in my basement. It's real, contaminated sand and other stuff. Other projects are resting, including my stable of virtual machines.

I just upgraded this box from Ubuntu server 8.04 to 9.10 without a hitch.

Not so simple to upgrade Astronaut. And that is what has sent me digging into the guts of the astronaut...deb. IMHO, the challenge of Astronaut is not how fast Ignatio can move it "forward". But, rather, how to make release x.x.x fully functional.

As far as "rolling my own", I think there is room for more species to evolve in this ecosystem. For example openvistaserver-1.5.sp2, installs with a little more hands on work than Astronaut. (It requires three .debs and a .zip.) But Jon Tai's install screencast makes it a piece of cake... even on Ubuntu server's command line.

Regards,
GpZ

Mostly just checking for ticks.

[I, Valdes]

Stay tuned JLZ :-) -- IV

On Nov 8, 12:49 pm, JohnLeo Zimmer <johnleo...@gmail.com> wrote:
> Butch,
>
> I am back home in Iowa after a month away. At the moment I am reconfiguring
> an old machine that has been a VistA server here in my basement. It's real,
> contaminated sand and other stuff. Other projects are resting, including my
> stable of virtual machines.
>
> I just upgraded this box from Ubuntu server 8.04 to 9.10 without a hitch.
>
> Not so simple to upgrade Astronaut. And that is what has sent me digging
> into the guts of the astronaut...deb. IMHO, the challenge of Astronaut is
> not how fast Ignatio can move it "forward". But, rather, how to make release
> x.x.x fully functional.
>
> As far as "rolling my own", I think there is room for more species to evolve
> in this ecosystem. For example openvistaserver-1.5.sp2, installs with a
> little more hands on work than Astronaut. (It requires three .debs and a
> .zip.) But Jon Tai's install screencast makes it a piece of cake... even on
> Ubuntu server's command line.
>
> Regards,
> GpZ
>
> Mostly just checking for ticks.
>

[Butch]

I'm kinda going all over the place with this reply, but I think it's
all relevant.

While I do agree that a more stable platform is needed, this is also
still beta software. As I understand it there is no upgrade path for
Astronaut as of the current release, but that is coming down the
pipeline. There is a lot of forward thinking that has gone into this,
and it's panning out rather quickly.

The real problem with "rolling our own" is not that there isn't room
for more species, quite the contrary. I've been working on the
installer for OpenSolaris, but it's quite literally being built as an
extension upon the Astronaut installer. I'm trying to help move it
forward, and at the same time make it portable to a completely
different platform. I'm doing the same with Medsphere's installer as
well. Anyone else who produces an installer I would try and do the
same for. (Some days I think it's harder to tear these things apart
than it is to put them together)

The problem that will inevitably manifest, is we will go from having
the Open VistA installer, Astronaut installer, and (lacking any clue
of what you might call it) Grandpa Z's VistA installer, to the above 3
plus a few more. I've seen more than one project start out like this,
fork several times, and then the whole project gets dropped in favor
of something else entirely. Mostly because the end user gets choice
over load, and doesn't know which direction to go. In the end it sets
the whole project back a step or two. Mayhap rolling our own, with
the established Astronaut code base, and comparing results with IV
should be considered.

I'm not saying that IV has the best installer or uses the best methods
(I'm not saying he doesn't either). I think that Ignacio has chosen
what he thought to be the best way of doing things, and he has
accomplished an astounding amount of work in a very short time. This
has produced a very rapid maturation of an installer, that should be
supported as much as possible. There isn't far to go before this
project could be labeled production ready, and have only bugfixes
going forward.

As a sys admin, to me the installer should only install the bare
minimum needed to be functional, GT.M, and VistA itself, possibly as a
single package, (but preferably separate) as long as the upgrade paths
don't interfere with each other. Having OVID as a separate package,
well thats a tough call, since it's potentially so useful, and
separating it starts leaning into choice overload. A good admin, wont
have a problem figuring out what to install but people just getting to
know the software probably will.

EWD and M2Web are great pieces of software, and the people who want to
use them should be able to install them separately, not have them
install by default. Another benefit of the modular approach is that
the upgrade path for individual packages becomes more manageable, and
troubleshooting becomes easier.

While Medsphere's method of doing things is more involved than using
Astronaut, they have the right idea for production software. Using
Medsphere's installer on rpm based distros is more involved than
Debian or Ubuntu, but it's still the method that almost any admin with
any experience is going to choose. In no small part because it
simplifies the troubleshooting process in test and production
environments.

Great progress has been made in making this software easy to install.
It's going to get a lot better, that's easy to see as well. More
focused collaboration on any given aspect of VistA is going to help
move things forward faster. There is a lot of fragmentation as far as
who is doing what, and not enough focus on collaboration on projects.
Groups of one or two people working on hundreds of different projects
slows progress. Owing almost entirely to a lack of coordination and
collaboration with other members of the community.

I know there are the tech calls, and developer meetings and such, yet
on the surface there is an apparent lack of forward movement. What I
mean by that, is most of the posts are questions about why this or
that aren't doing what they should be, and those questions get
answered or at least responded to, fairly quickly. What we don't hear
or see, is what is happening on the individual projects, or even what
projects are in the works, save for a couple of exceptions.

I'm not trying to scorn, bewail or bemoan any one in the community, I
know that a great many people are bustin there hump, trying to get
something done. My questions are things like: What projects are being
worked on? How far along are they? Whats missing? Aside from the
most obvious necessity ($money$) what kinds of things are needed to
help move VistA forward? Would a more centralized development
environment help? Would people benefit from being able to work on the
same systems no matter where they are? What tools are needed to help
with productivity? How many people are working on the different
projects on the same system, and seeing what problems are arising from
the co-development? There is a lot of progression testing, is there
any regression testing? Is it even necessary?

--
Butch

On Nov 8, 1:49 pm, JohnLeo Zimmer <johnleo...@gmail.com> wrote:
> Butch,
>
> I am back home in Iowa after a month away. At the moment I am reconfiguring
> an old machine that has been a VistA server here in my basement. It's real,
> contaminated sand and other stuff. Other projects are resting, including my
> stable of virtual machines.
>
> I just upgraded this box from Ubuntu server 8.04 to 9.10 without a hitch.
>
> Not so simple to upgrade Astronaut. And that is what has sent me digging
> into the guts of the astronaut...deb. IMHO, the challenge of Astronaut is
> not how fast Ignatio can move it "forward". But, rather, how to make release
> x.x.x fully functional.
>
> As far as "rolling my own", I think there is room for more species to evolve
> in this ecosystem. For example openvistaserver-1.5.sp2, installs with a
> little more hands on work than Astronaut. (It requires three .debs and a
> .zip.) But Jon Tai's install screencast makes it a piece of cake... even on
> Ubuntu server's command line.
>
> Regards,
> GpZ
>
> Mostly just checking for ticks.
>

[fred trotter]

As a sys admin, to me the installer should only install the bare
minimum needed to be functional, GT.M, and VistA itself, possibly as a
single package, (but preferably separate) as long as the upgrade paths
don't interfere with each other.  Having OVID as a separate package,
well thats a tough call, since it's potentially so useful, and
separating it starts leaning into choice overload.  A good admin, wont
have a problem figuring out what to install but people just getting to
know the software probably will.

EWD and M2Web are great pieces of software, and the people who want to
use them should be able to install them separately, not have them
install by default.  Another benefit of the modular approach is that
the upgrade path for individual packages becomes more manageable, and
troubleshooting becomes easier.

Ahh the classic debates. Are you a lumper or a splitter?

I have to say that Ignacio has done alot of thought about this and I think he has achieved the right balance.

The simple reality is that no one installs GTM without either A. wanting a working version of VistA or
B. Having some very specific other reason that has -nothing- to do with VistA.

Even a developer, who previously hacked MUMPS on VistA without having a fully working system, should see the benefit of at least trying to hack on a "working" version of the whole EHR.

Further, M2Web, EWD and OVID are only valuable to develop in, when you know with a reasonable level of certaintly that lots of people will have access to those development platforms. Keeping them pre-installed ensures that software developed with them can be deployed consistently, thus increasing the value in doing that kind of work.

So from the perspective of "VistA as a platform" (which btw should be the most important in this community, since it is -the- prerequisite for any kind of real success) lumping is the way to go.

Lumping also has the benifit of placing versioning issues entirely in the hands of the developer (i.e. Ignacio or Medsphere) rather than the administrator. In my view, it is worth giving administrators seperate packages, when doing so gives the administrator the ability to do something good and interesting by twiddling with package versions. In that case, you can still lump with meta-packages to get the typical effect of "I just want this all to work" , while giving super-duper-admins the ability to do interesting things. I believe that Medsphere will eventually go that route.

For Ignacio, as long as his work at reconciling VistA components is a one man show, I see no justification for splitting anything out. Someone else wrote a ewd rpm -for astronaut- (I understand) and I think in that case it is worth keeping things split. But -only- in the context of someone stepping up to contribute in that fashion.

In short I would advise Ignacio to refuse any requests to "split" his rpms or debs -unless- that request is paired with a seperate rpm or deb and a commitment for future maintence.

Is that the "right" way to do it from the admins standpoint? No, but the "rules of Unix administration" are designed to allow multiple servers to run on one operating system. So for instance if two servers make use of perl or mysql, it is tremendously valuable to have those packages seperatley versioned. Then you can think across many applications regarding version dependancies. However, VistA servers are carrier-grade applications that have totally unique dependancies. When you run a VistA server, you are not thinking "oh this is one of my many MUMPS/EWD/OVID/M2web applications, I better make sure I am getting the version mix right" You are thinking "I want to use VistA, I want everything just to work and I do not want to think about versions"

Lumping, one way or another, is the way to go for VistA.

-FT










 

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

[JohnLeo Zimmer]

I would point out that was Ignatio who brought up "roll your own", not GpZ. I am not interested in forking... so much as in understanding and debugging Astronaut. Learning to re-roll a .deb... or just to manually run the install can help with the "checking for ticks" process.

AND SO...
I still have a question about this construction in postinst:

if [ -f ./astro-defaults ]; then

source ./astro-defaults

fi

Why ./astro-defaults, rather than just /astro-defaults? which would guarantee finding the file in root.

GpZ
Just checking for ticks,
not trying to solve all of health care reform..

[I, Valdes]

The downside of email lists: when I said 'roll your own' I meant you
can try and test it on your own not fork it and I did not mean to
suggest that JLZ would even want to fork it. Fred and all: Astronaut
is not a one man show by any stretch, see Contributors in the Readme.
Am I 'idea manager and executor' of a distributed team of Astronauts?
Yes. Is it just me? No.

Sorry for the wasted energy.

Back to our regularly scheduled program.

-- IV

On Nov 9, 6:52 am, JohnLeo Zimmer <johnleo...@gmail.com> wrote:
> I would point out that was Ignatio who brought up "roll your own", not GpZ.
> I am not interested in forking... so much as in understanding and debugging
> Astronaut. Learning to re-roll a .deb... or just to manually run the install
> can help with the "checking for ticks" process.
>
> AND SO...
> I still have a question about this construction in postinst:
>
> if [ -f ./astro-defaults ]; then
>
> source ./astro-defaults
>
> fi
>

> Why *./astro-defaults*, rather than just */astro-defaults*? which would

> guarantee finding the file in root.
>
> GpZ
> Just checking for ticks,
> not trying to solve all of health care reform..
>

[Jonathan Tai]

On Sun, 2009-11-08 at 23:18 -0800, fred trotter wrote:

> Ahh the classic debates. Are you a lumper or a splitter?
>
> I have to say that Ignacio has done alot of thought about this and I
> think he has achieved the right balance.
>
> The simple reality is that no one installs GTM without either A.
> wanting a working version of VistA or
> B. Having some very specific other reason that has -nothing- to do
> with VistA.

That may be true, but I don't think that's a valid argument for lumping.
If anything, it's an argument for splitting -- there are two groups of
people, and the latter group may not want all of VistA installed just to
get GT.M! I think the point you're trying to make is that they wouldn't
use our installers since they have no interest in anything
VistA-related, but if we split instead of lump, the two groups could
collaborate on the common parts (GT.M).

We package GT.M independently of our OpenVista utilities, which are
independent of OpenVista. The EWD, M2Web, or OVID projects can build
packages for just EWD, M2Web, or OVID, then depend on the pre-existing
GT.M package. Even Astronaut, which installs all of the above, could be
made to do this. No more duplicated effort packaging GT.M when new
releases come out! And in the future, if FIS decides to ship an
official package, we could all just move over to that.

With some work on the WorldVista side, our OpenVista management
utilities could be used to install/manage WorldVista instances. Or
parallel tools specific to WorldVista could be written and packaged
that, again, depend on the same common components such as GT.M.

Our utilities depend on pre-existing packages on the system, such as
Apache and Munin. We don't have to worry about packaging that software,
keeping it up to date, or conflicts between our lumped version of
Apache/Munin and the Linux distro's version because we don't lump a
version in with our packages.

-- snip --

> So from the perspective of "VistA as a platform" (which btw should be
> the most important in this community, since it is -the- prerequisite
> for any kind of real success) lumping is the way to go.
>
> Lumping also has the benifit of placing versioning issues entirely in
> the hands of the developer (i.e. Ignacio or Medsphere) rather than the
> administrator.

What lumping does is place versioning issues entirely in the hands of
ONE developer. It does not allow for collaboration between packagers.

> For Ignacio, as long as his work at reconciling VistA components is a
> one man show, I see no justification for splitting anything out.
> Someone else wrote a ewd rpm -for astronaut- (I understand) and I
> think in that case it is worth keeping things split. But -only- in the
> context of someone stepping up to contribute in that fashion.

This is exactly *why* things should be split, so that people can focus
on packaging the parts they know, while being able to depend on others
for the parts they don't.

-- snip --

> Is that the "right" way to do it from the admins standpoint? No, but
> the "rules of Unix administration" are designed to allow multiple
> servers to run on one operating system. So for instance if two servers
> make use of perl or mysql, it is tremendously valuable to have those
> packages seperatley versioned. Then you can think across many
> applications regarding version dependancies. However, VistA servers
> are carrier-grade applications that have totally unique dependancies.
> When you run a VistA server, you are not thinking "oh this is one of
> my many MUMPS/EWD/OVID/M2web applications, I better make sure I am
> getting the version mix right" You are thinking "I want to use VistA,
> I want everything just to work and I do not want to think about
> versions"
>
> Lumping, one way or another, is the way to go for VistA.

Package dependencies sort out the versions for you, and well-built
packages and utilities will tolerate a range of compatible versions,
anyway. All of our packages have been independently upgrade-able since
the first alpha release.

The "version mix" is not an excuse to bundle everything together, and
there are benefits in splitting -- collaboration and reuse.

- Jon

[fred trotter]

good points.

-FT

[Jim Self]

Jonathan Tai wrote:

On Sun, 2009-11-08 at 23:18 -0800, fred trotter wrote:

  

Ahh the classic debates. Are you a lumper or a splitter? 

I have to say that Ignacio has done alot of thought about this and I
think he has achieved the right balance.

Astronaut is intereresting precisely because of the lumping. It makes it easier for all of us to access and learn about the VistA-related tools and development efforts that we don't already know in conjunction with the ones that we do. I, for one, have been interested in learning more about EWD and OpenVistA and the underpinnings and design of CPRS for quite some time, but had not done so due to the complications of installing them all together.

-- 

---------------------------------------
Jim Self (http://www.vmth.ucdavis.edu/us/jaself)
M2Web (enabling MUMPS-to-Web applications)
---------------------------------------

[Jonathan Tai]

On Mon, 2009-11-09 at 21:17 -0800, Jim Self wrote:
> Jonathan Tai wrote:
> > On Sun, 2009-11-08 at 23:18 -0800, fred trotter wrote:
> >
> >
> > > Ahh the classic debates. Are you a lumper or a splitter?
> > >
> > > I have to say that Ignacio has done alot of thought about this and I
> > > think he has achieved the right balance.
>
> Astronaut is intereresting precisely because of the lumping. It makes
> it easier for all of us to access and learn about the VistA-related
> tools and development efforts that we don't already know in
> conjunction with the ones that we do. I, for one, have been interested
> in learning more about EWD and OpenVistA and the underpinnings and
> design of CPRS for quite some time, but had not done so due to the
> complications of installing them all together.

Making things easy to install is certainly an admirable goal, but you
don't have to put multiple pieces of software in a single package to
make them easy to install together. You can put each piece of software
in its own package, then string them together with dependencies. For
people who really do want to install everything, you can provide a
metapackage that doesn't really install anything, but depends on a bunch
of real packages[1]. For example, most Linux distros have a "gnome" or
"desktop" metapackage that depends on the basic Gnome applications,
Firefox, OpenOffice.org, etc. A simple apt-get or yum install gnome
installs all of it at once. (And this is what your graphical Linux
installer does under the hood.)

Easy to install != everything in one package.

- Jon

[1] Suggested name for such a package: "astronaut"

[rtweed]

As I understand it, Mike Clayton's EWD installer for VistA makes it
easy to install on top of an existing VistA implementation. Currently
the installer is for Debian systems but I believe he is working on an
rpm alternative.

Rob

>  signature.asc
> < 1KViewDownload

[Butch]

Since none of the core packages are available from a "repo" as yet, it
would make sense to put all of the packages into a single tar ball,
including the meta-package. Then people who know exactly what they
want can install only those packages, or someone who wants everything,
can simply install the meta-package.

Although I think the meta-package shouldn't be created until Astronaut
has an upgrade path. Which knowing Ignacio isn't going to take long
at all.

Butch

[I, Valdes]

Hi Butch! The upgrade path convention proposal announcement is up:
http://astronautvista.com/news/veterans-affairs-vista-upgrade-convention-proposal-kids-toy
but so far little to no discussion or comment which I'll consider to
be a good thing? -- IV

[Butch]

2 things, I need an access code etc, to be able to comment ^_^. Also,
it seems that the only thing that is being addressed is the kids toys
(nice naming btw). My quick two cents on that, is you don't ever let
your system self patch. That process should ALWAYS be monitored by an
admin. I only speak in regards to the underlying OS, I don't know
enough about VistA to say one way or the other, but I would assume the
same principals apply.

On Nov 11, 4:20 pm, "I, Valdes" <ival...@hal-pc.org> wrote:
> Hi Butch! The upgrade path convention proposal announcement is up:http://astronautvista.com/news/veterans-affairs-vista-upgrade-convent...